[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: g++272 libs, revisited.



> 
> As part of a homework assignment I've written a little program to do
> arithmetic with fractions and mixed numbers, and I wanted to benchmark the
> speed of various algorithms for finding 'gcd,' the greatest common divisor.
> Not knowing how to do the timing piece, I started playing with gettimeofday.
> Here's what I came up with:
> 
> #include <iomanip.h>
> #include <sys/time.h>
> 
> int main()
> {
>  struct timeval *ThisTime;
                  ^
There we have our elementary C programming error :)

>  struct timezone *huh = 0;
>  int i;
>  long int k;
>  i = gettimeofday(ThisTime, huh);
>  cout << i << endl;
>  k = ThisTime->tv_sec;
>  cout << k;
> }

You need to provide a pointer to a struct timeval, not a struct timeval
pointer that points to some random address.  The gettimeofday function
is part of the standard C library.  In C, there are no reference
arguments (like in C++), so there is no way a function can write an
address into a pointer argument.  Therefore you need to provide the
address of an existing variable, so

struct timeval tv;
int i;

i = gettimeofday(&tv, 0);

Then the function will write into the struct timeval tv.

The fact that the code doesn't crash under DJGPP is a coincidence.  In
fact, if code crashes with one compiler and runs fine with the other,
chances are high you have a memory allocation error lurking.  Your best
bet is then to check the code with the compiler that makes it crash!

Besides, the function you really need for timing CPU usage is `times'
(do a `man 2 times').  Moreover, there is the unix command time (or the
bash builtin version) that gives you the statistics you want.  Just type

time myprg

where `myprg' is your program, and you get the statistics.

> Aha sez I; I'll just whip the g++272 package onto the Debian box and be home
> free. Did that, but it won't compile, complaining of many errors in the
> headers, eg:

Don't do that.  The 2.7.2 compiler is not nearly as good as the standard
egcs g++ that debian2.0 has.

[...]

> Aha sez I; I don't have the libg++272-dev package on board - I'll just whip
> that onto the Debian machine and be home free. Tried that, but I can't install
> this package, just produce an dpkg error stating I already have libg++-2.8-dev
> and that there's a conflict wrt libg++-dev that's provided by the latter.

Just remove the 2.7.2 g++ stuff again.  You really should only need that
if you try to compile old stuff that relies on buggy `features'.

> I am most curious about:
> 
> 1) How to write a little timing routine for benchmarking.

As I said before, use times().  Make sure to #include <time.h> as well
as <sys/times.h>, and divide the values from times by CLK_TCK to
convert from clock tics to seconds (don't use CLOCKS_PER_SECS as is
suggested in the libc6-doc info file, this has the wrong value (by the
way, install libc6-doc and read it with `info libc', it contains
valuable information on unix programming)).

> 2) Why egcs can't build a working version of that piece of code.

Because there was a bug in it.  In general, you should suspect bugs in
your own code, before suspecting bugs in a compiler (speaking from
experience here :).

> 3) How to get g++272 happily cohabiting with egcs on my Debian installation.

This is possible, but you have no need for it.  It is not very
convenient to have two compilers on your system, and you don't want to
start relying on g++272, because it is far worse than the egcs g++
compiler.  In general, you want to use the compiler that gives you the
most errors, it will help you remove bugs from _your_ code.

End of lesson ;)

HTH,
Eric

-- 
 E.L. Meijer (tgakem@chem.tue.nl)          | tel. office +31 40 2472189
 Eindhoven Univ. of Technology             | tel. lab.   +31 40 2475032
 Lab. for Catalysis and Inorg. Chem. (TAK) | tel. fax    +31 40 2455054


Reply to: