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
It's a usenet thread, not a google thread.
So up until now all compilers have been incomplete? What insanely great features have had to be left out because of this? I'm not a developer, so I'm more than a little ignorant. Mainly I'm just wondering if this will allow fewer lines in the same code, shorter compile times, etc...
Shift happens. Fire it up.
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.
The owls are not what they seem
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 "glasses" out of his code, and then manipulates these "glasses". Since I'm assuming that you, dear reader, are as skilled at programming as I am, I'll skip further explanation of these "glasses".
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 "glasses". Instead C uses what are called structs. Vaguely similiar to a C++ "glass", 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.
Egg Troll
C - A language that combines the speed of assembly with the ease of use of assembly.
Wow! A compiler! Now all we need is a language whose syntax makes sense! I have an easier time coding in Perl than trying to use the bloody C++ STL.
The kernel has been pretty much tailored to gcc and many other compilers seem to have trouble with it.
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..
-
It is good to see the conspiracy of silence finally ended. I have been using this program language since it was started, and finally to see C+_ to get the respect it deserves.I'd say it is the greatest... wait a minute, C++ where the hell did that come from??? Damn, slashdot, covering up the real "C+_" with the fake C++ language,can you say
C-O-N-spiracy
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?
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
Wonder how long the man page is.
The man page for gcc is bad enough... They could write something like "I love VB" somewhere in the midst of the thing and no one would ever get that far...
Hmm.
Blearf. Blearf, I say.
So while it is worth applauding a product which can handle the entire language, their work is not complete by any means. I sincerely hope they can produce the additional utilities that would make it worth implementing on. It is certainly promising.
They won't. They never have. They don't need to. Other people pay them a *lot* of money to do it. In particular, I know that KAI C++ and Compaq's C++ compiler are both based on EGD. Probably there are 3 or 4 others, at least.
EGD is a damn good optimizing compiler, too. I generates code that beats about anything out there.
Uh, ze linux kernel isn't written in C++, it is written in C.
:) extensions to C that no other compiler has, so this compiler hasn't a hope in hell of compiling the kernel.
Also, linux (kernel) uses a bunch of (proprietary to GCC
You need to realize that most low-level stuff isn't written in C++ (ie kernels, device drivers, TCP/IP stack, Apache, Perl, Python etc). C++ simply does not have the efficiency. I'm not saying C++ is slow, just that it isn't suitable for that kind of programming.
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.
I said most of the time , even within one program designers rarely need maximum speed at every point. My point is that the defaults of the language are almost uniformly dangerous. 95+% of the time, switch statements should not fall through; what's with making falling through the normal behaviour? I should put a 'nobreak' in to stop it breaking, not the other way around. I mean sure, I almost always remember it... these days... ;-)
Yes, C++ does not prevent you from making the kinds of mistakes that you refer to
No language can do that. C++ is the equivalent of a machine shop with no guards around any of the machinery. Sure, after you've been cut a few times you learn to move in a way that avoids the sharp bits; but here's an idea, why aren't there guards around them, that you can remove if you are doing something that needs them out of the way?
Languages which do restrict you in this area *cough*java*cough* also restrict your creativity and power to accomplish your task.
Oh yeah right. Lack of creativity and power. ;-) You must be the worst software engineer in the world if the language is getting in your way like that, but I don't buy that, you sound like you almost know what you're doing. But what's that smell? It's the Bull.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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.
Whether a switch is slow or not is both compiler and processor dependent; although most compilers don't optimise this much, switches are usually slow. But I don't see what that has to do with the syntax of the language.
so while your idea of using a nobreak option instead is intriguing, I personally like the way C++ encourages you to think about your switch statements to code them more efficiently.
So you like the naked sharp spinning things because the pending death concentrates the mind? You're perverse if you don't mind me saying.
You can always just use if-then-else-ifs to avoid the fall through problems when you don't want to think about what you are doing.
You could, but that's horrible.
-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
Doesn't it say something about the language's lack of standardization if you have to read a long technical book in order to understand how to use the tools that let you make your code portable?
Hey! I just finished reading that book too!
It also has a chapter on C portability problems, and is quite instructive with regards to shell portability as well. C++ is hardly alone when it comes to quirks.
Oh, and that book also considers "make uninstall" to be a "not a very useful feature."
A Government Is a Body of People, Usually Notably Ungoverned
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?
Actually, what deferencing the NULL pointer does depends on the platform. In plain DOS, it reads whatever value is in memory location 0 (part of the interrupt descriptor table on x86), since DOS doesn't use memory protection. In protected memory OSs, deferencing the NULL pointer essentially becomes an access to memory address 0, and this address is always unmapped by the kernel so referencing it generates a fault, which the OS catches, and results in the application being killed. It doesn't warp spacetime or anything like that, if that's what you were hoping for...
A deep unwavering belief is a sure sign you're missing something...
Hell, given gnome and kde, developers these days can't write acceptably fast software even in C/C++ (even on my 1.5GHz Athlon XP, KDE 3.x and GNOME 1.4 are pushing the limits of 'acceptable'), so maybe if they switched to languages that would allow them to add stupid features even more quickly without borking performance, software might even get faster! Seriously, though, it's all relative. You use whatever language you're comfortable with. Personally, I don't find C++ all that ardous, and with STL and whatnot, its as easy to write C++ applications as Java apps. When I need to interface at the shell level, however, I tend to use Perl, which can't be beat for its quickness and utility. But if you don't like C++, that's fine. Go use Java or something. I personally won't touch Java with a ten-foot pole, but then again, I grew up with C++. Of course, for some things, C/C++ is unavoidable. Kernel stuff, for example. Even C++ is almost too high-level for kernel development (lots of runtime support needed).
A deep unwavering belief is a sure sign you're missing something...
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
Actually, with a good implementation of the STL (SGI's for example), fast, standard, easy-to-use data structures and algorithms become a prime selling point for C++.
A deep unwavering belief is a sure sign you're missing something...
So you like the naked sharp spinning things because the pending death concentrates the mind? You're perverse if you don't mind me saying.
>>>>
Umm, it's actually scientfic fact that sharp spinning things concentrate the mind. Thing about it: when are you most attentive? Going 95mph on the freeway, or sitting in traffic going 15mph? Danger does sharpen attention.
A deep unwavering belief is a sure sign you're missing something...
Slashdot drops the symbol when posting as HTML ;)
A deep unwavering belief is a sure sign you're missing something...
This claim has no factual basis.
switch statements should not fall through; what's with making falling through the normal behaviour?
Using switch statements in C++ is not "default behaviour". They are rarely used, and serve mostly as a C compatibility tool. switch can nearly always be replaced by table lookup or polymorphism, and both of these things (tables and polymorphic objects) are supported by the language.
but here's an idea, why aren't there guards around them, that you can remove if you are doing something that needs them out of the way?
C++ was not designed from scratch, it was constrained by C compatibility. For the most part, this is the reason. Basically, getting rid of "sharp bits" wasn't the primary goal of the language.
>harsh restrictions of the BSD license. It also lacks >the GPLs requirement that anything coded with its >tools becomes property of the FSF. You have this totally backwards. The GPL only says that if you modify the source code of a GPL program amd redistribute it - you must make the orginal code available to the end user. What you use a GPL'd piece of software for is up to you. Furthermore GPL'd software is NOT property of FSF unless you decide to give them those rights. otherwise the copyright is held by the orginal author.
If religous zealots don't believe in Evolution, then why are they so worried about bird flu?
I cannot even begin to count how many times I have wanted to do something along these lines. Keeping everything nice and separated. Instead, the only way to make this work is to include Foo.cpp in main.cpp, which is well, retarded. C++ needs some serious work with templates... so is something like this fixed? Or does it contain some abiguity that I am not aware of?
/* Do magic here. */ } /* Do magic here. */ }
/* Foo.h */
template<class T>
class Foo {
public:
Foo(void);
void doSomething(void);
T bar;
};
/* Foo.cpp */
#include"Foo.h"
template<class T>
Foo<T>::Foo(void) {
template<class T>
void Foo<T>::doSomething(void) {
/* main.cpp */
#include"Foo.h"
int main(int argc, char *argv[]) {
Foo<int> *foo;
foo=new Foo<int>();
foo->doSomething();
}
Why bother.
There is an argument that drivers would drive much more safely if there was a sharp point sticking out of the steering wheel. Any accident and you would die. The drivers will be really attentive. However to ensure the safety, the drivers are going to have to slow down... In the software world this transfers to less code written.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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.
This claim has no factual basis.
What? No? As in none at all? Lack of a garbage collector? No array bounds checking? No constraints on pointer arithmetic? Automatic type casts usually with no compiler warnings?
C++ was not designed from scratch, it was constrained
I prefer the word 'damaged'
by C compatibility. For the most part, this is the reason. Basically, getting rid of "sharp bits" wasn't the primary goal of the language.
You mean it's an eyesore, but because we know why, that's ok then?
Look I've lived at the sharp end of the language more than most. I've worked on multi-million lines of embedded, persistent, realtime code much of it in C++, and without the benefit of the STL. Trust me when I say C++ has some major issues. I've also sometimes had to maintain less clueful peoples code... all I can say is: yuck.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"I can't belive posts like this one where an MS troll actually thinks that someone is going to believe things like "GCC is obscured from us by the marketing people at the FSF" or "Java's source seems to be under the monopolistic thumb of Sun" and "Microsoft's "shared source" under which Visual Basic is released definately seems to be the most fair and reasonable of all the licenses in existance" and "harsh restrictions of the BSD license".
I get so flabbergasted that I'm actually speechless when I see some say that the BSD licence is harsh. Or that GCC is obscured. Not only this but you have the sources of Java in every JDK downlowd and this troll actually thinks that the world is going to suddenly switch to VB??? And he hasn't actually ever coded in C++?? Has he coded at all I ask myself, because it seems he's actually better at repeating Microsoft press propaganda statements than anything else.
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.
>>My point is that the defaults of the language are almost uniformly dangerous.
>>This claim has no factual basis.
>What? No? As in none at all?
You said the defaults of the language are uniformly dangerous. A single example, or even multiple examples of dangerous aspects of the language does not support this claim, because (a) you'd need to show that these dangerous facets are "default" in some sense, and (b) you'd need to argue this for everything that's a "default" (whatever that means).
Lack of a garbage collector?
That's not a "default". It's a feature that the language doesn't have. It doesn't in any way support the "uniformly dangerous" hyperbole above.
No array bounds checking?
See std::vector. Use bounds checking if you like. In some applications (matrix arithmatic), I've found that bounds checking results in a 50% performance hit, so I'm glad that the language doesn't nanny me.
No constraints on pointer arithmetic?
Pointer arithmatic is not "a default". It's actually something you shouldn't need very often.
Automatic type casts usually with no compiler warnings?
Well, learn to use your compiler, and turn the warnings on.
I prefer the word 'damaged'
Use whatever word you like, but there are very good reasons for making the language C compatible. C compatibility is a two edged sword. On one hand, you inherit messy syntax and dangerous code. On the other hand, you also have compatibility with existing software systems, and a language framework suitable for developing high performance software.
You mean it's an eyesore, but because we know why, that's ok then?
No, it's an eyesore, because it makes tradeoffs. The tradeoffs (elegance/performance and compatibility) might not be "pretty", but purity and beauty are not design goals of C++. Solving real world problems is.
Look I've lived at the sharp end of the language more than most. I've worked on multi-million lines of embedded, persistent, realtime code much of it in C++, and without the benefit of the STL. Trust me when I say C++ has some major issues
So, why didn't they use java or smalltalk or LISP for that embedded, persistent, realtime code ??? I think you know the answer-- those languages make tradeoffs that make them more or less useless for embedded or realtime applications. On the other hand, the tradeoffs that C++ makes -- namely, tradeoffs in favor of compatibility and performance -- have a lot to do with the fact that you are using it for these things.
>>This claim has no factual basis.
>What? No? As in none at all?
You said the defaults of the language are uniformly dangerous.
No I equivocated. I said almost. And I stand by it.
So, why didn't they use java or smalltalk or LISP for that embedded, persistent, realtime code ??? I think you know the answer--
Yes, I know the answer ;-)
those languages make tradeoffs that make them more or less useless for embedded or realtime applications.
Bzzzzt. You lose. Actually we've redesigned it to be a mixture of Java and C, and ditched C++ entirely... The submillisecond hard realtime stuff is C, and Java is perfectly fine for soft realtime, and embedded. I understand that LISP or Smalltalk have been successfully used in similar situations as well.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Gee do you think? Perhaps you'd do that. We didn't. We were/are actually using classes extensively, some people (I count myself in this, I have been OO'd for more than a decade) actually know how to write them. We didn't do any compiling C with the C++ compiler either; we had two compilers that interworked fine.
Java isn't used for the realtime stuff, because you can't implement real time software when you have non-deterministic garbage collection.
Actually, we aren't doing this, but IRC; garbage collection issues can be avoided in Java. If you allocate memory ahead of time you can avoid triggering the garbage collector entirely. We were actually having to do the same thing in C to avoid fragmentation. Most of our soft realtime has response times of upto 2 seconds. Hard realtime is down to about a millisecond and has deadlines you have to meet.
Anyway modern incremental garbage collectors run plenty fast enough for soft realtime...
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"June's DDJ (#337) has a pretty good article in it about C++ conformance and actually goes on to test a series of compilers for standards compliance. Pick up the magazine and read the article which was pretty interesting because they used Python to write a test framework that could be used with different compilers and different operating systems. They tested compilers on Solaris, Linux, and Windows2000. GCC 3.04 ended up with the highest passing percentage while VC++ ended up with the worst. They didn't include either the DDJ compiler or Intel's which was one I was especially curious about considering I just got a demo of it.
I'm a loner Dottie, a Rebel.
There is nothing in your comment that has anything to do with Godel's Theorem.
Using C++ funky bits makes it much harder to control exactly what code the compiler produces, regardless of whether it's more efficient or not. You also need a runtime library for a lot of things. Those are the two main reasons C++ /isn't/ used.
/everything/, and when the compiler you're targetting is as portable as gcc, it's not even that big an isue for portability.
/not/ like userspace coding. The code tends to look much the same, but you operate under constraints that make the details vastly different, and which make things like C++ difficult propositions.
The control thing probably sounds like a red herring, but in kernel land knowing exactly what your code is doing is extremely important - every cycle really does count. Particularly in the core kernel, you often see strange and confusing constructs that are in there simply because they've been shown to produce faster code. And this isn't some kind of he-man "I can write more gotos than you!" crap - people actually sit down and look at the asm output from bits of code and decide which version is best.
That's the main reason why the kernel is so conservative about what compilers it builds on - there's code in there that relies on specific behaviour of gcc extensions to achieve the exact results desired. This probably sounds like a bad thing, but this is an OS kernel - performance is
Kernel coding is
himi
My very own DeCSS mirror.
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.
It really gets down to time management: would those programmers take the time saved by using a less-primitive language and use it to fix the design problems behind those slow programs or add a bunch of pointless crap?
I think the latter is more likely, no matter how much we might wish otherwise. Almost all of the slow programs we use are slow because of dumb code (from simple implementation gaffs up to complete architectural clusterfucks) and that's a language independent "skill".
sigh... Maybe I was too subtle?
A deep unwavering belief is a sure sign you're missing something...
I know it's kinda off-topic, but I need to know how you guys get that "google thread" thing.
Whenever I search the groups.google.com, even under the "thread mode", I get something like
http://groups.google.com/groups?hl=en&threadm=52f
instead of
http://groups.google.com/groups?hl=en&th=e653fbdb
So what has I done wrong ?
Muchas Gracias, Señor Edward Snowden !
Where did I say that?
But all this can be addressed by using object oriented code and STL.
Well, I certainly don't agree that switch statements disappear in sensibly written OO code, in fact absence of them is a sign of an inexperienced designer. Using polymorphism for that impacts both readability and speed, and implies a use of inheritance that is quite detrimental. Nearly all new OO designers misuse inheritance.
If you allocate memory ahead of time in C++, most of these "safety" issues that you complain about can also be avoided.
What colour is the sky in your world?
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"No, its very easy to support. You or I can write an entire book on the very obvious failings of C/C++ syntax. But, quite frankly I just can't be bothered here. You show no signs of being experienced enough with C++ and other languages to begin to appreciate it; plus in a few months all of these posting will be deleted. Only when you've learnt 20 or 30 computer languages and used atleast 10 in anger does it become clear just want went wrong- and what didn't (there's lots of good things about C/C++ too.)
Oh, ok, one more unbelieveably trivial example. Consider 'int'. What size is it? Yeah I know, its undefined 'for performance reasons'. WTF? What this really means is that a very significant fraction of programs are non portable; sure they might work, but as the size of the program grows, the probability approaches zero. If they had defined 'int' to be 32 bits, and created a different type, say 'nativeint', then only if you really need the performance would you use it. If you understand enough to know you want performance you use it. If you don't understand enough- I don't want people who don't understand what they are doing using 'int'. The standard language defaults are almost uniformly unnecessarily dangerous... and yes theres that equivocation again.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"If it's cheaper to buy a new server or ten than to write the program in a lower-level language and have twice the debugging time and greater risk of security concerns due to buffer overflows and such, then writing the code in a high-level language is the Right Thing to do. If you're writing something that needs every bit of speed available, and the hardware that would be needed to get the same performance in a higher-level language costs more than would be saved by the difference in your time... okay, have fun with your low-level language. Usually when I find myself in a situation like that, I know it's time to raise my rates.
That said -- a good civil engineer's techniques involve restrictions at their core. Every set of "well, we can do this..." incorporates hundreds of "but never do this, or that; and be sure that this load never exceeds that; and check for so-and-so". A good civil engineer's techniques are indeed self-limiting -- because only by playing within carefully defined limits can one be certain about the safety of the resulting structure. One of the things I agree with regarding software engineering is that far more dicipline is required in the field. Some of this has to be human dicipline -- there's no way around it -- but having tools that make it harder to make mistakes is a Good Thing too. Imagine trying to build chips without design checkers because the EEs should do all that work themselves -- it'd never fly at Intel.
Arrogance is not victory (-;
Oh, ok, one more unbelieveably trivial example. Consider 'int'. What size is it? Yeah I know, its undefined 'for performance reasons'. WTF?
No, it's undefined because it's undefined in C. Compatibility with C is a big design tradeoff-- and it's largely responsible for most of the sharp edges in C++, but it's also the main reason that C++ has enjoyed such widespread adoption.
Read up a few posts...
Re bounds checking, and unsafe pointer manipulations, these were among your citations of "dangerous defaults".
Well, I certainly don't agree that switch statements disappear in sensibly written OO code, in fact absence of them is a sign of an inexperienced designer.
A switch statement can usually be replaced by a table lookup or polymorphism. As you rightly point out, sometimes switch statements are useful-- another good reason to keep them in the language, huh ? (-;
Using polymorphism for that impacts both readability and speed,
Sometimes a table lookup is more appropriate than polymorphism, it's a little less opaque. A switch is essentially a sort of inlined table dispatch, so the only reason I see for using it is performance or convenience.
What colour is the sky in your world?
First, you're assuming that buffer overruns are the only possible error. This is simply wrong. Programs that do not have the benefit of static checking are prone to all sorts of wierd bugs, which ultimately can become security flaws. Apart from anything else, the assumption that C++ code always results in buffer overruns is just bogus. It's very hard to end up with buffer overruns if you stick to safe STL containers.
That said -- a good civil engineer's techniques involve restrictions at their core. Every set of "well, we can do this..." incorporates hundreds of "but never do this, or that; and be sure that this load never exceeds that; and check for so-and-so".
Yep. A professionals tools require some discipline to use.
First, you're assuming that buffer overruns are the only possible error.
Of course not. I didn't even say safe languages would fix even most security issues, only that the failure to use one would result in a "greater" risk of security concerns. Stop putting words in my mouth. I agree that static checking is extremely important. I do not see how use of STL containers are likely to be useful in fighting buffer overflow vulnerabilities -- most of the vulnerabilities I've seen have been inside boundary code (network or file I/O, parsing routines, &c) where the internal data storage mechanisms used after processing aren't particularly relevant.
A professional's tools require some dicipline to use.
Absolutely! But this dicipline is not strictly on the part of the user. When I buy a hammer, I don't expect to have a 3-part procedure I have to follow to prevent the head from flying off -- the tool should just Do The Right Thing, even if it means I don't get the benefits of a detachable hammer head usable as a counterweight. That is to say, the hammer should follow the Principle of Least Surprise. A good programming language should do the same.
So defining it for C++ would have made it incompatible? On reflection: No, I don't see that.
But that wasn't the point. My point was that many, many features of the language are unnecessarily dangerous; even an int; you haven't really grokked this point.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Read up a few posts...
I never said that anywhere.
As you rightly point out, sometimes switch statements are useful-- another good reason to keep them in the language, huh ? (-;
Of course, I love switch statements, but the syntax is much more dangerous than it needs to be. If fact you don't actually need 'if' statements, just use switch ;-)
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Oops ... I misunderstood you.
I do not see how use of STL containers are likely to be useful in fighting buffer overflow vulnerabilities -- most of the vulnerabilities I've seen have been inside boundary code (network or file I/O, parsing routines, &c) where the internal data storage mechanisms used after processing aren't particularly relevant.
In all of these cases, simply having containers that grow on demand deals with some of the issues, bounds checked access and using STL algorithms instead of loops deals with others. Basically, if you enumerate the things that can go wrong with respect to buffer overruns, I can enumerate a list of reasons why the STL containers address this.
Doh! I forgot to respond to this. There are a lot of things a good programming language "should" do, and suffice it to say, no programming language does all of them. This is where tradeoffs come in. Unlike most other programming languages, there is a well reasoned exlpanation (in book form) explaining how and why C++ is designed the way it is, and what the rationale behind the tradeoffs is.
For all practical intents and purposes, it would. Consider the implications of trying to reuse C libraries that declare functions that take arguments of type int, or data structures that aggregate ints.
My point was that many, many features of the language are unnecessarily dangerous; even an int; you haven't really grokked this point.
Most of the "dangerous" features of the language are a direct result of C compatibility. Compatibility has a lot of disadvantages, but it is dishonest to hype the disadvantages while belittling or ignoring the advantages.
It sucks that all these great technologies are being relegated to obscurity because of ...
... nice, but that's not enough.
I was trying to figure out how to end that sentence, and all I could come up with was Microsoft and FUD. I've been reading too much Slashdot!
Yes, you have. While it's true that MS can often save a language from obscurity (BASIC), it's hardly the only way, and making languages popular isn't MS's responsibility.
Languages like Java, JavaScript, and Perl are extremely popular, yet they owe little to MS. MS pushed for J++, JScript, and ignored Perl almost entirely until very recently, but that didn't matter much.
What it takes for a language to become popular is some huge advantage -- being the best way to do something that suddenly booms in importance (Perl for CGI) or having billions of dollars of development put behind it (Java, which was also in the right place at the right time), or being an incremental successor that keeps adding goodies to the most popular language (C++ absorbing C developers) so other (better) languages can't easily lure them away.
A language having some nice features is
I agree with your frustration, though. I really wish that it could be possible for each of us to create his dream language and just use it wherever we go. Create a way for that to happen, and you'll have real popularity.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
In all of these cases, simply having containers that grow on demand deals with some of the issues, bounds checked access and using STL algorithms instead of loops deals with others. Basically, if you enumerate the things that can go wrong with respect to buffer overruns, I can enumerate a list of reasons why the STL containers address this.
Then why do we still have buffer overruns, even in C++ code?
Even accepting your premise that Doing The Right Thing in C++ avoids buffer overflows completely, Doing The Right Thing in C++ is hard, or at least nonobvious -- as evidenced by the beginners (and experienced programmers who lack familiarity with C++) who do the wrong thing.
Should it be the programmer's duty to be sure they're doing the right thing? Of course! Is that any excuse for using tools that make it easy to do the wrong thing? Unless those tools have some other compelling advantage, absolutely not.
So... show me the advantage!
And lest you mention the flexibility involved in being able to do things either the C way or the C++ way or many hybrid ways between, I consider that a disadvantage, and a severe one at that -- redundancy in language design is a Very Bad Thing, as it means the language is not yet elegant; there's still more left to take away. A considered and defendable design decision? Certainly! The correct decision? No.
Hey- you're actually right for once!
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"As far as I can see, almost all the effort towards a new C++ standard is on the the library side. C++ has an excellent container library (STL), an ok library for serial i/o (iostream), but lacks libraries for networking, threads, file system, etc.
A bit of language cleanup is done, like getting rid of implicit int. However the major problem with regard to context sensitivity, the declaration syntax, is inherited from C and would be hard to remove.
I'd have to agree with this.
That said, I run into more projects (far more projects!) for which Java or Python or Scheme is appropriate than C++; at least in my line of work, performance is rarely at a premium
If you're saying these are "safe" languages, I'd have to beg to differ. Java has some static type safety, but unfortunately, the lack of generics (templates) greatly weakens this. Python is a very nice language, and the tradeoffs it makes are very sensible (in particular, it consistently prefers readability to writability). However, it doesn't make a whole lot of sense to compare it to C++. In my experience, Python does not compete with C++, it compliments it. That is, I use both C++ and python in the same project. As far as being "safe" is concerned, Python has no compile time type safety. It is well designed, and very useful, but I wouldn'y call it "safe".
Examples ? I never have buffer runs in my C++ code, so as far as choice of language for me is concerned, this is a non-issue. I suspect most such code probably predates STL.
Doing The Right Thing in C++ is hard, or at least nonobvious -- as evidenced by the beginners (and experienced programmers who lack familiarity with C++) who do the wrong thing.
No, it's not "hard" at all. There are beginners books, like Accelerated C++ that teach you to write code in a style that will prevent buffer overruns occurring.
Of course! Is that any excuse for using tools that make it easy to do the wrong thing? Unless those tools have some other compelling advantage, absolutely not.
C compatibility is a compelling advantage. It is the main reason that C++ enjoys its current level of popularity. As for "easy to do the wrong thing" ... I think you'd be hard pressed to find a language that doesn't make it easy to do the wrong thing in some form or other. For example, C++ is one of the few popular programming languages with sufficient type safety to prevent the programmer making type errors. Java, and interpreted languages all require a lot of runtime type checking (in Javas case, it's because the language lacks generics and uses a single rooted heirarchy instead)
I consider that a disadvantage, and a severe one at that -- redundancy in language design is a Very Bad Thing, as it means the language is not yet elegant;
Elegance is not one of the design goals of the C++ language. Largely because there is very little correlation between elegance (or purity or beauty) and usefulness in real-world projects.
All other things being equal, yes, of course. But in the real world, all other things aren't equal. The other languages have poor type safety, and in some cases, a lack of encapsulation. These factors also impact r maintainability (especially encapsulation!) But the more severe impact of not having type safety or encapsulation is that it severely hurts scalability, which is why C++ is still a popular choice for large projects.
you can make something with a messy design work, but the clean design is the one that'll actually be able to keep up with your requirements over 10 years of part-timer skeleton-crew maintenance.
That's why you want things like encapsulation and static checking. Clean design isn't that easy when every type of object looks like every other type, and there is no encapsulation.
How do you write typesafe container classes without generics ? In the case of java, you don't -- you abuse the single-rooted object heirarchy instead. Java containers are no more typesafe than perl or python containers.
I wouldn't say "no more typesafe" -- at least in Java you'll always get runtime errors for casting that which you get out of your container into the wrong type. Thus, if your compilation process includes a "make test" or some equivalent, such errors will always be caught. In Perl or Python you're not even guaranteed those (unless you try some use of the object which isn't available in the mistakenly-passed type).
Point taken-- this is a subtle but important distinction. The situation is still quite bad though, because the cause and effect of the error are separated by a wide margin -- that is, you could put an object of the wrong type into a container, and the problem wouldn't surface until you tried to access that element, which means that a simple backtrace (which java is kind enough to give you by default ... )
All that said, I actually like java. Sort of like C++ without the nasty C-isms. The only thing preventing me from using it is performance issues. But I'd still like to see generics.
A language can either facilitate encapsulation, or make it difficult. The whole argument against C++ in this thread has been that it's not idiot proof enough. So in this context, the fact that it may be possible to implement encapsulation via clever hacks is beside the point.
That said, there's still language support for encapsulation in all those languages I mention.
Python does not have any access protection on class members. Sure, you can write stub classes, but that requires more design, which eats away at this alleged "rapid development" advantage you're supposed to get from interpreted languages. And it doesn't alter the fact that you don't have private data. Java on the other hand has good data protection, arguably better than C++. Good C programmers can and do encapsulate, but then, good C++ programmers avoid the misfeatures of the language. C++ provides well-defined semantics for encapsulation.
If this were such a problem as you make it to be, one could (easily!) build a container class in Java that checks the types of objects put into it at runtime against a type passed in on its instanciation. (Heck, if it were a real-world problem, one would expect that Sun would have done it by now). Why don't I do it?
Because solving this problem in the general sense is roughly equivalent to writing generic containers. It's not easy to come up with a general solution, and writing once-off hacks is painful after a while. So the result is that you have a culture of subverting type-safety.
Making up objections because they seem like they'd be problems to you, however, makes you no better than those who c
and presuming you have an automatic test suite running after every compile -- which everyone should, no matter the language
If you want to talk about what everyone "should" do, they "should" use C++ correctly, by avoiding the dangerous features of the language (-; The language "should" avoid putting requirements on the user, such as developing test suites just to make sure the program is type safe. Of course test suites are good, but they are not a replacement for static checking. This is not an either-or proposition-- a test suite and static checking is more reliable than a test suite alone. Moreover, you get static checking for free in C++, and you can do other things besides checking type safety with your test suites. The other problem with test suites is that when you develop a library, your test suite can't check client code-- so you're requiring your clients to develop test suites as well.
A lot of problems go away if you test properly, or adopt a number of other sensible practices. Most of the arguments against C++ boil down to what happens when an idiot uses it. The bottom line is that no tool is going to allow idiots to develop large scale applications.
Regarding speed, btw -- depends on what you're writing, of course, but have you tried particularly new Java runtimes? I've been doing servlets lately, and have been very pleasently surprised by the performance.
If I were writing internet applications, I'd consider Java. As it is, I'm writing numerical analysis code, and that rules out java. Apart from anything else, bounds-checked element access is a performance killer in itself.
I've tried using these. Unfortunately, they don't work properly with inheritance.
Not hard at all. Take an extra parameter on container instanciation that refers to the class name. Every time an Object is passed in, verify that it's a member of that class. Easy. Done.
Perhaps I'm not understanding ... it looks like you're just doing an up-front runtime type check.
I suppose you've at least reduced the problem to something that could be detected with a backtrace.
You make that sound far worse than it is.
I don't mean to imply that it's the same thing as a reinterpret_cast -- it's comparable to a dynamic_cast (which is still pretty hideous to a C++ programmer.) Apart from the safety issues, it's also a substantial performance liability. (at least, my experience is that dynamic_cast is very expensive in C++.)
No wonder the roundup showed crappy results. They used GCC 2.95.2, which is three years old and uses a library that's even older.
GCC 3.x uses a rewritten library. I suspect their "library conformance" ratings would be quite different if they'd tested a compiler that's actually supported.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Not only are you offtopic, but you are OUT OF DATE!
;)
I had karma to burn, so I thought I'd use it getting the karma-free InSaNiAk with his l337 name and zero-content posts modded down. Despite my complaints, I was happy with the results, lame or otherwise
Yours Sincerely, Michael.