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

Comments

Balkanization

[(1 -sqrt(5))*(2**-1)]

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's engine being ported to Java, Quake seems to have fared well with feral C.

Re:Balkanization

[Bazzalisk]

C# seems to have a lot of support these days too.

Re:Balkanization

[Merle Darling]

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

[mwvdlee]

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

Re:Balkanization

[SilverspurG]

++x

Re:Balkanization

[LLuthor]

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

[Merle Darling]

Wow, you're right, I AM a tard. I guess the C++ quirks are right for me after all. =)

Re:Balkanization

[Threni]

> 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

[bhima]

"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?

Re:Balkanization

[(1 -sqrt(5))*(2**-1)]

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

[OzPeter]

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

[StrawberryFrog]

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

[Anonymous Coward]

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

[mwvdlee]

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

[mrsbrisby]

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

[OzPeter]

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

[OzPeter]

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

[Carewolf]

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

[mrsbrisby]

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

[Viol8]

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

Re:Balkanization

[mrsbrisby]

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

[SporkLand]

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

[Viol8]

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

[IpalindromeI]

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

[OzPeter]

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

[p3d0]

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

[SporkLand]

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

[ObsessiveMathsFreak]

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

[ObsessiveMathsFreak]

The point is you should always optimise your code within reason.

Rules of optimisation:

1. Don't
2. (Experts Only) Don't Yet!

Re:Balkanization

[YA_Python_dev]

    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

[Anonymous Coward]

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

[StrawberryFrog]

My mistake - it should fall into the "functional, highly productive if you can code like that" area.

Re:Balkanization

[YA_Python_dev]

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

[mattgreen]

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

[mrsbrisby]

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

[smcdow]

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

Re:Balkanization

[mrsbrisby]

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

[Anonymous Coward]

Except f2 and f1 are stubs that look like below. Note that ostream/ios/etc are all deeply virtual to make for good generics...

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_ostreamI T_T0_ES6_>:
      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@plt >
      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_ostream IT_T0_ES6_@plt>
      7da37: 83 c4 10 add $0x10,%esp
      7da3a: 5b pop %ebx
      7da3b: 5e pop %esi
      7da3c: 5d pop %ebp
      7da3d: c3 ret

Re:Balkanization

[ObsessiveMathsFreak]

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.

That's what's known as overloading streams, which is what cin is.

I have no idea what you mean by "decomposing" your programs.

Specifically, using object orientation and functional blocks to make everything simpler. i.e. not having a 40,000 line app in one file. C++'s big advantage is that I can do all this without using macros. C++'s big disadvantage is having to use pointers to do this, but C suffered from this as well.

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.

It's not as safe as Java, and it's a little slower than C. Safe code has gallons to do with the language. C++ is paticularly suseptible to this, in a way I don't think C ever was. C++ gives you enough rope to hang yourself and all your customers, your dog, and Stroustrup, and still encircle the eart five times. However, just think what you could so with that much rope!

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.

Near as I can tell, the methodology of C++ is to get as far away from assembly as possible while still maintaining acceptable performance. On this goal, I think it succeeds. However for most programmers, this goal sucks.

Re:Balkanization

[moro_666]

umm ... c# ?

c#'s performance under windows may be considerable, but under linux and the rest of the unix world, it still s*cked big time the last time i checked.

besides, if you don't need raw speed, you go for python, perl or tcl/tk to get a quick and reliable solution, instead of endangering your whole source code into a language that isn't eveny mature yet and who's puppet governed by the big evil redmond himself.

so, until c# demonstrates backward compatibility and really some _reason_ why to use it, i will keep it in the closet and use stuff that has proven to work very well so far. being "cool" is not a reason. speed is reason, widely usable is a reason. a c# application will need a huge runtime to run after a few years from now. so it won't really differ from java anymore.

  if you need speed, you choose C. everything else is just dull.

  why choose an brand new unsharpened handsaw if you have the old and trustworthy chainsaw in the back of your truck ?

Re:Balkanization

[mrsbrisby]

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.

That's what's known as overloading streams, which is what cin is.

But that's not what you said, you said ... overload cin- something that is actually possible in a language like Objective-C (although I don't know of any Objective-C programmers that would dare to call it "overloading"), but that is not possible in C++.

You can subclass istream and then cin = new istream_descendant provided nobody uses cin in their global constructors (do you know if they do?).

You can also provide a operator>> to a another class or type, and I'm fairly certain this is what you mean by overload- because at this point, cin>>foo can do something useful, but it affects other istreams elsewhere. That is also, often very desireable.

But, there's no way in C++ to actually replace cin with some subclass and make certain that every other class happens to see it that way.

Oddly enough, this is possible in Smalltalk, Objective-C, Java, and Simula67 (IIRC).

I have no idea what you mean by "decomposing" your programs.

Specifically, using object orientation and functional blocks to make everything simpler. i.e. not having a 40,000 line app in one file. C++'s big advantage is that I can do all this without using macros. C++'s big disadvantage is having to use pointers to do this, but C suffered from this as well

qmail is a "mere" 17,040 lines of source, but the longest file is 1,621 lines and the majority are under 20 lines long. There are a total of 305 #define statements, 60 of which qualify as actual macros- none of which are for typing, but simply mere wrappers to avoid typing quite so much- I don't think that's objectable as both GCC's C++ library and Microsoft's MFC use macros for similar reasons.

I don't see how C++ would be needed for any of this. But at this point, it's a little off topic- just my own curiosity.

It's not as safe as Java, and it's a little slower than C.

Accepted.

Near as I can tell, the methodology of C++ is to get as far away from assembly as possible while still maintaining acceptable performance.

Except that moment you need a runtime type-check, a JIT has the ability to beat your performance as it can actually patch the runnable sections.

I used to think this was mere theoretical stuff here, but Java has come a long way...

In any event, I reject that definition of C++'s methodology. Bjarne says:

"I wanted to write efficient systems programs in the styles encouraged by Simula67".

This of course, is not what most C++ programmers do: Using the features styled after Simula67 leads to extremely poor performance, and I don't think (hope?) that's in dispute with anyone except Bjarne himself.

His best quote has to be:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses".

How true that's become of C++ today.

Re:Balkanization

[ObsessiveMathsFreak]

You can subclass istream and then cin = new istream_descendant provided nobody uses cin in their global constructors (do you know if they do?).

You can also provide a operator>> to a another class or type, and I'm fairly certain this is what you mean by overload- because at this point, cin>>foo can do something useful, but it affects other istreams elsewhere. That is also, often very desireable.

But, there's no way in C++ to actually replace cin with some subclass and make certain that every other class happens to see it that way.

OK. I'm not that concerned about terminology. I just write the stuff.

Re:Balkanization

[pthisis]

Don't forget that PyPy performance has improved by a couple of orders of magnitude over the past 6 months, and it seems likely that Python on PyPy will overtake C# for raw native performance within the year (PyPy has a large amount of European Union funding behind it, and the psyco Python JIT author is one of the core developers). Although for a lot of CPU-intensive tasks if you're doing numerics, image manipulation, etc then your python project is going to spend most of its time in hand-coded C libraries anyway.

PyPy is pretty darned cool; with the approach they took it should be a fast general virtual machine/JIT for many dynamically typed languages (they already have a JavaScript front-end as well).

Re:Balkanization

[Viol8]

Hello Mr Gates. Hows Office 2007 coming on?

Re:Balkanization

[jcaldwel]

I have seen benchmarks that suggest that equivalent Java may be just as fast or faster than C code in some cases. This has to do with the JIT compiler, the benefits of asynchronous garbage collection, and compile-time optimizations, as I recall.

Of course, there is nothing you can do in Java that can't be done in C... so I guess you are just putting poorly written C against poorly written Java.

I'm waiting for the time when C--, uh, I mean C# gets edged out.

Re:Balkanization

[daem0n1x]

What do you mean, balkanization?
I think you're misusing the word:
Check Dictionary.com

Re:Balkanization

[ProZachar]

"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?"

Then you look at your code and see how the API optimization affects you, and decide if it's worth the time and effort (and of course, those translate to "money") to refactor your code. You'll only drive yourself and your fellow programmers insane if you try to predict future optimizations to your API and code around them in the present.

Write the best code you can with the tools you have today. Who knows what tomorrow will bring (or won't bring, as the case may be). It's not here yet.

Re:Balkanization

[(1 -sqrt(5))*(2**-1)]

What do you mean, balkanization?

Here's what the OED has to say:

Balkanize v., to divide (a region) into a number of smaller and often mutually hostile units, as was done in the Balkan Peninsula in the late 19th and early 20th centuries.

Meaning that, as certain orthodox languages become entrenched, the software industry becomes fractured along the lines of said languages; and the radicalization of which factions pushes out moderates (in this case, C++).

Re:Balkanization

[Anonymous Brave Guy]

Is that the same C# that a friend uses, which apparently requires 12 bytes of memory to store a single 32-bit integer?

If that's accurate, then I don't think C++ has much to fear from C# in its natural areas of strength...

Re:Balkanization

[Anonymous Brave Guy]

This entire thread is a complete straw man: you may be comparing cout with puts but the original post by OzPeter, and the rest of the discussion elsewhere, is talking about whether using a C++ compiler inherently slows things down. It doesn't, and to say otherwise is simply and demonstrably wrong.

I'm not going to do what you did and put words into Bjarne's mouth, though I will say that I've personally never heard him claim that using puts isn't writing C++, and I've seen him write on many occasions that the compatibility with C has been a major strength of C++ from the start. He may not recommend using the C-style output routines, but that's a different thing entirely.

In any case, you can't start arguing about speed based on a single, biased example (particularly one that wouldn't be apples-to-apples even if you were comparing recommended approaches, on account of your handling of newlines). If you're going to do that, I'll suggest you go try sorting a few arrays of thousands of entries with qsort, and then try again with C++'s std::sort, and see how you do. It's just as biased an example, if not more so, and it'll come down heavily in C++'s favour with any half-decent C++ compiler. Now, which is more likely to be relevant to performance, the speed of printing a line of text to the standard output stream, or the sorting of a large array?

There are fair criticisms one could make of C++, but I'm afraid your posts in this case are little more than straw man attacks and provably false conjecture. The reason there are so many ill-founded rumours flying around about C++ isn't because of people like Bjarne, it's because of people like you.

Re:Balkanization

[Mr. Slippery]

Specifically, using object orientation and functional blocks to make everything simpler. i.e. not having a 40,000 line app in one file.

Why in the world would you do that in C?

C's file scoping allows for a great deal of encapsulation. Create your app as a set of modules that interact via a well-defined interface; each module is implemented by one .h file containing the function and extern data declarations and one containing the function definitions (and of course one main.c or app.c that has main()).

It's not OO since you don't get polymorphism, but it gets you the crunchy goodness of encapsulation and abstraction.

Re:Balkanization

[adrianmonk]

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.

And even then, it may not happen. Imagine you have a class Beer with a method named drink(). The following code might use the v-table to get to the drink() method:

void drink_beer (Beer *b) { b->drink(); }

The reason is, the compiler doesn't know at this point whether you are going to subclass Beer so it has to allow for b having a type where that function has been overridden. But with this code it can generate a direct call:

void drink_beer (Beer b) { b.drink(); }

The reason is, at the point it makes the call to drink(), it knows the type for sure, so even though it's a virtual method, the class of the object on which it is being called is already known, so this can be optimized into a static call and the v-table can be ignored.

Re:Balkanization

[angel'o'sphere]

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:


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 ... haha ... what a hughe difference. Your C fuction puts has a side effect, it adds a new line to the string you write. So your two examples are not compareable anyway.

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 ... then probably you should focus on its strengthes and write about that, no need to try to compare it with C++ as you most of the time will make a mistake then :p

angel'o'sphere

Re:Balkanization

[angel'o'sphere]

Oh my gosh ... when will people learn to understand?

C: language with static types (even if you can drill big wholes into the type system).
C#: a language with static types, a decent typesystem even, pretty hard to drill wholes into.

The above 2 languages require you to declare the type of any variable and any parameter of a function.
Example: int i = 1;

PERL: a languag with a dynamic type system ...
python: a language with a dynamic type system!!

The above 2 languages DON'T even let you declare the type of any variable nor any parameter of a function.
Example: $i = 1;

So: calling the function puts(i); is either compiled and crashes in C because they type system has a whole (convrting the int automatically to a char*), or is flagged as an error in C when you use a C++ compiler, or it compiles as there is an overloaded function puts in C# that accepts an int, or it simply runs in PERL and python and works ... or just does not work .... depending on the internals of puts.

In C# and C++ you frankly can say: if it compiles, it will work.

Calling a function with only one argument is not that a problem, but if it has more than one? How do you remember wether the Person or the Class comes first in a call like schedule.add(aPerson, aClass); ??

