Slashdot Mirror
Standard C++ Moves Beyond Vapor
An Anonymous Coward++ writes "This google thread announces the first C++ compiler that can actually handle the whole language (we'd been waiting for half a decade here). The company that did it is EDG. They're a tiny outfit, but they're apparently also behind the Intel compiler (both on Windows with Visual C++ extensions, and on Linux with GCC extensions). There are rumors they can compile the Linux kernel too."
It's a usenet thread, not a google thread.
Is the Linux Kernel written in C++? I thought it was straight C.
Besides, even if it WAS in C++, most likely it would just use features that the compiler could handle.
That's more to do with algorithms than anything else. You can make almost anything faster with a better algorithms, and the two ings: caching and hashing. I bet you anything not one of those programs use the best algorithm.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"> I'm fed up with my software core dumping, memory leaking ... [etc.]
:)
Uh? C does that, unless you code REALLY carefully. C++ - unless you choose to use it simply as a C compiler - gives you the tools to eliminate precisely those irritating errors. Well-designed classes give you the ability to move to a higher level of abstraction so that stuff isn't even on the agenda. Even cursory knowledge of strings, vectors and maps/hashes allows you (in my own experience) to get at least one order of magnitude more reliability into your software and with exception handling, provides the mechanism for dealing with the errors when they do occur.
If you choose to use a C++ compiler to compile C, then there is little point. Moving up to what (IMHO) C++ was intended to provide puts you somewhere different altogether. But the idioms are different entirely; idiomatic C++ is a *very* different language from C. It's not perfect (it's far too big) but if you need a C-like tool and care about reliability and freedom from overruns, memory leaks and the like, it's a very good tool for the job. And it's a lot easier to get stuff right up at that abstraction level too. You get the airbags and ABS braking
If you want to see some of the really weird thigns you can do with the language, check out Andre Alexandrescu's "Modern C++ Design." You might also want to look at the signal system that gtk-- uses. Yes, it can lead to a twisty maze of templates, but it also affords some very powerful type checking, which I miss when moving to languages like Scheme or Java.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It's too bad that the standard itself is broken...
In case you're interested: The issue is a deceptively fine point in constructor/destructor semantics. The current standard allows behavior that massively breaks a bunch of stuff you'd have been able to do if it had required behavior that conformed with the rest of the philosophy of the language. It is this:
You have a class base class with,
a virtual member function and,
a constructor that,
exports a copy of the pointer to the instance under construction (which is stored externally), and
a derived class with,
a member variable of a class-with-construction type, and
an overriding of the virtual function, and
the constructor of the derived class's member variable (or something it calls, or some other member-variable initialization) gets hold of the pointer and,
calls the virtual member function.
Does it get the base class version, derived class version, or go wonky?
Similarly during DEstruction of the member variables (i.e. after the derived class destructor but before the base class destructor).
My claim is that the standard SHOULD explicitly specify the behavior as follows:
The result of a virtual member function call is defined from the execution of the first line of any constructor of the class through the execution of the last line of the destructor, at the most-baseward class where the virtual member function has a defined behavior (unless a more derived class overrides the function to again be pure virtual, and this is allowed).
The result of a virtual member function call to a virtual member function that is overridden in a derived class is the derived class behavior if the function is called during or after the execution of the first line of any constructor and before or during the execution of the last line of the destructor (unless a more derived class overrides the function again), the base class behavior if called before the first line of a derived class constructor or after the last line of the derived class destructor.
In other words: Member variable constructors/destructors (and everything else executing at that time) "see" the base class.
Instead we have this: With respect to calling virtual member functions during construction the early language definition and first ANSI standard said the behavior was undefined. The "final" standard essentially says "don't do that". I'm not sure what current compilers do. But when I checked about ten years ago, of the four binary combinations of whether constructors and destructors got it "right" or "wrong":
cfront (and cfront-derived compilers at Sun and SGI) got it "wrong" one way.
three compilers for PCs got it "wrong" a second way.
g++ got it "wrong" the third way.
Now the semantics I've described are very powerful and create a consistent object model.
Up to the beginning of the user-written code of the constructor through the end of the user-written code of the destructor the instance is a collection of components - base classes, member variables - which have their own internally-consistent behaviors. It is wrong to execute the derived-class member function, because the derived class instance doesn't exist yet. But it is right to execute the base-class member function, because the base class DOES exist and IS initialized.
After the execution of the constructor and before the execution of the destructor the derived-class instance is a fully-constructed and initialized member of the derived class. It might later be hammered into a new shape by serving as a component of a more-derived class, but for now it's consistent.
During the constructors the components are pulled together into a whole, and during the destructor they're disassembled into their components. But the constructors and destructor are aware of the state of the assembly, and can use care not to let a derived-class virtual member function be executed until everything it depends on is ready, or co-operate with it by passing it flags to inform it of construction progress.
I won't go into all the things this enables. But I will note that it would make C++ more consistent and more powerful for object-oriented programming than other contenders, which also do this "wrong". (For instance: Smalltalk has the derived-class ("subclass") behavior during the base-class ("superclass") construction. This risks breaking the consistency of already-debugged construction code whenever a method is overridden and requiring those coding to constantly recheck code outside their new class' modularity boundary.)
Since the behavior I want is a legal option within the standard, perhaps the Edison Design Group might be willing to give me a compiler switch or pragma ("object_construction_semantics"?) to cause their compiler to generate it?
Pretty please?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way