Demise of C++? 271
fashla writes "Several somber and soul searching threads have been recently posted to the USENET newsgroup comp.lang.c++ such as "C++ is Dead" and "A Dying Era". The reason for this reflective mood is the sudden demise of the magazine C/C++ Users Journal (CUJ) http://www.cuj.com/ that had been published by CMP Media. Participating in the posts have been such C++ luminaries such as Bjarne Stroustrup and P.J. Plauger. While some contributers think that CUJ's demise is due to the general trend away from print, others think something else is afoot..."
Re:Balkanization (Score:3, Informative)
Re:Balkanization (Score:5, Informative)
Magazine quality (Score:4, Informative)
I don't know about any subversive anti C++ group that is plotting the downfall of this language, but I was taken aback last week when I received the next issue in my C/C++ Users Journal subscription that had a letter attached to it saying that it was the last issue ever. This pissed me off as you don't just dump a magazine like a hot potato, you track the way it is selling and you say "well
What also annoyed me about it was that the publishing company will transfer my exisiting subscription over to Dr Dobbs (though I can get my money back). Personally I feel that Dr Dobbs took a major nose dive years ago and is in no way of the same quality as the C/C++UJ. The transfer from glossy to newsprint style paper showed that they were needing to make cost cutbacks which implies to me that they were losing it in general. But what really took the cake was an article printed in the Dec 2005 issue where in a DB app, presentation was confused with storage in a manner befitting a failed CS101 assignement. While I gagged at the article itself, what shocked me even more was that the Dr Dobbs editors actually included it for publication. (As I blame the editors, I am not directly pointing to the article itself).
C/C++UJ said in their cover letter that they will be expanding Dr Dobbs to take on a lot of the content from the C/C++UJ. Personally I think that Dr Dobbs may be too far gone for this sort of recovery, and that I have lost a magazine that I liked, was to the point and generally full of quality (though other people may say I am blind about this). I may give Dr Dobbs the chance to show that it has improved, but I won't be holding my breath for very long.
[/rant]
Re:Balkanization (Score:2, Informative)
So what is going on here?
cout << "Hello World!" << endl;
The above code uses V-tables, and the above code is what is recommended by C++'s "inventor". The above is slower and produces more machine code than:
puts("Hello World");
Period.
Supporters love to say that's a bad use of C++, or that the compiler could recognize this special code, or that the compiler should do some kinds of deep inlining at compile-time, or that some special CPU will be invented and become general purpose that will make indirect procedure calls (with a possible processor exception) as cheap as direct procedure calls.
The problem is that this is the recommended form of C++, and that if compilers recognized this form, they'd miss others, and that current C++ compilers don't do the kind of deep inlining required, and that special CPU doesn't exist.
Re:Balkanization (Score:4, Informative)
What I was saying was that the C code will run the same if it is compiled under a c++ or c compiler, whereas a lot of people thought that c++ automatically inserted v-tables and hence was presumed to be slower.
You example is flawed as you are comparing apples to oranges. The use of stream insertion will bring in all sorts of crap into the equation while "puts" will not. Hence your "puts" will run faster. (But try and overload your puts example to output custom data on a generic class by class basis and see how much extra code you have to add). Once you start using feaures of one language that are not implemented in the other, then simple speed comparisions go out the window.
Re:From my point of view (Score:2, Informative)
Re:Balkanization (Score:2, Informative)
Re:Balkanization (Score:5, Informative)
No, it doesn't (or at least shouldn't with a decent compiler).
I have compiled the following code:
#include <iostream>
int main() {
std::cout << "Hello, World!" << std::endl;
return 0;
}
with G++ 3.3.1 on x86 (and pretty standard options: "-ansi -fomit-frame-pointer -O2") and the results for the "main" function where the following:
main:
.LFB1550:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
pushl %edx
pushl %edx
andl $-16, %esp
pushl %eax
pushl %eax
pushl $_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostrea
subl $12, %esp
pushl $.LC0
pushl $_ZSt4cout
.LCFI2:
call _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_E
addl $20, %esp
pushl %eax
.LCFI3:
call _ZNSolsEPFRSoS_E
leave
xorl %eax, %eax
ret
[".LC0" is the string "Hello World"; warning:
As you can see it's exactly what you can expect, with only two *direct* calls. Granted the "puts" version requires only a single call, but only because here the output is split in two parts, first the "Hello World" and then the newline.
Hope this helps the discussion.
Re:C++ has its place (Score:3, Informative)
Common Lisp - Fast nowadays, powerful, flexible, but everyone ignores it.
Re:Balkanization (Score:3, Informative)
Sorry to reply to myself, but if anyone finds the above x86 assembly code difficult to understand, the equivalent C source code is:
where f1 and f2 are provided by the standard library, in the basic_ostream class (f1 returns its first argument, cout).
Re:Whatever. (Score:3, Informative)
Re:C/C++ dying? What are they smoking? (Score:3, Informative)
Dunno what you mean by "advanced software", but C has its place when programming near hardware. C++ will hopefully die and take buffer overflows and memory leaks with it.
Quake 2 [sourceforge.net] remade in Java runs just fine. It does use LWJGL, since Java doesn't have native OpenGL bindings - but the engine itself is pure enough Java to go through the Sun's JDK compiler without warnings.
Of course, there's Java3D [java.net], but I don't know how much native code it has.
Then, on the other end of the spectrum is FreeCol [freecol.org], which has less features than the old DOS version but requires 256 MB RAM to run and takes second-long garbage collection pauses on a 1 GHZ Duron, and has severe bugs relating to Java memory model (it starts threads from object constructors; fixing this made the problem go away) that make it throw NullPointerExceptions and misbehave when run with the parallel garbage collector. I guess some people can program and some can't...
Re:Balkanization (Score:2, Informative)
Note the jumps into the plt pages looks like this:
0003afb0 <_ZNSo3putEc@plt>:
3afb0: ff a3 0c 02 00 00 jmp *0x20c(%ebx)
3afb6: 68 00 04 00 00 push $0x400
3afbb: e9 e0 f7 ff ff jmp 3a7a0 <CXXABI_1.3+0x3a7a0>
Disassembly below:
0007d9f2 <_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostream
7d9f2: 55 push %ebp
7d9f3: 89 e5 mov %esp,%ebp
7d9f5: 56 push %esi
7d9f6: 53 push %ebx
7d9f7: 83 ec 10 sub $0x10,%esp
7d9fa: e8 5f 14 fc ff call 3ee5e <_ZN9__gnu_cxx9free_list6_M_getEj+0x17de>
7d9ff: 81 c3 b9 52 05 00 add $0x552b9,%ebx
7da05: 8b 75 08 mov 0x8(%ebp),%esi
7da08: c7 44 24 04 0a 00 00 movl $0xa,0x4(%esp)
7da0f: 00
7da10: 8b 06 mov (%esi),%eax
7da12: 8b 50 f4 mov 0xfffffff4(%eax),%edx
7da15: 8d 04 16 lea (%esi,%edx,1),%eax
7da18: 89 04 24 mov %eax,(%esp)
7da1b: e8 80 e0 fb ff call 3baa0 <_ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc@pl
7da20: 0f be c0 movsbl %al,%eax
7da23: 89 44 24 04 mov %eax,0x4(%esp)
7da27: 89 34 24 mov %esi,(%esp)
7da2a: e8 81 d5 fb ff call 3afb0 <_ZNSo3putEc@plt>
7da2f: 89 04 24 mov %eax,(%esp)
7da32: e8 c9 e2 fb ff call 3bd00 <_ZSt5flushIcSt11char_traitsIcEERSt13basic_ostrea
7da37: 83 c4 10 add $0x10,%esp
7da3a: 5b pop %ebx
7da3b: 5e pop %esi
7da3c: 5d pop %ebp
7da3d: c3 ret
Re:C/C++ dying? What are they smoking? (Score:5, Informative)
BWA hahahahah
That's pretty funny, pointing out that C++ has buffer overflows and memory leaks when compared with C. Especially since C++ has vastly better techniques for dealing with those particular problems.
Ahem.
But seriously, there is absolutely no reason why properly-written C++ can't be precisely as efficient as straight C, and as an added bonus, you get a more strongly-typed language with extra features.
I've been writing in C and C++ for close to 20 years, and C++ is just plain a better language than C. Sure, it has some crazy warts and dangerous bits, and things that can be problematic if you don't know what you are doing... but I submit to you that if you don't know what you are doing, you need to find another line of work.
Sure, other languages are definitely better in some scenarios -- it's all about using the right tool for the job! -- but for "close to the machine" work, you need a language like C or C++, and frankly, I can't understand why anyone with sufficient programming experience, and a real working knowledge of both languages, would voluntarily choose plain C over C++.
Re:C/C++ dying? What are they smoking? (Score:3, Informative)
The compiler allocates memory behind your back, and as a result the programmer has no direct means by which they can free that memory. Buffer overflows are trivially avoided in C, and in my experience (of looking at other peoples' C++ code) they seem to be as common, if not more common.
But seriously, there is absolutely no reason why properly-written C++ can't be precisely as efficient as straight C, and as an added bonus, you get a more strongly-typed language with extra features.
Wow. You sound like Bjarne.
He's wrong too:
2884 Dec 21 16:09 hello1
3836 Dec 21 16:14 hello2
Compiled both with -O2 and -s -- just like he said he did. Guess which one was written in C++?
I've been writing in C and C++ for close to 20 years,
Funny being as how C++ hasn't been stable for 20 years. It hasn't even been stable for 5 years- there are many C++ programs from 15 years ago that won't compile with C++ compilers anymore.
and C++ is just plain a better language than C.
That's subjective. Objectively, C++ has a thicker runtime, requires more memory, is harder to port to new targets than a C compiler, is younger (and less mature) and is a much more complicated language (measured by keywords and syntactic verbosity).
and frankly, I can't understand why anyone with sufficient programming experience, and a real working knowledge of both languages, would voluntarily choose plain C over C++.
Obligatory Linus quote:
* the whole C++ exception handling thing is fundamentally broken. It's especially broken for kernels.
* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
Of course, I have my own reasons: C++ is simply harder to audit for security purposes because program logic in what is considered authoritatively correct C++ (as per Bjarne himself) is spread out over such a large area.
When writing secure software, that is, software that represents a zero-potential attack vector - but STILL has to cross security boundaries, C++ is simply too complicated. No, this does not have a single thing to do with buffer overflows and memory leaks- parent is right, those are trivially avoided in C, and less so in C++.
I recommend that people use Objective-C when they want to intermix language-assisted object oriented constructs with C code because it accomplishes many things that C++ attempts to do with less verbosity, can do many things that C++ cannot do, and is much easier to audit from a security-standpoint.
Re:Balkanization (Score:3, Informative)
The above code uses V-tables, and the above code is what is recommended by C++'s "inventor". The above is slower and produces more machine code than:
No, the above does not use virtual functions/operators, and hence it does not use a v-table.
After all cout is not a pointer anyway!! So even if operator << would be virtual, it would be called directily without v-table.
The above is slower and produces more machine code than:
puts("Hello World");
If its to slow on your c++ compiler, then get a decent iostreams library.
OF COURSE the first version compiles to more code, as in the first version you compile exactly 2 function calls and in the later version you compile exactly one function call
There are VERY good articles about how to use iostreams in combination with C++ std::strings. One is written by Stroustrup himself. He has written a C char* and stdio program and compares that with a C++ iostream / std:string version. Guess what? The C++ version is faster and far far easyer to write/understand. (Because its a pain in the ass to read a text file in C where you don't know how long the individual lines are)
The problem with the C advocates is: they can't write proper C++
If you feel cool with C
angel'o'sphere
Re:It will be a happy day... (Score:1, Informative)
Totally incorrect. In Java, you would use final methods.
Eg, protected final void blah(). The fact that you can do exactly this is responsible for the Java textbook "conspiracy" you've so boldly cast the light of public inquiry upon.
I'm taking a wild guess, but you've probably never done in anything Java beyond superficial "Hello, world" apps, have you?