People like *I* are to dumb to remember such stuff. But in a decent Java/C# IDE the IDE not only lets me autocomplete the call, but most of the time the IDE itself inserts the arguments automaticaly in the correct order as it knwos what parameters the method expects. And if I indeed write it manually ... in most Java IDEs the compiler is called on save ... so I see that I made a mistake in the editor imediatly.

In python, PERL, I see simple bugs like that only AFTER I have applied my test cases!!!!

So if you are faster in python its only YOU!!! Plenty of people think like I or in other words their mind works like mine and they would waste hours and hours in working with python where a static typed language would be much faster.

Its very dangerous to draw the general conclusion that a secific language is a superior developemnt platform just because it is for some people, or just because it is it for YOU. All people using Lisp a lot never touch any other language (and stick to it, as Lisp is in their eyes the ultima ratio). I OTOH never touch Lisp, as it is in my eyes completely braindead.

angel'o'sphere

Re:Balkanization

[angel'o'sphere]

Thats only true for one single integer, that is treated as an object. As the int is then more or less an object with type info. Imho the number should be 8 anyway, and not 12, but I don't know ;D

However: how many global integers do you have that this matters?
I mean: in a fuction parameters and local variables are on the stack, so it should not matter if they are 4 bytes or 12 big.

If you need arrays of integers, then the whole array is n * 32/8 + X, where X is either 4 or 8, depending who is right. So the whole array has some extra bytes and the ints inside of the array are all 32 bits big, exactly as in C.

So what exactly is your point? I guess it is: you have no clue about C#? No problem, I don't know that much about it as well ;D

angel'o'sphere

Re:Balkanization

[rjshields]

In C# and C++ you frankly can say: if it compiles, it will work.

Absolute nonsense. You can only say it's compiled.

Re:Balkanization

[Anonymous Coward]

Haskell is neither a scripting language nor dynamic. It is compiled (first to C and then to machine code)

A language is not "compiled (first to C and then to machine code)". A given Haskell compiler might do that, but certainly not all of them do. And there are Haskell interpreters, as well (eg, hugs).

The best resource for this sort of things is, as usual, haskell.org.

Re:Balkanization

[daem0n1x]

That's not what I understood from your first post. Anyway, I don't agree.

I think there are quite some languages that people can use, it was never so easy to mix languages and technologies like it is today, thanks to all the standards we have available.

In my workplace, we mix several technologies together quite often, though Java is more often the choice. We don't usually have the zealot attitude around here, though I have faced some of it coming from the usual Microsoft drones. I had to show them how easy it is to call Java objects from .NET and vice-versa, to break through their shell a little bit.

