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."
gcc is missing export and some other stuff see http://gcc.gnu.org/bugs.html for more examples of what is missing, scroll down.
Go buy the newest version of Bjarne Strostrup's book, and try out his example programs in the majority of C++ compilers.
You'd be amazed at how much has been missing. Mainly the STL stuff, but there's some bugs in templating in some compilers too.
It sucks when you try to write portable code in C++ and you end up not being able to use some cool stuff because not all compilers support it. A friend of mine switched to Java specificly because of this.
:wq
They all don't properly implement different parts of the standard, which leads to all sorts of cross platform issues.
It's about time someone has done something about it. EDG is no small name in the compiler world either..
-
"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?
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!
You should take a look a the Mozilla C++ Portability Guide. It's quite depressing.
Supported C++ and C Language Features
This page also says:
--xPhase
The following sentence is TRUE. The previous sentence is FALSE.
Yes, KAI and Compaq use the Edison front end. So do Comeau, SGI, Intel, and a number of other compilers. See EDG's site for a more complete list.
Some of EDG's customers will release a compiler based on the new front end sooner than others, partly for business reasons (every company has different tradeoffs) and partly for technical reasons (for some companies, a new front end means an awful lot of integration work).
I expect Comeau to be the first company to sell a compiler based on the new EDG front end: Greg Comeau has been very excited at being able to support export. I'll be surprised if it takes longer than a few weeks for the new Comeau compiler to come out.
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!
I don't think gcc is missing any of the STL stuff anymore (or rather the includes and libg++). GCC does have trouble with some of the "new" namespace stuff, and some edge cases in the type system can do the wrong thing (however they are far enough on the edge that maybe I was wrong about them, not gcc).
Well that is the nice thing about pushing all the complexity into the libraries (yes Java is a more complex language the C...but less then C++ or Perl). Hmmm, speaking of Perl (or even Intercal...) it is also an advantage of really only having one implementation too...
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.