What are some opinions on a C/C++ merger? Will this truly ever happen?
What are some opinions on a C/C++ merger? Will this truly ever happen?
What C/C++ merger? They're different languages with different goals.
I wouldn't say the goals are that much different. They are both general purpose programming language. It wasn't my idea. Bjarne Strosoup first said it. I was just curious how serious this is and if it might actually happen.
If C and C++ merged, the result would be C++. So what's the point?
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Practically all there is bad in C++ is because the language is based on C. That also seems to be the reason why C++ became popular.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
>>If C and C++ merged, the result would be C++. So what's the point?
I like the name C.
I like the name XYZ. What difference does that make?Originally Posted by lruc
C++ is, as pointed out, derived from C. It has many of C's features (like it or not - but it's also a reason why C++ is successful. Bjarne Stroustrup came up with the idea of C++ becasue he wanted some of the features of Simula-67, but the speed of C - so if someone asked "what do you get if you mix Simula with C" the answer would be "something like C++").
All computer languages have a variety of strong points and weak points. C and C++ are very similar in the sense that they are low-level languages (relatively speaking) and it is up to the programmer to solve many issues that higher level languages solve for the programmer - but this also means that the programmer have no control over those aspects. In Bjarne's case, it was the memory allocation, or rather, the garbage collector, that causes problems, by running for a substantial amount of the run-time of the application (more than 50%) once sufficient amount of memory had been allocate. C and C++ doesn't have garbage collection [by default], so the programmer doesn't have to fight a garbage collection mechanism coming in and "interrupting the program itself".
C is picking valuable bits from C++ when it's suitable, but merging C and C++ would just end up with C++ - otherwise there would be a loss in the merge.
There is something called "Embedded C++" that is somewhat standardized, and is a stripped down version of C++ - although I found that some useful things [namespaces for example] where removed "because they confuse the programmer". Now I don't see that as particularly confusing, but that is perhaps an individual view.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I don't really agree that merging C and C++ would produce C++.
There is the politics of standardisation. C++ was designed with backward compatibility to the 1989 C standard, so those who use C89 or C++ would have few problems due to incompatibilities. However, C99 was not designed with backward compatibility to C++ in mind In fact, some language features of C99 have the same name as library features in C++, and the two are not interchangeable. Philosophically, C is designed as a low level language with a (relatively) few libraries, and the intent is that new capabilities will be added to the language first with some library support if necessary. C++, on the other hand, is designed as a language that supports abstraction, and the intent is most new features will be added by expanding the standard library, with some changes to the base language only if absolutely necessary. There are merits in both approaches but, politically, finding a middle ground between advocates of both approaches would be challenging -- each would have to give up some of the core strengths of their preferred language in order to merge them.
As an example: There would be considerable debate over things like an implicit conversion from a void pointer to another pointer type: C allows the implicit conversion in the interests of type safety, C++ disallows the implicit conversion also in the interests of type safety. Code in both languages would break, with a need for clumsy workarounds, if the approach of the other was adopted.
Details. C++ is C89 with additional features, except for some minor details. C99 adds various features to C, but only variadic macros aren't in some form (not necessarily compatible) already in C++98, and they will be adopted in C++0x. Variable-length arrays are covered by vector, although the implementation does differ considerably. The built-in complex datatype is covered by C++'s library complex class. Inlines and C++-style comments are already in C++. Most of C99's library updates will be in C++0x.
As a result, if you merge C++0x and C99, feature-wise the result will be C++0x. There may be discussion whether the C or the C++ way of doing things is correct in some details, but that won't change the feature list.
Philosophy-wise the result would be a blob without purpose, which is one more reason why they shouldn't be merged.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I'd just be happy if everyone agreed that designated initializers were as great as I think they are. I can't believe some of the popular compilers that don't support them yet.
What are designated initializers?
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Designated initializers is a C99 feature where you can initialize members or elements individually by name or location (in the case of arrays).
http://publib.boulder.ibm.com/infoce...esignators.htm
See also C99 6.7.8.
Ah. Oh, well. That's what constructors are for.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Designated initializers. It's one of those things that a computer can do much better than a living person. I just have to tell it which element(s) I want initialized to what, and the layout is taken care of. Reduces errors, maintenance overhead, maintenance risk (if someone switches member order in a struct), increases readability A LOT, and no runtime overhead at all.
I don't know why these have been received with such lukewarm enthusiasm. I tell most people about them, and I get either a shoulder shrug, or a "hmm, that's nice." Whatever.
