×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Demise of C++?

Hemos posted more than 8 years ago | from the reports-of-my-death-have-greatly.h dept.

Programming 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..."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

271 comments

Balkanization (5, Interesting)

(1+-sqrt(5))*(2**-1) (868173) | more than 8 years ago | (#14426407)

We're witnessing, I believe, the Balkanization of the software industry, where hybrids like C++ are being edged out; the ultimate trend: C where speed counts, and, for everything else, Java.

Though it were hard for me to imagine, for instance, Unreal [wikipedia.org] 's engine being ported to Java, Quake [wikipedia.org] seems to have fared well with feral C.

Re:Balkanization (2, Interesting)

Merle Darling (33121) | more than 8 years ago | (#14426545)

Yeah, I've noticed that for the last couple of years I've used C for crunchy stuff and C# for everything else. C++ has become superfluous for me.

Of course I always figured this was just my weirdness, I never realized anyone else felt this way about it. I sure don't miss those retarded C++ references and stream operator overloads.
// pass in a variable whose address is the value we wish to
// use. it will be incremented and then cout will be left
// shifted by the new value. I <3 C++!!1oneROFLCOPTER
void inc_print( int &x ) {
    cout << x++;
}

Re:Balkanization (1)

mwvdlee (775178) | more than 8 years ago | (#14426582)

Does a C++ compiler produce a slower run-time than a pure C compiler when only using C functionality?

Re:Balkanization (4, Informative)

LLuthor (909583) | more than 8 years ago | (#14426667)

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.

Re:Balkanization (1)

Threni (635302) | more than 8 years ago | (#14426697)

> Does a C++ compiler produce a slower run-time than a pure C compiler when only using C
> functionality?

That would depend on the C/C++ compiler at hand. Even if it were true of all current compilers then there's no reason why the next C/C++ compiler would conform to the previous results.

Re:Balkanization (2, Insightful)

(1+-sqrt(5))*(2**-1) (868173) | more than 8 years ago | (#14426789)

Does a C++ compiler produce a slower run-time [...].
Not necessarily; but the elegance of feral C where OO is superfluous may save developer time.

Re:Balkanization (2, Insightful)

mwvdlee (775178) | more than 8 years ago | (#14427388)

Then it is rather the quality of the coder then the quality of the code that makes the difference between C and C++ performance-wise.

My personal opinion has always been one of pragmatism instead of zealotry; pick a language based on the task. It has been said by knowledgeable people that the benefit of OO over procedural is not theoretical performance but rather the practical performance. OO techniques typically allow one to better understand large problems and thereby create better solutions. Ofcourse, reengineering those solutions to procedural code would make them faster, but would also limit maintainability since you'd be creating less a "clear" solution again. In short; a solution in procedural will likely be more complex than the same solution in OO.
IMHO, C++ in the hands of a well-thinking human should never be any slower than C, but may just be faster. The issue is not whether either language is inheritently faster, but how to educate the developers to work with multiple paradigms.

Re:Balkanization (4, Insightful)

OzPeter (195038) | more than 8 years ago | (#14426958)

A lot of the shit heaped on C++ for being slow was due to the use of V-tables. V-Tables are another layer of indirection that come about with virtual function use in C++. People incorrectly assuemd that C++ always uses V-tables in order perform any function call - virtual or not, hence the belief that C++ is slower than C.

But v-tables are only created when virtual functions are used in classes, and only then. If no virtual functions are used then a C++ program can use static linking the same as for a C compiler. Given that C++ compilers are also defined to be C compilers, then for any given C++ compiler (and no virtual functions in the C++), C and C++ code should run at the same speed.

Now if you want to compare *different* C and C++ compilers, that is a seperate matter.

If you are interested in the inner C++ workings I can suggest any of the Scott Meyers books. Other people can probably suggest other authors as well.

Re:Balkanization (0)

Anonymous Coward | more than 8 years ago | (#14427303)

this is why C++ is dead.. because people are still fighting about "an extra layer of indirection".. with today's processor V-tables are not slow at all. The problem w/C and C++ is the unhealthy obsession with micro optimization that its supporters keep arguing about.

Re:Balkanization (2, Insightful)

OzPeter (195038) | more than 8 years ago | (#14427496)

Obsession is not just a C/C++ thing. Look at all of the arguments over python and the use of whitespace. Every language has its obsessive arguments.

Re:Balkanization (2, Informative)

mrsbrisby (60242) | more than 8 years ago | (#14427492)

People incorrectly assuemd that C++ always uses V-tables in order perform any function call

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 (3, Informative)

OzPeter (195038) | more than 8 years ago | (#14427648)

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.

Re:Balkanization (0)

mrsbrisby (60242) | more than 8 years ago | (#14427766)

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)

Accepted.

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.

Actually, a lot of C code cannot be compiled by C++ compilers as C++ isn't a strict superset of C. In any event, I hope nobody ever thought what you suggest here, because if C++ compilers DID do this it would make linkage with C code extremely complicated.

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.

No. The C++ recommended "Hello World" as per Bjarne Stroustrup himself is to use cout. The C recommended "Hello World" as per Kernaghan and Ritchie is to use puts.

I'm not comparing the performance of puts versus puts, nor the performance of C++'s C-linkage versus C's C-linkage, I'm comparing what the inventor and authority of C++ says versus what the inventor and authority of C says.

The authority on C++ is to write code slower than the authority of C. Period.

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

Why would I want to do that? Sounds like you really want to compare apples to oranges.

Once you start using feaures of one language that are not implemented in the other, then simple speed comparisions go out the window.

Why would I want to do that? Sounds like you really want to compare apples to oranges.

Re:Balkanization (1)

OzPeter (195038) | more than 8 years ago | (#14428178)

Sorry to disagree with you .. but it is *you* who is comparing apples with oranges, but only with respect to my original post :-)

I effectively started talking about the speed of C and C++ statically linked code being the same with all things being equal. But (as I saw from another of your posts) you actaully were ripping Bjarne for stating that stream insertion is the same speed as puts. Now that is something I totally agree with. But it is still apples vs oranges as puts only has a fraction of the functionality of cout et al, hence there is no way in hell that the two can run at the same speed, except with special optimisations that you posited.

So Bjarne being a lying SOB has nothing to do with my original argument. Hence apples vs oranges :-)

BTW I hate the implementation of cout when it comes to trying to implement printf style formatting. I also hate lots of other C++ stuff as well. But in general I like what I can do with it over and above C, and it has made my life a lot better.

Re:Balkanization (0)

Anonymous Coward | more than 8 years ago | (#14428318)

I think his point is that there's an "accepted" way of doing something in any language, and the accepted way of doing something in C++ is not faster than the accepted way of doing the same thing in C.

Yes, you can code anything in C in C++, but to do so is to program "incorrectly". If in X, you write a string using "Syscall(TEXT_OUT, "Hello world"), and in Y you write a string using "Outchar("H"), Outchar("e"), Outchar("l")... (etc), but it happens that you can make system calls using the MakeSystemCall() function, and a simple "MakeSystemCall(write, stdout, 11, "Hello world")" will be as fast as Syscall() above in language X, that doesn't mean Y is as fast as X.

If you're comparing C and C++ by treating C++ as C, then you're not comparing the two languages at all. To continue to Apples to Oranges analogy, yes, by comparing puts() with puts() you're comparing apples and apples, but you're going one step further and comparing an apple with itself. puts() is not the C++ way of doing something, even if it "just happens to work".

Re:Balkanization (1)

mrsbrisby (60242) | more than 8 years ago | (#14428813)

...but it is *you* who is comparing apples with oranges,

Absolutely not. I am comparing two distinctly similar things: The accepted authoritative methodology that is C++ versus the accepted authoritative methodology that is C.

That difference methodology has produced rumor mills similar to the ones you have heard (about all functions being invoked through indirection)- but it isn't the difference in implementation. Consider that Objective-C uses a large amount of message passing, but there's no confusion whatsoever about what a->foo(); does in Objective-C!

I effectively started talking about the speed of C and C++ statically linked code being the same with all things being equal.

I already mentioned that I agree: When you write the subset of C code that is acceptable in C++, most C++ compilers will run at the same speed, with about the same startup time, and the sizes will be about the same. They might even be equal if the compiler is worth anything.

So Bjarne being a lying SOB has nothing to do with my original argument.

It most certainly does! People get this idea about C++ being slower than C because Bjarne says something wrong, people test it, and find out he's a lying SOB.

You started out saying people got these crazy ideas about C++ from some rumor mills of sorts (vtables for procedure calls, for example), and I'm saying no: they got these crazy ideas right from the horses' mouth!

Of course puts() and cout << aren't equivilent. They don't have to be. C++ doesn't have a puts() and the Authority on C++ says calling C's puts() isn't writing C++.

I also hate lots of [other] C++ stuff as well. But in general I like what I can do with it over and above C, and it has made my life a lot better.

That's important! It's really important, and would be a good reason that you could use to urge people to take a look at other parts of the C++ infrastructure instead of what is otherwise considered Modern C++, and especially so considering that you don't like Modern C++ either.

Re:Balkanization (2, Interesting)

Carewolf (581105) | more than 8 years ago | (#14427728)

Why on earth are you discussing speed of a SYSTEM CALL!

No matter what else it does the slow part is entering kernel mode and printing characters to the screen.

You are discussing a 20ns optimization on a 1ms call.

Re:Balkanization (1)

Viol8 (599362) | more than 8 years ago | (#14427767)

Ah , the old "because we can't optimise 100% why bother optimising at all"
argument. You should apply to work at Microsoft.

Re:Balkanization (2, Interesting)

SporkLand (225979) | more than 8 years ago | (#14427933)

I have to differ on this point, he was merely saying that the optimization wasn't signifcant in comparison to the gains in clarity you get. Programming is typically a resource constraint problem, you can only choose some of the optimizations to implement, so you should be choosey. Why optimize something small when that will have minimal impact on the performance when you can optimize something that can have a big impact. I don't typically use proofs by authority, but there are a number of really smart programmers (Carmack, Sweeney) that agree with some form of this argument.

He should apply to Microsoft, I hear they can use some help.

Re:Balkanization (1)

Viol8 (599362) | more than 8 years ago | (#14427956)

The point is you should always optimise your code within reason. Theres no
justification in saying "well the API/syscall is slower than anything I can
write so I won't bother" because what happens if 2 years down the road
someone speeds that API up 10x and then your code is recompiled and *it*
becomes the bottleneck?

Re:Balkanization (1)

SporkLand (225979) | more than 8 years ago | (#14428188)

I agree with your sentiment that we should not be lazy and should be always dilligent in regards to the performance of our applications, but you seem to be saying that anyone that passes up an opportunity for a micro-optimization for the sake of clarity is being lazy/sloppy and should be sent to your idea of hell (Microsoft). When instead they may be focusing on making sure their application is performing well via profiling / algorithmic optimization.

Re:Balkanization (1)

mattgreen (701203) | more than 8 years ago | (#14428727)

Please refrain from commenting if you have no clue what you are talking about. There is no need to optimize a program 100%. In fact, it isn't desirable to do so, because optimization usually produces code that is not as intuitive or clear as the original. Additionally, some 'optimizations' that people tout actually prevent the compiler from doing optimizations, and end up harder to read. (Pointer arithmetic is a good example - again, this is compiler dependent). The majority of a program's lifecycle is spent in maintenance, and it should be tailored toward that. Additionally, profilers can be used to pinpoint bottlenecks in the code.

Re:Balkanization (1, Redundant)

mrsbrisby (60242) | more than 8 years ago | (#14427816)

Why on earth are you discussing speed of a SYSTEM CALL!

puts() isn't a system call on UNIX. I don't know what Operating System you're referring to.

What's being compared and discussed is the authority of C++: Bjarne repeatedly states this is the way to go, and that it is not slower nor larger than in C. Bjarne is extremely confused on that point.

No matter what else it does the slow part is entering kernel mode and printing characters to the screen.

No it isn't. Profile it and see for yourself.

You are discussing a 20ns optimization on a 1ms call.

Absolutely not. Profile it and see for yourself.

In any event, the point is not that puts() is faster than cout << but that Bjarne Stroustrup says that cout << is how to write to standard output and that it's not slower or takes up more space than C-code.

Re:Balkanization (3, Interesting)

ObsessiveMathsFreak (773371) | more than 8 years ago | (#14428202)

In any event, the point is not that puts() is faster than cout but that Bjarne Stroustrup says that cout is how to write to standard output and that it's not slower or takes up more space than C-code.

OK. puts is faster. But I hate to break it to you, compared to cout, puts sucks.

puts is error prone in a way that cout is not. More appropriately, cin is far, far superior to get and all those derivatives. cin, cout and cerr, are slower, have more overheads, take more space,etc, etc. I still prefer them. Why? Because they're safer. Not totally safe, but leauges safer than the equivilent c functions.

On top of that you can overload cin. Some people do screw this up, but being able to write:


while(cin >> Big_Complicated_Object){ //do stuff
}

Is very sweet. C can only offer me this with hacks that will freeze thy young blodd etc, etc, etc.

I don't find C++ too bad. The compilers are OK, and I don't abuse the language features. I'm an OO kind of guy, and I like decomposing my programs. C++ lets me do this in a way C cannot.

Re:Balkanization (1)

mrsbrisby (60242) | more than 8 years ago | (#14428933)

OK. puts is faster.

Accepted.

compared to cout, puts sucks.

You've admitted puts is better than cout in at least one way.

In any event, this thread is not about whether C++ is better or worse than C, it's about whether rumors about performance and size penalties in C++ are justified, and in many cases it appears the answer is yes.

On top of that you can overload cin.

No you cannot. std::cin is a global variable. You can overload >> in the class istream but that's not the same thing at all.

I like decomposing my programs. C++ lets me do this in a way C cannot.

I have no idea what you mean by "decomposing" your programs. This thread is not about comparing C to C++ as languages, or even comparing puts to cout<<. It's not about what everyone's favorite language is, it's about the problems with C++ - not the language itself- because those problems exist in other languages too- but with the public's general perception of C++.

The perception is that it's not as fast as C, and not as safe as Java. I wasn't going to touch on the latter because I'm of the experience that safe code has very little to do with language itself, but performace IS important.

If the methodology of C++ is to perform operations that are costly in performance and size, then perhaps some attention needs to be given to reposturing C++, changing the methodology of C++, or moving on.

Re:Balkanization (2, Insightful)

p3d0 (42270) | more than 8 years ago | (#14428182)

The overhead of the indirect call is not the only (or even the primary) performance problem with vtables. The inability to inline virtual calls impairs the optimizer tremendously.

Re:Balkanization (4, Informative)

YA_Python_dev (885173) | more than 8 years ago | (#14428243)

    The above code uses V-tables

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_ostream IT_T0_ES6_
        subl    $12, %esp
        pushl   $.LC0
        pushl   $_ZSt4cout
.LCFI2:
        call    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES 5_PKc
        addl    $20, %esp
        pushl   %eax
.LCFI3:
        call    _ZNSolsEPFRSoS_E
        leave
        xorl    %eax, %eax
        ret

[".LC0" is the string "Hello World"; warning: /. inserts some spaces in the longest identifiers]
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:Balkanization (2, Informative)

YA_Python_dev (885173) | more than 8 years ago | (#14428403)

Sorry to reply to myself, but if anyone finds the above x86 assembly code difficult to understand, the equivalent C source code is:

f2(f1(cout, "Hello, World!"), endl);
return 0;

where f1 and f2 are provided by the standard library, in the basic_ostream class (f1 returns its first argument, cout).

Re:Balkanization (3, Funny)

bhima (46039) | more than 8 years ago | (#14426768)

"Feral C"... If there was ever a description of how I use C (and probably FORTRAN) there it is!

I love it... when will GCC be supporting it?

Java is dying too (1)

egarland (120202) | more than 8 years ago | (#14427289)

C where speed counts, and, for everything else, Java ...except that everyone has come to realize that Java is horrible. The language has some flaws but is decent. The big problem (I think) is java the platform. It's not designed to do things efficiently. I see a lot more growth (to my dismay) in .net languages than anything else and I see a steady shift away from java.

The thing we are shifting twords doesn't exist, but is being created slowly as we advance our programming languages. We need a nice platform that has a VM but allows you to write directly to machine code and have it interact gracefully with the VM based code. This way you could have your 3D engine coded hard and tight but your UI code could be up in VM land and loose and flexible. It should allow programming in multiple languages so programmers with all types of skilsets can program for it and allow the code written in different languages to interact. It should allow for scripting as well as compile to native OS executables for speed and to allow easy distribution. The best work I see twords that goal is Parrot (the new perl/everythning else platform). We'll see how that works out.

Re:Balkanization (4, Interesting)

StrawberryFrog (67065) | more than 8 years ago | (#14427290)

hybrids like C++ are being edged out; the ultimate trend: C where speed counts, and, for everything else, Java.

And just a few days ago I was reading on slashdot about Java/C# falling in between C/C++ for low-level systems programming and the "dynamic and/or scripting" languages for highest productivity (e.g Perl, JavaScript, Python, PHP, Ruby, Haskell).

Re:Balkanization (1, Informative)

IpalindromeI (515070) | more than 8 years ago | (#14428057)

Haskell is neither a scripting language nor dynamic. It is compiled (first to C and then to machine code), and employs compile-time static typing. It just feels dynamic because the type inferencer is so good that you usually don't need to put in the type directives yourself.

Re:Balkanization (1)

smcdow (114828) | more than 8 years ago | (#14428866)

I'm seeing a lot more multi-language solutions these days. Extending Python or Perl with C-language extensions. You do the difficult stuff with the higher-level language, and the performance stuff in C. Much easier to do this with Python or Perl than with Java (haven't tried GCJ yet, though).

From my point of view (3, Insightful)

Z00L00K (682162) | more than 8 years ago | (#14426608)

C++ has it's place, but it is agressively attacked from below (read C) and from above (read Java & C-hash (C#)).

The problem with C++ is that it is neither as simple as C nor has it the benefits of Java and C# as they allow for code that is easier to read and understand. The available tools are also better for the competing environments on the upper side.

C is still developing features at a slow but steady pace and it has inherited a few from C++. There will probably be more features inherited in the future, which will cut more into the area of C++. The difference between C and C++ is that C isn't object-oriented while C++ supports object-oriented design. But object-oriented design is not necessarily needed at the low-level programming that is used when accessing devices and similar operations, and hence C will be the choice of such programming.

It will be a happy day... (0)

Anonymous Coward | more than 8 years ago | (#14427562)

When C++ is finally a thing of the past, to be replaced by something like D [digitalmars.com] . I consider myself a rather adept programmer, proficient in both C and Java. Recently I've been learning C++ from a book many consider to be C++'s "Bible": C++ Primer 4th Edition by Lippman, Lajoie and Moo. I have discovered that C++ is thoroughly flawed conceptually, and that it is impossible to actually make a good book about it due to all the nuances.

Coming from a Java background, I find it difficult to understand the reason for all the const parameters, how C++ uses iterators and how *iter is something completely different from what I'm used to it meaning in C. You can somehow pass C-strings to C++ string parameters and they will be automatically converted. Initialization lists are horrible, a function can be declared virtual and const (seemingly pointless "features" when in Java all methods are virtual). Multiple-inheritance, the fact that you store the class interface in a separate file to reimplement it using disgusting syntax in another file: Class::method_name(int face = 3) const { /* blech! */ }. No garbage collection makes programming a pain and error-prone. I/O streams use variables instead of exceptions for error handling. Because there's no reference counting mechanism (as in Obj-C) and no garbage collection, one's often forced to copy the contents of parameters to ensure they aren't deallocated prematurely.

Java has the right idea, but unfortunately it's too slow. That's where D steps in and tries to resolve all the issues. C++ is too bloated, it has too many nuances, too many unnecessary "features", and there is far too much ambiguity in the code itself. C++ allows things that shouldn't be allowed. Operator overloading (while some may claim to be useful), is a horribly confusing feature that hides the actual action deep within the class implementation, forcing one to constantly jump back and forth from reference manual to code. Don't get me started on C++'s horrible class naming-scheme. Why do all standard library classes have lowercase first letters? Why is it "string" instead of "String" as it should be to differentiate it from primitives and object names?

- Posting anon. because there are too many hardcore C++ zealots out there.

Re:It will be a happy day... (1)

Viol8 (599362) | more than 8 years ago | (#14427830)

I agree with most of what you say except for garbage collection. Since I
do low level programming I want memory to be free'd when *I* request it,
not when the runtime (which would be extra overhead too) thinks it should
be done. The problem is C++ is trying to be all things to all men, as low
level as C and as high level as something such as python. Problem is what
you end up with is a rather unsatisfying smelly stew.

Re:It will be a happy day... (0)

Anonymous Coward | more than 8 years ago | (#14428106)

I want memory to be free'd when *I* request it

myObject = null;
System.gc();

Re:From my point of view (4, Insightful)

slamb (119285) | more than 8 years ago | (#14427639)

The difference between C and C++ is that C isn't object-oriented while C++ supports object-oriented design.

You're way off. So far that I'd say you've never read or written modern C++ code. There's a lot of metaprogramming. Look into templates sometime. Try out the STL and the boost libraries [boost.org] . There are significant C++ programs that are not object-oriented and would be nearly impossible to duplicate in C with the same kind of efficiency.

I find C++ to be an ugly, ugly language, but it's also a lot more than the "C + classes" that it used to be.

Don't talk to me about Boost (1)

Viol8 (599362) | more than 8 years ago | (#14427867)

A horrid kludge that tries to turn C++ into a completely different
language. If I wanted a different language I'd use one. Plus it tends
to be a solution for problems that don't exist.

"would be nearly impossible to duplicate in C with the same kind of efficiency"

BS. Unless you think theres some sort of magical assembly language that
a C++ compiler can generate than a C compiled couldn't.

Re:From my point of view (2, Insightful)

p3d0 (42270) | more than 8 years ago | (#14428204)

The difference between C and C++ is that C isn't object-oriented while C++ supports object-oriented design. But object-oriented design is not necessarily needed at the low-level programming that is used when accessing devices and similar operations, and hence C will be the choice of such programming.
Also, just because C doesn't "support" OO design doesn't mean you can't do it anyway with some discipline. (And no, I'm not talking about rolling your own vtables everywhere. That's OO implementation, not OO design.)

Re:From my point of view (5, Insightful)

macshit (157376) | more than 8 years ago | (#14428660)

The problem with C++ is that it is neither as simple as C nor has it the benefits of Java and C# as they allow for code that is easier to read and understand. The available tools are also better for the competing environments on the upper side.

My experience with C++ and Java is that Java is simpler to get your head around, but can really get annoying once you get going, because of the number of gross hacks and workarounds required to avoid excessive heap allocation. Compared to C, C++ often results in dramatically clearer code, simply because it offers the ability to wrap things with enough syntactic sugar that it makes source code much more concise.

However, taking advantages of C++'s strengths requires some discipline, and requires programmers to understand what's going on to some degree, and as we all know, the great majority of programmers are idiots.

I suppose in the end, the best progamming language for idiots will win...

Nah (5, Insightful)

codeboost (603798) | more than 8 years ago | (#14426736)

If you put it that way, everything is dying. I bet a buck that C# or Java will be dead as a rock in 20 years, just like C++ and most of the other programming languages we know today.
What we are noticing today is that programming languages alone just don't cut it anymore. The software is so advanced, that standard language constructs and libraries are way too raw to be applied to something useful for the average application programmer. Knowing frameworks, APIs and libraries is becoming a lot more important than using all the language paradigms and hidden tricks.

I think C++'s user base is splitting: On one hand there are the library and API developers, for whom the standard and the language are wholy. On the other hand, there are the application programmers, who care about the practical side of the language; they use it because it has advantages over other languages and has lots of libraries written for it.

My belief is that C++ is more alive today than ever. It is more powerful than ever. And it will be for a long time (in technology terms, indeed). Of course, in 10 years time it won't be recognizable. But it's wrong to say that C++ is dying.

Widely used languages don't die quickly (2, Insightful)

DavidNWelton (142216) | more than 8 years ago | (#14426866)

Perhaps C++ has passed its apex, but programming languages do not die quickly. Fortran and Lisp are from, what, the 1950's? Cobol? Still with us. If it's in widespread use, it won't die quickly. I discuss this some in an article on the economics of programming languages:

http://www.dedasys.com/articles/programming_langua ge_economics.html [dedasys.com]

( although my hosting provider's network seems to be running a bit slow:-/ )

Re:Widely used languages don't die quickly (1)

youknowmewell (754551) | more than 8 years ago | (#14428785)

Lisp is actually seeing an upsurge in use recently. With books like this [gigamonkeys.com] Lisp may rise like the Pheonix! It's definitely got this newbie interested :)

Re:Nah (0)

Anonymous Coward | more than 8 years ago | (#14427432)

If you put it that way, everything is dying. I bet a buck that C# or Java will be dead as a rock in 20 years, just like C++ and most of the other programming languages we know today.

I bet somebody told the same to Kernigan and Richie 30 years ago...

We just got tired of being insulted (5, Insightful)

Chemisor (97276) | more than 8 years ago | (#14426828)

We, C++ programmers, just got tired of being insulted all the time, so we don't talk much any more. After all, every time we mention C++ we are told how bad it is and how stupid we all are for using it. Sure, we can rebut all those arguments, but there are so many loud people declaiming them that nobody ever hears us. So, we just shrug, shut up, and go back to writing code. If you don't want to listen, you are only hurting yourselves and your employers.

Re:We just got tired of being insulted (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14426968)


Mr. Chemisor, what you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul

Re:We just got tired of being insulted (5, Insightful)

pslam (97660) | more than 8 years ago | (#14427095)

What Mr. Chemisor is saying is very familiar to me. Whenever the subject of C++ comes up on Slashdot, a big bunch of drones regurgitate some absurdities they heard somewhere about how it's slow, hard to use, and bogged down in legacy support. Some morons even go so far as to suggest plain C is superior. Some morons go so far as to make enormous projects using plain C and a bunch of type information hacks using macros that only serve to move type checking from compile-time to a run-time performance hit (cough GTK cough).

We're just plain tired of giving the same answers to the same people who never listen and carry on regurgitating the same crap they heard from some uninformed idiot. There's one thing that's very obvious from the numerous appearances of C++ on Slashdot recently: very few of the readers here have actually used C++ in any serious way.

You're only hurting yourselves when you dismiss C++ out-of-hand for uninformed reasons.

translation: LA LA LA LA, LA LA LA LA (2, Insightful)

mkcmkc (197982) | more than 8 years ago | (#14427256)

:-)

C++ is kind of a monster of a language (almost as bad as Perl), but it is one of the few I'd choose for the niche where speed/space really count. Unfortunately for C++, there are very few programs for which this is the appropriate niche. Most of the C++ that crosses my desk should have been written in an appropriate scripting language (insert your favorite, Python's currently mine). I even heard a tale of someone writing a "makefile" in C++ (gawd). These mistakes cost a lot of time and money.

My biggest problem with C++ is the apparent lack of a decent conforming compiler (preferably with useful diagnostics). Every few years I check and it seems like they're nearly there...

translation: Forth, Forth, Forth, Forth, Forth. (0)

Anonymous Coward | more than 8 years ago | (#14428089)

"C++ is kind of a monster of a language (almost as bad as Perl), but it is one of the few I'd choose for the niche where speed/space really count."

Forth fits the same catagory, and it gets the same treatment from the mainstream audiance.

Re:We just got tired of being insulted (-1, Flamebait)

mrsbrisby (60242) | more than 8 years ago | (#14427560)

We, C++ programmers, just got tired of being insulted all the time, so we don't talk much any more. After all, every time we mention C++ we are told how bad it is and how stupid we all are for using it. Sure, we can rebut all those arguments, but there are so many loud people declaiming them that nobody ever hears us. So, we just shrug, shut up, and go back to writing code. If you don't want to listen, you are only hurting yourselves and your employers.

We, people of Faith, just got tired ot being insulted all the time, so we don't talk much any more. After all, every time we mention our personal God, we are told how bad it is and how stupid we all are for using it. Sure, we can rebut all those arguments, but there are so many loud people declaiming them that nobody ever hears us. So, we just shrug, shut up, and go back to our prayer circles. If you don't want to listen, you are only hurting yourselves and your afterlife.
When the inventor of C++ stops lying about C++, perhaps then we can have rational discourse, but until then, I completely realize that talking to you about C++ is about as useful as talking to you about Santa Clause.

You are now free to return to your alternate universe that requires four different kinds of cast and all kinds of deep magic just to keep up.

I'm a C++ coder and I hate it too (0, Flamebait)

Viol8 (599362) | more than 8 years ago | (#14427894)

Its a god awful dogs dinner of a language. Whatever Stroustrup was
smoking when he designed the syntax I'm sure its illegal , and if
its not it should be. If you compare C++ syntax to a language such as
D (which is also C compatable so THAT excuse is out the window) you realise
what a mess C++ really is.

Re:We just got tired of being insulted (1)

Eli Gottlieb (917758) | more than 8 years ago | (#14428527)

Be happy. When Object Pascal (a language a little itty bit cleaner than C++, but mostly just nicer looking) programmers mention what we code in we're laughed out of the room, because everyone still thinks "Pascal" means the language invented by Wirth in the early '70s.

You, you use C++, which may be on somewhat of a decline thanks to its children Java and C#, but is still considered a "real language".

Magazine quality (3, Informative)

OzPeter (195038) | more than 8 years ago | (#14426870)

[rant]
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 .. 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.

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:Magazine quality (1)

GeckoFood (585211) | more than 8 years ago | (#14427738)

Until recently, I had subscriptions to both DDJ and CUJ, and I finally decided a few months ago that when DDJ was up for renewal, I would drop it. I have had a subscription for it since the summer of 1994, and like you I have seen it dropping in quality. So, I figured I would keep CUJ and dump DDJ. To find out that I will be getting DDJ *instead* of CUJ was frustrating to say the very least. They told me they would simply extend my DDJ subscription by the balance of what remained on my CUJ subscription - which I recently paid another year for. Unpleasant surprise.

For DDJ to cover the C++ stuff that CUJ covered will require a lot more paper and a lot more effort, effort I cannot see them making. They have gone so far into the Java world that I can't see them pulling back for those of us that didn't come alone for the ride. They quit doing an annual C++ issue a while ago, I doubt that will be coming back.

C++ : to remove yet another sucky java app. (2, Insightful)

Anonymous Coward | more than 8 years ago | (#14426891)

Considering a recent internal project re-write, I can relate the following example.

The initial Java implementation had too large a system footprint (we required it to run on fairly low spec machines with limited resources).

The rewrite in C++ ran smaller, faster, and without the Java "slow to load and start" TM.

The trade-off for the re-write was the longer development cycle.

Overall, we don't see C++ dying, but as a great tool, which still has it's place.

Less C++, more Ruby (4, Interesting)

yattaran (898911) | more than 8 years ago | (#14426901)

Despite my love for C++ I find myself writing less and less C++ code. Why? Well, I guess it's due Ruby ( http://www.ruby-lang.org/ [ruby-lang.org] ) in my case. And whenever I make an extention in Ruby I write it in C, not C++. Why should I spend 5 days writing a tool in C++ when I can write it in 5 hours using Ruby ?

I feel sad about not using C++ more often though, because it really was my favorite language for a long time. I just can't think of any project idea I have where C++ would be better suited than Ruby.

Print is in a coma... (2, Insightful)

ross_winn (610552) | more than 8 years ago | (#14427128)

I don't want to be "Miss Pollyanna blue sky" but let's be honest with ourselves. Print will be dead in a decade. For all but the widest possible audiences (Time, Newsweek, People) magazines are useless in the digital age.

Re:Print is in a coma... (1)

neelm (691182) | more than 8 years ago | (#14427695)

I dunno... I find it weird taking the laptop to the can with me... a print magazine seems so much better suited.

C++ has its place (1, Interesting)

Ekarderif (941116) | more than 8 years ago | (#14427160)

C++ remains as the only proper object-oriented language. Despite all the years of continuous development in languages, there has yet arisen an overall better object-oriented language. Yes it's ugly. Yes it's cryptic. Yes, it explodes often. But there isn't another language that does things better. Take a look at its competitors:
Java - Oh wow, a language that inherited the syntax from C++. Also completely controlled by a useless business committee. Tack on the JVM and you have yourself a C++ killer! Oh wait...
C# - Like Java, but worse. Switch the Java committee for a Microsoft one. Switch JVM for .NET. Stupidity for everyone!
Objective-C - Is it used ever outside of Apple development?
Smalltalk - Nice and pretty. And unheard of outside of the niche.
Python, Ruby, etc. - Often considered too slow.

If anything, Java/C# are dying. The reason: Python, Ruby, and other interpreted languages. C/C++ blazes Java in speed, and the interpreted are much faster (and easier on the eys) in design. In fact, if everybody switches to Python (can't say about Ruby), C++ will continue to thrive due to Python's adherence to C/C++ module. Implement in Python; tweak in C/C++. Where would Java be?

Re:C++ has its place (1)

BoomerSooner (308737) | more than 8 years ago | (#14427232)

I completely agree. However, the market isn't 100 percent efficient, so using C++ may or may not be a good choice. In a world where technology changes so quickly I find it's better do do whatever can get the job done as quick as possible with the minimal amount of effort and expense. If that means using (god forbid) VB.Net, C#, Java, ObjC, LAMP, JSP, or whatever else the number one thing in the business world is get it done. Customers don't give a shit what you use, as long as it works for them.

I would love to get a job doing C++ programming. Unfortunately, they are few and far between in my area.

BTW I have a friend that is a alpha/beta tester for Flash and he's super hyped about the x.5 verson of Flash that is coming out because they've rewritten actionscripting to be significantly more OO. Granted this is second hand but he's one of the best programmers I know, so i trust his info!

Re:C++ has its place (5, Interesting)

LizardKing (5245) | more than 8 years ago | (#14427294)

C++ remains as the only proper object-oriented language. Despite all the years of continuous development in languages, there has yet arisen an overall better object-oriented language. Yes it's ugly. Yes it's cryptic. Yes, it explodes often. But there isn't another language that does things better.

C++ the "only proper object oriented language"?!? It started life as a kludged on Modula extension to C. It has evolved into an overly complex language that includes elements of many programming paradigms, but implements all but the procedural ones poorly. The procedural stuff came from C anyway. Objective C is far closer to a "proper" object-oriented language, adding the minimum to C to give it OOP features. Smalltalk itself is the purest OOP language.

Java - Oh wow, a language that inherited the syntax from C++. Also completely controlled by a useless business committee. Tack on the JVM and you have yourself a C++ killer! Oh wait...

It inherited procedural syntax from C, not C++. The OOP aspects were inherited from Objective C and SmallTalk, along with a class library that owes much to NeXTstep/OpenStep. Gosling and other Sun engineers must have been exposed to NeXT's development platform during the brief Sun dalliance with OpenStep. As for being controlled by a "business" committee, my experience of Java's evolution is that it was largely driven byb engineers at Sun. Anyway, Stroustrup and the ISO committees haven't done a great job with C++.

As for being a C++ killer, it seems to be exactly that at my current employer. Our content delivery systems have been rewritten in Java and C, replacing a C++ monstrosity. Our only outsourced application is in the process of being rewritten in Java rather to replace the current C++ version from the same vendor. C++ ain't just dying, it's dead here.

C# - Like Java, but worse. Switch the Java committee for a Microsoft one. Switch JVM for .NET. Stupidity for everyone!

Although it's just Java for Windows, C# is a much more elegant language than C++.

Objective-C - Is it used ever outside of Apple development?

Why's that, doesn't development for MacOS X amount to much then? Plus, the Cocoa APIs are far more elegant than the hideous STL abomination.

Smalltalk - Nice and pretty. And unheard of outside of the niche.

It was ahead of it's time, but obscurity doesn't mean it's a poorer language than C++.

Python, Ruby, etc. - Often considered too slow.

Only in urban myths.

Re:C++ has its place (2, Interesting)

Decaff (42676) | more than 8 years ago | (#14427774)

"Python, Ruby, etc. - Often considered too slow."

Only in urban myths.


No, in practical use. Try doing something like image processing in those languages; or (perhaps more realistic) parsing a large XML file with native Python or Ruby code. Now try it in a C++ or Java parser. The difference in speed is phenomenal.

Re:C++ has its place (2, Insightful)

LizardKing (5245) | more than 8 years ago | (#14427918)

I've done a lot of XML (and SGML) parsing using toolkits written in C, Perl and Java. The C ones (expat, libxml2 and several commercial packages) were quick, although the nature of XML means that a lot memory allocation goes on. The Java and Perl toolkits behave well because memory is pooled at the userlevel, rather than requiring many malloc calls. Image processing on the other hand, is why the system I mentioned above has some parts coded in C. ImageMagick, using the raw C API, narrowly beats a similar processor written to use PerlMagick. However, the C version needed a fair bit of testing with tools like Purify to ensure it didn't leak memory. Both the C and Perl processors were written to replace a C++ application that used Magick++. It leaked memory and was a nightmare to debug.

Re:C++ has its place (2, Interesting)

Ekarderif (941116) | more than 8 years ago | (#14428179)

Sorry about the misunderstood proper. I simply meant that C++ is the most widespread object-oriented language that's not hampered by added "bloatness" so to speak. I didn't mean it's the best. Everybody knows that Python is the best.

Stuff like the JVM, .NET, Python framework are great, but they use extra memory that is considered bad practice in many circumstances. Objective-C is just about the only true competitor but its circle of use is limited. And I hate C# with a passion. Why? Platform closeness.

As for the ISO standard, it's only a standard. After all, C++ technically belongs to nobody and anybody can add information to (GCC) compilers. GCC had many C99 commands awhile before C99 was published. Nobody can easily add Java syntaxing, support, etc. (although GCJ is getting quite good so this may be moot).

Re:C++ has its place (1)

p3d0 (42270) | more than 8 years ago | (#14428414)

Python, Ruby, etc. - Often considered too slow.
Only in urban myths.
Huh? You had me until you said this.

Re:C++ has its place (1)

LizardKing (5245) | more than 8 years ago | (#14429035)

Python, Ruby, etc. - Often considered too slow.

Only in urban myths.

Huh? You had me until you said this.

What I meant was, that while on paper interpeted languages like Perl, Python or Ruby should be slower (plenty of runtime type resolution, higher level constructs, etc), in practice things like memory pooling and sophisticated JIT-style interpreters means they are often faster than the equivalent application written in C or C++. To make the most of the potential of C/C++ means expending a fair bit of effort optimising. I find that I code C applications with legibility and correctness as my first priority, then I optimise if I need to. The effort spent managing memory correctly in C/C++ often negates the potential for greater speed if I compare performance to a scripted application written in the same amount of time.

Re:C++ has its place (1)

StrawberryFrog (67065) | more than 8 years ago | (#14427564)

Java ... a C++ killer!

Rubbish. Nobody ever claimed that Java was the right tool for the same niche as C, ie OSs, device drivers and speed-critical apps. C++ is in this niche, Java isn't.

C# - Like Java, but worse

I'd be interested to see why you think everyone else is wrong, and C# is worse then Java.

Re:C++ has its place (1)

CaptainPinko (753849) | more than 8 years ago | (#14428155)

C++ remains as the only proper object-oriented language.

Really? Lets ask someone else's opinion on the matter:

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
-Alan Kay [smalltalk.org]
Hmm, I think I'll beg to disagree with your quote.

Re:C++ has its place (2, Informative)

Eli Gottlieb (917758) | more than 8 years ago | (#14428333)

You're forgetting one:

Common Lisp - Fast nowadays, powerful, flexible, but everyone ignores it.

depends on who you work for... (2, Insightful)

hurlpigeons (944368) | more than 8 years ago | (#14427265)

Just to add to this... Depending who you work for and what ill wind is blowing in your managers rear end, you could fine yourself defending your langauge of choice. I've heard "your using C that 70's yada yada", "we want java programmers they're easy to replace yada yada" and "Perl nobody uses that".

The clearest sign that C++ is a dead end: (2, Funny)

porkchop_d_clown (39923) | more than 8 years ago | (#14427392)

Large parts of the Darwin kernel layer are written in it.

Anything Apple uses - *must* be a dead end.

Video Games (2, Interesting)

MobyDisk (75490) | more than 8 years ago | (#14427512)

I wonder if C++ will remain the language for video games for a long time. It is one of those places where OO + efficiency are important. I believe there are engines written in C, but seldom entire games any more. Business systems care more about readability and scalability than efficiency, and languages like C#/Java offer a better balance there.

Re:Video Games (1)

ultranova (717540) | more than 8 years ago | (#14428503)

I wonder if C++ will remain the language for video games for a long time. It is one of those places where OO + efficiency are important. I believe there are engines written in C, but seldom entire games any more. Business systems care more about readability and scalability than efficiency, and languages like C#/Java offer a better balance there.

Well, Java is getting faster with each release, and game engines keep on getting more complex. At the same time the mainstream PC world is slowly starting to move from uniprocessor to multiprocessor (or multicore) machines, increasing complexity even more. To top it off, Linux is increasing its popularity, making portability an issue; and while C++ by itself might be portable, DirectX certainly isn't.

There is another important advantage a Java game engine enjoys over C++ one: scripting. Game engines are more and more turning to special-purpose virtual machines that execute the scripts that are responsible for the actual in-game logic. This means that executing those scripts takes more and more processing power. Now, if the game engine is done with Java, and the scripts are Java as well, they get compiled to native code by JIT. If, on the other hand, the engine is done in C++, the scripts get interpreted, unless the developer either includes a compiler with the program or demands that the user pre-compiles them with GCC (or something).

Please not that this isn't some theoretical hypothesis; in my experience, scripts available for Neverwinter Nights often specifically state that the script is not using heartbeat trigger (so it is not running for every frame). Similarly, plugins available for Morrowind specifically state if the plugin adds any global (always active, as opposed to regional, active when in a given location) scipts, since they slow the game down noticeably.

So, for a complex and modifiable enough game, Java will actually offer better performance than C++.

And of course Java is a much better choice when you're talking about multiplayer games, since receiving malformed data isn't going to let anyone exploit buffer overloads in the games network code. Not that segmentation violations are uncommon in any game nowadays...

So yes, I think that C++ will get supplanted by Java sooner or later, just like C++ supplanted C and C supplanted assembly. Computers keep on getting more powerfull and more complex and computer science keeps on advancing, so the focus moves from trying to control every last detail into trying to control the big picture and letting the computer to worry about the details. The low-level languages still have their place, but it isn't in normal application programming; they are used in low-level libraries and operating system kernels. The future belongs to ever higher-level languages; and I, for one, say "good riddance" to our old memory-leaking buffer-overflowing C/C++ overlords.

Another thing: I think that dataflow languages are going to make a comeback. They are pretty ideal for making programs that scale to N processors, and since desktops seem to be heading that way...

C++ not dead, but it is a dead end (1)

the eric conspiracy (20178) | more than 8 years ago | (#14427554)

The grafting of OO extensions onto C was the worst design decision I have ever run into. The result is a crappy arcane and confusing kitchen sink of language to work in. However we do need a compiled, powerful OO language to work in. The opportunity is ripe for a replacement to C++, lighter weight, with GC support and a comprehensive set of libraries designed from the start to fix the problems with C++ without the need to maintain backward compatability with C++.

Call it what you will - the need is there and we have a large set of good ideas now on how OO should be implemented from Smalltalk, Java, Pythin, Ruby and C++.

Re:C++ not dead, but it is a dead end (1)

metamatic (202216) | more than 8 years ago | (#14428052)

The grafting of OO extensions onto C was the worst design decision I have ever run into. The result is a crappy arcane and confusing kitchen sink of language to work in.

It didn't need to be, though. Objective-C is simple enough that a C programmer can learn it in a weekend, yet it also allows object oriented programming, and supports dynamic programming better than C++ does.

In todays hasty world... (4, Funny)

ballpoint (192660) | more than 8 years ago | (#14427604)

C++ still is a lovely language, but it takes a very long time to program anything in it, because we do not program anything in it, unless it is worth taking a long time to program.

Death by subscription? Please. (4, Insightful)

Craig Maloney (1104) | more than 8 years ago | (#14427664)

Saying that C++ is dead because C/C++ Users Journal is no more is about as ridiculous as saying that Linux is dead because Linuxworld magazine is dead. I'm sorry, but the two are not interconnected at all. True, there's no real magazine for C and C++ developers in the newsstands, but if magazine popularity has anything to do with it, then the same can be said for Perl, Python, Ruby, and a myriad of other languages that aren't in print. I'd be more inclined to say that the publishing industry for language content is dead as when it was time to renew my subscription to C/C++ UJ, I opted instead to not renew. Why pay $29.95 (or whatever the sliding scale that CMP Media uses to determine what you pay that month) for a bunch of articles that may or may not relate to doing useful work with C/C++ (and admit it... how many pure C++ articles were there? I remember many more articles on D, Java interoperability, and the like than there were C/C++ articles). I found that the one section I did read religiously was the fictional workplace created by Herb Sutter and his co-author (the name escapes me at the moment) which detailed three coders (the master, the apprentice, and the guru) against "Bob". That was about it.

So, I don't think that C++ is going anywhere because the journal is going away... I think instead people who are using C++ will go elsewhere for information about C++.

No story here... move along. :)

Re:Death by subscription? Please. (1)

OzPeter (195038) | more than 8 years ago | (#14428385)

"I think instead people who are using C++ will go elsewhere for information about C++."

And if you dig into one of the threads thats excatly what P.J.Plaugher says he does more and more now .. "go elsewhere for info".. and he is the *editor* of C/C++UJ

C/C++ dying? What are they smoking? (3, Insightful)

johnnnyboy (15145) | more than 8 years ago | (#14427710)


IMHO, C/C++ is far from dying. It's getting stronger than ever atleast in the realm of software engineering. I see it finding it's nitch closer to the hardware and in core of advanced software where speed and optimization is important.

Like, you wouldn't write a 3D game engine in java, atleast not yet anyway.
Look at KDE what is it written in? and Unreal? What is the JVM itself written in? and .NET?

I still see that software engineers are still using it heavily where as the rest of us mortals in the business realm, develop in other interpreted languages that can offer faster development time. Cost is everything, we programmers are no longer seen as an asset but more as a cost. Java and Lamp programmers are just cheaper.

I find it very unfortunate that schools are no longer teaching C++ and switching to Java.
The end result is a more limited amount of advanced C++ programmers out there working on very important advanced applications.

Re:C/C++ dying? What are they smoking? (2, Informative)

ultranova (717540) | more than 8 years ago | (#14428691)

IMHO, C/C++ is far from dying. It's getting stronger than ever atleast in the realm of software engineering. I see it finding it's nitch closer to the hardware and in core of advanced software where speed and optimization is important.

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.

Like, you wouldn't write a 3D game engine in java, atleast not yet anyway.

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...

C++ is more like Perl... (4, Insightful)

wandazulu (265281) | more than 8 years ago | (#14427725)

...in that there's often more than one (or one dozen) ways to do something. I think a lot of scorn heaped on C++ is due to the fact that the scorner at some point opened up an STL file (or anything generated by Microsoft's ATL) and ran screaming. And frankly, they're right...that's some imposing syntax and not at all friendly to read or understand.

But what I've told people again and again is that *you* don't have to write it that way. Don't understand multiple inheritence? Fine...*don't use it*. Don't get templates? Fine...*don't use them*. We still use VC6 and its template functionality isn't even complete!

The truth is, you can have bizzare WTF moments in *any* language. A lot of what people attribute to the failure of a language is the failure of a programmer to properly explain what his/her code does in a straightforward way *using the code itself*. The best code is clean and concise and C++ gives you as much opportunity to do this as any language. Sure you can have multi-thousand line functions in C++, but this isn't a failure of the language to somehow magically break it apart for you into better organized bits, it's a failure to understand that a language, *any* language, whether purely written or even spoken, is to convey a message, a story, and without careful attention to detail, can become an unholy mess (like this post).

Whatever. (4, Insightful)

pjkundert (597719) | more than 8 years ago | (#14427922)

One thing that differentiates an excellent tool from a poor tool is that the excellent tool handles and "feels" better the more proficient the tool user becomes.

Among all the programming languages I've used over the last 25 years (6502/6809/m68k/... assembly, Prolog/Miranda/... functional, Perl/Tcl/Python/Lisp/Java/... interpreted, C/C++/PL-1/... compiled), only 2 really stand out as "excellent" tools:

C++ and Python. I really have to struggle picking which one I love to write programs in more. They both have their place, and they are both lovely in their own way.

As far as C++ goes, since it exposes all the "knobs and dials" of the underlying computing architecure, it does have a very long learning curve. However, Template Metaprogramming is unlike anything, available anywhere, in any other language.

Listening to all these Java/C# fanboys flame C++ templates, and compare them to "Generics" etc., is like listening to guys compare their cool Ox-Cart wheel mods, while saying how much that new-fan-dangled "ferr-ar-eee" Sucks...

Yes, it took *years* for me to master C++. Someone smarter, and/or with better (read: any) instruction would -- and should -- do better. But, being able to express an algorithm purely, which will compile efficiently to process *any* type(s), stored in *any* container, accross *any* architecture, with full static type checking and bare-metal hand-coded assembly language efficiency, is something truly unique in the programming language world today.

When some other language comes out with something better and more efficient than Template Metaprogramming, let me know. 'Til then, its C++, baby!

Re:Whatever. (2, Informative)

Eli Gottlieb (917758) | more than 8 years ago | (#14428583)

Better and more efficient than template metaprogramming: Lisp programming with declare statements indicating the places where type guarantees can be made.

Re:Whatever. (0, Troll)

LizardKing (5245) | more than 8 years ago | (#14428912)

Listening to all these Java/C# fanboys flame C++ templates, and compare them to "Generics" etc., is like listening to guys compare their cool Ox-Cart wheel mods, while saying how much that new-fan-dangled "ferr-ar-eee" Sucks...

Well, if we're going to have the inevitable car or vehicle comparisons, then C++ is a Ford Mustang to Java's BMW five series. One's a poorly engineered mess and ungainly to use, while the other's an elegant balance of performance and features that's a pleasure to use. And anyone who thinks C++ is elegant or pleasant needs their head examining, or has only previously programmed in COBOL.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...