🔒 Locked

C vs. C++

Started by null_pointer Jul 21, 2002 at 8:30 AM 62 replies 3.9k views

Original Post

Jul 21, 2002 at 8:30 AM

Well, if you were expecting a flame war you will be disappointed.

I stumbled across this article and it really seems to put a different perspective on the matter. What do you think should be done about the incompatibilities between C and C++? Personally, I like the suggestion at the end as it seems the most logical choice. Throughout the years, it has frequently been the case that one of the two languages acquires features that would be of equally good use in the other language. The other language always ends up borrowing such features anyway, often several years down the road. The borrowing works both ways. If both languages were merged such that they shared the same language definition for common features, many people would benefit from simpler compilers and better libraries. Imagine being able to compile standards-compliant C source code on any C++ compiler without modifications or special considerations! Naturally, both languages would have to adjust, but I think the result would be well worth the effort. What do you think? P.S. Please read the article thoroughly before replying. And no flame wars!

LessBread

Jul 21, 2002 at 9:27 AM

That sounds reasonable. There''s been some similar discussions at comp.std.c lately involving this question, but the standards committees for both languages seem to enjoy having fiefdoms...

null_pointer

Jul 22, 2002 at 7:19 PM

Man, I gotta choose better titles.

Shannon Barber

Jul 22, 2002 at 9:43 PM

LessBread

Jul 22, 2002 at 10:13 PM

quote:
Original post by null_pointer
Man, I gotta choose better titles.

Lol!

How ''bout,
"C & C++: Compare & Contrast"
"C & C++: Spec Compatabilities"
"C & C++: Incompatabilities"
"C & C++: Raproachment Possibilities"

The conversation at comp.std.c involved some of the members of the English contingent of the standards committee. One of their major concerns/fears is that should the two languages be brought into strict conformity, then C users would end up marginalized and would likely split off anyways. I''m not so certain of that.

One thing I don''t like is refering to C as a "subset" of C++ as this suggests that C devolved from C++. I prefer instead to say that C++ is a superset of C as that suggests something much closer to the historical truth of the matter. I found Bjarne''s overlapping language domain graphs from that article rather interesting, and the nightmare scenario, well, rather nightmarish!

Magmai, are there specific things about the C99 spec that you don''t like? I''d like to hear what they are, not to argue them, but to take them under consideration.

Shannon Barber

Jul 23, 2002 at 2:05 AM

I can''t see many in the C crowd wanting the features they added - if they did, they''d be using C++.

They should have focused on the libraries - portable threading, UI widgets, etc... or additional low-level constructs (which could be added to C++0x more-or-less transparently).

I think efforts towards higher-level constructs should focus on C++, and the lower-level ones on C (standardized interrupt handling, ALU operations with carry, etc...).

Otherwise we''re just going to end up with two (or more) different syntaxes that do precisely the same thing.

Some things are useful, like the new preprocessor macros, but I think the dynamic-sized-array stuff is a mistake. It adds needless complexity the language, for a problem that''s already solved (make a struct, make a class, or make a template).

Null and Void

Jul 23, 2002 at 2:12 AM

quote:
Original post by Magmai Kai Holmlor
I can''t see many in the C crowd wanting the features they added - if they did, they''d be using C++.

Some of the C99 things that I like: the addition of ''long longs'' (although, I think a method of having integer types with a size specified in chars would be nice, and a header with some macros to see if a specific size is supported or not), inline functions, and the method for having a variable number of paramters for macros. I can''t think of any other C99 features that I pay attention to and like at the moment.

quote:
Original post by Magmai Kai Holmlor
Some things are useful, like the new preprocessor macros, but I think the dynamic-sized-array stuff is a mistake. It adds needless complexity the language, for a problem that''s already solved (make a struct, make a class, or make a template).

Yes, that''s one of the features of C99 that I don''t think was a good idea.

LessBread

Jul 23, 2002 at 4:10 AM

