Next Generation C++ In The Works
lamefrog writes: "Bjarne Stroustrup and other members of the C++ community
recently met to discuss new work on the language
for the first
time post-ISO standard (C++0x) in an effort to
keep the language moving,
avoid fossilization and avoid being
overtaken by proprietary extensions.
Suggested new features center around the standard library and include support for multi-threading and simple platform-independent systems abstractions (handles, TCP/IP, memory maps etc...)" (Read more.)
"Most intriguing is a suggestion to include extended type information that will eliminate the need for IDLs and make it possible to generate standard bindings to external systems (COM, CORBA, SQL). Clearly Bjarne wants to position this as a platform-neutral, vendor-neutral, standardized alternative to the proprietary, vendor-supported languages that have emerged over the recent years. Audio MP3 and slides available on Dr. Dobb's TechNetCast." Thoughtfully, it's available to download as well (not just streaming), and accompanied by a transcript. Good listening.
You moron -- that's no way to develop applications. What are you, a first year Fortran student?
The proper way to develop software is to have long, pointless meetings where techies can show off their intelligence, marketeers can display their ignorance and managers can "lead".
Then, everybody pisses around reading Slashdot while a few firebrands argue over what kind of versioning system to use: "CVS!" "RCVS!"
When half of the estimated time has past, the programmers start screaming about the Mythical Man-Month and how marketing is full of shit, while reconfiguring the Cisco switch to cut latency for Quake deathmatches.
Marketing then begins to sell the product to customers, promising to have asked-for features implemented "at beta".
Two weeks before due date, the programmers work 22 hour days cobbling an application from stolen code from previous jobs, algorithms designed in a drunken stupor, and (apparently) one programmer bashing his face into the keyboard.
This fresh, steaming turd gets pushed out the door to tumultuous disdain. Programmers blame marketing, marketing blames management, and the customers get told that it's Microsoft's fault.
So keep your wacky ideas to yourself, okay rookie?
"Beware by whom you are called sane."
Potato chips are a by-yourself food.
Get in line, sonny. They're still coming out with new versions of Ada, COBOL and FORTRAN.
Suppose:
you are constructing an instance of a derived class
one of its base classes has "published" a pointer to the partially-constructed instance
the class has a virtual member funciton
the member function is overridden by this class
the class also has a member variable of a class type with construction
the constructor of the member variable (or something it calls) finds the published pointer and calls the virtual member function.
What happens?
My claim is that such a call SHOULD be legal and SHOULD call the BASE CLASS version of the member function. Similarly, during the execution of the DEsctuctors of the member variables you should also get the BASE CLASS version of the member function. You should get the derived class version exactly from the beginning of the execution of the first line of the body of the constructor through the end of the execution of the last line of the body of the desctuctor.
The reasoning is too involved to go into here. Suffice it to say that:
It's a consistent generalization of the philosophy of the C++ constructon-destructon semantics (and of the way that the C++ semantics differs from those of Objective C and Smalltalk.)
It's an compiler implementation that is allowed by all the levels of C++ standardization.
There's a LOT of neat stuff you can do with this guarantee that you can't do without it.
There are a lot more opportunities for programming error if your compiler doesn't work this way. (Not to mention the issue of code that works find with a compiler that does it one way but breaks when run through a compiler that does it a different way.)
The original C++ work didn't specify the behavior in question. The first ANSI standard explicitly left it open. The revised ANSI standard not only explicitly left it open but said "don't do that". B-(
At the time I first proposed it (about 10 years ago) we looked into a sample of the compilers on the market. There are four binary combinations of member constructor/destructor and base/derived version of member function, of which I claim one is "right" and the other three "wrong":
Cfront and the Cfront-derived C++ compilers tested (Sun, SGI) got it "wrong" one way.
The three IBM PC compilers tested got it "wrong" a second way.
Gnu G++ got it "wrong" the third way.
so standardizing on this semantics wouldn't favor any particular vendor's existing product.
IMHO this somewhat obscure issue is one of the major impediments to C++ achieving its potential as an object-oriented language, and it is unfortunate that is wasn't "fixed" in one of the previous standards.
Perhaps there's one more chance here.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
As a programmer who often works on massively cross platform C++ server and client applications, a lot of these proposals (distributed processing, standard thread libraries) are nice, but there's one major gripe with the language under all platforms: the lack of standard sized types. What I mean is, integral types in parallel to the short int, int, long int, long long int (C99 standardized, not C++) etc, with names like int8, int16, int32, int64, int128... allowing portability without meticulous work in wrapping and handling functions, outside libs, autoconf scripts, etc. It would be especially nice if these types were *not* considered, for the sake of signatures, type-identical to counterpart size-variant types, and if enums were also given a generic root type instead of being int in signature (eg, operator(ClassName&, enum) ) and a variant size integral type defined to the size of a pointer were included. Just some thoughts from a person who has to extensively use the language.
-- Still waiting for the Nike endorsement