As an illustration, my personal experience:
5 years ago, applications were built using proprietary languages like VB, Delphi, Oracle PL/SQL, MS T-SQL, and all kinds of other one-of-a-kind technologies. None of these played well with each other. Most of the time, all the business logic was built in stored procedures and got locked to a particular database technology. It was a nightmare even to upgrade the DB software version, and completely impossible to switch BD technology.
The UNIX and MS worlds had their backs turned on each other. The interactions between both worlds was very difficult, and porting impossible many times.
I the presend day, you can develop pretty complex systems using only free languages that are powerful and available (Java, C#, PHP, Python, Perl, Shell scripting, Ruby). The change of paradigm to N-tier obsoleted the stored procedure nightmare. And the rise of standards allowed all these languages to interact easily, ending the custom protocols and the error-prone text file data transfers (aaarg!).

Nowadays, I can have 2 completely differnt development teams in the same project, one developing a pretty cool J2EE app and another developing a cool-looking Windows client for it using .NET, with zero or little integration issues. 5 years ago, you would have to develop a custom protocol for it, making up for a lot, if not most, of the project effort and costs. I know it, been there, done that.

So, what's your point for balkanization? I think it's exactly the opposite.

Re:Balkanization

[gbjbaanb]

12 bytes to store an int. Probably, but only if its boxed (ie converted into an object type so you can apply all those Object derived methods on it). Quite a lot like Java really. In fact, a *lot* like Java. They should have called it J# IMHO.

Re:Balkanization

[Anonymous Brave Guy]

I never claimed to know much about C# (but the person supplying the information to me certainly does). And I realise that the overheads are probably per-object. I'd be interested to know how this applies to, say, an integer that is a member of a class rather than an array. Are there overheads for thread safety, padding, etc. then?

In any case, my point is that if this kind of overhead applies even in some common circumstances, then that is a big minus point for C# as a possible language in many contexts. One of the biggest strengths of C++ is the zero overhead approach, and it's hard to see any language that doesn't at least approach a comparable standard making a dent in C++'s core market.

Re:Balkanization

[angel'o'sphere]

Hu?


void put(int i, char c);
void put(string s, float f);

string x = "bla";
float pi = 3.14;

put(x, pi);


The alst line compiles .... furthermore, from teh to functions "pseudo declared" above the correct one is called. Thsi code is staticalyl correct and will run.

Don't know what you talk about. Probably you want to claim that put() might have an internal error and fail ... sure. But I was not talking about put() but about *my* code.

angel'o'sphere

Re:Balkanization

[angel'o'sphere]

The overhead only applies when an int is passed around as single object.

When its only a field inside of a bigger structure it has its corect size. (As the type information of the bigger structure tells you field 4 is an int, that field does not need its own type tag).

C# has the option to write unsafe code, then you lose all that stuff and are more or less on C++ level (well, with less features than C++, ofc)

The funny thing is: C++ has no real core market. Most embedded stuff where C++ is used, the programmers only write C ... because they fear "to lsoe" something if they use C++ ....

So well, core market for C++ might still be telecommunications (phone and probably internet, switches/routers etc.)

angel'o'sphere

Re:Balkanization

[IronDweeb]

> drill wholes into

Oh for Pete's sake. If you are going to lecture about languages, use at least one correctly.

Re:Balkanization

[corngrower]

...drill big wholes into the type system...
..., pretty hard to drill wholes into...
...system has a whole ...

hole is the word you're looking for. Hole - an ommision, a spot where the dirt has been dug out of the ground. Whole - entire, complete, not partial.

Re:Balkanization

[Anonymous Brave Guy]

The funny thing is: C++ has no real core market.

Games?

Mathemetical modelling?

Engineering/instrument control?

CAD/CAM/CAE and similar heavily numerical applications?

System tools?

Telecomms?

(I realise that C and other languages are also used heavily in some of these fields, I'm just giving some examples of areas where C++ has been very successful.)

Re:Balkanization

[corngrower]

But chances are very good that calling the second

void drink_beer( Beer b) { b.drink(); }

will run slower than calling the first

void drink_beer( Beer *b) { b->drink(); } or
void drink_beer( Beer &b) { b.drink(); }

Because the second requires constructing completely (at least copying) the complete beer object, a task requiring more instructions than the 1 or 2 instruction overhead of the virtual function call.

Re:Balkanization

[2short]

    To put it simply, No.
    Using only C functionality, in the worst case, a C++ compiler should produce an equivalent runtime to a pure C compiler. In many cases it will produce a faster runtime; the classic example is the standard library sort function. This uses the same algorithm, and probably much of the same code, in both languages; but in c++ it is a template, so the comipler can inline the comparison function.
    People who beleive C is faster than C++ do not know what they are talking about. They will start telling you about virtual functions or exceptions. These are not required in C++, and C does not have them at all, so how is it faster again?
    C++ is very nearly a superset of C. There are certain ways in which it is not (can't call main(), stricter typing of pointers, etc.); but none of these adversely affect performance. So unless your compiler sucks (and non-sucky ones do exist) C++ should never be inherently slower than C. Sometimes it's faster; and it certainly has advantages in areas not related to performance.

Re:Balkanization

[Anonymous Coward]

I entirely agree with the above post. Whomever you are, thank you.

C++ is a multiparadigm language. You can and you should choose from them
the proper tool for the task at hand. Nothing but your own judgement keeps
you from using puts() any more than it keeps you from using malloc() and
direct pointer arithmetic.

It's job is to give you control and choice. Your job is to use those wisely.

Re:Balkanization

[angel'o'sphere]

Well, I dont want to depress you, as I don't have the impression we need to argue or have different views about that matter ... however:


Games?

Still often C.


Mathemetical modelling?

Mathematica? Simulink?


Engineering/instrument control?


Indeed, but often more or less only C.


CAD/CAM/CAE and similar heavily numerical applications?

No, you won't believe it, but most of them (CAD as well as numerics) are written in Fortran.


System tools?


Yes, at least I would chose C++ but rumors are even stuff like Bitkeeper is writen in C.


Telecomms?

Very true, as I mentioned ... basically the foudners of C and C++ come from the telcos, Bell and AT&T


(I realise that C and other languages are also used heavily in some of these fields, I'm just giving some examples of areas where C++ has been very successful.)

Perfectly right. However I would not call a field where success happends a core market.

The whole thread here is divided in 2 parts (if you exclude the majority, thats the ppl that have no clue about C++ anyway): one part (me included) belives C++ is on the decline (because we realize that C++ is in fact a nice language but it is not able to establish a 'core market'), and the other part is tracked by the fact that 'C++ is a nice language' and does not see it is no longer used widely anymore.

5 or 6 years ago I would have claimed that *I* am one of the 10, or 50 or lets say even only the 100 best german C++ programmers. (Yes, I could have been wrong as arrogant I'm often are) Guess what: the last 8 years I got no single job offer concerning C++, except 3 days ago. No one is doing hughe C++ projects anymore. Everything that is "hughe" is no done in C++.

angel'o'sphere

Re:Balkanization

[wayward_son]

Programming in C is like programming in C++ with one hand tied behind your back.

Even if you never touch the OO side of C++ and stay procedural, it makes C considerably easier. Let's see...

Stronger typing
Better casting
new/delete over malloc/free (C's memory allocation is a PITA compared to C++)
Pass by reference
C++ standard template library

And that's just what I can think of.

Sure, you can shoot yourself in the foot in C++, but you can do that in any language, feral C included.

Re:Balkanization

[Anonymous Brave Guy]

It seems we have very different experiences here. Maybe it's because I'm based in the UK, and our IT industry is moving in a different direction to that in Germany.

I don't personally write games, but a couple of friends do, and their code is almost entirely C++.

Of course there are applications that end users rely on for mathematical modelling, but what are they written in? It's usually C++.

I used to work for a company that wrote instrument control applications for customers in diverse industries. Everything we wrote was written in C++ (though sometimes the firmware and/or device drivers we talked to were written in C).

I'm afraid you're completely wrong about CAx. My current employer makes libraries used, quite literally, in almost every major CAD application in the world, together with countless smaller developments. Several of the big CAD firms have offices here, and I have friends working at most of them. I promise you, with complete confidence, that the vast majority of development in this industry is done using C++.

I don't think there's much doubt about system tools. Old ones were written in C, and many are still in use, but newer things are mostly C++ now IME. Just pick you favourite compiler or VM and check what language it's written in.

Perhaps it's a matter of perspective, or your industry has just evolved differently to ours, but IME all of the above categories are dominated by C++ today.

Re:Balkanization

[angel'o'sphere]

Hm,

another field, that probably indeed deserves the tag "core market" is embedded programming. I just had a longer talk about that with a company working in that field today. While on 8 and 16 bit systems mainly C is used, on larger systems C++ is very common.

About CAD you surely are right, as well as Telcos. I agreed there anyway ;D

angel'o'sphere

Re:Balkanization

[Anonymous Coward]

I guess you write all of your code in assembly, eh?

Re:Balkanization

[Anonymous Coward]

No, the above does not use virtual functions/operators, and hence it does not use a v-table.

Yes it does. Ever heard of a streambuf?

Re:Balkanization

[petermgreen]

The funny thing is: C++ has no real core market. Most embedded stuff where C++ is used, the programmers only write C ... because they fear "to lsoe" something if they use C++ ....
C++ is a very complex language so on platforms where you are forced to use the manufacturers compiler there is more chance they will have screwed up the C++ compiler than the C compiler.

and how many abi breaks have we seen in gnu C++ over the last few years because they screwed up some feature of the C++ standard? loads!

Re:Balkanization

[GlassHeart]

Even if you never touch the OO side of C++ and stay procedural, it makes C considerably easier. Let's see..

Stronger typing
Better casting

How so? Without inheritance, the only significant difference that comes to mind is the different handling of "void *", hardly a useful feature.

Pass by reference

Without the needs of OO, I don't agree with this one. One potential problem of pass by reference is that you can significantly change the meaning of code at the caller side without changing any code there. Pass by value requires any such change to be propagated to the caller side as well, which at least means a human would look at the code to see if it breaks anything.

Re:Balkanization

[Anonymous Coward]

You know, I read your comment and smirked. Then I thought.. "That isn't right. C# decrements C immediately not after the code is executed." So I think we should refer to C# as --C. I hope that way programmers get a better picture.

This reminds me of a C++ course I once took. Everyone flamed C++ because they couldn't even compile their code w/o a TA rewriting it for them - they liked java better. C++ was too powerful.

And to the example above with the address of a var and cout stream. If you dont like passing a reference - dont. Use a pointer. Easy as pie. I cant remember if this was everything he wanted to do, but I cant hit back w/o erasing this.

void blah(int *x)
{
    cout (*x);
}

Re:Balkanization

[rjshields]

Common problems include casting errors, off-by-one errors, and array index errors. Just because code compiles does not mean it will work.

Re:Balkanization

[rjshields]

There's also a trend to employing developers with more than one language, certainly in the UK - it's no longer good enough to "just" be a C++ whizz, you need C and Java or Perl and 10 other core skills. Perhaps the higher level jobs are fewer and further between, but there are a wealth of jobs for people with intermediate skills in a few areas.

From my point of view

[Z00L00K]

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.

Re:From my point of view

[slamb]

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

Re:From my point of view

[Z00L00K]

Notice that I stated SUPPORTS, not REQUIRES. A slight difference...

Re:From my point of view

[MagicM]

C-hash (C#)

It's called C-sharp.

Re:From my point of view

[p3d0]

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

[macshit]

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

Re:From my point of view

[mellon]

You're repeating some classic received knowledge about C++ that happens not to be true. I have to admit that for a long time I bought into the story that C++ was like C, only more complicated. And that C++ is fundamentally about object oriented programming.

I got over my dislike of C++ about two days ago when I decided to use Qt to do some programming, which pretty much forces you into C++. I was really shocked at how unpleasant it *wasn't*. I've had some really bad experiences with Java - a lot of "model" is forced down your throat. Using C++ felt very natural, and I noticed a huge number of really nice touches that are quite cheap, because they're done by the compiler, but that (a) make your coding less error-prone, and (b) are just horribly convenient.

So my point here is that if you've been hearing for years that C++ isn't worth your time because it's object oriented or because it's just C warmed over, neither of these statements is true. I'm embarrassed to have ever repeated them (sad to say, I have done so in the past).

I really don't think C++ is on the way out. My main complaint about it at this point is that g++ is too verbose when I use an overloaded function that doesn't exist - it prints a list of all the possible candidates, which can get quite long. I don't think that's a capital crime, though. :'}

Re:From my point of view

[slamb]

Notice that I stated SUPPORTS, not REQUIRES. A slight difference...

If you're going to nit-pick, look at the full sentence. What you said was this:

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

This is not the difference, and many people would say that it's not the most important difference - metaprogramming is. Agree or disagree, but don't just disregard what they're saying without comment.

Re:From my point of view

[stonecypher]

Wait, let me get this straight. You used QT and it wasn't unpleasant? When did that happen?

Re:From my point of view

[Anonymous Coward]

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

Thank you.

Now continue the race to the bottom.

Re:From my point of view

[the_womble]

read Java & C-hash (C#)

Do you mean C-octothorpe (C#)

Re:From my point of view

[mellon]

This past weekend. I haven't tried Qt3, so I don't know if it was a drag or not, but Qt4 was dead easy. I was truly amazed.

The one thing about Qt4 that I didn't like was the widget editor, not because it was completely awful, but just because I don't like widget editors - there's always knowledge embedded in the GUI that you have to learn by guessing wrong a lot or reading more documentation than you'd have to read if you just bypassed it and went straight to coding. But compared to the GUI for MSVC/.NET Forms or Cocoa's Interface Builder, both of which I've had the misfortune to have used, even the widget editor is pretty nice.

Re:From my point of view

[BorgCopyeditor]

I'm a mere hobbyist, and I agree. I knew no C++ before starting to write a QT4 app, but found it pretty easy going.

Re:From my point of view

[angel'o'sphere]

Well, you are the nitpicker ;D

So lets make it clear: The difference between C and C++ is that C isn't object-oriented and also does not support meta programming nor generic programming while C++ supports object-oriented design (should be programming IMHO) and supports templete based meta programming as well as generic programming.

To nitpick myself a bit: no, C++ does ot support meta programming, it only supports template based meta programming which is in the technical sense not meta programming but only a subset of meta programming and hence it got the naming addition "templete based".

After all it seems to me, you two completely agree anyway and only nitpick about wordings ;D

angel'o'sphere

Re:From my point of view

[angel'o'sphere]

Oh, fark my superb formatting got screwed ;D So I try again:

Well, you are the nitpicker ;D

So lets make it clear: The difference between C and C++ is that C isn't object-oriented and also does not support meta programming nor generic programming while C++ supports object-oriented design (should be programming IMHO) and supports templete based meta programming as well as generic programming .

To nitpick myself a bit: no, C++ does ot support meta programming, it only supports template based meta programming which is in the technical sense not meta programming but only a subset of meta programming and hence it got the naming addition "templete based".

After all it seems to me, you two completely agree anyway and only nitpick about wordings ;D

angel'o'sphere

Re:From my point of view

[corngrower]

You know you can do generic programming in 'C' as well. It's just not usually done and it's rather kludgy (using #defines and #includes). And also you can style your 'C' code in an object oriented manner. Take a look at the source for the XtIntrinsics library for X11 some time.

C++ Dying?

[jetsfandb]

If they want my C++ compiler they will have to pry it from my cold, dead hands!

Nah

[codeboost]

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.

Re:Nah

[Anonymous Coward]

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

[Chemisor]

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

[pslam]

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.

Re:We just got tired of being insulted

[Eli Gottlieb]

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

Re:We just got tired of being insulted

[Anonymous Coward]

My brother's girlfriend's uncle was a C++ programmer, and he died.

Re:We just got tired of being insulted

[baadger]

Personally i'd rather code in Borland Delphi/Kylix or Free Pascal any time. On the Windows platform it's wonderful, there are handy utilities to convert C (and C++?) header files to Delphi units and extract type libraries from Microsoft's COM/COM+ damnations (I dislike interfaces) so you can get away with alot. Not to mention it was the second language to 'support' .NET (after C#).

Re:We just got tired of being insulted

[Eli Gottlieb]

So would I. After all, a bare minimum RTL for Free Pascal (capable of running on bare metal) requires nothing more than heap support to get the language features working. The other annoying RTL functions don't need to be used or implemented at all, which pretty much mitigates the old complaint that Pascal requires an unwieldly RTL.

Re:We just got tired of being insulted

[stonecypher]

a big bunch of drones regurgitate some absurdities... Some morons even go so far as... Some morons go so far as... We're just plain tired of... and carry on regurgitating the same crap they heard from some uninformed idiot... very few of the readers here have actually used... You're only hurting yourselves...

Whereas I am a huge C++ zealot, the tone you're taking is the exact same uncompromising assumption of superiority in knowledge and authority that leads other people to saying the very things you're railing against. Your attitude is in fact the facilitator of that which you assail. Like it or not, C++ does have flaws. If you lash out blindly every time someone points one out, you're going to get marginalized very quickly.

Flies with vinegar. Nobody listens to people throwing tantrums, regardless of whether or not they're correct. There are in fact times when other languages are better, for one of several potential reasons falling on either side of the margin wherein C++ is the appropriate language. C++ is fairly clearly a language well-suited to general use; there's a reason it's globally dominant, despite being difficult to learn and fairly error ridden in the case of novice code. For other langauges those characteristics would be a death knell.

Nonetheless, even if you've taken it as some sort of personal insult every time someone raises a viewpoint with which your experiences disagree, perhaps you should take a point from Good Ol' Doctor Valium, and luude out. You'll actually reach people who don't already agree with you if you're, how does that go again, pleasant.

Re:We just got tired of being insulted

[RalphTWaP]

*smiles* C++ is a languages in which it is possible--albeit complex--to overcome the language's own limitations and express things with nearly the beauty of Lisp.

Re:We just got tired of being insulted

[Anonymous Coward]

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.

Add to that "long-time C++ users and Windows developers" that for various reasons believe C++ is (or should be ) the same as MFC and scream "C++ sucks" either becaquse they hate MFC with passion or because they never got to use the better parts of C++ due to lack of support in Visual C++ and as such are inherently biased against what they don't know.

Heck, the MSVC++ 6 generation of programers couldn't even try stuff like Loki due to the compiler barfing on it.

Widely used languages don't die quickly

[DavidNWelton]

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

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

Re:Widely used languages don't die quickly

[youknowmewell]

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

Magazine quality

[OzPeter]

[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

[GeckoFood]

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.

Re:Magazine quality

[LWATCDR]

Computer magazines for programmers are fading away. Micro, Byte, Microcornacopia, and Transactor where all great magazines at one time. Programmers can get more information from google and the web than a paper magazine plus download the source.

Re:Magazine quality

[SteeldrivingJon]

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

Frankly, I prefer the matte-finish newsprint.

The gloss serves no purpose and often makes the text harder to read due to glare.

C++ : to remove yet another sucky java app.

[Anonymous Coward]

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.

Re:C++ : to remove yet another sucky java app.

[OOGG_THE_CAVEMAN]

To get scientifically usable results, did you also

1) compare performance to a total rewrite in Java, given the experience gained from the first round.
2) normalize for programmer expertise in the two languages?

I'm guessing not.

Re:C++ : to remove yet another sucky java app.

[Profound]

You can argue about performance, but it is quite obvious that Java uses far more memory than C++. Just look at the underlying data structures.

1. The JVM seems to never release its memory back to the operating system.

2. In C++, a Vector of N integers is approx:

Overhead + N * 4 bytes

In Java, you can't put primitives in a collection so it is:

Overhead + N * 16 bytes

Which means it is 4 times as large as C++.

Netcraft

[just_another_sean]

Has Netcraft confirmed this?

Less C++, more Ruby

[yattaran]

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

[ross_winn]

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

[neelm]

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

Re:Print is in a coma...

[Anonym0us Cow Herd]

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

A print magazine is better suited. Consider how many minutes you spend there. If you don't spend long periods of time there, then a general print magazine (Newsweek, Time, etc.) may be the best. I'm certianly not planning to read something that is lengthy, or requires really deep thinking for an extended period.

Hint: I don't even use a print magazine. I pull out my...

...cell phone and use the WAP browser to check out CNN headlines, local news, local weather forecast, etc. Now I've just eliminated from my day the need to spend 30 minutes watching TV news to get the same info that I got during otherwise "unproductive" time.

Re:Print is in a coma...

[Anonymous Coward]

Time has already lost it, choosing George Bush as one of their "Men of the year" for 2005 due to his amazing work on the Hurricane Katrina incident. I think their staff are already on crack.

C++ has its place

[Ekarderif]

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

[BoomerSooner]

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

[LizardKing]

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

[StrawberryFrog]

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

[Decaff]

"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

[LizardKing]

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

[CaptainPinko]

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

Hmm, I think I'll beg to disagree with your quote.

Re:C++ has its place

[Ekarderif]

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

[Eli Gottlieb]

You're forgetting one:

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

Re:C++ has its place

[p3d0]

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

Only in urban myths.

Huh? You had me until you said this.

Re:C++ has its place

[LizardKing]

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

[everphilski]

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.

Shouldn't be using STL (Think you meant MFC?) anymore... use .NET and Windows Forms. Besides why would we compare a language that is available on what, 5% of end user machines out there (I think I am being generous) whereas every other language is operating system independant (except for c# - but Microsoft windows has what, 90%+ market share? And the compiler is free?)

-everphilski-

Re:C++ has its place

[LizardKing]

Shouldn't be using STL (Think you meant MFC?) anymore...

Nope, I meant STL, the standard template library not Microsoft Fried Chicken which is a horrible OOP API on top of a horrible procedural API for an even worse operating system.

Besides why would we compare a language that is available on what, 5% of end user machines out there (I think I am being generous) whereas every other language is operating system independant (except for c# - but Microsoft windows has what, 90%+ market share? And the compiler is free?)

So fucking what if MS Visual whatever is free for one operating system? GCC (the same compiler that MacOS X ships with) has support for Objective C, C, C++ and Fortran 95. It's available for free for dozens of Unix variants and even MS Windows.

Re:C++ has its place

[everphilski]

Point is why the hell are we talking about something with a 5% market penetration with the rest of the pack having 95%+ market penetration?

Re:C++ has its place

[everphilski]

And besides, compare apples to apples... cocoa is "Cocoa is an object-oriented application environment" (from Cocoa's web site, MFC/.NET are the equivalent under Windows. (MFC sucks but .NET isn't bad... Windows Forms is acceptable.) STL is not and was not intended to be an "object-oriented application environtment. It "is a general-purpose C++ library of algorithms and data structures". (source).

Re:C++ has its place

[everphilski]

let me clarify: sure I can code objective-c on my windows/linux/whatever box. But I wont have a decent API (cocoa). So why, please?

Re:C++ has its place

[Stele]

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.

"I can't unsterstand these features/am too lazy to learn them so they must be implemented poorly."

Go read "The Design and Evolution of C++" and then come back for a discussion about something you have a clue about.

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.

"We don't use it here so it must be useless."

The fact that you got moderated 5, Insightful proves how few /. people know anything about C++.

Re:C++ has its place

[wetfeetl33t]

So, if I want something simpler and faster than Java/C#/etc, but don't want to bother with C or want to use objects, what should I use if C++ is no good?

Re:C++ has its place

[mccoma]

hey, now....

Just because they are coming after you C++ folks, doesn't mean you should attack Objective-C. We get even less respect (failed Smalltalkers / Apple Lackeys) than you.

Re:C++ has its place

[mrsbrisby]

It started life as a kludged on Modula extension to C.

Simula67, not Modula.

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

That's like saying a dead badger is more elegant than a dead weasel. I'm not sure it's useful though :)

Everything else here I completely agree with.

Re:C++ has its place

[mrsbrisby]

let me clarify: sure I can code objective-c on my windows/linux/whatever box. But I wont have a decent API (cocoa). So why, please?

It's called GNUstep and yes, it works just fine.

Re:C++ has its place

[slamb]

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

Umm, no. I love Python as much as the next guy, but I also know that it doesn't have a JIT compiler. Neither do Perl or Ruby. In fact, they're quite slow for many tasks. Parrot may bring these optimizations to these languages, but it hasn't yet.

If these languages are faster, it's because their extreme rapid development frees you up to think of better algorithms. I certainly had a couple cases recently in which the Python code I wrote was much better than it would have been in Java, C++, or C because it was so quick to go through several design iterations. In fact, even if I had determined in the end that Python was too slow, it would have saved a lot of development effort and yielded a better product to use it as a prototyping tool before moving to a faster language.

The argument you gave applies to Java and C#.

Re:C++ has its place

[mccoma]

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.

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -- Alan Kay

Re:C++ has its place

[Thundersnatch]

The Ruby-on-Parrot project is basically stagnant. The status reads as "Broken. Last updated in 2002. Should probably be removed."

Similarly, the Python-on-Parrot project has a status of "Mostly working except for classes/exec/import". Those are some fairly large feature omissions. You'd think the Pythonistas would be all over support for such a project, but many refuse to admin that they care about the performance of Python at all.

I'd love to see a speedy implementation of Python for cross-platform use, but neither of these projects appear remotely close to completion in my opinion.

I recall reading somewhere that some orginzation was offering a Python compiler bounty... or am I imagining things?

Re:C++ has its place

[everphilski]

There are other api's that are truly cross-platform (Windows, Linux, Mac, Embedded) and don't just "run on top of X http://www.gnustep.org/information/aboutGNUstep.ht ml (and no offense, they look prettier too)

-everphilski-

Re:C++ has its place

[mrsbrisby]

GNUstep runs on X11, Cairo, Win32/GDI, and it can also be recompiled on MacOSX.

WxWindows might be able to target lots of platforms, it just does none of them well.

QT on the other hand, is written in a non-standard programming language ("moc C++") in an effort to add features available to Objective-C users for years. Better still: Programming Cocoa in Java or Python isn't anywhere near as unpleseant as writing WxWindows or QT applications in those languages. That's not subjective either.

So being as how GNUstep spans multiple platforms and languages, while WXWindows spans the lowest-common-denominator of multiple platforms and languages, and QT works on less platforms than GNUstep, and in less languages, I'd say that you're completely wrong and have no idea what you're talking about.

That said, I never knew anyone could actually say that this "looks better" than this, but you're welcome to be the first, and if that's how it is, at least I'm productive in the latter...

Re:C++ has its place

[everphilski]

OK, good for you, you can spend an hour digging around to find the worst screen shot of your opponent and the best of your proponent. I've designed better. My main tenent still stands: Cocoa only holds for Macs, which have a 5% market share. Who cares about 5%?

The discussion is about C++. Who cares about other programming languages (Java, Python). Now compare the 3 API's. wxWidgets and QT are skinnable. What about GNUstep? Nope. "moc C++" OK I give you that. But its still a decent API to work with and a breeze to port. As in, you do nothing to port it. (been there, done that)

"That's not subjective either."

I saw no mention of wxWidgets or QT in there. Nice try.

" GNUstep runs on X11, Cairo, Win32/GDI, and it can also be recompiled on MacOSX." (But why would you want to? You have Cocoa? You are talking yourself in circles... ) ... "QT works on less platforms than GNUstep,"

x11? Check. Win32? Check. MacOSX? Check. Embedded? Check. Cairo? According to the KDE-Qt forums: http://dot.kde.org/1135084395/1135100106/113518523 0/ you could. but why? Qt already has all the functionality of Cairo. You could write a backend into Cairo if you really wanted to (mentioned in the same forum ... ) but Qt is quicker and has all the same functionality. Which begs the question... if GNUstep has plugins into Cairo, it must be missing that functionality (that Qt already has). Please respond:

Re:C++ has its place

[PureCreditor]

> Python, Ruby, etc. - Often considered too slow.
>
> Only in urban myths.

totally agreed...if Google can trust Python for a bulk of their scripting, there must be a reason that any performance overhead is greatly countered by the savings in productivity

Re:C++ has its place

[mrsbrisby]

OK, good for you, you can spend an hour digging around to find the worst screen shot of your opponent and the best of your proponent. I've designed better.

Again, subjective.

My main tenent still stands: Cocoa only holds for Macs, which have a 5% market share. Who cares about 5%?

This is a circular argument. GNUstep runs where Cocoa does not.

The discussion is about C++.

So why are you defending QT? It's applications aren't written in C++.

Who cares about other programming languages (Java, Python).

Now compare the 3 API's. wxWidgets and QT are skinnable. What about GNUstep? Nope.

Wrong.

"moc C++" OK I give you that. But its still a decent API to work with and a breeze to port.

And GNUstep is a better API. It's also much more mature. ... and a breeze to port. As in, you do nothing to port it. (been there, done that)

Wrong. C++ is incompatible with C, and moc C++ is incompatible with C++. In contrast, Objective-C is a pure superset of C (in other words: all C code is also Objective-C code), and Objective-C++ is a pure superset of C++ (in other words: all C++ code is also Objective-C++ code).

"That's not subjective either."

That part? No. It was just wrong.

I saw no mention of wxWidgets or QT in there. Nice try.

What are you babbling about?

"QT works on less platforms than GNUstep,"

Which begs the question... if GNUstep has plugins into Cairo, it must be missing that functionality (that Qt already has). Please respond:

I don't think you know what "begs the question" means.

If QT has plugins into Win32, it must be missing that functionality (that Win32 already has).

GNUstep is a collection of many things, and yes, there is a significant amount of duplicated effort there. For example:

GNUstep provides an "art" backend (which is often used on X11) because it supports the nfont system. This is quite a bit older than fontconfig, but these days, "everyone else" wants to use fontconfig, and to make integration easier, GNUstep supports fontconfig through its Cairo interface.

The fact that GNUstep can please so many people on so many different targets in so many different languages on so many different platforms is part of MY point.

The fact that QT is harder to use, targets less systems, supports fewer languages (and the primary one being obscure), and on less platforms doesn't help YOUR point: which is that C++ is more useful and more robust and Objective-C.

So how is it that C++ is so useful and robust if it needs a preprocessor to make it usable in your preferred environment (QT)?

You say Cocoa/Objective-C has 5% of the market, so you use QT. Do you have any idea what kind of penetration QT has? Are you so certain it's higher than MacOSX, GNUStep, OpenStep, and NeXTStep combined?

Re:C++ has its place

[metternich]

(((((I (wonder) why)) ((that) could)) be?))

Re:C++ has its place

[everphilski]

If QT has plugins into Win32, it must be missing that functionality (that Win32 already has).

Doesn't plug into Win32. Its a replacement for the Win32 (MFC/.net) calls you would otherwise make. Same as *Step.

You say Cocoa/Objective-C has 5% of the market, so you use QT. Do you have any idea what kind of penetration QT has?

Doesn't matter, once its compiled it just works on the target platform (win/mac/lin/embedded). Cocoa restricts me to Mac only.

The fact that QT is harder to use, targets less systems, supports fewer languages (and the primary one being obscure) ...

If you are a C++ programmer Qt is a breeze. Qt works on all the desktops out there and on embedded systems, what other systems are there? you haven't told me. And it offers funcionality that *Step doesn't have. And why would I port from c++ to c? Or to objective-c? And give up operator overloading (say what you want but its useful as hell in math and sciences when you are working with vectors and matrices), templates (similar arguments), automatic type casting? Hell no.

The fact that you call C++ obscure makes it obvious that you are an idiot or trolling. I was going to answer blow by blow but you don't deserve it. You have been moderated appropriately, go away.

Re:C++ has its place

[mrsbrisby]

Doesn't plug into Win32. Its a replacement for the Win32 (MFC/.net) calls you would otherwise make. Same as *Step.

Win32 != MFC/.net. Those plug into Win32 as well.

You say Cocoa/Objective-C has 5% of the market, so you use QT. Do you have any idea what kind of penetration QT has?

Doesn't matter, once its compiled it just works on the target platform (win/mac/lin/embedded). Cocoa restricts me to Mac only.

No it doesn't. You keep saying this, but Using GNUStep gives you the same API on many platforms, and as mentioned, more platforms than QT.

If you are a C++ programmer Qt is a breeze.

Subjective.

Qt works on all the desktops out there and on embedded systems, what other systems are there?

You're confusing platforms and systems with "kinds of platforms" or "kinds of systems".

GNUstep runs on OS/2 (for example: a platform and a system). GNUstep runs on GGI (for example: a platform based on UNIX). There are more platforms that GNUstep runs on than QT.

And it offers funcionality that *Step doesn't have.

No it doesn't. In fact, QT had to use "moc C++" instead of C++ because C++ lacks language features that Objective-C has.

And give up operator overloading (say what you want but its useful as hell in math and sciences when you are working with vectors and matrices)

No. What's good there is using well understood operators with other number systems and fields.

Operator overloading isn't required for that. See Fortran.

templates (similar arguments),

No. What's good is the ability to quickly build generics. Templates were added to C++ so that C++ users could add and use generics similar to how Objective-C users can and do, although templates are far inferior to their Objective-C analog.

automatic type casting? Hell no.

Err, C++ doesn't do automatic type casting. It can do automatic type conversion, but C++ has four separate kinds of "cast operators", none of which actually convert the type, and none of which can be omitted and the compiler inserted "automatically".

The fact that you call C++ obscure makes it obvious that you are an idiot or trolling

Check again. I never called C++ obscure. I said QT's variant of C++ is obscure- far more so than Objective-C. "moc C++" is not C++, and the objects that it creates cannot be utilized by C++ code.

You even agreed that "moc C++" wasn't the same as C++, so I have no idea what argument you're making here.

I was going to answer blow by blow but you don't deserve it.

You mean you don't really know what you're talking about.

You have been moderated appropriately, go away.

Many times, but none of my posts on this thread have been moderated. On a nearby thread, I was moderated "Flame Bait" for mentioning lies told by the inventor and authority of C++, which just goes to demonstrate what kind of tools C++ users actually are.

translation: LA LA LA LA, LA LA LA LA

[mkcmkc]

:-)

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

Re:translation: LA LA LA LA, LA LA LA LA

[jgrahn]

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

Speed is not the only reason to prefer C++ to e.g. Python (which I happen to like and use a lot). Possibly not even a big reason. The type system and the C compatibility come to mind. And RAII. Do yourself a favor and read Stroustrup's C++ FAQ.

My biggest problem with C++ is the apparent lack of a decent conforming compiler

Huh? What's wrong with recent GCC releases, in practice? Or Microsoft's compiler? Is there any C++ compiler today with significant conformance issues? Apart from thoose that implement Embedded C++ ("Writing a C++ compiler is hard, so we've decided you don't need it"), that is.

Re:translation: LA LA LA LA, LA LA LA LA

[Arandir]

Don't condemn all of C++ just because some idiot wrote a Makefile in it. Get real. No one out there, not even the hardest of the diehard C++ fans, is advocating using C++ for everything. Stop being stupid.

Re:translation: LA LA LA LA, LA LA LA LA

[stonecypher]

Unfortunately for C++, there are very few programs for which this is the appropriate niche.

The RAND corporation says that more than 70% of all software is embedded software. Embedded as an industry is almost universally C++. Please do not confuse being in a different branch of the industry with a branch of industry simply not existing.

Re:translation: LA LA LA LA, LA LA LA LA

[taylork]

You mean C don't you?

Re:translation: LA LA LA LA, LA LA LA LA

[stonecypher]

I said what I meant and I meant what I said. According to the RAND corporation, embedded is 6:1 C++ versus everything else combined. C is rolled in with everything else, not with C++. The point of the article was to display the pervasive nature of C++ when making the case for reliable and secure systems, against myths like have otherwise been widely spread throughout this article's response chain.

depends on who you work for...

[hurlpigeons]

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

Java is dying too

[egarland]

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:Java is dying too

[wdr1]

Java is the new Visual Basic.

Re:Java is dying too

[Anonymous Coward]

Ok, let me guess, you never actually programmed anything in life and spends most of your time reading slashdot?

Last time I checked:

1- Last time I checked jobs for Java were at a high, too high for a "dying" language don't you think?
2- The quantity of open source projects using were high.
3- The big enterprises are using it and supporting it.

It's not anywhere near dying. It's growing, evolving and getting better at each realease. Despite of the wishful thinking of some people with their own agenda to make.

Re:Java is dying too

[egarland]

It's not anywhere near dying.

Java is falling out of favor with many programmers and corporations. It has a huge user base and tons of programs are written in it and will continue to be written in it but that doesn't make it not a dying language. Cobol still has tons of programs written in it. Java has flaws and limitations that make it a bad choice for many types of applications and programming. People are starting to realise that.

Re:Java is dying too

[Skjellifetti]

Java is falling out of favor with many programmers and corporations.

Got some peer-reviewed stats to back that up or you just making that up? I'm not saying it isn't true, but until you cite some real research, you are just talking out yer ass.

Java has flaws and limitations that make it a bad choice for many types of applications and programming. People are starting to realise that.

No shit, Sherlock. Could you possibly have written a more useless generalization? Let me paraphrase:

Hammers have flaws and limitations that make them a bad choice for many types of carpentry tasks. People are starting to realize that.

Re:Java is dying too

[egarland]

I'm not saying it isn't true, but until you cite some real research, you are just talking out yer ass.

If by "talking out yer ass" you mean stating my impression based on my experience as a professional in the field, then yes, that's what I'm doing. I am not citing anything but that doesn't make my statement any less valid. It's not backed up by any research that I know of but what did you expect? This isn't some peer reviewed journal.. it's a Slashdot discussion.

Could you possibly have written a more useless generalization?

The implied but not stated part of my comment was that people had the impression that pretty much everything except operating systems would be better, faster, easier to create and maintain if they were written in Java (due in no small part to lots of marketing and hype from Sun suggesting this.) Lots of projects were pushed away from other languages into Java because it was the future of programming. Reality is starting to set in and people are realizing that Java has some serious limitations and trade offs and the areas where Java is the best language for the job are much smaller than previously thought.

HAHAHAHAHAHA!!!

[Progman3K]

*wipes tears away from eyes*
You can have C++ when you pry it from my dead, cold hands.

Re:HAHAHAHAHAHA!!!

[Intangion]

im with you buddy
C++ is still the main language i use, for its speed, power, and usability

The clearest sign that C++ is a dead end:

[porkchop_d_clown]

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

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

Unreal's engine being ported to Java?

[Anm]

I've seen Jake2, the Java Port of Quake 2 to Java, but I've never heard of anything related to Unreal, or any port, related to Java. Can you provide a link to where you read that?

Anm

Video Games

[MobyDisk]

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

[ultranova]

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

Re:Video Games

[19thNervousBreakdown]

That's funny. I've written over 15,000 lines of C++ code over the last year in my spare time, and run it all through valgrind. Haven't had a memory leak yet. Using RAAI and the STL, I can't even think of a way I could get a memory leak... maybe if I leaked whole objects, but I apply the same discipline throughout my programs that I apply to memory allocation (of which I do very little).

As for buffor overflows, once again the STL helps a lot. For the rest of it, a little discipline goes a long way. Buffer overflows are a lot harder to reliably check for with automated tools, but I've gone over the code looking for them, and haven't found one yet. It's not that hard to program in a way that makes this stuff almost impossible, it's just not a lot of fun. My solution to that is to program the not very fun stuff in a real general and safe way so that I can reuse it and never have to write it again. Keeps you going if you know that when you're done you're done.

Re:Video Games

[Anonymous Coward]

not really, you're forgetting about consoles, which are specialized hardware and no one in their right minds will want to write code for them that goes through layers virtual machines and stuff.

Re:Video Games

[CuteAlien]

Currently nearly every game out there is written in C++, a few in c. One of the reasons is that those are at the moment the languages which are easy to port to consoles and a lot of companies want to do that right now. And i guess it will stay that way at least for another console generation (3-5 years). After that the dice might roll once more.

Re:Video Games

[CuteAlien]

Java is currently missing a really good game engine. Also portability is currenlty a reason to use c++ because linux is still not that important for the game market while consoles are. And even if companies would like to port for linux, there is not much reason to use java instead of c++, because the usual java libs are not really designed for games but more for business applications.

You won't get around the DirectX problem with any language, if you want portability for 3D you have to use OpenGL (or a higher-level library which supports it) and for the other stuff (DirectInput, DirectDraw etc.) the best bet is also just to use other libs (like SDL).

Scripting is often dependant on the used gameengine, but beside that lua or own scriptlanguages are often used. Once more that does not really depend much on the language in which your game is written (and it's even possible to script c++, for example with cint).

Don't know about the performance for a complex game, because i really haven't seen a complex game written in java so far. I guess as usual for 90% of the stuff it would not make much of a difference. But i doubt you can speed up the bottlenecks with java that well - and nothing else counts anyway.

The network transmission itself ain't a big part of the networkcode in multiplayer games (at least not a big part of the development time). Maybe Java can save a few days there, but no big reason to change the language as there are enough net-libs for c++ available.

Can't tell much about the adavantages of java for multiprocessors yet. So far most games try to avoid using several processes, but this will change a lot in the next years.

Memory leaks are not much of a problem with good libraries. Bad references which form ring-like structure (each class depends on the other) are much harder to solve usually and that's once more a problem for c++ and java alike.

Maybe Java has a chance in the future, but so far i don't see much of a trend in that direction in the game industry. And i sort of doubt it really will be the c++ killer in this area. Even if it might offer some advantages, it just does not seem to give the productivity boost which would be needed for a switch. The companies would have to drop all the libs which they are currently using and also most game programmers just know c++ nowadays a lot better than java.

What we problably *will* see is that more code is programmed with scripts, but most modern games do that already to the extend which is allowed without getting a performance hit.

C++ not dead, but it is a dead end

[the eric conspiracy]

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

[metamatic]

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.

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

[Anonymous Coward]

We don't need a C++ replacement with garbage collection (GC)! Real destructors and explicit memory management are the reasons to use C++ over other OOP languages.

Hardware drivers are good candidates for Objects, e.g. printers, but need explicit memory management. You can write a C++ class to run an RS-232 port directly. It can allocate and operate on low level buffers. It may have to destroy them immediately to free the port for others.

Java, e.g., leaves garbage collected memory for later, and someone can read unsecure String objects. See the java.net.Authenticator class, which stores passwords in Char[] objects instead so that they can be zeroed-out.

Also, Java finalize() methods (inheirited from Object) are poor destructors. They don't run until the GC forces them, possibly minutes or hours after the object has died! The Java docs even warn people not to leave close() methods for finalize(). So, C++ didn't need a (try..catch..)finally block because its destructors were guaranteed to fire.

It will be a happy day...

[Anonymous Coward]

When C++ is finally a thing of the past, to be replaced by something like D. 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...

[Viol8]

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

[Anonymous Coward]

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

myObject = null;
System.gc();

Re:It will be a happy day...

[AuMatar]

You forgot the 5 minute wait as the garbage collector goes through full collection at that point. And it still may or may not be freed on the next line, as that uses another thread. And it still may or may not have finalize called. Etc.

Re:It will be a happy day...

[Jerry Coffin]

When C++ is finally a thing of the past, to be replaced by something like D.

While D certainly has some good points, I'm not entirely certain that even Walter Bright is certain it's entirely ready to take over as the premier language. Since you posted as AC I don't know if you read or participate on comp.lang.c++[.moderated] on a regular basis, but if you've been following all the threads, you'll notice where DbC is being discussed, and D is being used as a prime example of how to completely screw things up. Walter is participating in those threads, but so far he seems mostly interested in learning how things should work rather than claiming that D really has it right (for those who didn't realize it, Walter Bright was the inventor of D, as well as the author of the Datalight/Zortech/Symantech/Digital Mars C compilers for C, C++ and D).

Recently I've been learning C++ from a book many consider to be C++'s "Bible": C++ Primer 4th Edition

Ah, it sounds like you probably do not follow the NG much, if at all -- if you did, I'm sure you'd realize that for people who already know programming reasonably well in some other language, Accelerated C++ is, far and away, the recommended book.

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.

The reason for const parameters is simple: they restrict your access to the object so passed. Restricting access as much as possible at any given time prevents accidents, making for safer programs. '*anything' has roughly the same meaning it has in C -- you have a pointer(-like object) and '*' dereferences it. It's possible to overload the (unary version of the) * operator (or nearly any other operator) to do something entirely different, but it's generally poor style to do so. Operator overloading does give the programmer the power to do really bad things, and produce horribly obfuscated code, but it allows the programmer to do really good things, and produce much clearer code than is generally possible without it (e.g. overloading for matrices and complex numbers).

You can somehow pass C-strings to C++ string parameters and they will be automatically converted.

Specifically, it's converted by a constructor. That's exactly what the constructor is for, and it's apparently doing its job exactly as designed. Do you have some objection to things working as they're supposed to?

Initialization lists are horrible, a function can be declared virtual and const (seemingly pointless "features" when in Java all methods are virtual).

This is far from a pointless feature -- while most Java textbooks fail to mention it, this is one of Java's larger shortcomings. Making a function non-virtual says something specific about the design -- that the function in question is invariant across all descendants. The Java language simply fails to allow that concept to be expressed.

Declaring a method const also has a specific meaning -- that the method in question does not alter the logical state of the object. Again, this contributes to the safety of programming. It's true that many languages are utter failures in this regard, but this is an area of strength in C++, and rather a shortcoming in many alternatives.

No garbage collection makes programming a pain and error-prone.

Rather the opposite. GC and it's non-deterministic destruction (finalization) of objects prevents you from using RAII. The fundamental difference here is that RAII can be applied to nearly all kinds of resource management, where GC only applies to memory.

Back before RAII was well developed (or at least before I u

Re:It will be a happy day...

[angel'o'sphere]

You forgot the 5 minute wait as the garbage collector goes through full collection at that point.

If GC takes that long, something is wrong.
As you likely prefer malloc/free over GC I like to ask one question: how long did you learn to use malloc / free? Did you only read 1 minute to find the two functions and you imediatly used it perfectly, or was there a learing curve?


  And it still may or may not be freed on the next line, as that uses another thread. And it still may or may not have finalize called. Etc.

If the GC collects your object, finalize *is* is called. You likely don't know much about Javas and .Net's concept of finalization.

So, after you probably thought about my question: why don't you spend a similar amount of time in learning how GC works? Most posts on /. claiming GC is this or that.... are compeltely wrong.

angel'o'sphere

Re:It will be a happy day...

[Anonymous Coward]

Making a function non-virtual says something specific about the design -- that the function in question is invariant across all descendants. The Java language simply fails to allow that concept to be expressed.

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?

In todays hasty world...

[ballpoint]

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.

Re:In todays hasty world...

[Anonymous Coward]

Are you sure you're talking about C++ and not Tree++

Death by subscription? Please.

[Craig Maloney]

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.

[OzPeter]

"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

Re:Death by subscription? Please.

[pilkul]

These print magazines on programming are particularly dumb since virtually all people who might subscribe to it have Internet access and are skilled enough to find their information online. It was just a weak market to begin with.

C/C++ dying? What are they smoking?

[johnnnyboy]

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?

[ultranova]

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 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, but I don't know how much native code it has.

Then, on the other end of the spectrum is FreeCol, 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:C/C++ dying? What are they smoking?

[mad.frog]

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

Re:C/C++ dying? What are they smoking?

[808140]

Well, let's see. C is an extremely simple and portable programming language. There are many, many compilers that support recent standards in their entirety. (I know C99 is lagging behind, but it contains a lot of fairly exotic features if you ask me).

In an anecdotal way, a relatively mature and competent C programmer could take a good shot at implementing a C compiler and come away with something pretty close to the real thing, because C is, well, simple, and consistant. C++ on the other hand -- it's so huge and complicated that I don't believe there has ever been a compiler that implements all of it, but correct me if I'm wrong on this. Needless to say, that level of complexity is troublesome.

In the old days -- by which I mean a decade ago -- we were still constrained enough on memory and CPU that C and C++ were the dominant programming languages for application development, with no sign of that ever changing. Dropping in on usenet would easily yield a religious C/C++ war with some C geek saying "C++ is bloated and slow" much as we say "Java is bloated and slow" today. It's laughable now. C++ may be slightly slower than C, but even without recent compiler advances by todays standards the difference has essentially always been negligible in well written code.

What I'm trying to point out here is that the focus in software development has changed drastically in the last decade. Unless you're in the embedded market, there are hardly ever CPU and memory constraints, and every corporation worth its salt has started to see that there may be something to languages that are easy to maintain and quick to develop in, even at the expense of speed (which is hardly ever relevant in a typical desktop or web application, which is what most application dev is these days).

Looking back, I think it was the web boom that changed everyone's perceptions. In the old days, you did all serious programming in C or C++ and everything else was either scripting or esoteric. But the first CGI scripts were, well, scripts. They were increasingly written with more and more powerful languages (more powerful than scripting languages, I mean) -- languages like perl, java, whatever -- and brought closer and closer to the webserver to increase their responsiveness and power -- but no one ever seriously considered writing these apps in C or C++, because it had been established historically that the pain and suffering, the bugs, the slow development cycle -- well, it just wasn't worth the effort.

I believe the explosion of web based services taught IT managers everywhere that C and C++ were, at least, not the only answer to the question of "what language should we write this thing in". CS folks have known forever that it's "the right tool for the job", but CTOs have generally always been partial to whatever language is vogue, without understanding the pros and cons at a deep level. So in the old days it was FORTRAN or C, then C++, then Java, Perl, C#, Python, Ruby -- the doors were opened by the whole web thing.

The result is, nowadays, C and C++ are increasingly less relevant. I say this as a die hard C programmer, mind you. C and C++ are increasingly used in relatively special environments. Embedded. System kernels. Drivers. That sort of stuff. In these fields, C++ is hurting. While I'd love to say it's because everyone recognizes that C++ is inferior, because I've always disliked C++'s hack-it-all-on approach, the truth is that legacy has a lot to do with this stuff. In the embedded market, resources are still so constrained that in many cases even pure C is not efficient enough -- they write programs in special subsets of C that have a lot of features built in to the language that take advantage of the somewhat exotic hardware they need to run on. So C++ is out, but then, strictly speaking, C didn't cut it either.

Kernels, well, the truth is that of the systems kernels in use these days, most of them predate C++ (or at least, th

Re:C/C++ dying? What are they smoking?

[mrsbrisby]

Especially since C++ has vastly better techniques for dealing with those [memory leaks and buffer overflows] particular problems.

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:C/C++ dying? What are they smoking?

[ultranova]

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.

And mandatory bounds checking eliminates buffer overflows completely, and garbage collection makes it much easier to manage memory, even if it doesn't remove leaks entirely.

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.

But there is good reasons why C++ will never be as clear about what, exactly speaking, the code ends up doing, and those reasons are the very extra features C++ gives. This C++ not as well suited to working close to the hardware, or implementing time-critical code, or in doing anything at all that requires low-level control. On the other hand, if you don't require that control, why bother with C++ ? You can as well use some high-level language and get the benefits.

In any case, I didn't make any claims about the performance of C++, only about its usefullness.

I've been writing in C and C++ for close to 20 years, and C++ is just plain a better language than C.

That isn't saying much ;).

Seriously, C++ may well be better language for writing large and complex applications; but higher-level languages are even better at that. C, on the other hand, is better at making small subroutines those large programs can use as libraries, since such code is naturally procedural and not object-oriented.

Sure, it has some crazy warts and dangerous bits, and things that can be problematic if you don't know what you are doing...

...and, thanks to operator overloading and #define, you can never be quite sure what you're doing, unless you're working alone.

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

Because you can implement the close-to-machine bytes with C and the really close bits with assembly, and the object-oriented overengineered architechture with some high-level language, since C interfaces with pretty much anything. Such use is by nature procedural - end up calling C functions with some variables, possibly an array for returning data in (so the C functions don't need to touch the heap), and return the end result back to the high-level language. C++ is completely unneccessary in this scenario.

Re:C/C++ dying? What are they smoking?

[spongman]

and given that ~0.01% of all programming os OS kernel development, and one guy doesn't know the language enough to work out how it can work for his kernel, then the language sucks?

Re:C/C++ dying? What are they smoking?

[mrsbrisby]

and given that ~0.01% of all programming os OS kernel development, and one guy doesn't know the language enough to work out how it can work for his kernel, then the language sucks?

Moron post hoc, ergo propter hoc.

The parent said he didn't know why anyone would use C when C++ was available given certain criterea.

I say, here's my reasons, and here's someone elses' reasons why people would use C instead of C++ despite other criterion.

Ergo, the actors must be ignorant to the language.

I suggest an alternate rationale: C++ is simply too complicated. It's too complicated for the thousands of people working on the Linux kernel, and it's too complicated for my audit work. It's too complicated for Bjarne to get even simple details right about, and it's too complicated for Microsoft to avoid these "buffer overflows" that are purportedly so easy to avoid.

Thusly, nobody can figure out C++, and it follows that those people that think they know C++ actually don't.

Or, we can simply accept that there are places that having a thin, well defined, and well understood runtime are appropriate, and places where people can get away with not having such.

By the way, the authority on C++, Bjarne himself, admits that using C is often easier than porting C++ to targets where memory constraints or timing constraints are important.

Re:C/C++ dying? What are they smoking?

[spongman]

Thusly, nobody can figure out C++, and it follows that those people that think they know C++ actually don't.

wait, who's 'post-hoccing' whom, here?

Re:C/C++ dying? What are they smoking?

[mrsbrisby]

Thusly, nobody can figure out C++, and it follows that those people that think they know C++ actually don't.

wait, who's 'post-hoccing' whom, here?

I provided justification in the previous paragraph:

It's too complicated for the thousands of people working on the Linux kernel, and it's too complicated for my audit work. It's too complicated for Bjarne to get even simple details right about, and it's too complicated for Microsoft to avoid these "buffer overflows" that are purportedly so easy to avoid.

You say that these people are simply doesn't know the language, and yet many of these peoplare strong advocates for C++!

I suggest this paragraph with sardonicism, and I hope that's obvious from the next paragraph:

Or, we can simply accept that there are places that having a thin, well defined, and well understood runtime are appropriate, and places where people can get away with not having such.

Which is really what you had problems with.

Re:C/C++ dying? What are they smoking?

[Anonymous Coward]

The difference is probably in your compiler's library and startup code. Here are two programs
compiled with gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2):

5090 Jan 11 15:22 c_hello
5092 Jan 11 15:22 cpp_hello ...a two byte difference. Hardly significant! My guess is that it comes
only from some slightly differing g++ startup code.

Here, I will even post the source code for you:

hello.c:
#include

int main(void)
{
  return puts("Hello, World!");
}

hello.cpp:
#include

int main()
{
  return puts("Hello, World!");
}

"...But you didn't use iostream!!"

Of course I didn't. If I had used iostream, the executable would probably
have been larger, because there would have been more code involved. puts() is
a small, single function. iostream is a very flexible stream framework. This makes
perfect sense.

So, if you just want to print "hello, world" on the screen use what makes sense
to you-- but if you are comparing two things, be sure you are comparing apples
with apples.

C++ is more like Perl...

[wandazulu]

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

Re:C++ is more like Perl...

[jejones]

The truth is, you can have bizzare [sic] WTF moments in *any* language.

That's no excuse for not trying to minimize them.

Avoiding the perverse features oneself doesn't help when faced with code written by others that does use them; also, compiler writers don't have the luxury of avoiding implementing, or trying to implement, said features. (Recall the C++ book whose author realized that the book, which describes a usable subset of the language, was necessary when Stroustrup himself said he hadn't realized how some C++ features interacted.)

Don't talk to me about Boost

[Viol8]

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:Don't talk to me about Boost

[slamb]

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

You could generate the same instructions in C, but you wouldn't. C++'s metaprogramming allows you to write code once yet specialize it for the best performance for each type. See this sorting comparison for an example. The C approach to genericizing code is to do extra work at run-time. The C++ approach is to do extra work at compile-time. In many cases (especially dealing with scientific stuff), that's much faster. So while theoretically, you can write specialized sorts for every data type in C, no one ever does. In C++, you don't even think about it.

Re:Don't talk to me about Boost

[Viol8]

"You could generate the same instructions in C, but you wouldn't."

Says who? His sorting example uses qsort. Well of course it'll be slower
than the STL because it uses function pointers. All he's proving is a
*generic* function in C is slower than *generics* in C++. Well duh.
As you say its run time vs compile time. However, if you *explicitly*
wrote a version of the algorithm for *every* type you wanted to sort
in C (which is what C++ templates do behind the scenes) you'd find it
would be just as fast. At the end of the day theres only so many ways
you can translate a sorting algorithm into assembler.

Re:Don't talk to me about Boost

[slamb]

You're not good at listening, are you?

You wrote: However, if you *explicitly* wrote a version of the algorithm for *every* type you wanted to sort in C (which is what C++ templates do behind the scenes) you'd find it would be just as fast. At the end of the day theres only so many ways you can translate a sorting algorithm into assembler.

Do you think this counters my point? I wrote: while theoretically, you can write specialized sorts for every data type in C, no one ever does.

The point is that in C, that'd be such a pain that you wouldn't do it. In C++, you write it once and the compiler does the specialization for you. It's easier to be efficient, so you actually do it, so the language is faster.

Re:Don't talk to me about Boost

[Viol8]

How many people require a sort for every possible type? 99% of sorts will
be integers or strings. And writing 2 functions is hardly a chore so its
hardly theoretical.

"In C++, you write it once and the compiler does the specialization for you"

You seem to be forgetting that to compare complex objects you have to
write your own overload of > and for every object type. This is hardly
a case "just use templates" on a standard sort function and in fact its
no simpler than writing seperate sort functions in C.

Re:Don't talk to me about Boost

[gnuLNX]

" How many people require a sort for every possible type? 99% of sorts will
be integers or strings. And writing 2 functions is hardly a chore so its
hardly theoretical."

WTF? You are kidding right?

No support for float or double?

C++ will be around for many a moon. Damn near every modern CADD program is writtenin C++. Oh and BOOST kicks ass. Obviously you don't write scientific software of system level software or you would see some of the obvious advantages of what BOOST has to offer.

Re:Don't talk to me about Boost

[Anonymous Brave Guy]

Damn near every modern CADD program is writtenin C++. Oh and BOOST kicks ass. Obviously you don't write scientific software of system level software or you would see some of the obvious advantages of what BOOST has to offer.

I do write libraries for use in CAD software, and we don't use Boost, or any templates or exceptions at all, for that matter. We'd love to, but a lot of the more obscure platforms we have to support still don't have compilers that are up to the job. The problem with the pace of standardisation in C++ isn't the standards committee, it's that nearly a decade later, there are still absurd, trivial bits missing on many minor platforms, and it's not even worth thinking about using the "new" bits.

Re:Don't talk to me about Boost

[gnuLNX]

Hum...Boost works on every Unix platform that I have ever used. I agree about the templates. I rarely write my own templates. I also don't use every feature of Boost. Mainly the smart pointers, and Python extension modules.

"he problem with the pace of standardization in C++ isn't the standards committee, it's that nearly a decade later, there are still absurd, trivial bits missing on many minor platforms, and it's not even worth thinking about using the "new" bits."

Use gcc on what ever platform you are running and your problems will go aways. I develop binaries for SGI Irix, various Linux, AIX, Solaris, and Windows without a hiccup.

Oh and on the building of large systems. I recently converted my entire project ~250,000 lines (not huge, but not small) to make use of the boost build system. bjam. It took some time and some effort, but wow was it worth it. Screw make files. I have a seemless build on whatever platform I am using.

Oh...you really should be using exceptions. I waited until quite late in my project to start adding them...it was a mistake. Much harder to add exceptions after the fact. I pretty muhc had to refactor my entire code base. Pain in the ass...but them it gave me the opportunity to go back in and do some optimization that needed to be done.

Just my 10 or 15 cents.

Re:Don't talk to me about Boost

[Anonymous Brave Guy]

Thanks for the reply. We'd love to be doing several of the things that you suggest, but alas the practicalities prevent it.

For example, we ship libraries, not end user products. That means we have to build and test with the same compilers that our customers use on each platform, which may well not be gcc. We also supply source code to some customers who build on more obscure platforms, so our code has to be fairly lowest-common-denominator to avoid tripping these folks up. In any case, our code is heavily mathematical, and g++ is still some way behind the field when it comes to optimisations for now. We do support it on an increasing number of platforms as its improvements catch up with the "home team" compiler, but it's got a way to go before it catches things like Intel C++ or Visual C++.

The build process isn't a problem for us. We long ago wrote our own system for managing makefiles on different platforms portably, not dissimilar to bjam.

As for exceptions, yes, architecturally they would be useful. Unfortunately, the product I work on has been around for a lot longer than exceptions in C++ have, and as you're probably aware, retrofitting an exception framework onto a project that wasn't design to use them is almost always a losing option. They're a great tool, but IME to get the most out of them, they really need to be used (or at least planned for) from the start.

I'm a C++ coder and I hate it too

[Viol8]

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:I'm a C++ coder and I hate it too

[ConceptJunkie]

Actually, C++ isn't so bad until you start considering templates. Templates are what makes it such a blarggy language, and these days, it seem severyone is keen on showing how clever they are by abusing templates to the nth degree (template metaprogramming? Yeah, maybe for Letterman's "Stupid Compiler Tricks", but I'd probably fire someone who tried that in the real world). Of course there are too many useful things you can do with templates, now that they are actually standardized, but this only reflects flaws in the rest of the language and violate C++'s OO-ness.

So in that respect, C++ is like Perl, but if you are calm and rational, C++ can be elegent, reasonably efficient and maintainable.

There's a language out there, maybe "C*=3" that will solve the hideous of needing templates in C++ with the superior OO features of Java and C#, but still allows you to do all the good things you can do with C++ now, and doesn't give you the overhead of a VM or the next-to-worthless libraries that killed Java or the lock-in and overhead required by C-Pound.

I wish I could invent it.

Re:I'm a C++ coder and I hate it too

[gbjbaanb]

If you think Templates are bad, just don't even look at programming using Reflection in Java like languages.

C++ seems to be a language where you just work in it, and have the ability to do fancy stuff too. I think that's a strength, don't let other people's idioic coding practices (the "look how clever I am" coders) tell you otherwise.

Re:I'm a C++ coder and I hate it too

[ConceptJunkie]

You're absolutely right, and after 13 years of C++, that's exactly what I do. Actually I'm doing mostly Tcl work now with some C, it's my first non-Windows job since 1990 and my first non-C++ work since '93. It's an interesting change. Tcl is a neat language although its capabilities for handling data structures leave a lot to be desired.

I'm convinced, as I said elsewhere, in this thread, that there is the perfect language hiding (mostly) inside C++ struggling to get out. Of course, the prospects of what will actually come out from C++0x actually scare me, but that's because I find things like STL obfuscating and wholly contrary to OOP and I think, in part, they are running the language off the rails by focussing attention on its more hideous bits. But it could be worse, they could be adopting MS's "managed" C++ with all their non-standard extensions.

Of course, at the end of the day, the language almost doesn't matter. It's the libraries that come with the language that make all the difference in productivity, which I see has been recognized by the C++0x folks as a very important aspect of the new standard. This is, in my opinion, why Java sucks for UI. It might be platform-independent, but it looks bad and works clumsily on all platforms. I found it wholly unusable as a solution for developing meaningful and non-hideous GUI's back in 2000 when asked to investigate. Although it seems better now based on some Java apps I actually use, some people who claim to know better argue that it really isn't.

As a long-time Windows developer, I always thought MFC was a good first cut and once it was fleshed out a little more and the developer was hidden 80% of the underlying Windows minutia (as opposed to 20% or so) that it could be really great. It begain to utilize the great power of C++, but because of horrible trade-offs made in the Windows 3.1 on 10MHz 286 days, there were so many legacy malfeatures that would never go away. Little did I realize that in the 10 years I used it that no significant improvements would ever be made, as MS focussed on other (equally underdeveloped) tools instead.

A good class library should make easy things clean and simple and hard things clean and simple. MS libraries, in particular has always made easy things messy, and hard things sometimes so much trouble that rewriting functionality from scratch is often a viable alternative. And in MS terms "easy things" is so narrowly defined as to be almost useless. It's like a car that is supposedly easy to maintain, but you have to remove the engine to upgrade the tires, and you have to upgrade the tires before you can use the Reverse gear.

Oh well.

Re:I'm a C++ coder and I hate it too

[gbjbaanb]

I wouldn't worry too much, there's always bad stuff and poorly implemrnted stuff in everything. The only thing I'd say to you though, is get famuiliar with the STL. Even if its just the container classes. They're possibly the best thing about C++, they're fantastic. Once you've grasped them (and its really easy to understand once you look) you'll never stop using them.

cheers.

Re:I'm a C++ coder and I hate it too

[Omnifarious]

I think templates are a beautiful feature that was accidentally far more powerful than the creator ever intended. OTOH, I think many of the details of how they work are horribly ugly, and that their interactions with other parts of C++ leave something to be desired.

I would like to see a language that made the concept of templates its center. The meta-language (the template language) would be a pure functional language. The language would be an imperative OO language without mandatory garbage collection that allowed the creation of objects who's storage could reside on the stack, the heap, or inside other objects.

Whatever.

[pjkundert]

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.

[Eli Gottlieb]

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

Re:Whatever.

[LizardKing]

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.

Re:Whatever.

[CableModemSniper]

However, Template Metaprogramming is unlike anything, available anywhere, in any other language.

Thank god for small favors. Templates are great, they do what they are supposed to, which is to all for more generic programming. Template meta-programming otoh is an evil movement to half-ass add features to a language that doesn't have them. If you want Lisp macros, please by all means use Lisp. But don't take something good (type-safe generic programming) and turn it into a tool for evil. Yech, you're probably one of those guys who show off the compile-time recursive fibonocci sequence trick.

Re:Whatever.

[Anonymous Coward]

Can I just give some mad, mad props for your "long" learning curve? Cause that is some dope shit. Yes, usage has passed us by, but dammit, for years I've been trying to get people to understand that a steep learning curve is a good thing. Hopeless, of course, but it's nice to see someone still cares. Peace out, brotha.

Re:Whatever.

[sashang]

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.

Just a few notes for comparison
Haskell does this but lacks the efficiency. Its type system is as expressive as C++ templates.
Python also does this but type checking is dynamic.
Java and C# have 'generics' which is basically pinching the C++ templates. I don't think Java or C# support the notion of partial specialization. They seem to be languages that follow C++.
But yeah I think your comment basically sums up why C++ kicks ass.

Re:Whatever.

[Nelson]

It's already been said but if you think template metaprogramming is the bomb, the things you can do in Lisp or ML would blow your mind.

Think ++(++TemplateMetaProgramming)

As far as statically compiled languages, I'll give you that.

Re:Whatever.

[corngrower]

I also think C++ and Python are excellent languages. I'd also add two others, C and C#. C because you just can't replace it when you need small, fast executables for embedded systems. The size of a C exeuctable usually seems to be half that of a corresponding C++ one. C# because it's moving towards the future of programming languages, more so than Java.

C# addresses many of the problems of C++, and yes C++ does have problems. C# being developed by Microsoft detracts from its acceptability, but it still is a very good language. Interfaces, delegates, and attributes are all definite improvements in the language. With todays large memory sizes, header files are pretty much obsolete as well.

Re:Whatever.

[Tet]

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.

Having driven a 2006 Mustang on a recent visit to the States, I can assure you that whatever flaws they may have had in the past appear to have been solved with recent models, and it was comparable to the last BMW I drove. None of which detracts from the fact that C++ is a hideous nightmare to work with, of course :-)

translation: Forth, Forth, Forth, Forth, Forth.

[Anonymous Coward]

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

This is the path of true wisdom

[ENOENT]

NO TEXT

I think "sharp" is not too appropriate...

[Chemisor]

... for a language that is just a hash of things created by random pounding on the keyboard.

Re:I think "sharp" is not too appropriate...

[Randolpho]

you are too sharp-witted for me. I will now pound sand.

I could go for some hashbrowns.

Re:I think "sharp" is not too appropriate...

[eric2hill]

You're both octothorpes.

C++ is dead.

[Randolpho]

Long live c++!

The real problem with C++

[Arandir]

The real problem with C++ is not what all of the trolls spew out of their yaps. Its real problem is that it is a mid-level language.

The reason I haven't moved on to "higher" level languages like Python or Ruby, is the dearth of high level GUI toolkits. X11, Win32, etc, are low level toolkits. Qt, GTK, .NET, are mid-level toolkits. Tk is the only high level toolkit I am aware of, but I respect my users too much to foist a Tk based application upon them.

My last project would have done well with Ruby, except for the lack of appropriate GUI toolkit.

p.s. Before you flame me to death, I am NOT a web developer. Ruby on Rails is NOT a solution for me. Anything involving client/server is NOT a solution for me.

Re:The real problem with C++

[Anonymous Coward]

I also have no idea what these people are talking about, but agree.

Re:The real problem with C++

[Anonymous Coward]

Try out Python (or Ruby) + GTK + Glade. Not sure if that meets your definition of high-level, but I'd sure call it that.

Re:The real problem with C++

[Arandir]

I wouldn't call it high-level. Neither is Python|Ruby Qt with Designer. The problem is that these toolkits were designed around a mid level paradigm. I would like to be able to directly manipulate the GUI at runtime as easily as I can manipulate text at runtime.

Re:The real problem with C++

[Teogue]

Having recently tried Qt after being browbeaten by MFC in windowsland for several years.... Qt seems high level... or maybe just quasi-intellegent. Like I said, recent experiences have biased me.

Why C++ is here to stay

[Anonymous Coward]

if I want to read a double floating point number 'd' from stdin, in C++ all it takes is:

      cin >> d;

But in Java I have to do this:

      BufferedReader br = new BufferedReader(
      new InputStreamReader(System.in), 1);
      String s = (br.readLine()).trim();
      d = Double.parseDouble(s);

Long live C++!!!

I thought...

[jd]

...it was pronounced D flat.

crossroads

[mario contestabile]

First it was C++ World, now CUJ...DrDobbs can be really good, but at times I find it can really suck.

Lets hope it can pick up some of the contributors we have all grown to appreciate over the years, Herb Sutter, Andrew Koening & wife, Lippman (who's doing MSDN mag), etc.

C++ has always taken what's good (STL), and dropped what wasn't (auto_ptr), and now more than ever developers using it will require assistance in understanding some of the latest developments in the language (Template MetaProgramming, concepts).

Sure the web is great, but a mag allowed for a monthly round-up in a easily accessible fashion, of all the language features (and darker corners).

We will have a C++09 standard, and for those of us using the language daily in creating apps that must sell, I believe there is a cross roads: Do we continue on using a very powerfull language, all the while having a harder time to find programmers knowledgeable enough to use it properly, having C++ magazines replaced with .NET magazines; or do we leave the C++ to the library implementors, and use another language without all the C++ bagage but with the wind in its sails (Eg C#).

I'll admit that a team of 6 C# devs may have an advantage over a team of 6C++ devs in the time to create software, to debug and test it, the available documentation, and the power of the language. Sure their code will run slower, but they rely on the Stan Lippman\s and Herb Sutter's @ microsoft to provide a good overall library...

Re:crossroads

[Anonymous Coward]

"First it was C++ World..." Does anyone remember when it was a "COBOL world"? And then a "C world"? For a nano-second it was a "Java world". Pretty soon it'll be a "C# world". And only a little after that it will be a "Ruby world". Change is the only thing that stays the same...

Re:To generalize a bit:

[SolitaryMan]

After all, every time we mention [insert topic] we are told how bad it is and how stupid we all are for using it.

Why CUJ failed

[Anonymous Brave Guy]

I think the reason the CUJ has died is very simple: it wasn't very good any more.

A few years ago, there would be many useful things going on in the C++ world. Then there would be many useful articles to accompany them in the C++ and more general programming press.

Today, the C++ world seems to have degenerated into two camps: the naive group who still think it's great for everything and love playing with intricate templatey stuff just because they can, and the much larger, practical group, who continue to use it because as a pragmatic tool, it remains unrivalled for many programming jobs. Everyone else has long since jumped ship.

What the C++ press should have been doing is continuing to educate the programming population. One only has to read any programming language thread on Slashdot to see how many people still don't understand simple but very effective ideas like RAII, never mind the power of C++'s object/exception model in comparison to some of the alternatives. But today, most of the C++ press is just the same in-crowd of authors repeating the same tired mantras over and over again. And it's almost all negative: I'm surprised no-one's ever written "50,000 Ways Not To Blow The Whole Leg Off" or something.

As a practical tool, C++ remains one of the most useful and adaptable languages around. It's just a shame that almost none of the professional authors seems to want to talk about how to use it well. Maybe it's just easier to find yet another obscure way to break it, or yet another way to reproduce an example from chapter 1 of a functional programming textbook using only 150 lines of template code. Until your magazine fails because no-one cares anymore, anyway.

If only we had really reached a crossroads

[Anonymous Brave Guy]

C++ has always taken what's good (STL), and dropped what wasn't (auto_ptr), and now more than ever developers using it will require assistance in understanding some of the latest developments in the language (Template MetaProgramming, concepts).

I think you've hit the problem with today's programming world right there. The STL -- or rather, the part of the C++ standard library that comes from Stepanov's original ideas -- actually isn't very good.

Don't get me wrong, it was a very interesting concept, and has some great ideas. It's just that the potential was never realised in practice within the C++ framework. The containers and iterators relationship is a decent start, but the toolbox isn't full yet: the support is poor for concepts like ranges (and maps between ranges from different containers), sources and sinks (or "generators" or whatever we're calling open-ended ranges this week), indexing... And of course, the algorithms would be great if C++ had good support for closures/lambda expressions/whatever, but as it stands it's often better to write a simple loop than to use one of the standard algorithms.

In fact, the STL suffers from much the same core problem as C++ itself: it had a lot of potential and introduced new ideas in its day, but with the benefit of hindsight that we now have, the design seems clunky, the quality is patchy, and we could do a lot better by starting over and learning from what worked and what didn't last time. I'm just waiting for someone to do that; it seems to me that there's an obvious and enormous market waiting for the natural heir to C++ (which doesn't look much like Java, C# or D, IMNSHO).

When that successor (or possibly several successors with some common advantages but different foci) does arrive, then we'll have your crossroads, and C++ and the STL can be retired to a well-earned place in programming history. Until then, they're the best we've got for a lot of jobs, but that still doesn't make them good on an absolute scale.

Re:If only we had really reached a crossroads

[chanceH]

ya what this guy said.

I love the idea of the STL. But it still feels like an 8th generation fix for a giant pound define hack. CLU had/has parameterized types, and it was simple. It didn't have this giant clusterf**k feel to it. Why can't I step through a readable/understandable template expansion in my debugger? Why can't I print out a particular object thats a template instantiation and get anything readable?

P.S. Implementing strings as a character Vector is just a tad bit too clever too.

Not dying according to job postings

[ahudson]

http://www.indeed.com/jobtrends?q=java%2C+c%2B%2B Not that far behind java, but neither really seem to be growing or shrinking at the moment.

Better Material?

[jcaldwel]

I subscribed to CUJ for some time, and I can say that I can get 3/4 of the same information from a single good C++ reference book as I can in every issue I got in the 2 1/2 years I subscribed. The reference, however, is much more efficient.

Let the numbers speak!

[lindquist]

I find it interesting that C++ is supposed to be dying with all those developers using it. The top 3 programming languages on SourceForge (based on number of projects using it): 1. Java (17457 projects) 2. C++ (17281 projects) 3. C (16363 projects) I think this indicates that C++ is quite healthy... I'll definitely stick to for yet a while.

Re:Let the numbers speak!

[Anonymous Coward]

Just checking the numbers for the 30 most downloaded applications in the past 7 days, c++ looks even a lot more alive :-)

c++ 18
c 10
java 5
php 4
asm 2
delphi 2
c# 2
tcl 2
python 2
perl 1
jsp 1

Are you sure?

[ggvaidya]

Perhaps you mean C++0x?

Java = Modula 3 w/ curly braces

[Anonymous Coward]

Wirth went on to create the Modula languages. While Java's syntax is very C-like, it's semantics are almost a straight lift from Modula-3. That was an excellent move by Sun.

C++

[In Fraudem Legis]

http://www.googlefight.com/index.php?lang=en_GB&wo rd1=%22C%2B%2B%22&word2=Java C++ has always been the de facto programming language and will be in the future too.

What's really wrong with C++: denial

[Animats]

The big problem with C++ is denial. Even Strostrup, who should know better, insists that C++ has no major problems. As a result, the fundamental problems are not being fixed.

C++ is the only remaining major language which has hiding without safety. C has neither. Java, C#, the Pascal/Modula/Ada/Eiffel family, and all the scripting languages have both hiding and safety. That lack of safety is responsible for most of the crashes and exploits in today's software. When a virus takes over your machine due to a buffer overflow, it's probably because of that bad design decision in C++. Every day, hundreds of millions of people must suffer because of that mistake.

The largest single problem comes from the decision in C to treat a pointer and an array as the same thing. This seemed convenient thirty years ago, but created a language in which the size of an array is not permanently associated with the array. In particular, the fact that arrays are passed to functions without size information is a huge source of trouble. This, of course, is why we have buffer overflows.

Attempts were made in the STL to fix this problem, but it didn't really work out. Trying to retrofit strings to the language via the template mechanism was not all that successful, since so many libraries and system calls required the old-style strings.

Safety is not a performance issue. It's possible to do checking very efficiently, if the compiler knows what to check. Subscript checks can usually be hoisted out of inner loops at compile time. But this is not possible for C++, because the subscript checking, when enabled, is in the STL, not the language.

The second big problem in C++ is the need to obsess on "who owns what". Memory allocation is the nightmare of C++. Again, the STL tried to address this, and again, it was botched. The auto_ptr debacle illustrates the limitations of the language. There have been many, many attempts to implement "smart pointers", and they're all unsafe. At some point, you have to extract a C-type pointer to get something done, which introduces a hole in reference counting. If you don't extract raw pointers, you spend too much time updating reference counts. Again, this is something that a compiler could optimize if the compiler knew more about what was going on. But with reference counting implemented at the macro level of templates, that's not possible.

Garbage collection is occasionally proposed as a panacea, but it's not compatible with the concept of destructors. In a garbage collected language, what destructors and finalizers do must be severely limited. This is contrary to the C++ concept of "resource allocation as initialization". You don't want to close a window from the garbage collector. Also, introducing garbage collection introduces a form of concurrency, in a language that doesn't handle concurrency well. There are workarounds for this, but like most workarounds, they're painful. Take a good look at how Microsoft's "Managed C++" approached the problem. It's wierd; read about "resurrection, where an object comes back to life during garbage collection.

Those are the two elephants in the living room of C++. Denying them will not make them go away. This is harsh. But it's not wrong.

Re:What's really wrong with C++: denial

[Anonymous Coward]

That lack of safety is responsible for most of the crashes and exploits in today's software. When a virus takes over your machine due to a buffer overflow, it's probably because of that bad design decision in C++. Every day, hundreds of millions of people must suffer because of that mistake.

Nonsense. There's a simple and effective way to prevent buffer overflows in C and C++. You just check the size of the buffer before writing to it. I have worked in a company that has produced widely used security software in C for quite some time and I don't think we have had a single buffer overflow exploit. The exploits we have had have mostly happened because of incorrect assumptions of OS behaviour and internal language-independent logical flaws. Any competent programmer can check the size of the target buffer before writing to it (this requires things like banning of sprintf in favor of snprintf, though) and code reviews will catch instances of writing without checking.

Hundreds of millions of people suffer because fucking idiots are writing software with absolutely no concern for security, not because of this or that language.

Re:What's really wrong with C++: denial

[Anonymous Coward]

You could have just put a full stop after "writing software" in your last sentence and that would have summed up the situation quite nicely! ;-) The world would be a better place, IMHO, if you could persuade them to use safer languages...

Bullshit

[WindBourne]

I saw this back in the late 80's/early 90's, when 4GLs were going to replace everything esp. languages such as C (2/2.5 GL language). They all disappeared. All the pundits against C are LONG gone.

C++ will be around for a long time due to one reason; safer than C and close in speed to C. It is a very good lanaguage for doing apps with. The problem is that somebody is trying to use a mag. writers and subscribers as a way to judge a language. That is one of the silliest ways to judge what the future holds for C++. Now, if you are trying to judge the mag, well, I left it long ago. It was way to expensive for what we were getting. In addition, I do not want print. I want it on a PDF on a CD (or better over the network). But they are not changing. Judging the language by subscribers is a bit like RIAA judging the CD theft by the fall of their products (which is more related to lousy products).

correction

[corngrower]

Embedded as an industry is almost universally C++

That should be 'C'.

Re:correction

[stonecypher]

The entire purpose of the article was to display that people who said things like "That should be C" were mired in history, rather than aware of current trends. The only significant subset of C++ given the way the study was made was Embedded C++, as implemented by compilers like GHOC. It's 6:1, C++ versus everything else. C is in everything else, not in C++.

Generally it's a bad idea to contradict people quoting specific-purpose studies based on rumor and common sense. As every engineer learns someday, common sense is more often wrong than right. These days, forth is almost one third as common as C in embedded programming, something almost nobody I know would even think to expect.

Leadership

[Nelson]

Dead? I bought apple stock the last time everyone was seriously
talking about them being dead and that was one of the better moves
I've made in the stock market... I imagine all the Sun people are
really concerned too; they're as good as dead. I suspect redbull is
killing coke too, they are probably dead.

I like C++, I like the idea and the intent. After spending like 10
years going through standards processes, I actually like the end
product and the STL and what have you, it's substantially more clean
that it was in 1991. I think they got a good 80% of the way there.
There is still some jankiness though.

I think the thing with C++ that is larger is that they are still old
world. There is no quick movement and there still isn't any "21st
century" development style in the standards group. Java has warts but
one of the great things it has going for it is Sun produced a lot of
standards and then the jakarta group did the same and there tends to
be a lot of similarity between "high quality" java products and
components. There is a ton of java stuff to reuse and the code tends
to be be laid out in a similar way, built in a similar way, javadoc is
used, xdocklet is used, etc.. C++ doesn't have any of these standards
working for it and there aren't any major projects (maybe KDE and QT)
that are really sort of laying out the guidelines and building
reusable components. In short, nobody is really showing everyone else
"how to do it." I think that alone has accellerated java at a
remarkable rate.

Beacuse of all of that, I don't know of a lot of good high quality
C++ reuse. There are some knickknacks that might be reused. Then
there is kind of this whole-world style framework, like QT which
includes tons and tons of stuff. Simple little libraries don't seem
to be popular because there are so many different ways you can use
them, different conventions, etc.. Every time you start a C++
project, you're starting over from scratch. The other thing java has
helping it is the class library. You cna buy Roguewave or something
but there isn't a good opensource alternative. Boost is kind of
filling the gap but it's still a little project and I think the scope
has stayed fairly small for a lot of reasons, many of which are
political.

Part of this is the C legacy and the C++ attitude, it let's you do
things "your way." And the languages tries not to do "too much" yet
it's supposed to compete with higher level languages that are totally
tricked out with features and libraries. I think if you were
starting a new large scale application project and Java wasn't an
option and mono/.net wasn't an option and you were looking at C++,
GNAT would also have to be considered (as radical a thought as that
is) because I think there might be as much or more high quality
reusable componets that you could harvest for it.

It just needs a really strong leader and some community built up
around it. Define some common framework rules. Write a couple
frameworks, if I could just instantiate a socket class (with SSL as a
yes/no flag) and create a high performance and high quality C++ server
network server in a small chunk of code, in a standard like way,
that'd be cool. Imagine that it had some template based policy stuff
that allowed me to plugin validators and crap like that and we created
a nice reusable network component and started to make some of the
security holes in that stuff go away... Simple and clean, reusable.
WOuld you write your own server everytime now or would you use this
one?

Re:Leadership

[apocalypse76]

ACE http://www.cs.wustl.edu/~schmidt/ACE.html is one of the best all around libraries that they have. Right now i'm using it and the STL within the same environment. They do really well at complimenting each other. ACE is very good if you need a prototype/test server quick.

Re:Leadership

[Viol8]

The network side of ACE is a pointless wrapper to the sockets
API which does little if anything to simplify it but just
adds an extra layer to slow the code down.

That's because

[Anonymous Coward]

you ARE bad, and you ARE stupid.

Everyone knows it, too.

Demise of Magazines in General?

[znx]

Interesting but could this just be a sympton of this article. I am certain that the demise of the magazine will not bring about the end of the language it, like C, has a very special place in the hearts of programmers.

With the Demise of c++

[MrCopilot]

I guess I'll be cleaning out my office then.

C++ Isn't Going Anywhere

[Austin Milbarge]

Whats the replacement? Java?? C#?? Thats like saying SQL is dying. Perhaps people are perceiving that C++ is dying simply because of the incredibly over hyped "web-centric" world of the programming in the new millenia. Languages like PHP and ASP.Net and Javascript (all web languages) have taken the forefront because business these days are demanding more web (scripting) applications. But that doesn't mean C++ is dying by any means.

In fact a lot of your network servers, programming IDEs and language interpreters are written in C++. It's true that C++ jobs are decreasing a little but again that is only because C++ is becoming more of a specialized language as it should be. A lot of apps do not require the complexity of C++ when a language like C# will do the job. But there are limits to what C# and Java can do. The only other language, I could think of that could have possibly taken C++'s place back in the 80's was Pascal or Object Pascal (aka Delphi), but never did. Besides libraries like the STL make C++ even more powerful and easier in many cases.

Comment removed

[account_deleted]

Comment removed based on user account deletion