Adding support for forward slash comments was a good addition as was loosening the restrictions on variable declarations. "for(int i=0;..." is and improvement I think. As for variable arrays, I never use them. I think they were added with the idea that they would make it easier for coders too fearful to mess with malloc, calloc and realloc. The new types, "long long" etc, appear to be a means for accomodating more powerful cpu''s and the like without "forcing" coders to forget everything they used to know about data types. Inline functions are a nice addition too, but having them declared in headers wreaks a terrible havoc - but that''s more an MS problem than a C99 spec problem, at least it seems that way to me. To my knowledge there aren''t any compilers fully compliant with the C99 spec, so even compiler writers aren''t completely happy with the spec either.

null_pointer

Jul 23, 2002 at 8:08 PM

quote:
Original post by Less Bread

The conversation at comp.std.c involved some of the members of the English contingent of the standards committee. One of their major concerns/fears is that should the two languages be brought into strict conformity, then C users would end up marginalized and would likely split off anyways. I''m not so certain of that.

Me either. Stroustrop has been very adamant about retaining the lower-level features of C++ and while the syntax has changed somewhat, the C++ language definition has arguably equal powerful low-level code to C. I don''t see him dropping ANY of C''s useful features in the next 20 years.

quote:
Original post by Less Bread

One thing I don''t like is refering to C as a "subset" of C++ as this suggests that C devolved from C++. I prefer instead to say that C++ is a superset of C as that suggests something much closer to the historical truth of the matter.

Well, subset and superset are just terms, like "integers" is a subject of "reals"...er, maybe I should have picked a better example. Anyway, the set terminology doesn''t bear any meaningful relation to the history of the matter. C++ borrowed elements from C, Smalltalk, Algol, and other languages; it also has elements that are unique, and some elements of C were actually borrowed back from C++.

quote:
Original post by Null and Void

Some of the C99 things that I like: the addition of ''long longs'' (although, I think a method of having integer types with a size specified in chars would be nice, and a header with some macros to see if a specific size is supported or not)

I already have a header like that. (How can one write portable code without such a header?) In fact, I use a whole slew of headers that detect the compiler, compiler version, supported platform, CPU architecture, detect the existance of various language features, etc. These can simply be included in the precompiled header and then be used project-wide. Write once, reuse.

As for long long''s, they just seemed like a bandaid type solution to me. The real problem is that programmers have assumed that the basic types have fixed sizes that are guaranteed to be the same on all platforms. They litter their code with longs, shorts, bit operations, and other non-portable things, instead of localizing all the non-portable code into one place and presenting a nice portable interface for it.

What will happen when programmers switch to 128-bit platforms? and 256-bit platforms?

  
char c;
short s;
long l;
long long ll;
long long long lll;
longedy longy long long llll; // eek!

long long just reinforces the faulty logic that caused the problem in the first place.

Personally, I think that introducing sized types into the language would be nice, but it might also exasperate the problem. Seeing as how it can be fixed with a relatively small header, it isn''t so terribly necessary. Having to write a header is just enough work to keep people from throwing uint16 all over their code and yet not enough work to make it a serious deficiency in the language.

quote:
Original post by Null and Void

I can''t think of any other C99 features that I pay attention to and like at the moment.

I think there''s some kind of fortran-like keyword to specify that the memory regions of two pointers does not overlap. This supposedly allows the compiler to perform better optimization for certain algorithms, but this topic isn''t exactly my strong suit so I can''t say how useful it is.

I think that two very useful things that could be added to the hypothetical new C/C++ language are: 1) forcing vector to store its elements contiguously, and 2) the addition of a "finally" keyword for exception-handling.

Does anyone have any other features they might find useful? Or perhaps people would like to discuss the problems that might result from a "merger"?

For example, what about the type system - C++ has stronger typing and, of course, the special casting operators. Should C++ have weaker typing, should C have stronger typing, or should both meet halfway? Should the C cast syntax be thrown out in favor of the cast operators, or should both be perfectly acceptable?

null_pointer

Jul 23, 2002 at 8:13 PM

