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."
This includes the first C++ compiler that fully implements the 1998 ISO/ANSI C++ standard (including "export")
1998. Ten years, eh? Oh wait- what year is it again?
Lack of eloquence does not denote lack of intelligence, though they often coincide.
We have here to my knowledge the first known /. misspelling of a story TITLE
;)
Yeah, well done, 'editors'
- S_D
Has Karma to blow
"There are rumors they can compile the Linux kernel too"
Finally!! Someone pulled it off!
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
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..
-
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?
.... Now all we need is a language whose syntax makes sense! ....
Which is the exact reason I've moved pretty much completely to Objective-C. After cursing C++ for years, I've finally found peace with a C-like, object-oriented language that makes sense. I learned Obj-C when I was getting familiar with OS X development, and I haven't used C++ on anything since, on any platform. Obviously, I still have to maintain plenty of C++ code, but as time goes on, that amount will become less and less and eventually, I'll be rid of C++ forever!
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
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.
Sun is constantly talking about protecting the Java language for the sake of humanity. I find it rather amusing, by comparison, that C++ is so out there in the open that it took 5 years to actually get a complete implementation of it. Evidence that such tight controls aren't necessary to make a language stable and long lasting?
This sig has been temporarily disconnected or is no longer in service
Hello Gentlemen,
I'm a first year programming student at an Ivy League school and I've just finished my Visual Basic classes. This term I'll be moving onto C++. However I've noticed some issues with C++ that I'd like to discuss with the rest of the programming community. Please do not think of me as being technically ignorant. In addition to VB, I am very skilled at HTML programming, one of the most challenging languages out there!
C++ is based on a concept known as Object Oriented Programming. In this style of programming (also known as OOPS in the coding community) a programmer builds "objects" or "classes" out of his code, and then manipulates these "classes". Since I'm assuming that you, dear reader, are as skilled at programming as I am, I'll skip further explanation of these "classes".
Please allow me to make a brief aside here and discuss the origins C++ for a moment. My research shows that this language is one of the oldest languages in existance, pre-dating even assembly! It was created in the early 70s when AT&T began looking for a new language to write BSD, its Unix Operation System (later on, other companies would "borrow" the BSD source code to build both Solaris and Linux!) Interestingly, the name C++ is a pun by the creator of the language. When the first beta was released, it was remarked that the language would be graded as a C+, because of how hideously complex and unwieldy it was. The extra plus was tacked on during a later release when some of these issues were fixed. The language would still be graded a C, but it was the highest C possible! Truly a clever name for this language.
Back to the topic on hand, I feel that C++ - despite its flaws - has been a very valuable tool to the world of computers. Unfortunately its starting to show its age, and I feel that it should be retired as COBOL, ADA and Smalltalk seem to have been. Recently I've become aquainted with another language that's quite recently been developed. Its one that promises to greatly simplify programming. This new language is called C.
Although syntactically borrowing a great deal from its predecessor C++, C greatly simplifies things (thus its name, which hints at its simpler nature by striping off the klunky double-pluses.) Its biggest strength is that it abandons an OOPS-style of programming. No more awkward "objects" or "classes". Instead C uses what are called structs. Vaguely similiar to a C++ "class", a struct does away with anachonisms like inheiritance, namespaces and the whole private/public/protected/friend access issues of its variables and routines. By freeing the programmer from the requirement to juggle all these issues, the coder can focus on implementing his algorithm and rapidly developing his application.
While C lacks the speed and robustness of C++, I think these are petty issues. Given the speed of modern computers, the relative sluggishness of C shouldn't be an issue. Robustness and stability will occur as C becomes more pervasive amongst the programming community and it becomes more fine-tuned. Eventually C should have stablity rivalling that of C++.
I'm hoping to see C adopted as the de facto standard of programming. Based on what I've learned of this language, the future seems very bright indeed for C! Eventually, many years from now, perhaps we'll even see an operating system coded in this langauage.
Thank you for your time. Your feedback is greatly appreciated.
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.
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!"<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
Part of the problem is I don't think anyone (including Stroustrup) have any idea of all the complicated things you can do with it.
Quite true... if memory serves me right in The C++ Programming Language Stroustrup actually says he does not consider himself an expert at C++. It's pretty much humanly impossible (IMHO) to know the entire language and make proper use of it 100% of the time. I smile to myself everytime I see young programmers fresh out of college calling themselves C++ experts.
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.
I am not in any way a C++ programmer. The only thing I've ever read my way through is the Bruce Eckel's book. That was enough for me. I know some Java and C and was starting to learn how to go further on Mac OSX (which uses GCC) and was wondering whether to go with C++ or ObjC. One little trial programme in both and I went with ObjC. It *is* a lot easier, especially if you know some Java and has similar dynamic features. I don't know enough to comment on whther C++ is faster or not but it defintely has a very difficult syntax for beginners.
Although I agree with the OSS crowd that Java should also be opensourced, it is at least a standard and this is a godsend for someone learning the language. In C++ the problem with learning it is whose version do you learn? Microsoft's? GCC? What are the fine points of symantic differences inbetween the differing versions? ObjC has this problem as well but since it's only heavily used on OSx at the moment it is not so critical, but if GNUStep were to more successful for instance there might arise differnces there as well (infighting over GCC ObjC compilation with Apple etc). I personally wish for more standards in these heavily used languages although I don't suppose it'll happen anytime soon.
Ada95 has had fully compliant compilers(plural) since at least 1995.(When it was Internationally standardized.)
Java has at least a coherent standard. And Common Lisp has been there for almost 20 years now.
It's funny to watch the members of the C/C++ Gestapo wet thier pants over this. I bet Bjorne is doing a double-take right about now.