Thread: Re: [Dev-C++] The new C99 Standard
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
dev-cpp-users
|
From: ropbert d b. <lon...@ju...> - 2001-01-03 11:53:52
|
Looks like you are right. Pile of JUNK!
lon...@ju...
On Tue, 2 Jan 2001 20:48:35 +0200 "Ioannis Vranos" <no...@ya...>
writes:
> Except of the long long type which corrupts compatibility with C89 &
> C++,
> and the _Bool type defined only in boolean.h (not built in type)
> which may
> or may not be stupid, there are a lot of fortran-style!!! stupid
> additions
> which corrupt compatibility with common sense and according to my
> opinion
> destroyed forever the language.
>
> Examples:
>
> 1) snprintf()
> 2) new formats for printf(). E.g. %ll for long long. We are used to
> %$d
> stuff for signed integers, where $ the integer type, so %ll is
> something you
> have to remember isolated.
>
>
> And now fasten your seabelt, "the great things" adopted by fortran:
>
> 3) int *p=(int []) {2, 4}
>
> It is something like a pointer pointing to an array where the first
> 2
> elements are 2, 4. Or something like that, i do not know and i do
> not want
> to know..
>
>
> 4) int (*q)[2]=(int[][2]) {{1,2}, {3,4}, {5,6}, {7, 8}};
>
> It is something an array of 2 pointers to functions accepting an
> int
> 2-dimensional array with default values?
>
>
> 5) drawline((struct point) {1, 2}, (struct point) {3, 4});
>
> It is a function accepting two *anonymous*(!) probably variable
> structs with
> default values?
>
>
> 6) drawline((struct point) {.y=2, .x=1}, (struct point) {.x=3,
> .y=});
>
> This creates 2 anonymous structs with those values. The structs and
> the
> values are created in there!!
>
>
> 7) int a[]={[2]=3, [1]=2, [0]=1};
>
> Translation: We create an array with the third element=3, the
> second=2, and
> the first=1. The same we used till nowadays as int a[]={1, 2, 3};
>
>
> 8) enum{ first, second};
>
> const char *nm[]={[second]="second", [first]="first",};
>
> Translation: The second element of the array gets the value "second"
> and the
> first the value "first".
>
> I wonder why the last comma (,) is used but perhaps it is a variable
> array
> or something.
>
>
> 9) int a[MAX]={1, 3, 5, [MAX-3]= 4, 2, 0};
>
> The "fortan-miracles" of the new standard: We give to the first 3
> elements
> of the array the values 1, 3, 5 and the 3 elements at the end the
> values 4,
> 2, and 0.
>
>
> 10) struct {int a[2], b}; x[]={[0].a = {1}, [1].a[0] = 2};
>
> I will try to translate this: We create an anonymous struct and then
> an
> array of it named x, with the first element taking the values:
> [0].a[0]=1 &
> [0].a[1]=1 both using the notation [0].a=1 , and the second elemet
> of the
> structure array x taking the value 1 at its first only array
> element:
>
> [1].a[0]=2
>
>
> 11)
>
> size_t fsize3(int n)
> {
> char b[n+3]; // Variable Length (Fortran-style) Array
> return sizeof b;
> }
>
> int main()
> {
> size_t size=fsize3(10); // 13
>
> return 0;
> }
>
>
> 12)
>
> void rowSum(int, int, int[*][*], int[*]);
>
> // ^^^^^^^^^ means variable length
> ...
>
> int a[5][6], b[5];
>
> rowSum(5, 6, a, b,);
>
> ...
>
> void rowSum(int n, int m, int in[n][m], int out[n])
>
> // ^^^^^^^^^ here we give names to the
> lengths
> {
> for(int i=0; i<n; i++)
> {
> int sum=0;
>
> for(j=0; j<m; j++)
> sum+=in[i][j];
>
> out[i]=sum;
> }
> }
>
>
> 13) Old Fortran trick:
>
> struct s { int n; double d[]; };
>
> struct s *s1=malloc(sizeof(struct s)+64);
>
> s1->d[0]=...
>
> Translation: We allocated space for the struct and 64 bytes for the
> double
> type array.
>
>
> 14) Exact width integers: int_least_8t (also 16, 32, 64)
> uint_least_8t (also 16, 32, 64)
>
> Fast minimum width integers: int_fast_8t (also 16, 32, 64)
> uint_fast_8t (also 16, 32, 64)
>
> Greatest width integers (the largest integer): intmax_t,
> uintmax_t.
>
>
> 15) restricted pointers. They assure that no other pointer points to
> the
> same data.
>
> There are many other changes too. I got all these from
> http://www.freshsources.com/dev/Forums/C99/
>
> Go and take a look there, it has a summary of the changes.
>
> I would like to see what the others (you) believe about these
> improvements.
>
>
> Ioannis
>
> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...]On Behalf Of
> James
> > Gordon
> > Sent: Tuesday, January 02, 2001 3:54 PM
> > To: 'dev...@li...'
> > Subject: RE: [Dev-C++] C99
> >
> >
> > For instance?
> >
> > Regards,
> >
> > James.
> >
> >
> >
> > -----Original Message-----
> > From: Ioannis Vranos [mailto:no...@ya...]
> > Sent: Saturday, December 30, 2000 12:17 PM
> > To: Dev-C++
> > Subject: [Dev-C++] C99
> >
> >
> > Talking about C, has anybody in here realized what crap has been
> > introduced
> > in C, in C99 standard? The language has been totally ruined. Now
> i
> > completely understand why K&R will not write a new book.
> >
> >
> > Ioannis
> >
> > * Ioannis Vranos
> > * Programming pages: http://members.nbci.com/noicys
> > <http://members.nbci.com/noicys>
> > * Alternative URL: http://run.to/noicys <http://run.to/noicys>
> >
> >
> >
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> *
> > This electronic message and any attachment is intended to be
> > read by the named addressee(s) only.
> > Any other recipient should be aware that its contents may be
> > legally privileged and/or confidential and that its use,
> > disclosure, copying or distribution may be unlawful.
> > Unless you are a named addressee, please delete this message
> >
> > Whilst C. & J. Clark International Limited has taken steps
> > to prevent the transmission of computer viruses with electronic
> mail,
> > responsibility for screening incoming messages and the risk of
> such
> > transmission and its consequences lies with the recipient.
> >
> > C. & J. Clark International Limited
> > Registered in England and Wales
> > Company No. 141015
> > Registered Office: 40 High Street, Street, Somerset BA16 0YA
> > Telephone: +44 (0) 1458 443131
> > Fax: +44 (0) 1458 447547
> >
> >
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dev-cpp-users
> >
>
>
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> http://lists.sourceforge.net/mailman/listinfo/dev-cpp-users
>
|
|
From: James G. <Jam...@Cl...> - 2001-01-04 16:08:56
|
I don't really see what the problem is. Most of it merely adds new
functionality or allows things that developers want to do be done in the
language rather than rolling your own.
I don't think it breaks much, if anything.
e.g. bool is only define if you include the header, which you would only do
as part of an upgrade/re-write.
If you can define variables as being sized at runtime than e.g. char
ms[b+3]; than that's good, isn't it?
The %ll etc. in snprintf is additional functionality, won't break existing
code and might make new code easier to write.
New types, no problem there?
Elastic structures, well I could of used that years ago.
Designators, seems good to me, creating temporary objects in the function
call saves having an object on the stack for the lifetime of the function
just to pass it to one function.
iso646, again, doesn't break code merely help in the readability.
Regards,
James.
-----Original Message-----
From: ropbert d baugh [mailto:lon...@ju...]
Sent: Tuesday, January 02, 2001 10:44 PM
To: dev...@li...
Subject: Re: [Dev-C++] The new C99 Standard
Looks like you are right. Pile of JUNK!
lon...@ju...
On Tue, 2 Jan 2001 20:48:35 +0200 "Ioannis Vranos" <no...@ya...>
writes:
> Except of the long long type which corrupts compatibility with C89 &
> C++,
> and the _Bool type defined only in boolean.h (not built in type)
> which may
> or may not be stupid, there are a lot of fortran-style!!! stupid
> additions
> which corrupt compatibility with common sense and according to my
> opinion
> destroyed forever the language.
>
> Examples:
>
> 1) snprintf()
> 2) new formats for printf(). E.g. %ll for long long. We are used to
> %$d
> stuff for signed integers, where $ the integer type, so %ll is
> something you
> have to remember isolated.
>
>
> And now fasten your seabelt, "the great things" adopted by fortran:
>
> 3) int *p=(int []) {2, 4}
>
> It is something like a pointer pointing to an array where the first
> 2
> elements are 2, 4. Or something like that, i do not know and i do
> not want
> to know..
>
>
> 4) int (*q)[2]=(int[][2]) {{1,2}, {3,4}, {5,6}, {7, 8}};
>
> It is something an array of 2 pointers to functions accepting an
> int
> 2-dimensional array with default values?
>
>
> 5) drawline((struct point) {1, 2}, (struct point) {3, 4});
>
> It is a function accepting two *anonymous*(!) probably variable
> structs with
> default values?
>
>
> 6) drawline((struct point) {.y=2, .x=1}, (struct point) {.x=3,
> .y=});
>
> This creates 2 anonymous structs with those values. The structs and
> the
> values are created in there!!
>
>
> 7) int a[]={[2]=3, [1]=2, [0]=1};
>
> Translation: We create an array with the third element=3, the
> second=2, and
> the first=1. The same we used till nowadays as int a[]={1, 2, 3};
>
>
> 8) enum{ first, second};
>
> const char *nm[]={[second]="second", [first]="first",};
>
> Translation: The second element of the array gets the value "second"
> and the
> first the value "first".
>
> I wonder why the last comma (,) is used but perhaps it is a variable
> array
> or something.
>
>
> 9) int a[MAX]={1, 3, 5, [MAX-3]= 4, 2, 0};
>
> The "fortan-miracles" of the new standard: We give to the first 3
> elements
> of the array the values 1, 3, 5 and the 3 elements at the end the
> values 4,
> 2, and 0.
>
>
> 10) struct {int a[2], b}; x[]={[0].a = {1}, [1].a[0] = 2};
>
> I will try to translate this: We create an anonymous struct and then
> an
> array of it named x, with the first element taking the values:
> [0].a[0]=1 &
> [0].a[1]=1 both using the notation [0].a=1 , and the second elemet
> of the
> structure array x taking the value 1 at its first only array
> element:
>
> [1].a[0]=2
>
>
> 11)
>
> size_t fsize3(int n)
> {
> char b[n+3]; // Variable Length (Fortran-style) Array
> return sizeof b;
> }
>
> int main()
> {
> size_t size=fsize3(10); // 13
>
> return 0;
> }
>
>
> 12)
>
> void rowSum(int, int, int[*][*], int[*]);
>
> // ^^^^^^^^^ means variable length
> ...
>
> int a[5][6], b[5];
>
> rowSum(5, 6, a, b,);
>
> ...
>
> void rowSum(int n, int m, int in[n][m], int out[n])
>
> // ^^^^^^^^^ here we give names to the
> lengths
> {
> for(int i=0; i<n; i++)
> {
> int sum=0;
>
> for(j=0; j<m; j++)
> sum+=in[i][j];
>
> out[i]=sum;
> }
> }
>
>
> 13) Old Fortran trick:
>
> struct s { int n; double d[]; };
>
> struct s *s1=malloc(sizeof(struct s)+64);
>
> s1->d[0]=...
>
> Translation: We allocated space for the struct and 64 bytes for the
> double
> type array.
>
>
> 14) Exact width integers: int_least_8t (also 16, 32, 64)
> uint_least_8t (also 16, 32, 64)
>
> Fast minimum width integers: int_fast_8t (also 16, 32, 64)
> uint_fast_8t (also 16, 32, 64)
>
> Greatest width integers (the largest integer): intmax_t,
> uintmax_t.
>
>
> 15) restricted pointers. They assure that no other pointer points to
> the
> same data.
>
> There are many other changes too. I got all these from
> http://www.freshsources.com/dev/Forums/C99/
>
> Go and take a look there, it has a summary of the changes.
>
> I would like to see what the others (you) believe about these
> improvements.
>
>
> Ioannis
>
> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...]On Behalf Of
> James
> > Gordon
> > Sent: Tuesday, January 02, 2001 3:54 PM
> > To: 'dev...@li...'
> > Subject: RE: [Dev-C++] C99
> >
> >
> > For instance?
> >
> > Regards,
> >
> > James.
> >
> >
> >
> > -----Original Message-----
> > From: Ioannis Vranos [mailto:no...@ya...]
> > Sent: Saturday, December 30, 2000 12:17 PM
> > To: Dev-C++
> > Subject: [Dev-C++] C99
> >
> >
> > Talking about C, has anybody in here realized what crap has been
> > introduced
> > in C, in C99 standard? The language has been totally ruined. Now
> i
> > completely understand why K&R will not write a new book.
> >
> >
> > Ioannis
> >
> > * Ioannis Vranos
> > * Programming pages: http://members.nbci.com/noicys
> > <http://members.nbci.com/noicys>
> > * Alternative URL: http://run.to/noicys <http://run.to/noicys>
> >
> >
> >
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> *
> > This electronic message and any attachment is intended to be
> > read by the named addressee(s) only.
> > Any other recipient should be aware that its contents may be
> > legally privileged and/or confidential and that its use,
> > disclosure, copying or distribution may be unlawful.
> > Unless you are a named addressee, please delete this message
> >
> > Whilst C. & J. Clark International Limited has taken steps
> > to prevent the transmission of computer viruses with electronic
> mail,
> > responsibility for screening incoming messages and the risk of
> such
> > transmission and its consequences lies with the recipient.
> >
> > C. & J. Clark International Limited
> > Registered in England and Wales
> > Company No. 141015
> > Registered Office: 40 High Street, Street, Somerset BA16 0YA
> > Telephone: +44 (0) 1458 443131
> > Fax: +44 (0) 1458 447547
> >
> >
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dev-cpp-users
> >
>
>
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> http://lists.sourceforge.net/mailman/listinfo/dev-cpp-users
>
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
http://lists.sourceforge.net/mailman/listinfo/dev-cpp-users
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This electronic message and any attachment is intended to be
read by the named addressee(s) only.
Any other recipient should be aware that its contents may be
legally privileged and/or confidential and that its use,
disclosure, copying or distribution may be unlawful.
Unless you are a named addressee, please delete this message
Whilst C. & J. Clark International Limited has taken steps
to prevent the transmission of computer viruses with electronic mail,
responsibility for screening incoming messages and the risk of such
transmission and its consequences lies with the recipient.
C. & J. Clark International Limited
Registered in England and Wales
Company No. 141015
Registered Office: 40 High Street, Street, Somerset BA16 0YA
Telephone: +44 (0) 1458 443131
Fax: +44 (0) 1458 447547
|
|
From: Ioannis V. <no...@ya...> - 2001-01-04 18:57:50
|
Do you find this kind of stuff:
drawline((struct point) {.y=2, .x=1}, (struct point) {.x=3, .y=});
int a[]={[2]=3, [1]=2, [0]=1};
enum{ first, second};
const char *nm[]={[second]="second", [first]="first",};
struct {int a[2], b}; x[]={[0].a = {1}, [1].a[0] = 2};
as missing and recommended additions, that is, there was no other way of
doing this? C's power has been for years the fact that it was small, yet
versatile enough to do anything. The only useful and needed addition was
that of restricted pointers. The rest of the "improvements" are bloated
features without providing any easier way to do things already be done. long
long type corrupts compatibility with the previous standard and C++. Aside
of C++, the previous standard considered long as the bigger integral type,
and all programs written then were asssuming long as the biggest integral
type. We could live for years without bool defined in stdbool.h . I imagine
the bool improvement is something like:
stdbool.h:
enum bool{FALSE, TRUE};
what an improvement!
All these bloated language extensions (and long long corrupting
compatibility wiith the previous C and existing C++ standards) show the
following things:
a) Most in the committee were fortran programmers or were bored to vote
negatively, or were too friendly with one another and did not want to create
bad feelings.
b) "New" C is bloated with unuseful new complementary features much like the
pascal things write, writeln...
c) Basic issues were not covered. Type safety mechanisms were not
introduced, better code management mechanisms such as C++ namespaces were
not adopted. These are better things to adopt than things from fortran.
Conclusion: No any new benefits (except of the restrict pointers and perhaps
the variable sized arrays although the second was accessible via realloc()),
and yet one has to learn a lot more things so as to be credited to say that
he knows the whole C language.
Of course this is my personal opinion which will not change facts after all.
:) Just mentioning my opinion. I think that the new standard brings much
trouble to the viability of the language.
Ioannis
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...]On Behalf Of James
> Gordon
> Sent: Thursday, January 04, 2001 6:06 PM
> To: 'dev...@li...'
> Subject: RE: [Dev-C++] The new C99 Standard
>
>
> I don't really see what the problem is. Most of it merely adds new
> functionality or allows things that developers want to do be done in the
> language rather than rolling your own.
>
> I don't think it breaks much, if anything.
>
> e.g. bool is only define if you include the header, which you
> would only do
> as part of an upgrade/re-write.
>
> If you can define variables as being sized at runtime than e.g. char
> ms[b+3]; than that's good, isn't it?
>
> The %ll etc. in snprintf is additional functionality, won't break existing
> code and might make new code easier to write.
>
> New types, no problem there?
>
> Elastic structures, well I could of used that years ago.
>
> Designators, seems good to me, creating temporary objects in the function
> call saves having an object on the stack for the lifetime of the function
> just to pass it to one function.
>
> iso646, again, doesn't break code merely help in the readability.
>
> Regards,
>
> James.
|
|
From: James G. <Jam...@Cl...> - 2001-01-05 08:43:08
|
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.
Why does long long corrupt existing code?
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.
-----Original Message-----
From: Ioannis Vranos [mailto:no...@ya...]
Sent: Thursday, January 04, 2001 6:59 PM
To: dev...@li...
Subject: RE: [Dev-C++] The new C99 Standard
Do you find this kind of stuff:
drawline((struct point) {.y=2, .x=1}, (struct point) {.x=3, .y=});
int a[]={[2]=3, [1]=2, [0]=1};
enum{ first, second};
const char *nm[]={[second]="second", [first]="first",};
struct {int a[2], b}; x[]={[0].a = {1}, [1].a[0] = 2};
as missing and recommended additions, that is, there was no other way of
doing this? C's power has been for years the fact that it was small, yet
versatile enough to do anything. The only useful and needed addition was
that of restricted pointers. The rest of the "improvements" are bloated
features without providing any easier way to do things already be done. long
long type corrupts compatibility with the previous standard and C++. Aside
of C++, the previous standard considered long as the bigger integral type,
and all programs written then were asssuming long as the biggest integral
type. We could live for years without bool defined in stdbool.h . I imagine
the bool improvement is something like:
stdbool.h:
enum bool{FALSE, TRUE};
what an improvement!
All these bloated language extensions (and long long corrupting
compatibility wiith the previous C and existing C++ standards) show the
following things:
a) Most in the committee were fortran programmers or were bored to vote
negatively, or were too friendly with one another and did not want to create
bad feelings.
b) "New" C is bloated with unuseful new complementary features much like the
pascal things write, writeln...
c) Basic issues were not covered. Type safety mechanisms were not
introduced, better code management mechanisms such as C++ namespaces were
not adopted. These are better things to adopt than things from fortran.
Conclusion: No any new benefits (except of the restrict pointers and perhaps
the variable sized arrays although the second was accessible via realloc()),
and yet one has to learn a lot more things so as to be credited to say that
he knows the whole C language.
Of course this is my personal opinion which will not change facts after all.
:) Just mentioning my opinion. I think that the new standard brings much
trouble to the viability of the language.
Ioannis
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...]On Behalf Of James
> Gordon
> Sent: Thursday, January 04, 2001 6:06 PM
> To: 'dev...@li...'
> Subject: RE: [Dev-C++] The new C99 Standard
>
>
> I don't really see what the problem is. Most of it merely adds new
> functionality or allows things that developers want to do be done in the
> language rather than rolling your own.
>
> I don't think it breaks much, if anything.
>
> e.g. bool is only define if you include the header, which you
> would only do
> as part of an upgrade/re-write.
>
> If you can define variables as being sized at runtime than e.g. char
> ms[b+3]; than that's good, isn't it?
>
> The %ll etc. in snprintf is additional functionality, won't break existing
> code and might make new code easier to write.
>
> New types, no problem there?
>
> Elastic structures, well I could of used that years ago.
>
> Designators, seems good to me, creating temporary objects in the function
> call saves having an object on the stack for the lifetime of the function
> just to pass it to one function.
>
> iso646, again, doesn't break code merely help in the readability.
>
> Regards,
>
> James.
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
http://lists.sourceforge.net/mailman/listinfo/dev-cpp-users
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This electronic message and any attachment is intended to be
read by the named addressee(s) only.
Any other recipient should be aware that its contents may be
legally privileged and/or confidential and that its use,
disclosure, copying or distribution may be unlawful.
Unless you are a named addressee, please delete this message
Whilst C. & J. Clark International Limited has taken steps
to prevent the transmission of computer viruses with electronic mail,
responsibility for screening incoming messages and the risk of such
transmission and its consequences lies with the recipient.
C. & J. Clark International Limited
Registered in England and Wales
Company No. 141015
Registered Office: 40 High Street, Street, Somerset BA16 0YA
Telephone: +44 (0) 1458 443131
Fax: +44 (0) 1458 447547
|
|
From: Ioannis V. <no...@ya...> - 2001-01-05 10:00:59
|
> -----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
|
|
From: Chad S. <ho...@ho...> - 2001-01-05 16:24:53
|
>From: "Ioannis Vranos" <no...@ya...>
>Reply-To: dev...@li...
>To: <dev...@li...>
>Subject: RE: [Dev-C++] The new C99 Standard
>Date: Fri, 5 Jan 2001 12:02:38 +0200
>
> > -----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):
But the size of a long didn't change with this standard. It simply allows
new code to specify exactly how much memory should be used for a particular
variable. A long is still the same size as it always has been, and as such
existing code won't "break" because new data types were introduced. The
whole reason for the new data types is probably due to the fact that pretty
soon processors will be optimised for 64 bit computations, and as such, the
int will go from being 32 bits to being 64 bits, and that could cause
programs written on these new platforms to be uncompileable on 32 bit
platforms if the writer of the program made assumtions about the size of an
int. This way there is no abiguity as to how much space a certain varaible
needs to utilize in order for the program to run properly. It also prevents
massive code rewrites in those cases.
I guess my point it that adding new data types doesn't in any way change
existing functionality, so I don't see where your claim that the C99
standards breaks compatibility has much of a leg to stand on.
Chad Simmons
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
|
|
From: Ioannis V. <no...@ya...> - 2001-01-05 18:32:33
|
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...]On Behalf Of Chad
> Simmons
> Sent: Friday, January 05, 2001 6:25 PM
> To: dev...@li...
> Subject: RE: [Dev-C++] The new C99 Standard
> I guess my point it that adding new data types doesn't in any way change
> existing functionality, so I don't see where your claim that the C99
> standards breaks compatibility has much of a leg to stand on.
>
> Chad Simmons
:) This is my last message concerning the matter since i am starting to feel
the anger of the others. long was the largest integer supported by the C89.
The standard did not define a size, only the fact that
sizeof(int)<=sizeof(long).
When writing portable code on any platform, the assumption that long is the
largest integer value supported was made. Now this has changed and the most
code must be changed.
Also the need for "100" more integer types did not exist. The introduction
of system specific integers breaks the generality of the language. It is
system vendor's job to provide platform extensions. When i write C code i
expect it to run unchanged from Pentium IV to PDP-11 in the local museum.
Except of these incompatibilites, adddition of more features doing the same
job as existing ones (in the style write, writeln, e.t.c. of Pascal)
increases the weight of the language without adding any new benefit.
E.g.. int a[]={[2]=1, [1]=0, [0]=7};
which is equivallent of always existing int a[]={7,0,1};
Ioannis
|
|
From: Chad S. <ho...@ho...> - 2001-01-05 18:50:23
|
>From: "Ioannis Vranos" <no...@ya...>
>Reply-To: dev...@li...
>To: <dev...@li...>
>Subject: RE: [Dev-C++] The new C99 Standard
>Date: Fri, 5 Jan 2001 20:34:14 +0200
>
>:) This is my last message concerning the matter since i am starting to
>feel the anger of the others. long was the largest integer supported by the
>C89. The standard did not define a size, only the fact that
>sizeof(int)<=sizeof(long).
>
>When writing portable code on any platform, the assumption that long is the
>largest integer value supported was made. Now this has changed and the most
>code must be changed.
Wrong. No code need be changed, because they didn't change the specification
of int or long, so the assertion you made that
sizeof(int) <= sizeof(long) will still be true even will compilers following
the new standard.
>Also the need for "100" more integer types did not exist. The introduction
>of system specific integers breaks the generality of the language. It is
>system vendor's job to provide platform extensions. When i write C code i
>expect it to run unchanged from Pentium IV to PDP-11 in the local museum.
This is the point I'm trying to stress. Since no changes where made to any
existing data types there need be no changes to code that uses the existing
data types. All that C99 does is introduce new data types that allow
programmers to more specifically specify at least how large a particular int
variable should be independant of the platform. I see this as a big
advantage, because it enables me to write (for example) a bitfield which
utalizes 64 bits, and will not requre that I change the data type depending
on what platform I'm running it on. I can use the int64 (or whatever the new
spec calls it) and I am then assured that even if my software is compiled on
32 bit architecture the size of that field will still accomodate all 64
bits.
>
>E.g.. int a[]={[2]=1, [1]=0, [0]=7};
>
>which is equivallent of always existing int a[]={7,0,1};
I agree that in this particular example nothing much is gained by the new
(as you say FORTRAN-like) intitialization scheme. However, nothing was lost
either. So on that issue I don't really have any strong feelings one way or
the other. I will most likely continue to initialize my structs and arrays
according to the old standard since I'm personally more used to seeing it
that way, but I don't understand why you are so opposed to them since they
really won't affect you unless you use them. (Or work with someone who
does.)
Chad Simmons
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
|