Heh, that last post wasn''t a flame...it just got a little long.

Talk to me people!

LessBread

Jul 23, 2002 at 8:58 PM

quote:
Original post by null_pointer
Stroustrop has been very adamant about retaining the lower-level features of C++ and while the syntax has changed somewhat, the C++ language definition has arguably equal powerful low-level code to C. I don''t see him dropping ANY of C''s useful features in the next 20 years.

Yes, but the decision is beyond his control.

quote:
Original post by Less Bread
Well, subset and superset are just terms, like "integers" is a subject of "reals"...er, maybe I should have picked a better example. Anyway, the set terminology doesn''t bear any meaningful relation to the history of the matter. C++ borrowed elements from C, Smalltalk, Algol, and other languages; it also has elements that are unique, and some elements of C were actually borrowed back from C++.

Yes, but terminology should add clarity not obscurity. Although C++ borrowed from those other languages it''s not known as smalltalk++ etc.

One of the comments at comp.std.c was that Bjarne thought that if he named C++ something different it wouldn''t have gone anywhere and so he named it C++ before that for a short time it was known as "C with classes".

quote:
Original post by Null and Void
What will happen when programmers switch to 128-bit platforms? and 256-bit platforms?

Yes, the intrinsic data types betray the age of the language(s). When 4 Kb of ram is enough to get to the moon I can understand how they didn''t foresee the need for 256 bit integers. It seems to me that the easier solution is to make the number of bits in the type explicit: int8, int16, int32, int64, int128, ... It might look ungainly, but it removes any doubts as to what the coder intended.

quote:
Original post by Null and Void
I think that two very useful things that could be added to the hypothetical new C/C++ language are: 1) forcing vector to store its elements contiguously, and 2) the addition of a "finally" keyword for exception-handling.

As it stands now, both of those items are C++ only. That is, stl and exception handling. Microsoft provides SEH, but that''s not a part of the language.

quote:
Original post by Null and Void
Does anyone have any other features they might find useful? Or perhaps people would like to discuss the problems that might result from a "merger"?

The "typeof" operator could be very useful with C. Afaik, this is a gcc extension at the moment.

quote:
Original post by Null and Void
For example, what about the type system - C++ has stronger typing and, of course, the special casting operators. Should C++ have weaker typing, should C have stronger typing, or should both meet halfway? Should the C cast syntax be thrown out in favor of the cast operators, or should both be perfectly acceptable?

lccwin32, the C compiler that I use quite frequently has extensions that allow for operator and function overloading. I don''t know that C++ should weaken it''s typing, but perhaps C should tighten its. The trouble that I see with the C++ cast syntax is that it appears too similar to a function call or macro, whereas the C cast syntax in unlike anything else in the language.

Null and Void

Jul 24, 2002 at 3:00 AM

quote:
Original post by null_pointer
I already have a header like that. (How can one write portable code without such a header?) In fact, I use a whole slew of headers that detect the compiler, compiler version, supported platform, CPU architecture, detect the existance of various language features, etc. These can simply be included in the precompiled header and then be used project-wide. Write once, reuse.

I have a header like that too (many headers like that, actually

). My point is that I shouldn't be forced to have a header like that if all I want are specified-size integer types. I need them for network communication and portable file reading, so the language might want to just give them to me.

quote:
Original post by null_pointer
As for long long's, they just seemed like a bandaid type solution to me. The real problem is that programmers have assumed that the basic types have fixed sizes that are guaranteed to be the same on all platforms. They litter their code with longs, shorts, bit operations, and other non-portable things, instead of localizing all the non-portable code into one place and presenting a nice portable interface for it.

What will happen when programmers switch to 128-bit platforms? and 256-bit platforms?

Example

That's exactly why I think there should be some method of having sized types (the "long long long" stuff). Sure, we can use just normal short/int/long/long-long for most tasks, but what about when we need more specification than 'really big types' or 'small types' (or whatever), for example '2 bytes' and short/int/long/long-long doesn't have a 2 byte type?

