l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2001 Dec 30 17:03

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] [john_zie_99@yahoo.com: help needed]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] [john_zie_99@yahoo.com: help needed]



On Thu, Apr 12, 2001 at 04:42:27PM -0700, Jan Wynholds wrote:

> I agree completely.  My "rule of thumb" with redhat is if they have
> released an alpha (platform) version, then it's stable enough to use
> in production environment.  Redhat 7.0 has no alpha version, but 6.2
> does have a good alpha version.  6.2 is the stable one (but get
> those updates).

For my part, I had to learn about Redhat 7.0 the hard way.  It's not a
good sign when you get a brand, spankin' new distro, and all of a
sudden things just won't compile.  I'd say C programs would compile
about 70% of the time, but anytime you have a sufficiently large or
complex program which had optimizations of some kind or another turned
on, I'd have to turn off the optimizations (after which, it'd compile
flawlessly).  C++ programs compiled about 30% of the time, regardless
of optimizations.  Very wierd internal compiler errors.

I appreciate that RedHat does a lot of work to make sure that their
RPM packages work seamlessly, but to expect RPMs to be the /only/ way
to install new software is unconscionable (whew!  Thank goodness for
ispell!), especially when compiling from source is a major reason why
I friggin' run Linux in the first place.

Yes, they did release patches for the broken gcc and the equally
broken glibc, but the patches are /still/ development versions
(actually, dunno about glibc - it really shouldn't be, because there
are newer stable versions of it now than the development version RH7.0
ships with).

I am happily using RedHat 7.0 now with no problems - because I
/ditched/ their gcc and glibc and am using gcc-2.95.2 (ships with
RH6.2) and glibc-2.2 (doesn't).  Yes, I compiled these with RedHat's
broken compiler first....  >:-]

Still, there are other things which are unstable - I note that the
dependency between emacs and ispell is mysteriously broken (haven't
bothered looking into fixing it - I mostly use the one here at work,
which works fine).

Can't wait 'til GCC 3.0 is finished (any month now...) - I have a copy
of ANSI C99 and can't wait to be able to take advantage of the new
features (and still be ANSI-compatible).


------------------------------
Among my favorite C99 features:
(Note that many of these have been in gcc in one form or another for
some time - they're just "official C" now...)

- Variable Length Arrays (VLAs)

Pete mentioned these a couple months back - various useful things you
can do with these, but basically, you can calculate the size of an
array at runtime.  Makes POSIX (or is it GNU?) alloca() kinda useless
(fine with me).

Example:

void some_dumb_function (size_t array_size, int array[array_size]);

or:

...
new_array_size = calculate_size_of_array ();

int array[ new_array_size ];
...

(Note that this also demonstrates another feature of C99 - you can
have declarations after statements in the same block.  This doesn't
work /exactly/ the same as C++, though...)


- Declarations in first part of a for() construct:

for (int i=0; i<99; i++)
  printf ("i: %d", i);


- Complex literals:

struct point
{
  unsigned int x;
  unsigned int y;
};

extern void drawline (struct point from_to[2]);

int main (void)
{
  drawline (
             (struct point []){ {64,20}, {324, 56} }
           );

  /* This could also be written:

  drawline (
             (struct point []){
               [1].y = 56,
               [1].x = 324,
               [0].y = 20,
               [0].x = 64
             }
           );

  return 0;
}

...  cool, huh?



- stdint.h types...

On implementations which provide the analogous types, we have:

int8_t, int16_t, int32_t, int64_t
uint8_t, uint16_t, uint32_t, int64_t

...so that you don't have to resort to unportable tactics, such as
assuming short is 16 bits, or that a char is 8 bits (not all machines
use 8-bit bytes).

Also:

int_least8_t, int_least16_t, etc.

so that, if you can't guarantee that the former types were available,
you can at least be sure that the sizes of the above are at /least/
the minimum size indicated...

And:

int_fast16_t, int_fast32_t, etc.

The fastest integer type that is at least those types, etc.

- Type-generic math:

Special math macros which automajically figure out the types of
arguments you are passing, and do the fastest calculation (ideally)
based on those types: for example...

#include <tgmath.h>

int main (void)
{
  float f1, f2, f3;
  double d1, d2, d3;
  long double ld1, ld2, ld3;
  double complex dc1, dc2, dc3; /* Yes, C99 added support for
                                   imaginary numbers and complex math! */

  f1 = pow (f2, f3); /* Same as calling powf() - uses floats
                        calculation */

  d1 = pow (d2, d3); /* Same as calling <math.h>'s pow() - uses doubles
                        calculation */

  ld1 = pow (ld2, ld3); /* Same as calling powl() - uses long doubles
                        calculation */

  dc1 = pow (dc2, dc3); /* Same as calling cpow() - uses complex numbers
                           calculation */

}

- Variadic funciton-like macros

#define foo(a, ...)   /* whatever... */

... type of stuff...



........and I'm just getting started!

Glibc apparently already has 100% C99 support; GCC 3.0 is supposed to
(and so alot of it is already in gcc 2.96 and gcc 2.97 - the one
reason why you might want to keep RH's gcc around...)

Sorry about the tangent...  but I can't wait!

Micah


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.