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."
If so, where can I go to find out what GCC is missing?
(I had to write this three times because of that damn 20 second after reply widget. Thanks, trolls.)
StoneCypher is Full of BS
Unless a few of the unimplemented language features have uses that nobody has thought of (not entirely unlikely since this is the first compiler I know of that supports all of them), I doubt it will make a huge difference for most coders. C++ programmers have gotten along fine without them thus far.
However, it is nice to see that they have made it in. Maybe now other groups will start imlementing the full language, too.
"The product Edison sells is basically just the front end. Someone needs :-)."
to add a code generator, libraries, support tools, etc. to produce
a complete compiler package. (We use the Edison front end for our
compiler product at Concurrent, so hopefully we'll have all these
nifty features someday - but everyone should be sure they don't
interpret this casual comment as an official promise - I don't even
work on the compiler
I dont know how right this guy is, and I have no expertise in the area myself... but isn't this exactly what we're doing with this slash story? Interpretting this comment as an official promise?
There was a time when it was called usenet. Unless you have been living in a cave you will know that Google bought the usenet and renamed it to google groups.
My understanding of C++ is that it doesn't define things like how class data is stored, standard name-mangling, etc.
Which, overall, is a good thing. I should note C doesn't either - the C ABIs are specified by systems people. For example, there is a System V ABI for x86, which is basically what all the Unix versions on x86 use.
So I guess that this is a good step towards compiler compatibility, but linking will probably still be a problem.
There is now an official IA-32 C++ ABI. Nobody has done it completely, but GCC and Intel are supposed to converge on it in the future. There has also been an IA-64 C++ ABI since the start, though AFAIK some incompatibilies still remain between different compilers (but they are working on it, I think).
Read the test results of the C/C++ User Journal's compiler roundup.
Frankly, your number pulling of "99% of software engineers" not needing the speed of C++ is just ridiculous and arbitrary. Look at the sheer number of complaints of about gnome, kde, mozilla, and related projects being to slow and you will realize that there is never enough speed. And those are just UI programs.
I won't stoop to your pulling numbers out of the blue, but I would contend there is a great deal of scientific and research software that also need every bit of speed they can get. These programs alone must constitute way more than the 1% you have allotted. The software I am developing is in that category.
Finally, when you speak as you have, you declare your ignorance loudly. Yes, C++ does not prevent you from making the kinds of mistakes that you refer to; but by learning good engineering techniques, you can avoid and prevent them yourself. Languages which do restrict you in this area *cough*java*cough* also restrict your creativity and power to accomplish your task. A civil engineer for example, uses techniques -- not restrictions -- to make his/her designs infallible; it is time software engineers step up to the plate and begin using solid techniques rather than blame the language.
That being said, it is still important to use the right tools for the job, if speed is not a concern and you can acclompish the task with something safer and easier -- do it! C++, however is going to remain an important and key tool to accomplish many tasks in the future. Its speed, ability, and flexibility will assure its long life.
Guess what? I got a fever! And the only prescription.. is more cowbell!
Supported C++ and C Language Features
This page also says:
--xPhase
The following sentence is TRUE. The previous sentence is FALSE.
Well, P.J. Plauger did post on the thread: "The new EDG front end passes all the tests in the Dinkum C++ Proofer." I'd say that's a pretty good start.
<sigh>Once again my story gets rejected when it contains more info than the one that gets posted. :-(
To set the record straight, EDG do indeed produce C++ front end compiler tools, and it is these that have just been released.
However, major C++ vendors including Comeau Computing use that in their compilers. Comeau already have a beta of their 4.3.0 compiler available at their on-line compiler. The full version is due later this month.
Dinkumware have also announced a version of their standard library implementation to work with Comeau, which should be available shortly after the Comeau compiler is released. Apparently, it makes extensive use of export, but for little change in performance at compile-time.
That makes their new library implementation a bit academic as far as Joe Developer goes. However, it's excellent news in general, because it shows that using export isn't going to entail a performance hit. We can finally write template code with interface and implementation properly separated out.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
GCC code is slow.
I code computationally intensive number crunching code and I had to buy Intel's compiler for Intel and Compaq's compiler for Alpha just to get some performance. And I'm talking about 10-20% difference.
Then you should like GCC 3.1. Here is a snippet from the changelog (you can see the entire list of changes at http://gcc.gnu.org/gcc-3.1/changes.html):
- According to the SPECInt2000 results on an AMD Athlon CPU, the code generated by GCC 3.1 is 6% faster on the average (8.2% faster with profile feedback) compared to GCC 3.0. The code produced by GCC 3.0 is about 2.1% faster compared to 2.95.3. Tests were done using the -O2 -march=athlon command-line options.
- The compiler now supports MMX, 3DNow!, SSE, and SSE2 instructions. Options -mmmx, -m3dnow, -msse, and -msse2 will enable the respective instruction sets. Intel C++ compatible MMX/3DNow!/SSE intrics are implemented. SSE2 intrics will be added in next major release.
- Following those improvements, targets for Pentium MMX, K6-2, K6-3, Pentium III, Pentium 4, and Athlon 4 Mobile/XP/MP were added. Refer to the documentation on -march= and -mcpu= options for details.
- For those targets that support it, -mfpmath=sse will cause the compiler to generate SSE/SSE2 instructions for floating point math instead of x87 instructions. Usually, this will lead to quicker code -- especially on the Pentium 4. Note that only scalar floating point instructions are used and GCC does not exploit SIMD features yet.
- Prefetch support has been added to the Pentium III, Pentium 4, K6-2, K6-3, and Athlon series.
- Code generated for floating point to integer converisons has been improved leading to better performance of many 3D applications.
There is also AltiVec support for the PowerPC now. You can also trying using -fprofile-arcs, run your program once, then recompile with -fbranch-probabilities to help GCC predict branches (but then again if all your code does is crunch large numbers, there might not be too many branches in the first place).HAL 7000, fewer features than the HAL 9000, but just as homicidal!
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
It says something about how complex C++ syntax has become that this is the case. It's very hard to parse C++, because you have to do extensive declaration handling to find out what's a type name, and you have to know what's a type name just to parse. C++ is thus context-dependent.
One major implication of that context-dependency is that you can't parse a C++ text file without processing the include files. This is why tools like "indent" are hard to find for C++. "Little" tools for C++ are rare. And that hurts the language.
I'd like to see a cleanup of C++, but it's not going to happen. Most of the action in the C++ standards effort is going into adding obscure features for fancy templates. As a result, C# and Java are gaining market share.