quote:
Original post by null_pointer
Personally, I think that introducing sized types into the language would be nice, but it might also exasperate the problem. Seeing as how it can be fixed with a relatively small header, it isn't so terribly necessary. Having to write a header is just enough work to keep people from throwing uint16 all over their code and yet not enough work to make it a serious deficiency in the language.

Just because a feature can be used badly doesn't mean the language shouldn't have them (I'm sure you know lots of bad uses of exceptions, goto, macros, et cetera).

[edited by - Null and Void on July 24, 2002 4:04:44 AM]

Null and Void

Jul 24, 2002 at 3:02 AM

LessBread, you put my name on some (all?) of the quotes you take from null_pointer

davepermen

Jul 24, 2002 at 3:45 AM

quote:
Original post by LessBread
lccwin32, the C compiler that I use quite frequently has extensions that allow for operator and function overloading. I don''t know that C++ should weaken it''s typing, but perhaps C should tighten its. The trouble that I see with the C++ cast syntax is that it appears too similar to a function call or macro, whereas the C cast syntax in unlike anything else in the language.

hm.. why not simply use a c++ compiler..

actually the cast syntax _IS_ a templated function (well, you can code other casts as templated functions) and you can use the old casts as well (i use them everywhere..)

and whats the problem if a cast is like a function..

int to_int(float f); actually is a funcion. and to get an int out of a float you need some function (that gets inlined into the asm code ''fist'' etc bla bla

).
the casts of the pointers are simply most the time useless in c++ if you have a nice coding habit.. they are still there to interfer with c-libraries most the time.. a SetWindowLong will always take a long, even if its a classpointer..

"take a look around" - limp bizkit
www.google.com

LessBread

Jul 24, 2002 at 3:55 AM

quote:
Original post by Null and Void
LessBread, you put my name on some (all?) of the quotes you take from null_pointer .

That wasn''t intentional! Quoting posts with multiple quotes often leads to getting the attributes mixed. And I must not have double checked my cut and paste. Sorry.

LessBread

Jul 24, 2002 at 4:18 AM

quote:
Original post by davepermen
hm.. why not simply use a c++ compiler..

I don''t use those extensions precisely for that reason.

quote:
Original post by davepermen
actually the cast syntax _IS_ a templated function (well, you can code other casts as templated functions) and you can use the old casts as well (i use them everywhere..)

It seems to me that adding template support to C would change C into C++.

quote:
Original post by davepermen
and whats the problem if a cast is like a function..

int to_int(float f); actually is a funcion. and to get an int out of a float you need some function (that gets inlined into the asm code ''fist'' etc bla bla).

I suppose the distinction hinges on how the compiler deals with a cast. If a cast operates in similar fashion to a function, I don''t see any problem with that syntax. If it doesn''t, then I think a syntax that conveys that the conversion is not a function should be used. I don''t have any suggestion, although I mulled it over a little bit this afternoon. Nothing that came to mind seemed appropriate.

quote:
Original post by davepermen
the casts of the pointers are simply most the time useless in c++ if you have a nice coding habit.. they are still there to interfer with c-libraries most the time.. a SetWindowLong will always take a long, even if its a classpointer..

I made my comment in response to the quesiton of whether C should dump the cast syntax and not whether C++ should. I assumed the unstated subcontext was that C should adopt the C++ cast syntax. My pov is from C where the definition of "nice coding habit" varies somewhat from that of C++.

I actually had a brief discussion of the topic of overloading the cast operator with the author of lccwin32. He was interesting in adding support for it to the compiler. I gave it some thought and replied that doing so might necessitate adding support for constructors/destructors for adts. He hasn''t yet responded, so I don''t know if he''s made a final decision on the matter or not, but I suspect not as he''s not fond many elements of C++.

Another item from C++ that lccwin32 implements is argument passing by reference. But again I don''t use that extension.

granat

Jul 24, 2002 at 5:34 AM

quote:
Original post by LessBread
Yes, the intrinsic data types betray the age of the language(s). When 4 Kb of ram is enough to get to the moon I can understand how they didn''t foresee the need for 256 bit integers. It seems to me that the easier solution is to make the number of bits in the type explicit: int8, int16, int32, int64, int128, ... It might look ungainly, but it removes any doubts as to what the coder intended.

Amen to that. Only I would suggest this:

byte, int16, int32, int64, int128,....

I can''t bare to loose byte. Byte is cool !

And then:

float32, float64, float 128, .....

No more doubles...

SabreMan

Jul 24, 2002 at 7:17 AM

quote:
Original post by LessBread
Yes, the intrinsic data types betray the age of the language(s). When 4 Kb of ram is enough to get to the moon I can understand how they didn''t foresee the need for 256 bit integers.

The reason the Standard does not prescribe the sizes of built-ins is because they vary according to the machine. When we have 256-bit machines, we''ll have 256-bit ints available to the compiler. There''s nothing in the C++ Standard that prevents that. If you want a 256-bit int now, then you have to simulate it. The means of doing that depends on why you think you need 256-bits.

quote:
Original post by granat
Amen to that. Only I would suggest this:

byte, int16, int32, int64, int128,....

If the architecture does not support a particular size as native then it has to be simulated. Believe it or not, that''s the exact situation we have now and we will have in the foreseeable future. If you wanted, for example, an int24, then C++ allows you to build a type to simulate that naturally (hint: Boost). C also allows idiomatic abstraction mechanisms to provide a reasonable simulated type. There''s no good reason to have these inherently non-portable types added to the C++ Standard.

LessBread

Jul 24, 2002 at 8:21 AM

quote:
Original post by SabreMan
The reason the Standard does not prescribe the sizes of built-ins is because they vary according to the machine. When we have 256-bit machines, we''ll have 256-bit ints available to the compiler. There''s nothing in the C++ Standard that prevents that. If you want a 256-bit int now, then you have to simulate it. The means of doing that depends on why you think you need 256-bits.

Don''t forget to take into consideration the element of speculation and wishlist compilation in this thread.

I don''t think the variation across machines is nearly as great as it once was and considering that compilers do much more today than they used to, why not put the onus on them to properly interpret "integer X bits"? As it stands, the plethora of type names is useless. There are essentially two primative types, integers and floating points. Why not use these terms as a basename that can scale accordingly? To my eyes, int256 is far more sightly than long long long long long long long long.

SabreMan

Jul 24, 2002 at 9:20 AM

quote:
Original post by LessBread
I don''t think the variation across machines is nearly as great as it once was and considering that compilers do much more today than they used to, why not put the onus on them to properly interpret "integer X bits"?

Because then the compiler has to has to make the decision of why you want X bits, taking the choice away from the developer. The requirement for a numeric range provided by 2x10e64, for example, is different to the requirement to overlay 64-bits onto a region of memory. Compilers can and do provide types relevant to the native platform.

quote:

As it stands, the plethora of type names is useless. There are essentially two primative types, integers and floating points.

There are at least two size of integral of wide-ranging use: char and int. I personally don''t use anything else for integrals. The issue of how long is meant by "long" is up to the compiler. I suppose if the CPU provides for 32-bit and 64-bit operations, then it makes sense to have a 64-bit long (in which case I might use it), but that choice is with the compiler, and the Standard should not impose the size.

quote:

Why not use these terms as a basename that can scale accordingly?

Because the integrals correspond to natively supported sizes. If the platform does not support a size, then it has to be simulated wherever needed. There are different ways of simulating a numeric type, and the philosophy of C and C++ is to leave the decision with the programmer, not the compiler. If a particular platform supports a particular size, then the developer is free to typedef that type to achieve the desired level of portability.

quote:

To my eyes, int256 is far more sightly than long long long long long long long long.

But what should happen if I select int256 and my platform doesn''t support it? There''s a possibility that Boost''s type selection templates will be incorporated into the Standard, but that will be part of the library, not the core language.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.