RE: [Dev-C++] The new C99 Standard

[Ioannis V. <no...@ya...>]

> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...]On Behalf Of James
> Gordon
> Sent: Friday, January 05, 2001 10:40 AM
> To: 'dev...@li...'
> Subject: RE: [Dev-C++] The new C99 Standard
>
>
> Taking the example
>
> drawline((struct point) {.y=2, .x=1}, (struct point) {.x=3, .y=1});
>
> Is easier than
>
> {
> struct point mypoint1, mypoint2;
> mypoint1.y = 2;
> mypoint1.x = 1;
> mypoint2.y = 3;
> mypoint2.x = 1;
> drawline(mypoint1, mypoint2);
> ... 100's of lines later
> } <- Now mypoint1 & 2 are destroyed.
>

Do you find these:

struct {int a[2], b}; x[]={[0].a = {1}, [1].a[0] = 2};


 struct s { int n; double d[]; };
------------------------------------

 struct s *s1=malloc(sizeof(struct s)+64); //64 is for the d[]
 s1->d[0]=...

as badly needed too?

> Why does long long corrupt existing code?

:))
Because the previous standard assumed long as the biggest integer and
programs were written with that in mind. Obviously we have different
opinions on the matter but is long long the biggest integer? Do not forget
that more integers were introduced (breaking further the compatibility):

http://www.freshsources.com/dev/Forums/C99/sld014.htm (please take a look at
it)

I guess that the biggest integer is intmax_t.


>
> I'm sure that the committee try only to make changes which doesn't break
> existing code, as does the C++ committee not change things that
> might break
> existing C code when using a compliant C++ compiler.
>
> As to the bool thing. Well people have been doing that sort of thing for
> years. I started by using #define's and then moved onto enum's
> later on. So
> they've move that code into the standard, big deal. Old code can still use
> the hand crafted stuff. New code can make use of the new header.
>
> as to
> >b) "New" C is bloated with unuseful new complementary features much like
> the pascal things write, writeln...
>
> Well they probably said that to the C89 standard. 'It's just code bloat',
> etc.
> Isn't that what a standard is for, to evolve and take things that
> everybody
> has had to do by hand and incorporate into the standard to make things
> easier?
>
> They must have a hard job to improve the standard but still not break
> existing code if at all possible. Not the sort of job I'd like to do.
>
> Regards,
>
> James.

As i said, we simply disagree. :)


Ioannis