Slashdot Mirror
Interview Update With Bjarne Stroustrup On C++0x
An anonymous reader writes "DevX interviewed Bjarne Stroustrup about C++0x, the new C++ standard that is due in 2009. Bjarne Stroustrup has classified the new features into three categories: Concurrency, Libraries and Language. The changes introduced in Concurrency makes C++ more standardized and easy to use on multi-core processors. It is good to see that some of the commonly used libraries are becoming standard (eg: unordered_maps and regex)."
I saw the headline and thought I was seeing some 1337 form of "cox."
huhuhuuhuhuh he said "form."
will it be applied to C as well?
The grass is always greener on the other side of the light cone.
If anyone has used both Objective-C and current C++, can anyone tell me whether the new specification is a clear improvement on either if these?
Jumpstart the tartan drive.
Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python, or whatever is your preferred language.
"control of alignment"
I'd like chaotic good please
Knowledge is power. Knowledge shared is power lost.
Yes.
I'm a big tall mofo.
Been there, done that.
Most of the time, the potentially reduced running time of the C++ implementation never comes close to the months saved in development.
And when it does, it's trivial to go in and write the speed-sensitive portions of the program in a faster language.
If you mod me Overrated, you are admitting that you have no penis.
I want to like C++, heck, it was the first language I learned. But after so many hours of memory leaks and pointer-induced errors... My friend had mentioned at one point there was going to be transparent garbage collection in the C++0x standard. Unfortunately... looks like it's tabled for now: http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_garbage_collection Oh well.
Most/All NDS games are Written in C++. C++ is a great language because it allows you to do so many things and still run fast. BTW i love this quote from Bjarne: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows your whole leg off." -Bjarne Stroustrup
Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python
Those languages are way too high level. What you make up in development time will nowhere near compensate you for the greater processing time. I mean, CPU costs are through the roof these days!
But I have to say - even C++ is too high level. I hand code assembler with vi. That's what real number crunchers do.
I'm a big tall mofo.
...or, as a former manager explained it, "When C++ is your hammer, everything looks like a thumb."
So we are going to create the unmanaged form of C#?
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Have you ever tried writing a large-scale simulation code, for say dark matter/cosmology or cosmic-ray propagation in Java or C#? Please let me know when your code has finished executing.
Why the hell would you waste precious cycles running an assembler? That's what grad students are for!
Most/All NDS games are Written in C++. C++ is a great language because it allows you to do so many things and still run fast. BTW i love this quote from Bjarne:
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows your whole leg off."
-Bjarne Stroustrup
Yeah except he's absolutely wrong. C++ makes it much easier to shoot yourself, but the effect is more like dropping an atomic weapon on yourself.
I think Alan Kay put it best:
"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."
Kay goes on further to categorically state that C++ does not support object oriented programming because of the static type system.
hours finding memory leaks? How bad are you at debugging? Plus there are tons of tools to assist with memory leak detection. However, protection is no substitute for abstinence. Learn to write code better. BTW go do some embedded software with C# or Java.
I have C++ code that I maintain. It was written in 2004. I also use Firefox, Notepad++, FileZilla, 7-Zip, which are all written in C++. It seems like most the applications I run are written in C++, with many written in C and some Microsoft programs perhaps written in C#. Java killed C++? You wouldn't be aware of it from the software on my computer.
What a fool believes, he sees, no wise man has the power to reason away.
There's only one interview with Stroustrup that's worth reading: http://www.nsbasic.com/desktop/info/interview.shtml
{Science sans conscience n'est que ruine de l'âme}
C++? Isn't that dead and buried? Bjorne created one interesting thing in his life and he is hell bent on keeping it alive--after Java and C# have buried it. Anyone ever tried to get a C++ job? They are few and far between.
Maybe if you are the kind of programmer/developer that endlessly creates one-off database front end applications, this is true. C/C++ jobs are not hard to find at all. They just have a different target than you are apparently willing to work with. Try analytics. Try custom driver development.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
That's what this is... automatic memory management...bigger libraries... restricting pointers more and more....
I mean, C++ is evolving so badly it makes Pascal suddenly look a lot better as a compile time language.
This is my sig.
...what do people find so difficult about C++? Use the standard libraries, exception handling, and make sure your news all have deletes, and it's no more difficult than any scripting language. I actually prefer it over scripting languages, which have their place, but feel all sloppy and unspecific. It's like the difference between building a house out of 2x4s and building one out of sticks you found laying on the ground.
I'll consider Java and C# as C++ replacements once they get:
These points are serious, especially the first, without real templates, generic programming/metaprogramming at compile-time is not possible. These two are one of C++'s biggest strenghts, though.
To be fair, C# 3.0 is somewhat nice, especially its functional core. Java is a totally uninteresting language with very small expressiveness. Of course, if the job requires it, there is no discussion, but in my spare time, I prefer C++.
This sig does not contain any SCO code.
And when it does, it's trivial to go in and write the speed-sensitive portions of the program in a faster language.
Agreed. Premature optimization is the root of all evil. Write the control flow in a high-level, easy-to-debug language, and later optimize the pieces running unacceptably slow by rewriting them in C. No object-oriented language with legacy holdovers, static typing, and gross syntax needed.
Despite knowing it is a fallacy, I will instruct by appealing to my experience: 27 years coding, 10 of that with a salary, and 5 years before that as an entrepreneur. I have forgotten more C++ than most people know, having written everything from a reference-counting garbage collector to an entire content management system in it... and with the benefit of 7 years of professional C++ development, I can say with a straight face that it is the wrong tool for every job.
[ home ]
http://yosefk.com/c++fqa/ - this site says it all.
And it's also being argumentative and verbose at that, unlike your routine 'C++ sucks' rant.
Obviously c++ isn't really object orientated it was meant to be an application of object orientation on C. and still be able to run and compile C. Only an idiot would say C++ is the definition of an Object Orientated language. but why did we get on its not object orientated all i said was it runs fast and can be used to do a lot of things. It seems you want to say c++ sucks because its not Object orientated when I didn't claim it was.
Yeah except he's absolutely wrong. C++ makes it much easier to shoot yourself, but the effect is more like dropping an atomic weapon on yourself.
I keep hearing this, and every time I see the actual code, its a horrible mess. C++ has bazillions of features; if people are too stupid to understand them, then they shall not blame it on the language. The same people abhor Lisp because its so complicated, Haskell because its so alien etc. and stay in C#/Java wonderland.
Of course there are problems with C++, like the horrible, over-complicated syntax, slow compilation, etc. but most people dont come even close to these.
This sig does not contain any SCO code.
Well, it is like a fence: it protects you from falling over, but once it runs out, you may fall again. If you put the fence all around you, you won't be able to go anywhere further.
Similar thing is with protection provided in C++: it works against C kind of stupid mistakes but it brings in a set of its own stupid mistakes. There is always another downfall we are yet to encounter.
Therefore, and realizing it struck me this very moment, languages should be as permissive and empowering as possible (go ahead, knock your self out completely, foot, leg, everything!), but discipline should be enforced intrinsic to language definition.
Language should have means to enable us to construct discipline rule set and just blindly check consistency of code and attached discipline (akin to XML idea, although XML is not a programming language). To return to "fence" analogy, programmer (or project architect) should be allowed to construct new safety fences (or even remove old ones if necessary) as needs arise or problems are encountered.
I've found that the biggest advantage for C++ is the portability. I have written an application backend for PC's (back in the days of DOS) and since then ported it through various versions of windows, Linux (for web use), Palms, and Pocket PC's.
Using C++ allowed me to very easily make the different processor needs, compatible, by writing little compatibility layers, which would swap bigend values, unpack data structures from disk into memory (so is on even boundary). and so on.
Yes the fast speed was why I originally went with the C/C++ route, but the big benefit has been the portability.
...and roll on the C++-hatred! Second C++ article in a short time, and again lots of venom and anger. "Months saved in development"? Really? What are you doing, implementing your own OS before you start application development? Here's a newsflash: C++ also has support libraries, just like Java, Perl, Python and Ruby. They may not be part of the language specification (and I still think that's a weird idea to begin with, but I'm old-fashioned that way), but that doesn't mean they don't exist.
Anything you could want for in a modern language is there. And nobody is holding a gun to your head and making you write those scary templates if you don't want to.
I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++. Not that there is nothing to criticize about it, but it is still an amazingly powerful, versatile tool that programmers anywhere would do well to learn.
All my favorite video game engines are written in Java I hear.
This guy is an obvious troll.
One thing I've noticed is that you're much more likely to work with idiots if working on applications that use Java or C#. As the programming language becomes more powerful, the programmers using it are often far better and of superior education and degree.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
"C++0x" - it just rolls off the tounge!
But to their/his credit, from the Wikipedia entry on the "Haxe" language:
he name haXe was chosen because it is short, easy, cool, and "has an X inside", which the author claims is necessary to make any new technology a success. /quote
I really, really, really hope a lot of these things are implemented as compiler- or runtime-level features. I understand the purity aspect of implementing features as templates, but it just bloats my code and slows my compile times. A lot of the compile time for my apps is spent regenerating the same template crap over and over, then waiting on the linker to weed out what's duplicated. It takes forever.
C++ is to C as Lung Cancer is to Lung
You didn't get a big show of hands here, eh? 1997 called, he wants his raw pointers back. Nowadays we use any of the myriad freely available pointer wrappers and libraries. If you're using any framework at all, chances are you have a pointer class. STL, Boost, ATL, APR, MFC, MC++, etc. They all do. If you are a masochist, that's fine. Just don't assume everyone else is too.
Well, you're probably just trolling here, but C++ is hardly dead, and it's hardly crap. After all, the two languages you claim "buried" it are written in C++.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Actually I just did a couple of months ago. And I found more than one. In fact I'm sitting here at the one I took posting this while I wait for a whole lot of C++ code to compile.
You are forgetting about the areas where everything is "unacceptably slow" by default. I.E it's never fast enough. (Real time A/V processing for example)
What is needed in those circumstances is a language that is both "close to the metal" and allows for inline ASM, but also lets you do OO on the structural level.
What are the options there? D maybe?
And I can say with a straight face that you are wrong.
If you base your experiences on pre-2000s C++, you know very little of modern C++. I have been developing in it for more than 10 years, and a few years ago I would have agreed with you, but things have changed. Really.
This sig does not contain any SCO code.
The amazing part to me is that when people try to compare managed code -- like java or .NET -- to native code c, c+++ they make these wild claims about how much faster native code is. But they fail to mention that most of the managed code is running natively. And as far as your simulation, can you reasonably explain why it would be so much faster in c++ as opposed to say java that we would have to wait forever for it to finish?
Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python, or whatever is your preferred language.
Python + Numpy is probably faster that anything most C++ programmer can write, since it uses libraries that can be optimized for the specific processor they run on, including using multiple processors/cores if available.
Hand-optimizing code that runs on modern processors is not a trivial task at all (very simple example: caches can have extremely big and very non-intuitive effects on the speed of code).
Try writing a trivial (5 or 6 lines of code) md5 implementation using only the Python standard library and compare its speed to the GNU md5sum program (written in C). Hint: read blocks with sizes of roughly 10 kB.
There's a hidden treasure in Python 3.x: __prepare__()
Anyone ever tried to get a C++ job?
I had done some very light/minor C++ dev in my time, so I included it as an item on my resume. Last time I was job hunting (about a year ago), 90% of the calls that I got were for C++ positions, which I really did not want. I ended up removing it to filter out the noise.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
C++ also has support libraries, just like Java, Perl, Python and Ruby. They may not be part of the language specification (and I still think that's a weird idea to begin with, but I'm old-fashioned that way)
Agreed. The thought of C++ going the way of PHP (The number of built-ins is OVER NINE^WTHREE THOUSAND!!!) makes my soul die a little.
We will see the usual litany of C++ hating here in this thread. The hating will be generally based around misconceptions or problems that are 5 years old.
So to get them out of the way:
If you're leaking memory or spending time managing memory in C++, then you're using C++ wrong. Get a book written in the last 5 years.
If you're worried about compiler compatibility (with the exception of export which isn't much use anyway), get a compiler written in the last 5 years.
If you think that C does some subset of your task better, then write it in the common subset of C and C++ and quit whining. Or, write it in C and link it against your C++ code and quit whining.
If you think that templates simply provide code bloat, then get a compiler newer than 5 years old.
If you think C++ is slower than C, then get a good optimizing compiler (you know one written in the last 5 years) and do a benchmark. You will generally find that templates make C++ faster.
If you think "modern" languages are more expressive, then give "modern" C++ a try (insert comment about recent compilers here).
Sure there are valid complaints about C++, but the majority of them I hear on slashdot are complete bull. The majority of the remaining complaints will be fixed by C++0x.
One remaining problem is the lack of a vast array of standard, business oriented libraries. I don't write business oriented code, and I find the C++ STL one of the best libraries out there since it provides really good support for writing efficient algorithms.
Another problem is the difficulty in parsing C++. Sadly that's never going away.
But if you're going to complain about C++ compared to recent languages here, make sure that you're talking about recent C++ too, and try to make sure the complaints are accurate.
SJW n. One who posts facts.
Confucius say "Those who do not understand Lisp are doomed to reinvent it - poorly."
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
Fixed that for you. Maybe it's how you program?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
You do know that you don't have to screw around with any of that in a managed language, right? "Very easily make the different processor needs compatible" my ass--Java/C# do it on their own.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
and with the benefit of 7 years of professional C++ development, I can say with a straight face that it is the wrong tool for every job.
Just goes to show that no matter how experienced you are, you still have things to learn.. I program in C++/Qt full time at work, and for my side business. I did some years of Java, and every time we eventually ran into performance problems. Not to mention terrible platform integration. So I use C++ with a good cross-platform class library (Qt). No performance problems, just as easy to program as Java (although eclipse is nicer than most C++ IDEs), cross-platform, and integrated much better into any platform than Java is.
C# is right out, since it's not cross-platform. Any scripting language is not suitable for large scale apps (and performance is a problem). C is way too low-level to be productive compared to OO languages.
You used C++ for the wrong jobs, or used it with the wrong class libraries (MFC for example). Sucks for you, but if you use the right tools it just can't be beaten.
Thank the maker that I won't live to see it.
Sure - pick a reasonable Scheme implementation. Something like Gambit www.iro.umontreal.ca/~gambit/
Full number tower. Reasonable compiler. Sane syntax and semantics. Templates for performance? Sure, just partially specialize functions. Since functions are first-class, you CAN operate on them (just like templates, but without losing your mind). Macros that work, and, if you REALLY like infix notation, Gambit support "six" syntax -- a C-like syntax for Scheme.
Compile your code when you are done (both an interpreter and a compiler). Need MORE optimization? Drop in C bits; right in-line with the Scheme code. Or, for "better-than-C" compilation, move to Stalin. en.wikipedia.org/wiki/Stalin_(Scheme_implementation) Possibly the most aggressive optimizing compiler in (common) use.
Back to you -- why C++?
Just another "Cubible(sic) Joe" 2 17 3061
C++ is an extremely powerful programming language and that is why I use it every day. But it has one major problem: It is too complicated. As long as you do programming full time you are OK but if too much of your time is spent on the application side of things you quickly get in trouble. This is what people like BS don't seem to get - not everyone can spend 100% of their time studying the language.
No, the "premature optimization" thing applies to all areas. Especially areas where it's never fast enough.
Why? It's simple: resource management.
You have X amount of resources to put into your product. X is always finite. It's kind of tough to measure X, but you can think of it as lines of code, man-years, or even just dollars. The amount of resources you have varies a lot depending on your budget, how much time you have, and the quality of the programmers you have. But the important thing is that X is always limited.
Now you have two approaches:
Paradoxically, I hold that #2 will produce a faster program. This is because the X you spend on making the program faster in #2 will be more effective, because you've already laid the groundwork for it. It's always difficult and time consuming to optimize code that doesn't even run yet. It's much more efficient to optimize code that already works. So the result, even though you spend less X on speed, is a faster program.
Think of it as transporting a lot of material into the wilderness somewhere. If you first spend some of your resources on building a road, you'll get the job done for less time and money than if you just start hauling stuff into the woods immediately.
If you mod me Overrated, you are admitting that you have no penis.
You're doing it wrong.
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
The new "auto" declarations really fix one of the biggest gripes with C++. Everybody is dead tired of doing
std::map::iterator it = m.begin()
Now you can just do:
auto ip = m.begin()
It takes much of the pain away from static typing...
Save your wrists today - switch to Dvorak
A couple questions for you then:
1. If it was already written in one language why did you rewrite it in the other?
2. If it wasn't written in both languages how would you know it was just as fast?
If you really did write it in both languages I'd be surprised if it really was the "large program" the grandparent was talking about.
Wow, I don't know what I wrote to deserve such a response.
Speaking from my own personal experience, developing anything sizable in C++ takes much longer than in other languages. Maybe there are C++ gurus out there for whom this is not true. If so, good for them. It does not change my situation. For me, C++ is the wrong tool for the job, end of story. You don't have to agree with that, or even like it, but you ought to at least respect it.
If you mod me Overrated, you are admitting that you have no penis.
Building a self-consistent rule set as complex as a parser/compiler combination takes years and years of work to get it right. And you're saying leave that to the programmer??? That's the biggest maintenance nightmare I have EVER heard of.
It's bad enough that a new programmer has to learn the application idiosyncrasies; throwing in the fact that every instance of the language is fundamentally different would at least double the length of the learning curve.
I do however see the appeal of having a common syntax for several different styles of programming schema. Imagine having one punctuation set and operator set for a language that can be either script-like (no typing system), strongly typed, garbage collected, etc, and have it all inter-operate. I just don't think it should be left to the whims of some dude in the back room that would never document his intent and execution properly.
If you do go ahead and write it, I nominate Female+- as the name (see http://www.anvari.org/fun/Gender/17_Female_Rules.html )
They ARE out to get you simply because They are in it for themselves and they don't care about you.
How can you blame a language for shitty programmers. They shouldn't be called programmers if they need a syntax to hold their hands and say oh you didn't set this pointer to a reference so I won't run it please fix it. People that can't handle the raw power shouldn't receive it in the first place. I say ban people from using c++ if they can't handle it.
Great! That means in 2099, will have another "man made crisis" when C++99 is being superseded by C++100!!!
Or will we count by Hex? C++0x0x63?
Hopefully, we'll be up to "D" by then.
1. Boost.
2. Nonsense. Boost has facilities for this ("any", iirc) and also for something called "sum" types which can achieve what you want in a better way ("variant", iirc).
3. shared_ptr, weak_ptr.
4. Yup. Going to be fixed by C++0x.
5. C++ can be written to be a lot more portable than your Ruby or Python.
6. A matter of taste.
HAND.
And I can say with a straight face that you are wrong.
If you base your experiences on pre-2000s C++, you know very little of modern C++. I have been developing in it for more than 10 years, and a few years ago I would have agreed with you, but things have changed. Really.
Citation needed. What is post-2000's C++? Please enlighten me. All of my professional C++ experience occurred between 1999 and 2006, conforming to the 1998 ISO/IEC spec sitting on my desk, with various modifications made for broken compilers (e.g., VC++6, the lack of support for the export keyword in any C++ compiler I've used, etc.). If there's a later "version" of C++ that is supported by gcc, I have not heard of it.
I did some C++ programming in high school and college, but didn't really dig in until 1999. From that point forward, I spent far too much time building tools---like the aforementioned refcounter, or utilities for atomic access to shared variables across threads---to make up for C++'s shortcomings. After some time, I realized that I was wasting my time and should switch to using a language that comes with these features built-in.
My advice to my junior colleagues is simple: use Python or Ruby (not so much Perl, because of its syntactic ugliness and hacked-up object and exception models) for the control flow, and interface to C when necessary, using open source, peer-reviewed C libraries with existing Python/Ruby interfaces wherever possible. You will not only develop code more quickly, and develop more reliable code with better failure modes; you will make debugging much easier for other engineers who will inevitably have to dig into your code later.
[ home ]
You actually don't build a house out of 2x4s anymore. It's a lot more of 2x6s for exterior walls and 2x8-2x10+12s for beams and the like. 2x4's are merely for interior walls, at least according to most building codes.
I just don't like the expression, since it is quite imprecise. Languages are not fast? Is English faster than Japanese?
Languages can be more concise or terse, i.e. you write little and say a lot.
Now language implementation can be faster or slower (for exact same code), and almost always is (e.g. Intel's C++ compiler vs. GNU gcc).
As the island of our knowledge grows, so does the shore of our ignorance.
Well, that in itself is a point. I've been a coder for 20 years, and pre-2000 I used C++. I switched to Java and have not gone back. Perhaps the reason that "modern C++" is always forgotten is that maybe C++ didn't evolve fast enough, and Java and C# took over?
Towards the Singularity.
Just goes to show that no matter how experienced you are, you still have things to learn.. I program in C++/Qt full time at work, and for my side business. I did some years of Java, and every time we eventually ran into performance problems. Not to mention terrible platform integration. So I use C++ with a good cross-platform class library (Qt).
False dilemma and straw man all-in-one. I consider Java no better than C++, and worse in many respects. And where are the other choices? Was it really Java vs. C++, with no other options?
Any scripting language is not suitable for large scale apps (and performance is a problem).
False. You are stuck in the mindset where all aspects of an application need to be written in the same language. If that is your premise, then yes, you are doomed to use C++. I prefer the hybrid approach of using the best tool for each part of the job.
[ home ]
Read: http://www.amazon.co.uk/Modern-Design-Applied-Generic-Patterns/dp/0201704315
It's a good introduction to modern C++. While the book itself is not really helpful, it gives you a nice overview of "modern" development techniques.
This whole language X is better than language Y and Z is crap anyway thing makes me sick. Any discussion touching such subject tends to evolve into a flame.
Language is just a tool. Maybe one is better for some purposes than others but my experience of a contractor coder and QA engineer is that you can create mess in any language. If you build big applications than the mess may grow correspondingly big too. That is good so for people like me that test and verify this nice fresh mess.
This update used to be called "C++9x", but the committee got lost in template la-la land for a decade.
Thread-local storage is a good idea. GCC and Microsoft have had it for a decade. There's still no language guarantee that a pointer to a thread-local variable can't be exported outside the thread. But that was already true of stack variables. (Can't say "auto" any more; that keyword has been "repurposed".)
Threading is basically POSIX threads with new paint, plus some atomic primitives that have been around in incompatible forms since the 1990s. There's no improvement in thread safety.
Unordered maps were supposed to go into the original STL years ago, but somebody didn't get the paperwork in on time. Really.
It's no safer than the previous revision of C++. We're doomed to another decade of crashes and buffer overflows. Amit Yoran pointed this out when he was the director of the National Cyber Security Division at Homeland Security. (He resigned under political pressure for pointing out that Microsoft's poor security was the biggest part of the problem.)
At least they didn't put in "concepts".
Hey, nothing personal! I didn't really have time to respond to the earlier article, and I wanted to express my disgust at the C++-hatred on Slashdot in general, and your statement of "taking months longer" made for an easy enough target (months longer than what, anyway?).
So why is it taking you so much longer to write something in C++? Is the problem with the syntax? Standard libraries? Built environments? Something else altogether?
Have you the slightest clue about how computing intensive cosmology simulations are? Even on our 96 node cluster, a single simple run takes on the order of several days to finish. I have yet to see any Java/C#/Python code that can compete. I have been involved in developing code for simulating cosmic-ray acceleration in expanding supernova remnants, this in Python. It is incredibly slow and we can only compute on small grid sizes. Granted, on your little home desktop or even workstation, your managed code will do just fine. But that is on a completely different level. It is like comparing oranges and coconuts.
I am not going to go read a book simply to settle an argument: you need to summarize here.
In particular, explain to me why his techniques are not generally applicable to other languages (or to Python or Ruby in particular) or why using those techniques or similar ones and interfacing to C when necessary actually provide a less efficient development environment.
I know C++ can be made "acceptable" as a high-level language through sufficient effort; I spent 7 years doing such a thing. I want to know why that's a better solution than using tools that are---out-of-the-box and without reference to a magic cookbook---ready to do the things that require months of development or dozens of third-party libraries to achieve in C++.
[ home ]
Rather than rewrite it, I'll just direct you to another post I made. I don't claim these to be universal, but they're why I don't use the language.
If you mod me Overrated, you are admitting that you have no penis.
These are all very good points, particularly regarding RAII. I'm sure you know this already, but other languages such as Python provide deterministic resource management as well (in Python, it's the "with" statement). Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern.
> I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++.
Because C++ is not a pure language. It is a multi-paradigm language (imperative, OO and functional) with both a high and low-level language features and people seem to hate the aspect they which they don't prefer.
The close-to-the-metal types hate the high-level aspects and rather use C. Disregarding the fact, that changing the code from C to C++ is purely syntactical and runs without any detriment in performance. Exactly the prime idea behind C++.
The high-level people dislike C++ exactly for this approach. They don't like that the basics are so clearly visible, and are even the default. You have to hop through some loops, before you get to a higher abstraction layer. E.g. you have to use external libraries and/or special classes for memory management.
Personally, I like C++ for exactly that reason. I can start on a fairly abstract layer with pure virtual interfaces, smart pointer, signal slots and there is not a single (raw) pointer or a manual deallocation to see (or other manual resource deallocation).
Granted, it is more verbose than in a pure high level language, but that is what the machine has to do.
And if there is a performance bottleneck, I can seamless go down in the abstraction level from simple inline functions, over imperative functions with pointer arithmetic, down to inline assembler and can even guarantee a certain timing, if necessary.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
For me the main reason is that C and C++ allow you access to the "real thing", while other languages just wrapper things up and these wrapper have the tendency to be unmaintained, buggy, limited or simply being non-existent. So instead of writing tons of wrapper code and hunting bugs in wrapper code, I simply write it directly in C++.
Another advantage is that C++ is statically typed, never could see much of a real benefit of dynamic typing, since it just moves errors that your compiler would have found automatically down to runtime where you have to find them one by one, pretty annoying an time consuming.
That of course doesn't mean that C++ is perfect, it has tons of problems, but since none of the alternatives can do what C++ can do, there often isn't really much of a choice.
That's because we're running out of good lumber (the last construction company I worked for used imported studs ,) and skilled labor. Laminates and truss systems are even easier to put together.
Ask an average framer how big a birds mouth on a (insert example of pitched roof here with dimensions) should be, compared to how to assemble a truss package. Easy, instructions and even supervisors come with truss packages.
Here's a newsflash: C++ also has support libraries, just like Java, Perl, Python and Ruby. They may not be part of the language specification (and I still think that's a weird idea to begin with, but I'm old-fashioned that way), but that doesn't mean they don't exist.
I can't speak for Perl, Python or Ruby but I can say that the Java Language Specification only specifies a very small part of the standard libraries - some of the java.lang package. There's a distinction between Java the language and Java the environment.
Anything you could want for in a modern language is there. And nobody is holding a gun to your head and making you write those scary templates if you don't want to.
Everything I could want may be in there (although I doubt it - I want garbage collection without having to explicitly do anything) but so is a load of stuff which I don't want in a modern language. Maintaining other people's code is bad enough in Java: I dread to think what the people who wrote the project I'm currently trying to fix would have done in a language with pointers.
Many of the tools you described are in the tr1 already,meaning they are a de-facto standard, and official in C++0x. Using stuff like shared_ptr makes writing custom refcounting unnecessary in ~80-90% of all cases. I suggest you look up TR1, C++0x novelties, and Boost 1.36. Oh, and Modern C++ Design by Alexei Alexandrescu.
This sig does not contain any SCO code.
There are vanishingly few programmer geeks left on slashdot. Most of the "programmers" here, these days, are folks who've written a few scripts or set up a movable type install.
There are a few real programmers left here, but they're lost in the noise. You know, the roaring noise made by the python and ruby folks.
This post brought to you by a C++ programmer who happens to love Python and Ruby ( and javascript! it's an amazing language ), but uses the different languages where appropriate.
lorem ipsum, dolor sit amet
Post on a real account and you won't have to worry about it.
A library that isn't baked into the language may or may not exist, or have been tested, or work, on any given platform. And it may not coexist well with any other such libraries. E.g., your cloud computing API and your network stack don't use the same thread class, so now what?
Modern languages don't produce "undefined behavior" if anyone that was involved with a project has ever made a single mistake in handling references, pointers, or iterators.
And lambdas aren't a lot to ask. They were invented forty years ago.
I must be mentally ill, but, as much as I gripe about C++ and now C++0x, (even calling it C++#), I have to know, does anyone know when GNU targets the compiler to be due? I mean, I can't imagine them chasing a moving target but with the standard evolving I'm sure there's some stuff that they could work on.
I looked at their C++0x implementation web site, and it looks like they have a way to go:
http://gcc.gnu.org/projects/cxx0x.html
I like C++, even though I hate it, and this next incarnation has me tremendously excited.
This is my sig.
Improvements are always welcome, but this seems more like a case of a marketing exercise to try and keep C++ in the game as a serious language for general application development, which IMNSHO is something that should have been relegated to legacy systems.
Actually, the improvements are fundamental and the biggest change C++ ever experienced. concepts, lambda, variadic templates, type deduction, these aren't just nice toys. Add into this language-level support for multithreading, garbage collection etc. and you almost get a new language.
This sig does not contain any SCO code.
Maybe I'm not fully appreciating your problem with (2), but FYI, the "using" keyword in C# is pretty nice. It looks like this:
using(Bitmap mybitmap = new Bitmap(...args...))
{
// do work with bitmap
}
Once the program exits the "using" scope, the bitmap's Dispose method will be called (which for the sake of this argument is roughly equivalent to calling its destructor).
Yes, this sounds logical. C++ has only recently become interesting. C++0x back in, say, 1999, would have totally killed off Java.
This sig does not contain any SCO code.
I used to think like that, but then all the things you talk about are just syntactic sugar. There is nothing you can do with proper generic that you can't do in Java or C#. Yes, C++ is way more expressive than almost any other language, but that is also its peril.
And when was the last time you used meta programming to solve a concrete problem that could not be elegantly solved otherwise.
Most people learn how to calculate a factorial using meta programming techniques and stop right there. It's more of a curiosity than useful practical technique.
As the island of our knowledge grows, so does the shore of our ignorance.
To summarize it, C++ now moves toward design which allows to catch more and more errors during compilation. But at the same time C++ provides tools which allow to write generic code.
Wow, I second that. I have written moderately complex programs in C++ that port beautifully, often without any modification whatsoever. Using the curses library, you can actually have rudimentary GUI programs and good interactivity without any real platform-specific code. A couple silly programs I wrote for fun (sudoku solver, medical calculator) compile on linux and PDA with minimal modification. I can rest assured knowing that they will compile on run on just about any machine in the near future.
I view programming languages as a clear continuum -- from Machine to Assembly to C to C++ to C# to Java / Python / Ruby / MATLAB / script-du-jour. Choose where on this line you want to program, trading convenience/portability for speed/low level optimization/customization.
I, for one, have been always pleasantly amazed by C++. It's low as you want to go, near to C, but you get classes and their benefits (encapsulation, overloading, etc.) that makes larger projects much more easily organized. Manual garbage collection gets to be a pain, but I view this as a little bit of a necessary pain (though I admit perhaps I have just gotten used to meticulously keeping track of memory and pointers.)
Also, I think we need a car analogy: C++ is a manual transmission car, but Python is an automatic. They just get you from place to place, but the manual is a bit more difficult, sportier, customizable for your style, and potentially more fun.
Slashdotter, ID #101. UIDs are in binary, right?
Don't blame a real language because you need one of those dumbed-down tell-a-tubby languages.
Does mastering unnecessary complexity make you smart, or does it make you an idiot?
I'm sure you're very proud of your C++ skillz, but can you get a given task done in less time than someone using a better language?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
hours finding memory leaks? How bad are you at debugging?
If you think that taking hours to find a leak is excessive, the people at mozilla could do with some help -- they've been hunting them down for *years* :-P
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Programming is not like building a house. You don't get halfway through, change your mind, and then have to tear things down, wasting a great deal of manpower and materials in the process.
Building things that you later have to throw away is simply par for the course. Even if none of your Python survives into the final product, that prototype you built and then threw away is still going to make you more efficient overall. And this outcome is extremely unlikely. More likely is that you discover that all of the slow parts of your program only comprise about 10% of your code. And then you can take those parts out, replace them with C++, and leave the rest of the Python code in place.
If you mod me Overrated, you are admitting that you have no penis.
Apparently you've not heard of Hadoop which is written in Java and, unlike Google's MapReduce, actually available to people outside of Google today.
"I may not have morals, but I have standards."
What's the difference between C and C++?
C gives you lots of different ways to shoot yourself in the foot. C++ allows you to instantiate ten copies of ten feet and shoot them all at the same time.
The kernel of truth in this joke is that no language is going to make a lousy programmer into a good one. Rigor is required in every program. Rigor transcends language.
As for which language is best - learn many. Pick the best one for the given task at hand.
Weaselmancer
rediculous.
C++ was once thought to be a language that was powerful enough that it could be used to express most features that other languages had. With things like operator overloading, multiple inheritance, and templates, you could pretty much make a class behave however you want. But years later, we have seen that C++ failed at that mission. There are simple and common OO constructs that C++ is unable to represent. Rather than focusing on improving the template functionality, I want the OO syntax fixed.
Let me cite some examples:
1) It is impossible to make a string class that behaves "normally"
Plenty of people have tried. QT, Boost, STL, Gnome, WxWidgets, all have their own string classes. Years ago, when VB developers touted how easy it was to use strings compared to C++, I told them it was merely because nobody had made a good string class. After 10 years of trying to write one, and using dozens of other ones people created, I realized that C++ is simply too weak and too loosely typed to do this.
Suppose I make a string class, kinda like the STL string:
string foo;
1) foo = "whatever";
2) foo = foo + "bar";
3) foo = 7;
4) foo = foo + 7;
5) foo += 7;
Take a look at these. The first one is no problem. That can call an assignment operator to copy the char * contents to the string. The second one can also be done with a + operator. The third one can also be done via assignment. But what if you forget that? Well, the compiler will see that as foo = foo(7) which will call the constructor that allocates 7 characters, and then assign that. So instead of the string "7" you get a blank string. The next example is a problem too. If the string class can be converted to a const char *, as is common, then does this mean to use the + operator on string and an integer? Or did it mean to convert foo to a const char *, then move 7 characters ahead, then assign it? That can result in a crash. This is because pointer arithmetic is intrinsic in C++, but it is inherently type unsafe.
Then how about a function that returns a string? A simple case in most languages, but in C++ it results in redundant copies across the stack. So people revert to funny things like auto_ptr and other wrappers, or complex mechanisms for doing shallow copies to prevent that. Other languages just avoid the problem entirely by not allocating things on the callee's stack. It's just an intrinsic problem in the old everything-goes-on-the-stack-by-default mentality of C++. It just doesn't always work.
Properties are another one. This is something that various libraries try to do, and is free in most new OO languages. But just cant be done in C++ // C#
class Foo
{
private int _x;
public int x
{
get { return _x; }
set { _x = value; }
}
}
So in the above class, I want to access _x via a property get/set. C# has a built-in construct for this. In C#, I could do:
MyFoo.x = 7;
MyFoo.x++;
MyFoo.x = MyFoo.x + 3;
MyFoo.x/= 7;
etc. The compiler knows how to get/set x, and it can even be inlined! This allows me to do things like log when x changes, or see what accesses the variable. Now, let's try that in C++.
class Foo
{
private:
int _x;
public: // Get X // Set X // Another way to get/set X
int x();
void x(int);
int &x2();
};
MyFoo.x(); // Gets x, no problem // Weird syntax, but that is fine // Does not modify the value of x, hmmm... //
MyFoo.x(7);
MyFoo.x()++;
MyFoo.x2()++;// Modifies x, but only lets you track the get, not the set.
MyFoo.x()/=7;// Same exact issue
MyFoo.x(MyFoo.x()/7);
I do not understand why the post is modded "funny". Indeed, very fast SIMD libraries are coded in assembly. I think even 'liboil' has some parts coded in assembly
I would never do what you suggest. We have a hard enough time finding developers who are proficient in one language, much less two or more. I guess it depends on where your heart is. If your heart's in the technology you do whatever is the best option right now. If your heart's in the business, you do the best to maintain your sustainability moving forward.
Check out my lame java blog at www.javachopshop.com
I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++.
There are at least two ways to interpret that:
Now, "most popular" isn't automatically the same as "best", or else McDonald's make the most delicious hamburgers. Still, if a huge crowd of people who at least hypothetically have experience with the subject matter tend to have the same opinion, perhaps there's something to it.
Not that there is nothing to criticize about it, but it is still an amazingly powerful, versatile tool that programmers anywhere would do well to learn.
It could be that we learned it, cringed in horror, and went back to our more expressive dynamic languages. I have no fear of programming to the metal, but I bought a computer so that I don't have to deal with all the low-level gruntwork on a daily basis. There's nothing more powerful or versatile than raw machine code, but there's a reason why most of us use something else.
Dewey, what part of this looks like authorities should be involved?
Then you're hiring the most junior programmers you can find and paying them peanuts. You want talented staff with a broad range of skills? You need to pay reasonably well and encourage them to continually improve their skills. Fund additional training. Encourage them to involve themselves in coding related activities outside work. Reward those who show initiative.
Otherwise, you've got nothing but baby code monkeys who will never grow up to be gorillas.
Such as C++, for instance?
It's simple enough to deal with people who would abuse pointers in C++, if you're running the project.
Tell them that if you find a single actual pointer in their code that you haven't pre-approved for good reason, you will shoot them. It should only take a few pointers before the rest get the idea.
If you live in the sort of benighted country that lacks the casual death penalty for not following coding standards, figure out some suitable sanction yourself.
In my experience, people who write bad code have the flexibility to do it in any language. COBOL is a pretty simple language, and I've seen some truly frightening messes in COBOL programs.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Logical fallacy: higher level languages are in use already.
If you mod me Overrated, you are admitting that you have no penis.
> I have been involved in developing code for simulating cosmic-ray acceleration in expanding supernova remnants, this in Python.
Well, Python is a different game than Java or C#, which both have a much better JIT-compiler.
I mainly program in C++ (real-time data processing), but I feel hard-pressed to believe, that Java has to be severely slower than C++ in numeric computations. The Java implementations of FFT and LinPack suggest, that comparable performance should be possible. The SciMark 2.0 should also be more up to par, when you replace the synchronized Random in the benchmark with a Java implemented Mersenne Twister.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
Language is just a tool.
Sadly that's oftem true of the programmer too.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Well, python+numpy in a single cpu environment can be very fast, depending on what you want to calculate. But you completely miss the point; for really computing intensive work you have to go parallel, and I have yet to see anything in Java that works efficiently in a parallel environment.
You've never spent hours on a single bug? And you only work on code you yourself have written? Wow, I wish I were you. Then all of the memory leaks, uninitialized values, pointer screwups, etc. that I have dealt with in the past will either never exist or be easily tracked down and fixed within minutes.
Most of the development is done by the devs on their local windows machines, ant compiles everything nicely on any platform into a jar or war or ear or just classes, then you just copy the binaries to a Unix machine and it works. (of-course if you start using platform specific stuff, then you will have to do more work, but actually it's very rare for business apps. to use platform specific stuff, especially if it's all about databases and networks.)
The memory is managed by the JVM, which of-course does not prevent memory leaking in itself, but at least buffer overruns will not allow injected code execution, at this point anyway.
The libraries are part into the JRE and you can rely on them for being present.
There are many people familiar with the language.
Note that I didn't write anything bad about C++, which I also use and often link to Java. Why can't it be more about positives than about negatives? C++ has a place in the world.
You can't handle the truth.
I also have an extensive experience with C++, and I tend to agree with a lot of the criticism that it gets.
But the problem is that no alternative exists for the type of problems where C++ is used extensively. I guess the most important area is games.
The world really NEEDS a language (the last low-level language) with the low-level performance of C++/C and with a full, modern library, and modern language features (threading, modern module system (not based on #includes and a crude preprocessor...), optional strong typing system a la Ada with optional runtime-checking etc etc etc.
Basically, a really nice, compiled, well-performing, modern low-level language could easily exist. But it doesn't. So we'll have to settle for C++ until someone makes something better.
We pay markedly above market rates for developers and have a very good corporate culture with paid training we're practically begged to take. The market I'm in is driven by a small group of very big hitters in the defense industry. Most people try to get in there, get their clearance, and bounce around between the defense contractors for the rest of their career. Taking a job outside of the defense industry means letting their clearance (and practically guaranteed job any time they want one) to expire. Any other ideas you have?
Check out my lame java blog at www.javachopshop.com
then you don't bother trying. Hire specialists, preferably those who can turn their hand to something else but generally keep to one thing.
I mean, you wouldn't expect your DBA to code middleware applications in C++, you'd want them to be the best guru sql dev ever. The same can apply to everyone else - you need Web skills, get a web dev and tell him he only needs the basics of c++, java and sql but he'd better be "teh l33t hax0r" at javascript and html.
Often this approach makes everyone happier, there's less politics in a group, they start to work much more co-operatively and are happier in their roles.
Unfortunately, most people who are good like this are focussed on the technology. If they have to reskill every time something new comes out, they'll never be any good, they'll be continually junior developers as soon as they start to get good, its all-change time again. A good businessman would understand that and only introduce new stuff when there's a very good reason to do so.
Rewriting in another language, and then managing a multi-language application, is itself nontrivial.
Consider, for instance, a research application I'm currently working on. 95% of the code is extremely performance critical- every "run" takes 2 to 4 weeks of computer time. Dealing with multi-language complexities just to write the other 5% in something other than C++ would be stupid. Most changes between runs are either adding additional algorithms that run in a performance-critical fashion, or tweaking existing portions- the framework changes rarely, if ever.
The "premature optimization is the root of all evil" comment has a very specific limitation- it corresponds to low-level optimization. There's a lot of performance considerations that happen at the design and algorithmic level, and when you're initially contemplating the design for a project it is often obvious from the outset which pieces are going to be performance critical. Writing them in something other than a performance conscious language is just wasting your time.
The ringing of the division bell has begun... -PF
GCC should learn from Intel here. ic is way way ahead of them.
I've always liked Intel's compiler but I wonder -- what does ic do that gnu doesn't? Yeah, I know that gnu's error messages make no sense but it does seem to be more standards correct and to generate working code.
This is my sig.
If not, it can't do this:
char * p, * q;
while (*p++ = *q++);
You seriously think, as you post to a web site that runs entirely on Perl, that there is no evidence that higher level languages are in use today? Get real!
If you mod me Overrated, you are admitting that you have no penis.
trouble is, once you get past 1 object you're into a nightmare world of nested 'using' statements that make 'if then elseif' look good.
C++ is a write-only language. That's why it receives so much hate.
All languages are write-only in the hands of incompetent programmers. No languages are in the hands of competent ones.
"Convictions are more dangerous enemies of truth than lies."
C++ is a write-only language. That's why it receives so much hate.
Perl's getting plenty of love around here...
....posting this while I wait for a whole lot of C++ code to compile.
From the new list of "features":
> nullptr: a name for the null pointer
#define nullptr NULL
There, that was hard.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
95%? That's extraordinary! Inner-loops comprise 95% of your source code? I've never seen a program like that in my 25 years of programming.
They may not be part of the language specification (and I still think that's a weird idea to begin with, but I'm old-fashioned that way),
I work a lot with C++/Qt, but it's damn near that I want to say I program in Qt instead of C++. What's the problem with that? Well, I'm essentially lost if I have to work on a STL/WinAPI/MFC/wxWorks/boost/whatever project. Not in that I don't grok C++ which I do, but that I don't know any of the objects or functions or whatnot being in use. I do realize that there are differences between the libraries but certain basic functions should just be common, there's no reason why you'd need more than one string class. Sun got behind Java, Microsoft got behind C#, nobody got behind C++ and the result is that even the most basic of appliications can source-wise look completely different using different toolkits. It means that apart from equal syntax (and which kind of braces is the least of my problems moving to another language) there's barely something like "C++" - it's a loose family of code which happens to be compatible.
Live today, because you never know what tomorrow brings
I'm going to have to disagree with you. For CERTAIN kinds of optimization, I'll definitely agree with you. Things like algorithmic optimization can and should absolutely wait until the whole program is finished. Certain kinds of optimization, though, need to be accounted for from the start as part of the higher level design. Or example, the choice to use a formal graph representation of your data, or a specific database representation, or (to pick an example from 3D graphics) the kind of visibility determination algorithm you use, that has implications on the design of your entire program and IS something you should optimize for in the design from the very beginning, because changing that kind of thing at the end requires MAJOR refactoring. Just my two cents, but I think it's dangerous to say you should NEVER consider optimization until the end.
Stuff I would like to see, all of which is really simple:
1. A "0" type. The typename is "0" and the only value is the constant "0". This would expose the C fact that "0" can be cast to more types than "1" or void* can. The following allows fast compile-time initialization without an if statement and without having to put these functions inline (or the typical kludge of allowing the object to be initialized with any integer, which is silly but I have seen it done):
class Foo {
A* p;
public:
Foo(0) { p = 0; }
Foo(A* pp) { p = do_expensive_stuff(pp); }
};
2. Partial classes. You can already put "class Foo;" in a header file. The following syntax would allow all the same things as that statement, plus allow the getX() and setX() methods to be efficiently run:
... // this ellipsis must be last
class Foo {
int x;
public:
int getX() const {return x;}
void setX(int v) {x = v;}
static Foo& makeone();
};
Implementation would do this to finish the Foo class:
... // ellipsis must be first
class Foo {
int more_stuff;
Foo() : x(0), more_stuff(1) {}
};
Foo& Foo::makeone() {return new Foo;}
Yes I know you can do something like this with a derived class but I think that is stupid to have to make two names for what is really one type of object.
3. Even without the ellipsis shown above, you can define private inline functions outside the class definition. This allows implementation details to be hidden from the header file. Again I know it can be done with a derived class but the need for an extra dummy classname is really annoying.
class Foo {
public:
int f();
int g();
};
The following would be in an implementation file. It would act exactly as though the method implementation_detail() was declared in the private part of Foo:
int Foo::implementation_detail(int) { return stuff_used_by_both_f_and_g();}
int Foo::f() { return implementation_detail(1); }
int Foo::g() { return implementation_detail(2)*5; }
Sorry to hear it. Unfortunately, the English language belongs to the people who use it, and it is popular usage that defines terms, not the opinions of the people who merely happened to coin those terms. Forty years have passed since Kay coined the term, and guess what? The meaning has shifted.
By any sensible real-world definition, C++ supports object-oriented programming, whatever Kay might wish.
Yes, actually.
Structure is something like this:
There's a core dataset. A piece of that dataset is loaded, and then a set of about 30 individual algorithms are run on that dataset; they in turn produce additional data.
Once those algorithms are done, another set of algorithms runs on pieces of the data that the first set produced, and produces new data
Once *those* are done, another tier of the same happens, producing final results.
The only code that cannot be considered "tight loop" is the outer framework code that sets up the data structures and then calls the various algorithmic bits, and the code that interacts with the database. That together isn't more than a couple thousand lines of code.
The project basically entails calling a set of algorithms repeatedly on many, many, many different sets of data, and then aggregating and analyzing the results.
The ringing of the division bell has begun... -PF
Please expand: C++ is a functional language? Can you actually code without (imperative) assignment?
C++ is an OOP language? Can objects be completely isolated?
And WHY would "smart pointers" be needed in a functional language anyway? Or even in an OOP language. Isn't the point of EITHER of these paradigms to eliminate that need?
Just another "Cubible(sic) Joe" 2 17 3061
There's the rub. If it's not written in both, how do you know C++ is faster? By intuition? I think the one best lesson a code profiler can teach you is that intuition is often wrong.
I am my own customer for my primary piece of number-crunching Python. I gladly accept the fact that it takes a few hours to run instead of a few minutes like it probably would in super-efficient C++, as a tradeoff for having been able to write it so much faster.
The customer can do their own tradeoff. If the high level language is faster, then the product should be cheaper. If the customer values speed enough to pay the extra premium for a C++ version, they can do so.
If you mod me Overrated, you are admitting that you have no penis.
Sorry for replying to myself.
I guess that C++ could (in a demented way) be viewed as a functional language. I imagine that template expansion could be viewed as functional programming (assuming your compiler doesn't blow up) to implement this at compile time.
Just another "Cubible(sic) Joe" 2 17 3061
I entirely concede your point, while noting that this sort of higher level design optimization is completely orthogonal to choosing an implementation language.
If you mod me Overrated, you are admitting that you have no penis.
If you need to rewrite something for speed, advocating C over C++ makes no sense -- for any given piece of C code, there is equivalent C++ that is just as fast, and with only a few minor exceptions (no pun intended) the exact same code will compile as either one and with an average compiler will run the same speed either way. On the rare occasion that you need to change the code at all (e.g. you've used 'class' as an identifier) the change is purely syntactic, and still has no effect on speed.
In the other direction, it's often fairly easy to produce code in C++ that's substantially faster than any reasonable equivalent in C. An obvious case in point is std::sort compared to C's qsort. For many cases, especially primitive types like int, std::sort will typically be three to five times as fast as qsort when operating on exactly the same data.
Most of these could theoretically be handled in C by a combination of writing specialized code everywhere needed and (perhaps) some unbelievably gross macros. I've been programming just about as long as anybody (going back as far as writing FORTRAN 66 on Control Data mainframes) and based on my experience, I'd say 1) this doesn't happen often enough to matter, and 2) thank God for that.
The universe is a figment of its own imagination.
I don't know. Someday, when there IS a better language, maybe we'll find out.
Don't get me wrong: IMO, C++ sucks. But the alternatives suck even more!
The universe is a figment of its own imagination.
As for libraries, they're there, and, IMNSHO, do not belong in the language definition.
I like that C++0x concepts will add some type-checking to the template system, though I'm not sure I follow all the examples in the referenced article.
I'm not sure I like the native iterator support that is proposed -- it looks too much like C# to me: where the acceptable syntax depends on the object's type to such a degree that the orthogonality of the language over the type system is broken -- and implicit conversion of explicit arrays (over objects of a base type in contiguous memory locations) to iterable objects strikes me as a hack.
I would much rahter have the array syntax [] extended to represent enumerable (and thus iteratable) collections of objects.
But, my biggest lamemt is no means to turn off language features in an enforcable way, much like the C# notion of "unsafe", but in a more generic fashion: nothing stops one from taking a bald pointer or reference to an object, and that busts any reference-counting memory management system right there. Either the scope of such things must be strictly controlled, or they should be selectively not permitted. That addresses the concerns of those who dislike exposure of low-level capabailities at the wrong level of abstraction, while permitting the coding of custom memory managers where necessary.
In Liberty, Rene
> Well, python+numpy in a single cpu environment can be very fast, depending on what you want to calculate.
So can be MATLAB, as long as it matrix-multiplication, which is practically reduced to a single call to an external C++ library. Java, in contrast, has native implementations of numeric algorithms, which are on par with C(++) ones.
> But you completely miss the point; for really computing intensive work you have to go parallel,
I am well aware of that. I assume you've seen, that the Java version of FFT is, like the C version, running multi-threaded on a single computer. So, I guess you are talking about computer cluster.
In that case, I/O latency and bandwidth should be the limiting factor, which should be fairly language independent. Also, communication should be only a small part of the computation time, which makes the impact even smaller.
> and I have yet to see anything in Java that works efficiently in a parallel environment.
Not so long ago, people argued the same way in favour for Fortran over C++, but
as someone put it so eloquently: The absence of proof is not the proof of absence.
From what I gather from a quick search: The results of Java MPI bindings didn't look too favourable.
MPJava, however, suggests that comparable performance is possible (within 10% of the Fortran/MPI results in NAS PB Conjugate Gradient benchmark).
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
The C syntax is horrendous, the conversion rules chaotic
Bjarne Stroustrup, creator of C++, is saying that C has a horrendous syntax and chaotic conversion rules...
Hahahahahahahahaha.
Someday, when there IS a better language, maybe we'll find out.
I can name half a dozen. Maybe you should get out more.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
No, you can't. At least not knowing the parent's application domain, you can't. If you think you can for me, then try suggesting a better language, so I can have a good laugh.
SJW n. One who posts facts.
"Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern."
Really?
What about:
COBOL
FORTRAN
VB
Prolog
Lisp
ML
In fact any non-OO languages , given that RAII is an OO concept.
I'm going to the casino. Don't gamble.
You claim you can without even knowing the application? Maybe you should think more.
The universe is a figment of its own imagination.
Lots of heavy number crunching applications don't really care how long they run.
In my case, I run my app about six times a year. Each event involves running it a few times to refine things. To me it is well worth the tradeoff to save a lot of programmer time for a few hours of CPU time, which is essentially free for me anyway.
As for Azureus, I'm pretty sure that the Azureus programmers would be capable of making it bloated and slow in any language. Its bloat goes far deeper than just using Java. Just look at its GUI! In any case, people who use Azureus must think that it's a good tradeoff.
If you mod me Overrated, you are admitting that you have no penis.
C++ is not a multi-paradigm language. You are confusing the meaning of procedural and imperative. All OO languages are imperative (based on state mutations). The organisation of those state mutations is OO rather than procedural like C. This is quite a weak difference, they are both within the same imperative paradigm : the difference is merely how code is organised on the medium scale, and how namespaces are split.
It is often argued that the templates in C++ form a functional language. This is partially true. Template programming can only be performed at compile-time, not at run-time so there are many programs that cannot be written this way. So it is not possible to write C++ programs in a functional style - it is only true that the type system can be abused to write some programs in a style that looks a bit functional.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Maybe you should think more.
I do, and that's why I abandoned C++ around fifteen years ago.
Look, I'm sorry that you have your ego wrapped up in defending the indefensible, but that's your own cross to bear.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
MOD PARENT UP. Calling it a "Troll" is disgusting.
How much does it matter to you that Python is only bytecode compiled, allowing easy de-compilation?
It seems to me that the fundamental problem with C++ is that the development of the language that will happen in 2009 or 2010 should have happened 10 years ago. It amazes me that big corporations use C++, but aren't willing to support the language.
So, why don't you put us out of our collective misery and tell us what language is better, then?
SJW n. One who posts facts.
If 95% of your code is in the critical path for optimization, why use C++ instead of dedicated hardware or assembly language? Perhaps if it's all numeric you can get autovectorization to pick up the slack without resorting to other languages. How much memory management do you have to worry about?
Autovectorization does a pretty good job of boosting performance, though it's not all actually vectorizable (too many cases and branches). It is pretty much all numeric- a mixture of integer and floating point.
Dedicated hardware is definitely not workable; the algorithms are in pretty much constant flux - it's a research application, so a lot of what's going on is testing new algorithms, or tweaking existing ones.
Memory management is extremely minimal, by design (malloc and free aren't cheap). A chunk of data is read from the DB, a block of memory is allocated for results to be written into, and then various algorithms look at various parts of the big chunk and produce output; the DB is only hit for new data about once every hour per process (the whole thing is massively parallelizable on an extremely coarse-grained level, so we usually have well over a dozen independent processes running to split up the work- throwing more hardware at the problem is definitely something that's slowly happening, but that doesn't change the need for optimal code to reduce the amount of hardware that needs to be used).
Assembly language is possible, of course, but the portions of the algorithms that don't change all that often and are therefore good candidates for assembly language tuning are also the portions that we get very good results from with just the compiler; the effort to move them to assembly language wouldn't get us sufficient benefit to be worth it. Oh- we're using LLVM as our compiler, which gave us a pretty decent speed boost.
We're constantly profiling the app, tweaking algorithms for performance. New algorithms are surely written to *work* first and to be optimized second- but given that we know it's going to need that optimization, there's really no point to starting the write in anything other than c++.
The ringing of the division bell has begun... -PF
VB.Net does, actually. Anyway, I was referring to object-oriented languages, which I should have made clear. I included C on purpose, as various people out there will tell you how "easy" it is to write object-oriented C code, so I guess that was a bit of a dig at them.
write the intensive kernel in both and measure the performance. It should be a tiny part of the overall code, and if that's too expensive, you probably shouldn't care about the difference anyway.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
The fact is, given the complete lack of information you have available right now, suggestion you might make would do nothing more than open you to public ridicule.
The universe is a figment of its own imagination.
You obviously never wrote a single line of (C++) server code. When you have your code running in production, and it suddenly starts to leaks after two weeks of running, there's very little you can do except to hope that your logging is good enough to help you figure out the problem. Tools to assist with memory leaks? In my experience, vast number of such tools are unusable when you go to big league (when your code uses 1+ GB of memory) - when you run your program with such tools, it usually slows down so much that you don't have a chance to see actual leak (except if it's really trivial one)
I thought my reference to COBOL would be enough to imply that I meant in the corporation where I think most of us work.
Do you use COBOL at home? No, of course not. Some industries (insurance, finance) still do run that. C++ is gone from industry except for a few places, such as you mentioned. And companies these days don't want to spend endless time while you perfect your microscopic bit of code to do some tiny thing. Face it: developers are more productive in the newer languages: Java & C#. Those languages were invented precisely to overcome the obvious weaknesses of C++. If you are a C++ guru then you are a master of the Edsel. What I've noticed is the great number of Prima Donnas you meet in a C++ shop. Developers who have spent years perfecting some tiny app. Well, there is not time. These people cannot survive in any typical modern corporation where you get single digit days to get a large application or feature set done. If you're a dinosaur, you should just lie down and take your extinction with a smile.
Well, full disclosure: I'm not up on the latest band aids you guys are using to overcome the inherant weaknesses in C++. I agree that C++ is a fast, powerful language. I full-well know that both Java and C# are written in C++. The fastest language of all is Assembler. Having been exposed to a tiny bit of that, I know why it's so fast in execution: it's bare metal. I do not doubt the power of C++ in the hands of the specialist. My question pertains to its suitability for the wild corporate environment. I think C++ is like Assembler. Though its raw power is always available, the difficulty of executing code in Assembler and C++ should discourage it from being used as a standard. If you want to become the expert at Assembler or C++, be my guest. I just would NEVER recommend to any company I work for that we choose C++ for a project. I have seen quite a few projects that were rewritten from C++ to Java and we ended up after the refactoring with a better executing app. The old version was so brittle and ill understood that no one was ever willing to tinker with it. The old version was opaque because it was written in C++ and of course had no notes in the code. One guy wrote it and the manual was in his neocortex. You are free to label me a troll. Anyone who pushes you from your comfort zone would qualify, I suppose.
Nothing more, nothing less. C++0x does not change that fact.
Having a memory model is a good thing though :)
As the document shows from page 3 to 7, C++ values efficiency a lot. If that's a requirement C++ is great. Criticism that C++ is not Python/Java totally missed the point!
http://www.research.att.com/~bs/abstraction-and-machine.pdf
You must not do much bit twiddling or memory alignment in C# and Java then.
They most certainly don't do any of this on their own.
Microsoft has entire articles dedicated to converting endianess in C# on MSDN. Java is just as bad. Which is a problem because endian conversion is often required in network communication (kind of a big deal).
God forbid you ever have to write to a specifically aligned memory address in C# or Java.
Just the sight of his picture makes you shudder? Oh, don't wary. It is just Pavlov's reflex, Mr Guinea Pig.
If enithin kan gow rong it whil. (Murfey)
For many, there isn't.
Java: operator overloading
No, never. Operator overloading is one of the worst features to be added to a typed language. I don't want to have to account for a billion different cases for the + operator because someone thinks a+b looks better than a.add(b) or that the shift operator should somehow be used for streams in addition to bits. Operators belong in the realm of reserved words that should never be redefined from their original purpose. If you are defining your own operation on your own types I expect an identifier with a well chosen name rather than yet another function tacked on to the meaning of '+' that is sorta like addition but not really.
In Lisp there is something functionally equivalent to RAII. It is a macro that opens the resource, lets you pass the code to process it and closes it. Very neat, and it does not need special language support.
Very insightful point. C++ is like a Swiss army knife and those folks who tend to be negative by nature can always find something they don't like about it (much like life and everything else really).
Don't forget C#, but then it's basically an enhanced form of Java.
If you think "modern" languages are more expressive, then give "modern" C++ a try (insert comment about recent compilers here).
If I were going to ditch my preferred more expressive language, why wouldn't I just go to something like D?
Tweet, tweet.
Stick to your modern languages kidz, don't spoil the party B-)
Maybe you should hate C++. We really do not need that kind of expertiCe around :-)
I wouldn't want to work with whoever's servers you are maintaining. None of the C++ servers I've worked on have had the same issues.
What happens when you have to use 5 different objects with Dispose methods? Do you need 5 levels of indentation? I'm genuinely curious, because I've been spoiled by RAII (C++, PHP, Python), and I get frustrated in any language that doesn't have deterministic destruction by default.
The proper solution is to smack the idiot developers, not hamstring the intelligent ones.
I love that UID. :)
I also like the way you explained the continuum. It is exactly right.
You are now my friend
GCC has done a pretty good job of keeping up with ICC on Intel... even though GCC supports a multitude of other platforms. Pretty much the only place where ICC is ahead of the game (based on aggressive in-house benchmarking) is interprocedural optimization and hardcore floating-point math. Everything else is a wash, and GCC is free software. The biggest hurdle with GCC is that it takes a fair amount of compiler flags in order to get reasonable output out of it - in comparison, ICC works well (for an Intel chipset) without any extra flags. On the other hand, ICC isn't going to do well for anyone on any other chipsets...
Um, I'm sorry, but... what the hell are you talking about? Restricting pointers?
Yes, restricting pointers.
You know how you tell that C++0x disappoints? It's that arrays are still not first class objects in the language. It's that you can't do cool stuff like attach extra junk to the prologue and epilogue of a function and then walk up the call graph and put things in there. I don't see any keywords for specifying the endianness of an integer - how useful would that be.. to be able to say "bigend int foo" or "littleend int foo". I'd like to be able to specify a structure or a class which could have a single value be composed of a few bits in utterly random places in it. In other words, you could say something like:
struct foo {
int a bits 1-2 this+1.2, bits 4-5 this+3.3
};
which you would read as int a bits 1-2 are at a byte and bit offset from the structure.
And, while we were at it, how about packed pointers. AMD64 has 64 bit pointers and we can easily stuff some extra crap at the high end of them if the compiler knew to strip it out before we dereferenced them. You could implement that as a mov and an and.
If you do want to "guard" your pointers, it would be interesting to perhaps tag different pointers as having different selectors for those hardware architectures that support it, like Intel. I mean, you could make programs a lot safer under Intel and AMD if you didn't use a flat memory model. Put all of input data onto their own segments and lock it down with the hardware mmu. If it blows up, or overruns, oh well. No need to check arrays in that case because the hardware will do it. And of course, having some explicit language support for memory mapping seems useful.
To me, a language like C or C++ is that you can evolve your own exact brick of memory and carve it up in some way... really, the idea of C is almost to be just to be a very fancy macro assembler and C++ was to throw a bit of object orientedness around it, if you want.
But, instead, we have iterators and containers and ever more powerful templates and, gross, garbage collection support... that's all nice and all, but, its all indicative of a movement towards this idea that C++ is -only- an OOP language and libraries are written on building OOP programs and not necessarily smaller systems ones. C was short and sweet and simple and fast and C++ was a couple of useful things on it at first but now its just getting out of hand with this C++0x.
The great irony, of course, is that C++ templates and, wow, look at generics in C++0x, are so incredibly powerful that, what we have is a extremely high level language that still doesn't do comma delimited output of numbers. It's schizophrenic, is what it is.
This is my sig.
This is wrong on many levels. You claim you like your dynamic languages. Fine, but this also means you only use them for tasks where the cost is acceptable.
The run-time cost, and also the hidden errors, because you obviously do not understand why there are types in the first place.
Which in turns means there is something profound about maths and formal logic that you have not yet understood.
So you are in essence claiming that your ignorance is not only a valid opinion, but also the valid opinion.
You also claim that raw machine code is ultimately powerful or versatile. This assumes you are capable of producing better assembly than your compiler. All the time. Which is no small feat nowadays.
A "reference-counting garbage collector" - assuming it means what it should - is a trivial C++ exercise, a hundred lines of code at most. A CMS is nothing big either.
In fact, the philosophy of Qt is closer to Java or C# - and C++ language features used by Qt itself are mostly restricted to the same subset, too.
Kay can say anything he likes, but he did not invent the first OO language - it was Simula 67, also a statically typed language, and OOP in C++ has very visible roots in Simula (dot-notation to access members, "virtual" and "protected" originate there, for example; but in general, the very concepts of classes with methods and fields, combined interface/implementation class inheritance, object instances, special syntax for message receiver in a method call, object identity, object references and null, upcasting and downcasting, explicit polymorphism via virtual declarations and overrides, controlled encapsulation by means of visibility levels, etc).
Well, C# is halfway there with Dispose and "using" blocks - using them to perform some actions on exit from a block are fairly common. Though "finally" is really a better replacement for scoped guards that are specific to a single piece of code.
Came across this link at reddit just yesterday: http://importantshock.wordpress.com/2008/08/20/a-skeptics-look/
Ada + a modern library meets most of the requirements. To ease learning, an "ugly" version of Ada using C/C++/Java/C#-like syntax could easily be made.
...header files. Having to manually synchronize header and implementation files each time the design changes is a major pain the butt. It takes away valuable time and greatly distracts from the mental process that is design of a program.
That is, until you try to combine it with other libraries, like Qt, for example. Boost has a namespace signals, Qt has a #define signals. Yes, you can solve the problem using the preprocessor, but boost was supposed to be 'plug-n-play'...
Smart pointers are difficult to manage in the context of complex object relationships. See my other post for more info.
The idea that destructors don't play well with GC is largely a myth. Non-trivial jobs should not be done in destructors. But even if they are done in destructors, they should be invoked using RAII style. The destructor is only a function, so it can be called normally just like any other C++ function.
As I explain in my other post, the problems of cyclic references introduced indirectly, the situation where you only have 'this' and you should use shared_ptrs, etc are great problems and you should not underestimate them.
And you're saying leave that to the programmer??? That's the biggest maintenance nightmare I have EVER heard of.
I just don't think it should be left to the whims of some dude in the back room that would never document his intent and execution properly.
If you do go ahead and write it, ...
I can see you are very tempted with the idea of unlimited power but you struggle to keep your sanity (*my preciouss*)...
Yes, it IS a lot like putting all the eggs in one basket ... it requires WATCHING OVER THAT BASKET LIKE A HAWK! Hopefully, it should be easier then watching all over wide area of baskets (whole project). With it, you could actually *take away* freedom to do many stupid things from your underling code monkeys.
The dangerous "freedom" is just theoretical. Flexibility may mean more freedom, but also less freedom, of for that matter, same amount of it as it is presently. First of all, the language would have to carry "standard set of rules definition" with it, but including them in your project would be optional and RECOMMENDED. Rule sets would not be designed by any programmer (like probably someone you regret to know, or whose code you regret to had to read), but by an expert (e.g. a CS PhD) who is capable of properly detecting problems and devising solutions.
It is near equivalent situation to C/C++ system API being moved from language definition into accompanying standard library: you *could* write your own library replacement, or even not use any at all (in small embedded systems development), but hardly ever anyone does anything like that. However, should it become absolutely necessary, it could be done. Of course, anyone could write their own rule sets, if they dared, but it will be considered dangerous and not recommended, just like messing with standard library. Someone more foolish, toying with programming for fun, or knowing very well what they do, could also do some stunts without safety gear, hopefully in some very thoroughly isolated and well documented performance-critical part of code.
Imagine integrating language contemporary best practices and recommendations, your own organization coding standards, your project specific safety (or style) rules, thus (by means of having each coworker #include-ing header file with their definition in each source file) instantly enforcing them project-wide, all in modular and layered manner? Over time accumulated experience will be possible to transfer onto new projects. I think it could be great collaboration (hmm, an one-way collaboration) tool.
Admittedly, saying about a project that it was written in such a language would not mean any hint of measure of its quality any more. Instead, one would say that certain well known and respectable set of rules was applied to the project, and then we would know that it was enforced by compiler, not left to whim of developers to "respect" and prone to bugs wiggling through the loopholes of manual code inspections.
Most of any app doesnt need the speed, but sometimes there are small components that need the speed, that if written in java/c# would be 10-50x slower due to less reductions in memory movement.
Given that, it still possible to make slow C code, just look at windows and how sometimes icons take forever to refresh from empty blobs to images on the desktop. (poor design).
For enterprise style apps, that need to scale and handle billions of objects, only C or C++ or ObjC will cut it.
Then again... I am supprised intel wont push java/c# more, because that will increase demand for faster CPUs.
Liberty freedom are no1, not dicks in suits.
The proper solution is to smack the idiot developers, not hamstring the intelligent ones.
Intelligent developers can deal with not having operator overloading. Idiot developers can't deal with having it.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
The run-time cost, and also the hidden errors, because you obviously do not understand why there are types in the first place.
Nice try, son, but I've probably been hacking long than you've been alive. Trust me, I know what types are and why they're good, and also why strongly typed, dynamic languages are so popular right now.
If a program is running too slow, I see if there are algorithmic improvements I can make. Failing that, I replace critical parts with C (or C++). Failing that, we buy more hardware. I am far more expensive than any of the servers we own, and my boss is much more interested in paying me to add new features for our customers than to wring another 2% out of optimized, correct code.
Which in turns means there is something profound about maths and formal logic that you have not yet understood.
Lisp is also dynamically typed, and much beloved by computer scientists everywhere. Apparently there is more to math and formal logic than you've learned so far.
You also claim that raw machine code is ultimately powerful or versatile. This assumes you are capable of producing better assembly than your compiler.
No. It assumes that I am capable of producing more versatile assembly than my compiler. Of that, my friend, I am certain.
Dewey, what part of this looks like authorities should be involved?
And where are the other choices? Was it really Java vs. C++, with no other options?
If you had bothered to read the next sentence.... Other languages have other problems as I mentioned. But feel free to suggest an alternative
You are stuck in the mindset where all aspects of an application need to be written in the same language.
No, but that only makes sense when there is some huge compelling advantage for using another language. Sure, for a web frontend use PHP/Java/C#/Whatever, or if some critical lib is only available to a specific language, then it is justified, but for the most part, additional languages only bring more hassle.
Your problem is that you've worked on some crappy C++ code using crappy class libraries and therefore are stuck in preconceptions like someone would be "doomed to use C++". Sure I could write some parts of the code in Python or whatever, but there wouldn't be any point. C++ is just as easy (again, with the right class libraries) and runs faster.
And I can say with a straight face that you are wrong.
I'm glad I'm not playing you at poker.
"Little does he know, but there is no 'I' in 'Idiot'!"
Nah, it's not funny and certainly not original the second time. Your reply really boils down to "I know you are, but what am I?".
And for a really good "fixed that for you" you need to be a little more subtle. So replying to a post about Iran being an evil theocracy, just s/Iran/USA/. Got that, pottymouth?
Lame.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Let' backtrack a little, shall we?
mangu: Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python, or whatever is your preferred language.
you: I have on numerous occasions...and you know what? It was just as fast in Java.
So we've established that you're a liar, the question is then or now?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Well, you might want to tell Adobe that. Hint: they do use this modern C++ you abhor. You did use Photoshop, right?
Also, your conclusion is flawed. Since when does the best solution automatically win? The one which gets strongly pushed, hyped, marketed etc. is the one that wins, NOT the best one.
Instead of that they have been built using "toyish" (hey, they don't have things such as multiple inheritance etc what the C++ nerds always whine about) languages that actually lack most of the "nice" things of C++.
Yes, because 20 mediocre programmer code monkeys are cheaper than 4 top-class developers. Java is primitive, thus easy to grasp. C++ is not, even without the hideous syntax that artificially increases the difficulty. Its simple: if one language has more features and expressiveness than another, the latter is better suited for the average code monkey. Also, code monkeys are expendable, top-class developers are not. A manager's dream.
except that it takes 10 times more time to develop in C++
Now we have to be precise here. Remove enough bits of the Java standard library to equal C++'s in size, THEN judge again. People keep comparing plain C++ with a JDK-doped, Eclipse/IDEAI-enhanced Java. This brings us to Java's REAL advantage: its toolchain and SDK. Both are very good. Without them, the language is worthless.
This sig does not contain any SCO code.
I have no ego wrapped up in any such thing
Sure you do. There's no other reason to advocate C++.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Lots of heavy number crunching applications don't really care how long they run.
I would say that is true for number crunching, but not for heavy number crunching, with any reasonable definition for heavy. 10 or 20 twenty times faster would generally mean that you can go down from running it on a cluster overnight to running it on a local machine, which tends to be more convenient -- or run it over a coffee break on that cluster.
If you ever cared about multithreading to be efficient on modern systems, you should seriously consider what language you use as well.
Well, one reason to find it funny is that function calls are expensive these days. Small operations encapsulated in libraries that are only available through linking can degrade performance, even if the implementation is superior. That's one reason to prefer inline assembly in C++. To top it off, introduce the specific implementations as template specializations, for example hand-unrolled loops for a few specific small sizes. That is simply not possible to do in C, or macro assembler, without introducing a maintenance mess.
I've always liked the Intel compilers... and I even once plinked down some bucks for the Intel compiler and vTune when I was writing commodity server back in the day... but the thing that keeps me away from Intel now is that I don't know how much I can trust that compiler to produce good code for AMD chips. Even though they have nearly the same instruction sets, they are very different internally and it follows that the timings and sequences of the instructions might well be different. I just don't know... and the other thing too is that I don't know how well deploying an Intel compiled solution would even fly on a Linux platform. Doing a source / make solution almost seems like it would be out of the question. Are these perceptions unfounded, or are they accurate. I defer to your experience and await your answer literally with baited breath.
This is my sig.
C++ is to C as Lung Cancer is to Cancer.
Seriously, the problem with C++ is its C heritage.
C is a language whose design was driven by having to fit the compiler into the 64kbyte instruction space of the PDP-11.
Was it before ISO C++ or (significantly) after? I wouldn't have touched pre-ISO C++ with a 10-foot pole but now it's a good, consistent language, especially with boost.
If your problem can be nearly completely solved in Python or Ruby you don't need C++, I agree. If you are doing compute or memory-intensive stuff neither Python or Ruby are likely to be suitable. Python must be one of the slowest language on earth with no production compiler available.
Modern C++ includes all sorts of goodies in the template metaprogramming area. The Alexandrescu book explain what is possible with these techniques, and some of them have been put into use in Boost. It is possible to produce very high-level programs that are extremely efficient.
People write in C++ now very differently now, especially since Microsoft has finally produced a standard-compliant compiler since 2003 or so, and dev shops are finally phasing out VC6.
However the 'export' keyword for templates is a bug in the spec. One compiler company (I think it was Comeau) has implemented it and found that it serves zero purpose.
Fifteen years ago, in 1993 or so, C++ sucked big time. Now it doesn't. ISO-C++ is a tough language to master, but understanding its design will make you a much better programmer.
So, language list? we are awaiting with bated breath...