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.
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.
As for the lack of templates, I just haven't found it to be a problem -- interfaces have served my purposes suitably there.
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.
A language can be useful without being elegant -- but an elegant language will be more readable, more easily learned, more maintainable, and more fun to write in.
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.
Then why do we still have buffer overruns, even in C++ code?
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.
the only way to tell is by considering whether those tradeoffs are appropriate given the project in mind.
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".
So defining it for C++ would have made it incompatible? On reflection: No, I don't see that.
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.
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.
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.
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.
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.
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.
...code much of it in C++, and without the benefit of the STL.
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.
You show no signs of being experienced enough with C++ and other languages to begin to appreciate it;
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.
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.
Yet, you didn't use STL, and were constantly forced
to use unsafe pointer manipulations ? I don't really follow most of the complaints you made about C++: you talk about unsafe switch statements, no bounds checking, and dangerous
pointer arithmatic. But all this can be addressed
by using object oriented code and STL.
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.
(-; If you allocate memory ahead of time in C++,
most of these "safety" issues that you complain about can also be avoided. This can be done by
providing allocators to STL containers and/or
overloading operator new.
No I equivocated. I said almost. And I stand by it.
>
In that form, it is indeed a very weak and equivocal statement indeed, but judging by your snippage of my response, it's one that you're having a hard time supporting.
Bzzzzt. You lose. Actually we've redesigned it to be a mixture of Java and C, and ditched C++ entirely...
Hardly surprising-- from what you've said about your C++ usage (no STL, always using low level
unsafe features), one gets the impression that you
were never using C++ in the first place (compiling C with a C++ compiler doesn't count).
As usual,
you're dodging the question here. Java isn't used
for the realtime stuff, because you can't implement
real time software when you have non-deterministic
garbage collection. As for "perfectly fine for soft realtime, and embedded", soft realtime doesn't mean a whole lot, and "embedded" covers a broad spectrum of things. Java works fine on the Zaurus, but the fact remains that C++ is less of a
resource pig.
>>>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.
>>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.
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?
Not at all. ANSI C is portable, and will compile on
next to any modern compiler. There are a number of other reasons to use autoconf and libtool. The main for me are:
To provide compile time install options (eg --prefix=/foo/bar)
To provide build options (for example, debug versus release builds, Motif vs GTK vs console mode version of VIM, etc)
To detect non-standard third party libraries that your program requires, and check the versions.
To work out what commands to use to link and compile
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,
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.
Not at all. Redhat decided to wrap it up and make a release of it earlier than gcc, in the spirit of "release early, release often". I don't see anything wrong with Redhat jumping in and shortening what was an excessively long release cycle.
The gcc project have
used very long release cycles. Summary:
gcc 3.1 : may 2002 (?)
gcc 3.0 : june 2001
gcc 2.95 : july 1999
gcc 2.8 : jan 1998
gcc 2.7 : june 1995
Consider this in context of the fact that gcc 3.0.4 has bugs that basically make it useless as
a distribution compiler, and you've got a 3 year release cycle (between 2.95 and 3.1), much like the long 2.7/2.8 gap that led to the EGCS fork. IMO, this apparent bungling has vindicated Redhat, and taking matters into their own hands by effectively shortening the release cycle was a good move.
Note: About my insinuations about GCC 2.96 brokenness, I work side by side with a person who used to be on the GCC/GNU team, and has found strange bugs in certain version of the glibc that has been compiled by the 2.96 series. It went away when using release glibc compiled by release GCC.
gcc 2.96 contained bugs, but so did 2.95. Improving a compiler sometimes results in bugs that weren't there earlier ("regressions"), and we can see examples of this sort of thing in gcc 3.0.
There are a number of improvements in gcc 2.96. As someone who writes C++ code, I've observed some important improvements in support for ISO/ANSI C++.
It has been said that if a broken compiler compiles a library the library can be strangely broken and very difficult to debug.
I've got news for you -- all this emotive rhetoric about "broken" gcc 2.96 isn't supported by facts. There are a number of things in gcc 2.95 that are also "broken", and on the balance of it, gcc 2.96 comes out as a somewhat stronger compiler.
On a side note, as far as GCC 3.X not being prime time, for C is surely is, I don't know about the rest, but for C its, as far as I can see, quite useable, stable and reliable with some interesting new optimizations.
Hmmmm... I've had some very wierd bugs pop up with the "interesting new optimisations". Seriously, gcc 3.0 is a tremendous improvement in a number of ways, but there are some fairly show-stopping bugs (including a substantial C++ ABI bug which means that it can't compile KDE correcty) Because of this
bug, gcc 3.0 is unsuitable as a compiler for a
Linux distribution, and this is why no distributor
is going to ship it as the primary compiler.
I think that GNU has been a great force in the world, and to uselessly outpace them or point fingers at them is frustrating and bad for both sides of the camp
It's not "useless" outpacing. gcc 3.0 was late, and the 3.1 release that dealt with the stuff that needed fixing in gcc 3.0 was almost a year later. What Redhat did is released their own derivative version of the gcc 3 CVS that was customised for use as a distribution compiler. gcc 3.0 on the other hand is not useful as a distro compiler.
Programmers ignore in favor of GNU releases. Debian ignores it.
Programmers ignoring Redhat ? Laughable in the extreme. Programmers don't ignore it, but even if they did, it wouldn't matter, because anything that will copmile with gcc 3.0 and gcc 2.95 will compile with gcc 2.96. A number of distributors have included it.
Breaking C to fix C++ is kind of silly, wouldn't you say? I know it's not perfect, but it's a release, people build to it as a point of reference, and its anomalies are clearly documents as much time has passed since its release. Your "RH" secret sauce approach with no one knows what the f**k you did approach is so much worse, and it is ANTI OSS philosophy.
Horseshit. Part of the "OSS philosoppy" is that the users have the right to revolt and fork a project when the maintainer drops the ball. gcc shipped a gcc 3.0 release that was (a) late, and (b) too broken to use as the base for a distribution. The fact that the gcc 3.0 series was not fit to be used for a distribution vindicates Redhats decision to fork, IMO. RH need a compiler that can build a number of software packages, and gcc didn't provide that.
That's only because a lot of software includes workarounds for broken gcc releases.
It doesn't compile anything that uses the sstream header. It compiles a lot of nonstandard code. The 2.95 compiler has several severe problems with its standard library.
I use GCC 3.0.4, and it's a lot more standard-compliant than 2.96, has better error messages, and seems just as stable as 2.96.
Then why won't any distributor use 3.0.x as its compiler ? Why have RH released 7.3 instead of moving to gcc 3.0? The answer is that gcc 3.0 have some fatal bugs which prevent it from compiling KDE correctly. Fancy that-- they actually released something as big as 3.0, without checking that it could compile KDE correctly. Apparently, they've ramped up the C++ requirements for the 3.1 release, which means they're at least starting to take the issue seriously. However, this "ball dropping" exercise has kind of vindicated RH, who unlike the gcc project, need to ship a compiler that will compile the bulk of their distribution.
Slashdot Mirror
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.
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.
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.
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.
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".
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.
Yes you did
Of course, I love switch statements, but the syntax is much more dangerous than it needs to be.
What change of syntax do you propose, without breaking C compatibility ?
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.
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.
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.
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?
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.
Yet, you didn't use STL, and were constantly forced to use unsafe pointer manipulations ? I don't really follow most of the complaints you made about C++: you talk about unsafe switch statements, no bounds checking, and dangerous pointer arithmatic. But all this can be addressed by using object oriented code and STL.
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.
(-; If you allocate memory ahead of time in C++, most of these "safety" issues that you complain about can also be avoided. This can be done by providing allocators to STL containers and/or overloading operator new.
> In that form, it is indeed a very weak and equivocal statement indeed, but judging by your snippage of my response, it's one that you're having a hard time supporting.
Bzzzzt. You lose. Actually we've redesigned it to be a mixture of Java and C, and ditched C++ entirely...
Hardly surprising-- from what you've said about your C++ usage (no STL, always using low level unsafe features), one gets the impression that you were never using C++ in the first place (compiling C with a C++ compiler doesn't count).
As usual, you're dodging the question here. Java isn't used for the realtime stuff, because you can't implement real time software when you have non-deterministic garbage collection. As for "perfectly fine for soft realtime, and embedded", soft realtime doesn't mean a whole lot, and "embedded" covers a broad spectrum of things. Java works fine on the Zaurus, but the fact remains that C++ is less of a resource pig.
>>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.
Not at all. ANSI C is portable, and will compile on next to any modern compiler. There are a number of other reasons to use autoconf and libtool. The main for me are:
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.
C99 allows // comments
You're that "Egg Troll" guy who cross-posts trolls to all the comp.lang groups, right ? Well, nice troll. Cheers,
Not at all. Redhat decided to wrap it up and make a release of it earlier than gcc, in the spirit of "release early, release often". I don't see anything wrong with Redhat jumping in and shortening what was an excessively long release cycle. The gcc project have used very long release cycles. Summary:
- gcc 3.1 : may 2002 (?)
- gcc 3.0 : june 2001
- gcc 2.95 : july 1999
- gcc 2.8 : jan 1998
- gcc 2.7 : june 1995
Consider this in context of the fact that gcc 3.0.4 has bugs that basically make it useless as a distribution compiler, and you've got a 3 year release cycle (between 2.95 and 3.1), much like the long 2.7/2.8 gap that led to the EGCS fork. IMO, this apparent bungling has vindicated Redhat, and taking matters into their own hands by effectively shortening the release cycle was a good move.It wasn't a beta, it was a fork. Forking is what you do when the maintainer drops the ball. HTH,
gcc 2.96 contained bugs, but so did 2.95. Improving a compiler sometimes results in bugs that weren't there earlier ("regressions"), and we can see examples of this sort of thing in gcc 3.0. There are a number of improvements in gcc 2.96. As someone who writes C++ code, I've observed some important improvements in support for ISO/ANSI C++.
It has been said that if a broken compiler compiles a library the library can be strangely broken and very difficult to debug.
I've got news for you -- all this emotive rhetoric about "broken" gcc 2.96 isn't supported by facts. There are a number of things in gcc 2.95 that are also "broken", and on the balance of it, gcc 2.96 comes out as a somewhat stronger compiler.
On a side note, as far as GCC 3.X not being prime time, for C is surely is, I don't know about the rest, but for C its, as far as I can see, quite useable, stable and reliable with some interesting new optimizations.
Hmmmm... I've had some very wierd bugs pop up with the "interesting new optimisations". Seriously, gcc 3.0 is a tremendous improvement in a number of ways, but there are some fairly show-stopping bugs (including a substantial C++ ABI bug which means that it can't compile KDE correcty) Because of this bug, gcc 3.0 is unsuitable as a compiler for a Linux distribution, and this is why no distributor is going to ship it as the primary compiler.
I think that GNU has been a great force in the world, and to uselessly outpace them or point fingers at them is frustrating and bad for both sides of the camp
It's not "useless" outpacing. gcc 3.0 was late, and the 3.1 release that dealt with the stuff that needed fixing in gcc 3.0 was almost a year later. What Redhat did is released their own derivative version of the gcc 3 CVS that was customised for use as a distribution compiler. gcc 3.0 on the other hand is not useful as a distro compiler.
Programmers ignore in favor of GNU releases. Debian ignores it.
Programmers ignoring Redhat ? Laughable in the extreme. Programmers don't ignore it, but even if they did, it wouldn't matter, because anything that will copmile with gcc 3.0 and gcc 2.95 will compile with gcc 2.96. A number of distributors have included it.
Horseshit. Part of the "OSS philosoppy" is that the users have the right to revolt and fork a project when the maintainer drops the ball. gcc shipped a gcc 3.0 release that was (a) late, and (b) too broken to use as the base for a distribution. The fact that the gcc 3.0 series was not fit to be used for a distribution vindicates Redhats decision to fork, IMO. RH need a compiler that can build a number of software packages, and gcc didn't provide that.
That's only because a lot of software includes workarounds for broken gcc releases. It doesn't compile anything that uses the sstream header. It compiles a lot of nonstandard code. The 2.95 compiler has several severe problems with its standard library.
Then why won't any distributor use 3.0.x as its compiler ? Why have RH released 7.3 instead of moving to gcc 3.0? The answer is that gcc 3.0 have some fatal bugs which prevent it from compiling KDE correctly. Fancy that-- they actually released something as big as 3.0, without checking that it could compile KDE correctly. Apparently, they've ramped up the C++ requirements for the 3.1 release, which means they're at least starting to take the issue seriously. However, this "ball dropping" exercise has kind of vindicated RH, who unlike the gcc project, need to ship a compiler that will compile the bulk of their distribution.