Latest Proposals for C++0x 911
CodeDemon writes "It looks like the ISO/IEC JTC1/SC22/WG21 working group has made some headway in reviewing new proposals for the C++ language. The long anticipated upgrade for C++, C++0x, may be just around the corner. Head on over to check out the proposals yourself."
where does the name come from? (Score:4, Interesting)
Why C didn't progress to D.. (Score:2, Interesting)
Either way, it doesn't look too exciting judging from these proposals. It's certainly nothing on the scale of Perl 6 compared to Perl 5, so yeah, maybe I've answered my own question. This is just a routine standards adjustment, rather than a real 'development.'
Re:where does the name come from? (Score:4, Interesting)
Anonymous array members (Score:5, Interesting)
struct somestruct {
int a;
int [3];
int b;
}
vs.
struct somestruct {
int a;
int pad[3];
int b;
}
The only thing its really saving you is the variable name, and its giving you an extra check at compile time to ensure you don't use the 'pad' array. Which shouldn't be a problem with proper variable naming and documentation, right?
How 'bout range checking like purify? (Score:4, Interesting)
Lots of good papers there (Score:4, Interesting)
Williams, Stephen, cited by Lois Goldthwaite in her Technical Report on C++ Performance [dkuug.dk]
Compiler Compliance (Score:4, Interesting)
But that's not why I'm posting.
It's nice to read about all the standards processes, and I can appreciate all the great work that these bodies perform. But after the standards are completed, and everyone goes home, it seems to take years for the compiler writers to implement the standards properly.
I'm not trying to slam the poor developers who have to implement the changes. But yet, it seems that the standards bodies don't seem to take acutual usage of the last set of changes into account before proposing the next set of standards.
What I mean is this: Take C++ 97. OK? How many of us have actually used a 100% compliant compiler, and used the latest features? Not too many. I know I haven't. But it seems to me that the language masters want to go ahead and move C++ along without getting real feedback from developers about how useful the language changes are.
It's almost like the big boys are saying "well, it'd be nice to have X, Y, and Z in the language" instead of "you know, everybody hates the way we did A, B, and C back in 97. Lets think about fixing that". The language masters, IMHO are basing the next round of changes on their experiences, not the experiences of the developer community at large.
C++ is already a big complicated language. Maybe the standards process should slow down a bit and give us ordinary developers a few more years to catch up.
SCO (Score:5, Interesting)
MozillaQuest Magazine: C++ appears to be one of the properties that SCO acquired through Novell's acquisition of AT&T's UNIX Systems Laboratories and subsequent purchase of Novell's UNIX interests by SCO. At this time most Linux and/or GNU/Linux distributions include C++ compilers and editors. Is this something for which SCO currently charges? If so, just what are the current arrangements? If not, will C++ licensing and enforcement be added to SCO's licensing and enforcement program?
Blake Stowell: C++ is one of the properties that SCO owns today and we frequently are approached by customers who wish to license C++ from us and we do charge for that. Those arrangements are done on a case-by-case basis with each customer and are not disclosed publicly. C++ licensing is currently part of SCO's SCOsource licensing program.
MozillaQuest Magazine: How about GNU C++? Does GNU C++ use SCO IP? If so, could SCO license and/or charge for use of its IP in GNU C++?
Blake Stowell: I honestly don't know.
Re:COBOL (Score:5, Interesting)
It's great to see some metaprogramming related... (Score:5, Interesting)
Unfortunately metaprogramming is a pain in C++. One of the biggest problems is the lack of reflection in C++ that would allow template metaprograms to easily determine type information. Some of the new proposals would remedy that issue. Also the use of local classes in templates, that is sorely lacking in the current standard, would be a great boon for such techniques.
And maybe one day there will be many more C++ textbooks that don't just relegate templates to half a paragraph in the "advanced techniques" section. Templates are fundamental to C++. If you don't use the benefits of C++ then C++ really isn't that interesting a language. No wonder so many people propose using C rather than C++. It's like programming in Lisp but refusing to use list datastructures.
Create a C++ platform like Java (Score:3, Interesting)
C++0x's biggest new feature... (Score:2, Interesting)
If they can do this right, I'll be very happy. After all, Java's main advantage over C++ is their abstracting away pointers. Course Java is still slow, and that pointer abstraction is expensive, in terms of garbage collection, program speed, and (most important) huge memory footprint. C++ pointers are a major PITA, but they are fast 'n cheap. How fast 'n cheap are smart pointers?????
Fragile Base Class problem (whining follows) (Score:3, Interesting)
I'm tired, so forgive me if i explain this poorly, but C++ has this issue where, since object methods are really just function pointers, if you have class A that is shipped as a library or API, and class B which inherits from class A and is part of some third-party program, and the people who make class A add a private method or private variable to class A and then re-ship their libraries, every existing binary containing class B breaks becuase C++ just slaps a struct containing Bs methods and variables at the end of A, and becuase the size of A has changed the offsets have all changed.
This is horrible. This completely negates the purposes of encapsulization and information hiding, which is the entire reason you'd be writing an OO API in the first place, and leads to anyone attempting to create a C++ API doing horrible workarounds [2f.ru] like sticking a whole bunch of dead space in the form of methods named, for example, "reserved_23" at the end of every class they make, just so that in case later they have to add a method or instance variable they'll have a little bit of room to do so without breaking everyone who's ever inherited from them.
Until they fix this, and until they reach the point where there is some kind of standard String class that everyone uses (as is, there are an untold number of String classes, one for just about every major C++ API, and so from what i've seen people rarely if ever store their strings as anything other than c-strings just because in the end, all they're going to do with their strings is pass them to other c or c++ libraries.. who expect to be given c-strings..), I will continue to consider C++ to be more or less a huge joke that can be used as a high-level oo programming language, but only by coincidence.
Also note that they still are not even considering adding any sort of real reflection into the language, nor are they considering adding a real, robust macro system despite the fact people clearly want one (or else they wouldn't be trying to metaprogram the C++ template system to be a macro system!). It would be nice to be able to typedef a single variable type that acts as a template, though.. that's a good innovation, if i'm reading that right. Anything that minimizes the contact I have with the C++ template system makes me happy. (If it were up to me, they would add ML-like syntax where you can say something like 'typedef myinttype = int | long | IntegerClass | BigInt;' and it would automatically generate the templates for me whenever i used a myinttype in a function.) Of course, considering how long the major compiler makers took to all implement C++ in a standard fashion (the STL doesn't really even seem standard across all the platforms i use, yet), it will probably be a long time before i can safely use any C++0x features
I will, however, support the spread of C++0x, just becuase that will make it the first major language whose name is written in leetspeak.
Useful for structs/unions (Score:3, Interesting)
Suppose I have:
struct foo {
int i;
struct bar {
int j;
int k;
} s;
} n;
Now to reference j, I have to say n.s.j. But why not leave the s out so that I can just reference n.j?
This becomes really useful is when you have a huge project and you decide that some element of a struct should be made into a union. Now you wouldn't have to change every reference throughout your project (or use #define to simulate the old naming).
I like (Score:3, Interesting)
N1428 Dynamic Library Support in C++
Coming from Java (well, I did do a bit of introductory C++), one of the things that really bugs me, is the aesthetic of looking at the soup of classname::function implementation declarations. Class namespaces would clean this up considerably and make things much easier to read and more manageable (Java packages and classes are basically namespaces, and this concept confers very well). I also like the dynamic library support (another thing that is automatic in Java)...the worst thing is having to code native OS-specific macros, extern "C" DECLSPEC(dllexport) BLAH BLAH F'ING BLAH. Dynamic libraries are a ubiquitous concept and support should be built in. Leave it to the compiler to figure out what that actually *means* for a given OS. There is no performance benefit in making a human code this.
Further library standardization would of course help...it really helps to have a standard library (even if it is not the BEST one), since it avoids balkenization, which makes skills truly portable ("C++ developer eh? well do you know how to use the Frobnitz Super Fantastic library? No? Shame."), and programs reusable (by other humans).
C++0x is a Frankenstein Java (Score:4, Interesting)
Unfortunately with Java 1.5, some of C++ is corrupting Java, mainly the completely academic confusing implementation of C++'s templates. Why not go for a more easier to understand concept of templates as implemented by languages such as Haskell?
Re:C++0x? (Score:2, Interesting)
C n. [..] 3. The name of a programming language designed by Dennis Ritchie during the early 1970s and immediately used to reimplement Unix; so called because many features derived from an earlier compiler named `B' in commemoration of its parent, BCPL. (BCPL was in turn descended from an earlier Algol-derived language, CPL.) Before Bjarne Stroustrup settled the question by designing C++, there was a humorous debate over whether C's successor should be named `D' or `P'.[..]
So does everyone else. (Score:5, Interesting)
The most popular suggestion, during the original standards process, was: every time someone proposes a new feature, they have to also propose an existing feature to be removed.
The followup suggestion: every time someone proposes a new feature, they have to donate a kidney. This ensures that proposals will be given serious thought, and that a serious idiot can only propose, at worst, two extensions.
No, I'm not joking. Those were some of the suggestions that received rare unanamous agreement.
Seriously, everyone on the committee, from Stroustrup and Koenig on out, agrees that the language is too complicated. They even said so before it was standardized. But...
Let's hear your suggestions on which stuff should be removed. Remember that no matter what you choose, people somewhere are currently using it, and you will break their code. No matter what you change, it will cause incompatabilities, which future generations of /. will then bitch and moan about.
Also, since compiler vendors don't like pissing off their customers, they can't really completely remove stuff even when the standard says it's okay.
This will help out companies (Score:4, Interesting)
The company I worked for used to write our software in C++, but moved over to java 3 or 4 years ago for the cross platform abaility of this. There are so many core parts of a program that are system dependent, that supporting 8 different operating systems in C++ is impossible without a standard library of some sorts. Add a standard socket structure will be very nice, and most OSs have very different ways of handling this. Threading is also the other huge issue with crossplatform, there is near zero standard on out threading works in C++.
The one thing that the new C++ proposal is missing is a standard widget/windowing commands. But there is no good way to make standard libraries for something like that, the best if to create a general class to create and control widgets, then write the system specific code for each OS you want it to run on.
It's something I'm looking forward to.
A few suggestions (Score:1, Interesting)
The PDF file shows that they're committed to killing some of the idiosyncrasies of the language. I could list a lot of them, but here are a few that stick out at this moment in time.
What would be most beneficial is if the . operator worked in the same context the arrow operator did. It is a pain to have to convert every usage of it over if you switch a reference to a pointer. The arrow operator could just be a deprecated operator for C compatibility.
Also, references seem to be ill conceived. The worst part is they can't be stored in STL structures because there is (currently) no such thing as a double reference. References should only be allowed in function argument lists.
Cool (Score:5, Interesting)
1) Metafunctions. Like Lisp macros, they allow code-generation at compile time. They're less flexible, because they don't allow access to the AST, but they're much better than the current template-metaprogramming kludge.
2) Lambdas. Even if we don't get true lambdas, with continuations and closures, but I'd like to see some sort of anonymous functions. The STL desperately requires it. Overall, I'd like to see more functional stuff get into the language. Unlike many of the other features discussed, lambdas and higher order functions really need language-level support to work well.
3) Type inference. There is a proposal to allow a new use of the auto keyword like such:
auto x = new int;
The compiler will automatically detect that 'x' should be an int*. I've wanted this feature from the minute I saw stuff like:
int* i = new int;
Its so redundant! I'm surprised that Java (whose simple semantics would make type inference much easier) still makes you do stuff like:
foo i = new foo;
An additional motiviation is that:
vector::iterator i = vec.begin()
can be shortened to:
auto i = vec.begin();
C++ is seriously eating into the horizontal space, thanks to namespaces and nested typedefs and whatnot, and type inference would go a long way in alleviating some of that pain.
The nice thing about these features is they keep with C++'s philosophy. Most of the complexity here is in the compiler --- there is no overhead in the generated code.
Hmm...0x or 1x? (Score:3, Interesting)
Re:hehe.. sorta (Score:3, Interesting)
Why in the world would you want access to matrix3 from the plus operator???
Re:It keeps going and going.... (Score:3, Interesting)
(C++)++ invokes undefined behavior, because you're altering the same variable twice before the next sequence point.
Re:remove export (Score:3, Interesting)
EDG are some really smart people, but their comments have since then been disproven.
export in itself (specifically, the idea which export is trying to implement) is a good idea. Where the committee screwed up was mandating its existence without any prior experience.
Keep in mind that the point of an ISO standard is not to require/"legislate" new ideas, but to standardize existing practice. Everything in C++98 had already existed by the time the standard was even close to being done, except export.
Re:How 'bout range checking like purify? (Score:1, Interesting)
I totally agree, the preprocessor must go! (Score:1, Interesting)
1) macros definitions to reduce the execution time overhead of a function call.
2) constants in the form of #define
3) the ability to conditionally compile code
A modern c/c++ compiler covers all of these cases by:
1) inline functions, in place of macros and all their evil side effects.
2) const, in place of #define
3) throwing away unreachable code during code generation, in place of conditional compilation. Granted you still pay the compilation cost, but the execution costs are negated.
Re:hehe.. sorta (Score:2, Interesting)
Re:OOP (Score:2, Interesting)