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."
Give it another ten years, and we might have some C compilers that implement all of C99!
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!
Sweet :)
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
What compiler is used to compile Linux?
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.
> There are rumors they can compile the Linux kernel too.
Sjeesh this is news? I have been able to compile the kernel for years now. OK, I have to admit I do sometimes forget to put vital things in like netlink code, but then I just compile again and usually it works.
I'm sure there are hundreds of Slashdot readers who are able to compile the kernel so I don't understand what the fuzz is.
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.
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.
Why did you post?
Besides having nothing to say, you chose a sickening way to say it, the word 'sweet'.
I bet in your head you heard it as "shweet" too, but you didn't know how to spell it. That's even more sickening.
Yours Sincerely, Michael.
I am going to wait for the C_+ compiler from slashdot, instead!!
For a moment I thinked that it was something related to C#, like an expanded subset, named by an ascii art fan
"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?
i think, and hope, the parent was a joke.
Intelligent comments? I thought this was slashdot :)
This sig has been temporarily disconnected or is no longer in service
"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."
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.
If Bill Gates had a nickel for every time Windows crashed... Oh wait, he does.
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
It's interesting that you would say such a thing, as it only draws attention to yourself. Your comment prompted me to look at your comment history, and it is quite evident that you are an ass that has little trouble making enemies, simply by your presence. Of course I am citing the fact that your highest rated comment on the most recent 24 is ZERO- and there is only one of those. Some large group of people really hates you. Perhaps you should start listening to people (which is what you accuse me of doing), and after having done this, perhaps kill yourself when you realize how utterly useless you are.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
Seems the pet people have a sense of humour, which is more than can be said for the Linux clan. Bunch of fucking losers. The replies seem to be split between calling you a troll, insulting you, claiming you're funded by MS (fucknuts), and the obligatory clueless post that assumes you've told the truth and tries to argue around it. Beautiful.
Actually, my favorite bit was cross-posting to alt.fan.british-accent. One troll from you and then the entire Linux dev team spam it to buggery!
I rate that posting as an A
I couldn't help but laugh at the number of people complaining about detail-obsessed comic book/movie nerds, yet all I see so far in this thread are people bitching about the grammar and mistakes in the slashdot story!!
Worst. Story. Ever.
There will always be a tradeoff between CPU specific optimization and crossplatform portability. Ever hear of Goedels therom?
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.
Yay.
I've lost count of the number of times companies have claimed to be "standards compliant" only for this to turn out not to be the case when close scrutiny is applied to the product.
A USENET thread claiming that a product is standards complaint has 0 credibility in my book regardless of who stated it. On the other hand passing the C/C++ User Journal's compiler roundup's set of conformance tests from Dinkumware, Perennial and Plum Hall with flying colors is worthy of comment.
That said, EDG has long been producing the best C++ language compiler in the industry and if anyone could have achieved this I'd expect it to be them. However, running a front page story on Slashdot based on a USENET post lacks editorial judgement.
C was originally designed as a low-level systems programming language that would let you get close to the hardware. It was envisioned as a slightly higher-level version of assembly language. For that kind of work, it's a miracle if you get any reusable code from one platform to the next. But how did C end up becoming the language of choice for application programming?? It's a disaster.
C is like masturbation --- not very good, but always available.
Find free books.
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.
In my opinion, and I've done a LOT of both C and C++; C++ is just a rotten language. I've nothing against a launguage that can run fast. I just don't think that in these days of >2Ghz processors that 99% of software engineers need that much speed most of the time; and forcing engineers to code in a particular style that enforces speed but impacts reliability is just crazy.I'm fed up with my software core dumping, memory leaking and inappropriately casting. I'm tired of switch statements that fall through by default. I really hate off by one errors blowing away the end of an array. And I really hate the way its so easy to write software that is susceptible to buffer overrun attacks.
Let's face it, C++ is slightly warmed over 1973 technology, and it really, really shows.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"perhaps he cannot believe that someone with a +1 bonus wouldnt suppress the bonus on a magnificant comment such as this and let it stan on it's own merrits :).especially considering the author was having the story read to him.
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!
So what are you coding in ? VB ?
You should take a look a the Mozilla C++ Portability Guide. It's quite depressing.
Umm, on the contrary....
I am a grad student at an ivy league school, having graduated from the same school as an undergrad, and I took a class on UNIX that included its history, its inner-workings, and learning to write my own shell from scratch. My professor has been an avid user and developer for UNIX for a VERY long time.
You have it backwards. C was based off a language; B. C was created to write the UNIX operating systems as well as applications you mentioned. This was before OOP was in use (or possibly existed).
As for speed, OOP allows for the faster CREATION of programs through the use of objects (re-usability and potential ease-of-coding). However, due to a large amount of overhead, ordinary C will often out-perform C++ in most cases.
This post is in no way meant to be construed as mocking you or your knowledge. Perhaps we are both wrong, due to our sources of information (be it bias or otherwise).
I have read that one good thing about Java is that it does not rely on pointers for memory management. Is that true?
:) -- the VERY FIRST THING I wanted to try to do was to "dereference" this NULL pointer.
Also, I recently have begun a C++ class and on the subject of pointers, the textbook says this:
Never dereference the "NULL" pointer.
Well, after reading that, I decided that -- being a total programming geek after all
Unfortunately, the textbook did not go into detail about how this could be accomplished -- no surprise there.
So can someone tell me what the probably outcomes of dereferncing &NULL would be? Is it really as dangerous as the book's author suggests?
(It occurred to me that it might have a similar effect to something that I read about a while, back -- "Tao of Windows Buffer Overflow" -- an article by one of the founding members of the L0pht.
So does anyone here know how to "dereference the NULL pointer"?
I would appreciate some detailed sample code.
Supported C++ and C Language Features
This page also says:
--xPhase
The following sentence is TRUE. The previous sentence is FALSE.
1: You're both retarded
2: You're both retarded
3: You're both retarded
4: You're both retarded
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!"I'm fed up with my software core dumping, memory leaking and inappropriately casting. I'm tired of switch statements that fall through by default. I really hate off by one errors blowing away the end of an array. And I really hate the way its so easy to write software that is susceptible to buffer overrun attacks.
It seems to me that the drawbacks you speak of here are all found in C many which have been addressed by new semantics and constructs available in the C++ standard. It seems you were compaing C++ to C ?
Off by 1 errors? Are you using char *'s? Use std::string's. Are you using arrays? use STL containers and iterators (no more off by 1 errors)!
Memory leaks ?? Learn to handle dynamic memory allocation, its not very hard, it just takes a little design and thought.
C++ does not enforce the engineer to code for speed, it just allows it. An engineer should more often than not, code for reliabality and maintainability and optimize where performance issues arrise.
I think you are being over critical, each language has its place, and all have their flaws, C++ may not be your cup of tea, but that does not make a bad language.
My 2 cents...
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!"this is possibly the most interesting thing i've ever read on slashdot.
check Google, enter "The Programmers Stone". Download it, read it. Youre one of those "packers".
Get a clue. Until then, shut up.
Here we go again with numbers from the blue.
95+% of the time, switch statements should not fall through
While I can't argue with your experience, mine is not this way. There are many instances where you have progressive types of options where you want to do something additionally when you hit the next option. If you have written a compiler (maybe even if you haven't) you will realize that writing a switch statement involves a jump table. Avoiding jumps really helps speed, 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. 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.
even within one program designers rarely need maximum speed at every point.
While I agree completely with this, I have yet to see a good method of mixing this type of inherent safety one language provides with the raw speed of another. C++ perhaps has accomplished this the best. While not the safest, there are a lot of safety classes out there to use, and if those are too slow, you can still go the raw power.
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?
If you are familiar with the Standard Library, then you know that there are many tools here to do just that. And, they still do them efficiently for most things. Still, if you want to avoid the guards you can.
Oh yeah right. Lack of creativity and power.
Yes, I phrased this a little poorly. (Surely with the creativity part) But, I was thinking in terms of multi-paradigm programming with generics and operator overloading. Both of these tools can increase expressiveness and decrease programming time. Java's original implemetors (I guess they are considering templates) did not include these things because they are too dangerous. I personally dislike this philosophy because, as I referred to, good techniques can help you avoid most, if not all of the dangers.
Guess what? I got a fever! And the only prescription.. is more cowbell!
Shut the fuck up, cocksnot. No one cares what your well-fucked blood-dribbling ass tulip has to say.
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.
While most likely true that these programs don't use the best algorithm, and better algorithms are always a better way to solve a problem; not everything is an algorithm. All I was thinking of was implementing the same ideas in different languages. When, given the same algorithms, a language provides safety at a cost of cycles, if your code is too slow, then you need to consider a different language. I guess my main beef was that you claimed first that C++ is a terrible language, and second that 99% of the programs don't need the speed offered. (You clarified your position on this somewhat)
Finally, I still submit that not only does C++ offer greater speed and efficiency given the same algorithms than most languages, it offers greater expressiveness in accomplishing those ideas. No language should not get in the way of expressing algorithms. For me, C++ gets out of the way the best.
Guess what? I got a fever! And the only prescription.. is more cowbell!
First: I have personal experience with the EDG front end.
Second: This is only half (arguably less) of a compiler. They provide a front end that parses and typechecks the entirety of standard C++. They DO NOT provide a standard backend optimizer or code generator. They do provide a C++ to C translation system. Directly compiling the C probably won't result in very efficient code.
That being said, the EDG front end has some of the best documentation I've seen. It's available for non-commercial use to academics and researchers.
A lot of people license and use it, (Microsoft is a client, although not for VC++). Their code is clean and very well commented. The authors actually ask you to report any typos you find in the comments!
EDG can be viewed a lesson to open source developers. Creating extensive documentation and performing extensive testing are not frequently associated with open source development; in fact these activities appear to be frowned upon by a lot of developers I know.
<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.
Gentlemen, the time has come for a serious discussion on whether or not to continue using C++ for serious programming projects. As I will explain, I feel that C++ needs to be retired, much the same way that Fortran, Cobol and Perl have been. Furthermore, allow me to be so bold as to suggest a superior replacement to this outdated language.
To give you a little background on this subject, I was recently asked to develop a client/server project on a Unix platform for a Fortune 500 company. While I've never coded in C++ before I have coded in VB for fifteen years, and in Java for over ten, I was stunned to see how poorly C++ fared compared to these two, more low-level languages.
C++'s biggest difficulty, as we all know, is the fact that it is by far one of the slowest languages in existance, especially when compared to more modern languages such as Java and C#. Although the reasons for this are varied, the main reasons seems to be the way C++ requires a programmer to laboriously work with chunks of memory.
Requiring a programmer to manipulate blocks of memory is a tedious way to program. This was satisfactory back in the early days of coding, but then again, so were punchcards. By using what are called "pointers" a C++ programmer is basically requiring the computer to do three sets of work rather than one. The first time requires the computer to duplicate whatever is stored in the memory space "pointed to" by the pointer. The second time requires it to perform the needed operation on this space. Finally the computer must delete the duplicate set and set the values of the original accordingly.
Clearly this is a horrendous use of resources and the chief reason why C++ is so slow. When one looks at a more modern (and a more serious) programming language like Java, C# or - even better - Visual Basic that lacks such archaic coding styles, one will also note a serious speed increase over C++.
So what does this mean for the programming community? I think clearly that C++ needs to be abandonded. There are two candidates that would be a suitable replacement for it. Those are Java and Visual Basic.
Having programmed in both for many years, I believe that VB has the edge. Not only is it slightly faster than Java its also much easier to code in. I found C++ to be confusing, frightening and intimidating with its non-GUI-based coding style. Furthermore, I like to see the source code of the projects I work with. Java's source seems to be under the monopolistic thumb of Sun much the way that GCC is obscured from us by the marketing people at the FSF. 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, with none of the harsh restrictions of the BSD license. It also lacks the GPLs requirement that anything coded with its tools becomes property of the FSF.
I hope to see a switch to VB very soon. I've already spoken with various luminaries in the *nix coding world and most are eager to begin to transition. Having just gotten off the phone with Mr. Alan Cox, I can say that he is quite thrilled with the speed increases that will occur when the Linux kernel is completely rewritten in Visual Basic. Richard Stallman plans to support this, and hopes that the great Swede himself, Linux Torvaldis, won't object to renaming Linux to VB/Linux. Although not a C++ coder himself, I'm told that Slashdot's very own Admiral Taco will support this on his web site. Finally, Bjarne Strutsoup is excited about the switch!
Thank you for your time. Happy coding.
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
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?
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...
You need to take a programming course.
> C++ simply does not have the efficiency.
ummm... I had to deflate your little universe of naivity, but C++ has been proven to produce code faster than C and faster even that Fortran on numerical benchmarks, and this was years ago. The problem is that BAD C++ code can be slower than good C code.
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.
This post seems very familiar. In fact, it's a word-for-word repost of a post from a previous story.
Follow the link i gave.. my response is the second response, #3447013. It answers your question quite nicely.
>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 figured it out, just enjoying the opportunity to point out evidence that they are completely full of it. It's a shame that they have to be so stupid about it because I really like Java.
This sig has been temporarily disconnected or is no longer in service
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.
Hello,
Consulting for several large companies, I'd always done my work on Windows. Recently however, a top online investment firm asked us to do some work using Linux. The concept of having access to source code was very appealing to us, as we'd be able to modify the kernel to meet our exacting standards which we're unable to do with Microsoft's products.
Although we met several technical challenges along the way (specifically, Linux's lack of Token Ring support and the fact that we were unable to defrag its ext2 file system), all in all the process went smoothly. Everyone was very pleased with Linux, and we were considering using it for a great deal of future internal projects.
So you can imagine our suprise when we were informed by a lawyer that we would be required to publish our source code for others to use. It was brought to our attention that Linux is copyrighted under something called the GPL, or the Gnu Protection License. Part of this license states that any changes to the kernel are to be made freely available.
Unfortunately for us, this meant that the great deal of time and money we spent "touching up" Linux to work for this investment firm would now be available at no cost to our competitors.
Furthermore, after reviewing this GPL our lawyers advised us that any products compiled with GPL'ed tools - such as gcc - would also have to its source code released. This was simply unacceptable.
Although we had planned for no one outside of this company to ever use, let alone see the source code, we were now put in a difficult position. We could either give away our hard work, or come up with another solution. Although it was tought to do, there really was no option: We had to rewrite the code, from scratch, for Windows 2000.
I think the biggest thing keeping Linux from being truly competitive with Microsoft is this GPL. Its draconian requirements virtually guarentee that no business will ever be able to use it. After my experience with Linux, I won't be recommending it to any of my associates. I may reconsider if Linux switches its license to something a little more fair, such as Microsoft's "Shared Source".
Until then its attempts to socialize the software market will insure it remains only a bit player.
Thank you for your time.
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!"More importantly, they misspelled "vapour" as "vapor".;)
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
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.
Hmm same disease as HURD and stallman..
Okay whats next in 2012? It will compile COBOL?
Don't Tread on OpenSource
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!"but isn't the entire, entire point of trolling to get a reaction like that?
Wow, this is my first post in at least three months! We really need more digital video compression and / or Sealand threads on here I think.
- Chris
> 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 want to write programs about my C++ programs. I can't get the info I want from GCC, the free ones I found suck, and it's really really hard to write my own. Why can't these EDG folks let me use their software for free? Why isn't there a reference C++ implementation? Why is C++ so damn hard to parse?
Does anyone know a good way to get complete metatdata out of C++? Ideally it'd be complete enough to rewrite the source code, but I'd even settle for as much info as Java provides.
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.
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.
Just about 4 years ago, people like Patrick Naughton were telling me that I'm wasting my time with C++, and that Java would replace everything. (I heard that story before, 20 years earlier, with UCSD Pascal!).
Today, of course, C++ is the only choice for many real-world applications, and Patrick Naughton, Sun's Java Guru, is on the "Megan's Law" list as a convicted and admitted child raper
Now that's funny!
Use C++ because Java is for Child-Rapers
--
Ask the Ya-Hoot Oracle Anything!
i always thought that char = short = int = long where short takes at least 16 bits and long at least 32. but possibly even this isn't engraved on stone..
= should be <=
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.
the first thing my programs do is to mmap the zero page for that very reason.
... much the way that GCC is obscured from us by the marketing people at the FSF.
... wanna go in on it with me?
Dude, no problem. Post your e-mail address and I'll send you a couple of different versions of gcc source.
Plus I know this dude who promised to get me a 0-day rip of gcc 3.1 when it comes out if I pay him some $$$
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".
...and unlike your run-of-the-mill troll, it actually contains some partial truths and isn't intended to be taken seriounly by anyone.
Now, if some people are idiots and take the post at face value... well, that's their problem. But a troll it ain't.
from Comeau's site
"Although not a C or C++ feature, Comeau C/C++ does not generate multi-threading aware code, although you can surely write code or use functions/classes that implement such things."
Dont bother trying to use Comeau if your intending to do multi threaded stuff, my last company wasted 2-3 months of work converting the code to work in Comeau only to find that none of the threading stuff worked (that notice wasnt on the site at the time, its since appeard after we started shouting at them)
other than that its a good compiler shame its not of much use to anyone who wants to do any serious code (server apps etc)
The sad thing is that this sort of sarcasim is beyond %90 of mcse's comprehension.
http://saveie6.com/
It has more to do with the effiency of the code than the language, IMHO. For example, I opened a zip-file containing 3000+ files in ark and it took about 10 minutes to display the complete index! While just unzip -v takes less than 5 seconds.
I looked at the source for ark and discovered that the contents are retrieved by spawning zip and then parsing the output using regular expressions! Of course that takes forever. If they would just have used a zip library, display could be much faster.
The source contains even a comment like "could just as well parse output of unzip command"! Of course it's going to be slow that way.
I have always found it amusing that Sun continues to get away with the very same crap that MS has done. The only difference in Sun and MS is that MS was more sucessful at its raping.
He commented that this is in itself not a bad thing, but that there damn well better be the ability to have full functionality without ever using pointers... simply having the 'ability' but not the requirement to use them just adds to the tweaking ability of programs while cutting back on much of the complexity.
Seriously though, I have talked to many that say that the reason Java seems to be evolving into a C++ clone is that C++ is the way to do it, were its problems fixed. Consider C++ the old Prototype or proof of concept: we have proven what and how things can be done, we must not refine it and get it right. Java had the possibility to do this, if it were not for stupidity and politics that are resulting in the very same mistakes. C# has a great possibility technically, but again you have the politics, ego and greed that could screw everything up. What I want for christmas is the dream of a language that simply produces complete objective binaries that can be called from any compatable (there's the problem) language efficiently (not this horrible lookup mess and indexing crap) and that I can embed and integrate scripting languages like Python, Lisp and even more web centric ones like Perl and PHP without a giant amount of overhead. These languages should ONLY be the human interface to the computer code and so should produce binary data that is usable by anything.
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!"Hell, I can do it too. Pretty simple, actually:
- make bzImage
You can do it, too!--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Parent was not a joke. The kernel uses a lot of gcc extensions.
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.
Four more things:
1) What the hell do I care? Hemos' UID is even lower than yours, do get up and shout "Heil Hemos" every morning? I didn't think so.
2) "Some large group of people really hates you." Actually, English is my first language, and I'm damn good at it. There is nothing wrong with that sentence, and it goes against your minimal intelligence that you were unable to fathom its simplicity. Try going through it a couple more times, someday you'll get it. Perhaps.
3) What comments? Hey, just be glad it isn't "Post-Columbine Spider-Man in a Globalist Techno Geek World" so turn off the lights 'cause it's night on the sun +3 for spamming? Hmm... maybe I can pick up some extra karma too: Increase your ejaculation 800% with Ejacu-spurt! All natural, all legal, all herbal! "the" event? Which event is that? You don't mention a specific event in the story. Imagine if Slashdot had something like 'editors' to correct stories before they were posted... damn... that'd almost be something worth paying for. Wil, do you sell pairs of used underwear, and if so, how much? You pedophiles disgust me. this fp brought to you buy the hardy boys... SuSe is gnome-only, and Mandrake can do KDE or Gnome or whatever. How the hell would those be rewarded with high moderation? I think you need to recheck your definition of "infinite." Or at least your definitions of "intelligent" and "informative." Your posts are none of these.
4) Congratulations, you have managed to bring in the ultimate buzzword: September 11th! Oh hot damn, isn't this great? The son of a bitch named beee who started this little argument here is now accusing the articulate defendant of "tearing apart" the proverbial "us." O you, as shocked and outraged as you may be, are the party guilty of flinging four pieces of shit in my direction.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
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.
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 ?
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."
Would it help if someone documented that most folks using counterweights also need hammers?
Just because someone can write a book explaining their decisions (or because the tradeoffs involved in some design have a consistant rationale behind them) doesn't make the end product the Right Thing. A book could be written defending (say) Guido's design decisions in making Python, or defending the decisions behind R5RS. Neither of these facts makes Python or Scheme a more appropriate language for my hypothetical next project -- the only way to tell is by considering whether those tradeoffs are appropriate given the project in mind. 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 (usually -- when writing some code for testing embedded systems, the (very thin) client code ended up being best done in C, and the code running on the big beefy server found itself written mostly in Python). (FWIW, I've never had a project worth mentioning where Scheme was appropriate for the whole thing -- but sometimes some small component such as the test suite just screams for it).
As for me, the proof is in the pudding -- I go from concept to finished, debugged product faster using safe languages than unsafe ones. Maybe you currently work better with C++ -- but unless your problem space is crying out for the language (ie. you have a huge amount of legacy code), I suspect you'd be at least as productive, and perhaps even happier, elsewhere.
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.
I agree -- Python is not "safe" in the sense that Java is, and it lacks the compile-time checking done with C and C++. Weird and interesting error states are possible, and making demonstrably reliable Python software absolutely and unquestionably requires a large and well-maintained test suite (as all the error checking is done at runtime). The same's pretty much true of Scheme -- yes, the variant I use has compile-time type checking, but that's very much an extension, and purely optional, and doesn't look inside structures (and is otherwise quite limited).
So yes, it's a very different manner in which I use "safe" here -- it doesn't imply all-round reliable software, but just software where one particular (large!) class of problems is solved while others may exist. Suffice to say that I don't use Python or Scheme for code that needs to be reliable -- they find their way into surrounding stuff like the test suites or administration tools or are used in code built for internal use.
As for the lack of templates, I just haven't found it to be a problem -- interfaces have served my purposes suitably there. YMMV, of course; if you absolutely need a generic function that works on classes you didn't write and can't subclass (but which still has all the compile-time checking needed), that could indeed make for a bad situation (where one's handling Objects and doing introspection-style calls). That said, a good test suite will generally find issues in that kind of code -- and any worthwhile project will (hopefully!) have one anyhow.
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. (Does "fun" matter? Hell, yes! Granted, I'll still get the job done regardless, but I do my best work when I'm enjoying it).
The more extra stuff a language has upon that which is needed to be elegant, the more there is to learn; the more different "obvious" ways there are to implement the exact same thing (and so the more likely ways to run into bugs are available); the more individuals' particular coding styles affect the output; the more libraries one has to learn. Having a clean language helps in the production of clean code -- it's no panacia to be sure (I've seen horrid Python and beautiful Perl) but it's helpful. Like cleanliness of design, the importance of elegance should never be underestimated -- 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.
For that matter, one can "know C++" without knowing STL, and be pretty much useless in fact. One can't "know Java" without knowing the Java runtime, and being conversant with its proper use.
As for the particulars... well, I mention the lack of generics in the other thread; might as well keep it there.
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.
No encapsulation?! One doesn't even need any language support to do encapsulation -- one can do encapsulation in C, or assembly for that matter; it's a matter of good design, rather than language features. That said, there's still language support for encapsulation in all those languages I mention. What do interfaces do in Java? Stub classes in Python? (ya know... base classes with functions left to inherited classes throwing "NotImplementedError")? Hell, I can do encapsulation in scheme, and we both know it's a language not well suited to that. And every type of object most certainly does not look like every other type in Java (maybe when you're taking them out of a container -- but the moment you put them into a variable or call something with them, the checking is enforced). 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 IRL (at least if one does runtime testing... hence my emphasis on test suites!), the problem that addresses just doesn't come up, or at least doesn't result in latent bugs. If you need to write such a container class to take advantage of the other capabilities of Java, though, go ahead, and have fun. Making up objections because they seem like they'd be problems to you, however, makes you no better than those who can't see how Python's whitespace syntax could possibly be useful, though they've yet to try it.
Take the runtime checking into account (and presuming you have an automatic test suite running after every compile -- which everyone should, no matter the language), Java is as "safe" (in that usage) as C++ -- and given the use of GC rather than manual memory management, enforced runtime bounds checking (even in code written by poor programmers) and the like, it's considerably more so.
A good test suite will do more for reliability and maintainability than a little extra static checking ever will; presuming one to be in place either way, sacrificing the benefits of an elegant language for only that tiny bit of extra type checking is simply not The Right Thing.
Making the containers check the types of added objects upon their addition isn't a particularly hard thing -- though it's unfortunate that it isn't already implemented in the container classes included in the Java runtime. That said, you'd have to have the wrong object be added somewhere where it's either a return value put directly into the collection without being put into a variable (and thus type-checked!), passed to any other function in your code (and thus type-checked!) or explicitly casted to what it Should Be (say, before the cast to Object), or where the type it's being checked against is fully wrong.
If you've got a test suite that runs on every compile, of course, this is less of a problem -- if you just touched the code that adds an object to that collection at point *a* and the test suite starts failing, you know what's up even if point *b* is what the stack trace indicates. Granted, though, having proper compile-time checking on insert would be a much better thing. Doing it at runtime is probably not a bad idea, though it'd be unfortunate to have to provide your own container (sub)classes.
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.
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.
The whole argument against C++ in this thread has been that it's not idiot proof enough.
...you get static checking for free in C++
...a culture of subverting type-safety
Erm -- you're right.
(Might I add, however, that Python *does* have private variables, however little-used they may be. See section 9.6 of the tutorial).
No, you get static checking in C++ if you're not an idiot. It's sickening how many folks (ones who write C++ as if it were C -- something that wouldn't be as much of a problem if backwards compatibility had been ditched) still pass void*s around. The worst case in Java (an Object instance) is solvable -- one can find out what that Object was created as, for instance, or whether it can be safely casted to some other type. The worst case in C++ isn't; given only a void*, there's nothing really you can do with it without risking a segfault.
Because solving this problem in the general sense is roughly equivalent to writing generic containers.
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. Yes, it requires making a subclass of your container with a new constructor and wrappers for the insertion functions -- but that's all it takes.
You make that sound far worse than it is. "Subverting type-safety" is what happens in C when folks cast their pointers to (void*). Casting things to Object in Java is far, far safer because the objects still know what they once were, even if the container (usually) doesn't look at that data.
The bottom line is that no tool is going to allow idiots to develop large scale applications.
I utterly agree -- but given that an idiot is going to be maintaining my applications, I'd prefer that it be as easy as possible to understand what I'm trying to do and as hard as possible to screw it up.
As it is, I'm writing numerical analysis code...
Yup, that's definitely not a Java kind of problem. I haven't done any work in that problem space, so C++ may well be The Right Thing there -- where I work (and play), though, it certainly isn't.
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++.)
Exactly.
Apart from the safety issues, it's also a substantial performance liability.
Yup, that's part of why Java is slower than C++. I consider it a price worth paying -- and for the kinds of code I write, it is. For what you write, that price probably wouldn't be appropriate -- but them's the breaks.
Wrt private variables in Python -- hmm. Wouldn't know, haven't used 'em -- I've always just relied on good dicipline in Python to only touch the public interfaces. Of course, if what we're arguing is that it should be hard to do things The Wrong Way, that's not a valid argument... *shrug*. Yet Another Reason Python's not really appropriate for big projects -- but it sure is handy for the little stuff!
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)
Because it was offtopic. You made an ontopic comment to an offtopic response, and it was... well, lame. What do you want, 'insightful?'
Lest being called a hypocrite, I recognize that I'm offtopic too. Wah.
I think you need an auto first to pick up that volatile chick. Although, I think she'll still restrict your actions to the occasional union though. Besides, you have no class.
--JoeProgram Intellivision!