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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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. :'}

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.

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.

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

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]

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.

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.

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

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

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

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.

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.

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

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

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.

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

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.

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

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.

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

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

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

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.

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?