Slashdot Mirror
Demise of C++?
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..."
In many cases, a good C++ compiler will produce better code if the C sources are C++ clean, due to the extra type-safety in C++ the compiler is safely allowed to make more assumptions leading to better optimized code.
LL
[rant] .. if ain't good by such and such a date then we cut it". So this cut has been in the pipeline for a while.
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]
I am Slashdot. Are you Slashdot as well?
I never said that V-tables were as fast as code without them. It is a given that they are not (unless you have some deep machine logic to perform fast v-table lookup)
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.
I am Slashdot. Are you Slashdot as well?
The above code uses V-tables
m IT_T0_ES6_S 5_PKc
/. inserts some spaces in the longest identifiers]
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.
There's a hidden treasure in Python 3.x: __prepare__()
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.
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++.