ISO C++ Committee Approves C++0x Final Draft

Randyll writes "On the 25th, in Madrid, Spain, the ISO C++ committee approved a Final Draft International Standard (FDIS) for the C++ programming language. This means that the proposed changes to the new standard so far known as C++0x are now final. The finalization of the standard itself, i.e. updating the working draft and transmitting the final draft to ITTF, is due to be completed during the summer, after which the standard is going to be published, to be known as C++ 2011. With the previous ISO C++ standard dating back to 2003 and C++0x having been for over eight years in development, the implementation of the standard is already well underway in the GCC and Visual C++ compilers. Bjarne Stroustrup, the creator of C++, maintains a handy FAQ of the new standard."

Comments

Yay for C++'0B

[sabre]

Enough said!

-Chris

Re:Yay for C++'0B

[JAlexoi]

And soon enough, just in 2021 we will have the C++1x.
WTF People?! Rename it already!.. The 201th decade is over, 202 is here!

Re:Yay for C++'0B

[TheRaven64]

No, they kept the name to warn people that any project using C++ - including the language itself - is impossible to finish on time.

Re:Yay for C++'0B

[Sulphur]

Enough said!

-Chris

Olly Olly 0x 'an C

sigh

[Anonymous Coward]

My collection of C++ books from Addison Wesley (who has apparently cornered the market for C++ books above intro level) has just become obsolete. Most likely new editions for most of them will be coming out over the next couple years.

Re:sigh

[EvanED]

They aren't obselete yet. There's probably another year or two before you can expect the latest version of MSVC to have support for most of the features (and that's if they even get it into the next version!), and a couple years after that (depending on your taste) before you are likely to be able to reasonably demand "you must use a compiler that supports C++0x."

The situation in GCC-land is better because they've been more on-the-ball with releasing support for the new features, but even they have a way to go yet (4.6, released yesterday, just added support for 3 new features including nullptr), and you don't have to go too far back before there's basically no support.

Re:sigh

[shutdown -p now]

There's probably another year or two before you can expect the latest version of MSVC to have support for most of the features (and that's if they even get it into the next version!)

There are already quite enough C++0x features in VC++2010 to invalidate a lot of old techniques and rules: it has lambdas, rvalue references, and decltype/auto. Lambdas make STL much more attractive to use, so you're going to see more of that (but that should be covered well by existing books, and lambdas themselves are easy to understand). But rvalue references and decltype open a whole new dimension for generic code and template metaprogramming. Combined with new rules for SFINAE, you can now make substitution failures on pretty much any expression - which is a very messy but working way to get "contracts" (and combine with static_assert for good error messages).

Don't forget also that it's more than the language alone, it's also the library. All the new threading stuff is big deal.

Re:sigh

[Korin43]

My collection of C++ books from Addison Wesley (who has apparently cornered the market for C++ books above intro level) has just become obsolete.

Yeah, if only they had spent an entire decade making sure that it was fully backwards compatible. It sucks how C++ just completely throws out compatibility, like that time when they threw out compatibility with existing C code to make the language easier to maintain.

Re:sigh

[Rei]

Thanks to g++, I've been coding in C++0x for months. Programming without it has now become painful. 0x is such a huge leap. I love, love things like:

while (true) thread( [](shared_ptr p){ p->process(); }, Packet::read()).detach();

That's a one-line network subsystem ;) In a loop, hang until you can read a packet, then process it in its own thread, continue reading new packets while it processes, and when a given packet finishes processing, delete it. Your "Packet" base class simply requires a factory read() method and a virtual process() function.

The only "gotcha" for me was that you still have to link in pthread.

Thread pairs very nicely with lambdas. Shared pointers were already fine in Boost, but it's nice to be able to ditch boost where possible. I can't wait for futures to make it into g++ as part of the c++0x standard. Futures + lambdas = trivial inline threading of arbitrary statements.

Re:sigh

[EvanED]

Thanks to g++, I've been coding in C++0x for months

It's great if you can swing it, but at least for me, it'll be a couple years (like I said) before I'd feel comfortable saying "you need a recent version of GCC." And in my case, I'd like cross-platform compatibility (including across compilers) so I need to wait for MSVC on top of that.

E.g. take your use of closures (lambdas): support for the revised closure syntax has been in a release version of GCC for less than a year. Lots of people can't move that fast.

Re:sigh

[maxwell demon]

Well, he specifically said "above intro level." Yes, 99.9% of existing code will continue to work unmodified. However, best practices will change. For example, in C++03, a loop through a vector of ints would be coded like this (assuming you cannot or don't want to use std::for_each, which in C++03 is often a pain to use):

for(std::vector<int>::iterator iter = myvec.begin(), end = myvec.end(); iter != end; ++iter)
{
// use *iter to access the elements
}

In C++0x, this still works, but no sane person would write that. They would write

for(auto& value: myvec)
{
// use value to access the elements
}

or use the new lambdas with for_each:

std::for_each(myvec.begin(), myvec.end(), [](int& value)
{
// use value to access the elements
});

Re:sigh

[Anonymous Coward]

Lambdas make STL much more attractive to use

In the sense that a one-legged leperous hooker is "more attractive to use" with a condom?

Like a zombie

[russotto]

C++ just keeps on going, eating the brains out of anyone who dares to use it. When template metaprogramming was invented, the language should have been internationally banned by treaty. Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.

Re:Like a zombie

[Anonymous Coward]

Garbage collection? Did I miss something?

Also BRAAAIIIINNNNSSSSSSSS

Re:Like a zombie

[JAlexoi]

See... Buffer overflow is still there or is it properly uninitialized char**? GC is probably from something else.

Re:Like a zombie

[turgid]

C++ should be officially classed as a Weapon of Mass Destruction

It's also a Cruel and Unusual Punishment for those of us who try to earn a living writing code.

Re:Like a zombie

[Anonymous Coward]

Just because a language has incomprehensible features doesn't mean you have to use them. C++ may give you enough rope to hang yourself, but you are the one putting your head in the noose.

Re:Like a zombie

[shutdown -p now]

Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.

That's why C++ is so awesome - it's a WMD that can be wielded by a single man. Granted, this gives the whole new meaning to the expression "shoot your own foot", but once you get past that, you can shoot so many other things in very spectacular way!

I only hope that user-defined literals are still in (there was a proposal to take them out). ~

Re:Like a zombie

[Zandamesh]

C++ just keeps on going, eating the brains out of anyone who dares to use it. When template metaprogramming was invented, the language should have been internationally banned by treaty. Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.

It's because there isn't a good replacement for it. The only programming language that I know of that _really_ replaces C++ is D, I did a bit of research on it a while ago, it's great. Better than the C++ language in almost every aspect. But D has problems as well, just not in the language design department. There is no working D IDE, you can't find a lot about it online, the language has not 100% stabilized yet, only has backwards compatibility with C, and many other things that we take for granted in the C++ language.

Anyway, what I'm trying to say is that D is a well designed language that could potentially replace C++ better than any other language.

Re:Like a zombie

[euroq]

So glad to hear that some people actually know about D! D is great. This new C++0x crap is awful:

        template
        class tuple
                : private tuple { // here is the recursion // Basically, a tuple stores its head (first (type/value) pair // and derives from the tuple of its tail (the rest ofthe (type/value) pairs. // Note that the type is encoded in the type, not stored as data
                typedef tuple inherited;
        public:
                tuple() { } // default: the empty tuple // Construct tuple from separate arguments:
                tuple(typename add_const_reference::type v, typename add_const_reference::type... vtail)
                        : m_head(v), inherited(vtail...) { } // Construct tuple from another tuple:
                template
                tuple(const tuple& other)
                : m_head(other.head()), inherited(other.tail()) { }

                template
                tuple& operator=(const tuple& other) // assignment
                {
                        m_head = other.head();
                        tail() = other.tail();
                        return *this;
                }

                typename add_reference::type head() { return m_head; }
                typename add_reference::type head() const { return m_head; }

                inherited& tail() { return *this; }
                const inherited& tail() const { return *this; }
        protected:
                Head m_head;
        }

        tuple tt("hello",{1,2,3,4},1.2);
        string h = tt.head(); // "hello"
        tuple,double> t2 = tt.tail(); // {{1,2,3,4},1.2};

D does a marvelous job fixing the syntax and the shortcomings of C++. Also, there's NO PREPROCESSOR! (Before you jump on this, there is nothing you can't do in D that you could do with a C preprocessor) Also, there is an environment for D in Eclipse.

Re:Like a zombie

[MichaelSmith]

C++ may give you enough rope to hang yourself, but you are the one putting your head in the noose.

Not if you work for a large software company. Some idiot could use c++ to write incomprehensible code, then leave or be sacked. You get the job of maintaining the ever so clever rubbish he left behind.

Re:Like a zombie

[the linux geek]

Too bad the D development process is screwed up. 1.x was never really finished/stabilized, there's no community consensus on standard library, and 2.x appears to be going nowhere good.

Re:Like a zombie

[Anonymous Coward]

Next time run a replace-search on your code substituting < with &lt; and > with &gt;. Actually, it's better to use a website like pastebin.

Re:Like a zombie

[Anonymous Coward]

Not if you work for a large software company. Some idiot could use c++ to write incomprehensible code, then leave or be sacked. You get the job of maintaining the ever so clever rubbish he left behind.

For you guys that think C++ is hard or incomprehensible, please, for the good of mankind, change your line of work. You're not worthy of calling yourselves programmers.

Re:Like a zombie

[d6]

you know, for the folks that never understood what a memory leak is.

next version, we get rid of pointers :P

Re:Like a zombie

[betterunixthanunix]

Or for the projects where having to manage every allocation and deletion is tedious and gets in the way of actually implementing a program.

next version, we get rid of pointers :P

You say this like it is a joke, but it is actually not so terrible an idea. Dumb pointers introduce a whole host of ways for things to go wrong, and in a lot of cases the compiler is in a position to create a pointer for you (see: Common Lisp) when it is truly what you need. If you are writing code at the lowest level, then sure, you need pointers and it would be stupid not to use them; but a lot of projects out there do not need the sort of low level control over pointers that you wind up dealing with when you write C++ code.

Re:Like a zombie

[Anonymous Coward]

People can (and do) write incomprehensible code in any language; that's not something specific to C++. My point was that the fault usually lies with the developer (trying to being too clever for his own good) and not the language.

Re:Like a zombie

[arkenian]

Not if you work for a large software company. Some idiot could use c++ to write incomprehensible code, then leave or be sacked. You get the job of maintaining the ever so clever rubbish he left behind.

For you guys that think C++ is hard or incomprehensible, please, for the good of mankind, change your line of work. You're not worthy of calling yourselves programmers.

You know, I have to say I've been a professional programmer for 15 years. And, in fact, C/C++ is in many ways my preferred language. That said, I have to agree with GP. While I love C/C++, I have never run across any other language (that's actually used, please don't mention malboge and the like) where a programmer can so easily obfuscate his code WITHOUT INTENDING TO. No, C++ is not hard or incomprehenisble, if used right. But there are coders out there who seem to have a knack for taking the beautifully powerful language and turning it into a terrible torture of agony for all people who ever have to maintain it.

Re:Like a zombie

[Anonymous Coward]

For you guys that think C++ is hard or incomprehensible, please, for the good of mankind, change your line of work. You're not worthy of calling yourselves programmers.

As others have pointed out, it's not the language that's hard or incomprehensible, it's the code it allows you to write!

I've programmed in various languages for 20 years. I've studied C++, written a few programs in it, and have a pretty good grasp of how it works...yet, 9 times out of 10 when I download the C++ source of a project from SourceForge, I can't make head or tail of it. That's got to tell you something.

Re:Like a zombie

[Anonymous Coward]

I have never run across any other language (that's actually used, please don't mention malboge and the like) where a programmer can so easily obfuscate his code WITHOUT INTENDING TO.

Perl. And this is from someone who sees Perl as the first solution for everything (C/C++ as second).

Re:Like a zombie

[narcc]

you can shoot so many other things in very spectacular way!

The most popular is shooting the guy who maintains your old code, in the head, by his own hand.

Re:Like a zombie

[TheRaven64]

The ArrayBuffer class that WebGL adds to JavaScript lets me do almost everything that I actually want to use pointers (as opposed to references) for. I can create an ArrayBuffer object, which represents a block of memory, and then create views on it that treat it as an array of 8, 16, or 32-bit, signed or unsigned integers, or 32- or 64-bit floats.

Re:Like a zombie

[Threni]

> I have never run across any other language (that's actually used, please don't mention malboge and the like)
> where a programmer can so easily obfuscate his code WITHOUT INTENDING TO

You've never used Perl, or seen it used?

There's certainly a lot of noobs crawling out of the woodwork to criticize c++ today. Don't you guys have some HTML to edit or something?

Re:Like a zombie

[mikael]

you know, for the folks that never understood what a memory leak is.

It's like wikileaks, but with memristors instead of wikis

Re:Like a zombie

[TheRaven64]

I've worked on a couple of C++ compilers and implemented the RTTI / exception handling runtime for C++. There's nothing like implementing the language to make you hate it. I thought that the designers were sadists who hated the people who would use their creation, but I think they hated the people were expected to implement it.

I've also worked on compilers for C, Objective-C, Smalltalk and JavaScript, but C++ is the only one that has a specification that is almost impossible to implement correctly (and, when you do, developers complain because they're used to the incorrect behaviour of their favourite compiler - which is incompatible with the incorrect behaviour of some other compiler).

Re:Like a zombie

[Xtifr]

Or for the projects where having to manage every allocation and deletion is tedious and gets in the way of actually implementing a program.

you know, for folks that never understood what RAII (Resource Acquisition Is Initialization) is or how to use it.

C++ offers both dumb pointers (for those rare occasions when you actually need them) and smart pointers, and C++0x will offer vastly improved smart pointers (shared_ptr)--currently available in Boost, and one of the best reasons for using Boost up until now.

People who insist on writing C++ as if it were a mildly enhanced form of C have no one to blame but themselves for the problems they encounter.

It is a valid complaint that C++ makes creating dumb (dangerous) pointers so much easier than smart pointers, but then if you use RAII for your classes more broadly, the need for pointers of any type is usually greatly reduced. Why, you can create whole complex structures of trees of lists of sets of strings, modify them wildly on-the-fly, and never once have to worry about pointers or allocation or deallocation.

There are plenty of reasons to complain about C++. The language is full of warts, and has some really tedious and error-prone corners. But if your complaint is simply about overuse/abuse of pointers leading to memory leaks, Ur Doin' It Rong(tm)!

Re:Like a zombie

[mikael]

There are so many design philosophies out there - going way beyond whether you put the opening { on the same line as the function name or else. These are just fourteen I can recall:

o Separate dll's vs separate static libraries
o Separate directories for each class
o Separate header/source files for each class
o Inheritance vs class member objects
o inline functions or not
o use of STL vs Boost vs own templates
o multiple template class types
o Use of smart pointers
o enum's vs defines
o The use of class identifiers before functions : ClassName::FuncCall( x, y ) vs FuncCall
o use of virtual inheritance with multiple inheritance
o hand-written Makefile vs Cmake vs qmake
o private class members always, with accessor functions
o The GUI and other libraries used: WXwidgets, Qt, SDL, X-windows

Each author may have any combination of these fourteen methods - so any project can be rolled in at least 16000+ different ways.

Re:Like a zombie

[funkatron]

OK, so C++ is a little heavy on the features available but guess what; they're only available features, not compulsory features. If you just want to do a couple of classes, C++ can do that fine. If you want to program with all that stuff you hate, C++ can do that fine too. You just have to choose what to use in your code and write it accordingly.

Re:Like a zombie

[arkenian]

I have never run across any other language (that's actually used, please don't mention malboge and the like) where a programmer can so easily obfuscate his code WITHOUT INTENDING TO.

Perl. And this is from someone who sees Perl as the first solution for everything (C/C++ as second).

I have blocked my few experiences of maintaining Perl code completely from my memory. *shivers*

Important note: I love C. I was just noting that I can easily understand how young programmers who had unfortunate experiences in their first legacy C++ code could be traumatized for life.

Re:Like a zombie

[shutdown -p now]

It's so easy it's not even sporting. You don't even need C++ for that.

// Suck that, bitches!
#define true false

Bonus points for tucking it away into some build script as a compiler switch instead. Double bonus when build scripts are generated.

Re:Like a zombie

[virgnarus]

I think you and this guy should have a beer together.

Re:Like a zombie

[Zandamesh]

Yes you could call D's development process a bit screwed up, but I'd say that if you look at the design goals of D, it's a whole lot less screwed up. A few things. D1 was designed by a compiler programmer, for compiler programmers, to run native code that at speeds that could compete with C++, and D1 was doing fine, but I'm guessing it came at a point where to add/remove functionality, hacks/patches needed to be added to the compiler code. Now remember, one of the biggest problem with C++ is that it's compiler is extremely complex, from my understanding, this is because each piece of functionality that is added to C++ has to be squeezed in these somehow by means of hacks in the compilers.

Walter Bright decided to take a different route, he decided to create D2, basically making D1 obsolete, breaking backwards compatibility, to keep D's compiler code free of hacks, but it came at a cost. It broke the D community a little, but because D didn't have too many users, Walter Bright could get away with it. D2 is great. If D2 it was standardized today, it would still be light years ahead of C++ in language design terms, it's just that there still is work to be done before that can happen. It's been a while since I've read their newsgroups, but I've also read that there even might be a D3 to replace D2, breaking backwards compatibility again. But if you look at the dev logs, you can see that progress is being made, D is being sculpted into a great language, it's only taking a while.

Re:Like a zombie

[NightCreature83]

Actually my first introduction into C++ was straight into the deep-end with some horrendously hideous code, that hasn't scared me off though. C++ is in some ways so much more easy to write than Java or other high end languages where you have no real pointer types.

Re:Like a zombie

[Puff_Of_Hot_Air]

A couple of C++ compilers? Which? RTTI and exception handling hardley fit your definition of "standards that are impossible to implement correctly" Look, you're entitled to have your preference on programming language, but whatever your pain in compiler implementation; it's hardly a rational reason.

Re:Like a zombie

[Anonymous Coward]

-1 C/C++

People who call their language that, can program in neither. C and C++ are two separate languages. C++ happens to contain a language similar to C as a subset, but again, if you think you can write C using a C++ compiler you are doing it wrong. Like the dumbfucks at ISO contaminating C with C++ stuff.

Re:Like a zombie

[Anonymous Coward]

This never made any sense to me. People are complaining about option features that some people find useful? Just don't use them. It's different if the syntax is horrible, but I've seen quite a few people complaining about the mere existence of optional features.

Re:Like a zombie

[ibbie]

Indeed. Add onto all of those the fact that, AFAIK, on Linux, completely static linking a project is damn near impossible.

If you know otherwise, please let me know. I love the hell out of the language (yes, yes, I'm insane) but this kind of shit kills me. Is it so much to ask, to want to be able to compile a program and simply drop it onto another machine, without having to worry about what version of the standard libraries that machine has installed?

I can understand the issue with network libraries - C has issues with those, as well. But for basic applications - a non-networked game, for instance - this sort of limitation is annoying.

Re:Like a zombie

[thoughtsatthemoment]

It's because there isn't a good replacement for it.

Plain C is a good replacement. Most programmers do need a big library to start coding anything. That's why they always have to search for the perfect language with library support. If you can roll your own, the best replacement comes from within yourself (including inventing your own "better C" language).

Re:Like a zombie

[darenw]

There's no difference between available and compulsory if you spend any time at all fixing and adding to code written by someone else. That would be about 99% of all of us.

Re:Like a zombie

[Anonymous Coward]

WTF? To my mind the best replacement for C++ is C.

Re:Like a zombie

[ibbie]

Indeed, D2 looks amazing. And as I've said before, I love C++.

I'm curious as to how the C and C++ interop fronts are for D, though. I mean, one of the big reasons C++ hasn't gone away is the enormous amount of libraries written in it. Lua has Luabind, Python has Boost.Python ... how does one connect D to these marvelous wonders that keep us from diving head first into NIH syndrome?

Serious question - I haven't had a chance to look into it myself.

Re:Like a zombie

[shutdown -p now]

C++0x will offer vastly improved smart pointers (shared_ptr)--currently available in Boost, and one of the best reasons for using Boost up until now.

shared_ptr and weak_ptr were available in C++ TR1 already, and that got picked up by compilers - g++ had it for a while, and VC++ since 2008 SP1 (not fully - e.g. no stdint.h until 2010 - but shared_ptr was there). So no reason to Boost for those alone. Ditto for the immensely useful std::function.

C++0x only adds unique_ptr on top of that, since you couldn't really do it right in C++03 (it needs language support for move semantics). Still good stuff, as it's much more foolproof than auto_ptr, and you can actually use it in containers.

Re:Like a zombie

[polymeris]

The OP said D was backwards compatible with C. (not C++, though) If that is true, it would have access to more libraries than (almost) anyone could ever need.

Re:Like a zombie

[Anonymous Coward]

In this day and age, you never work with code written by other people?

Re:Like a zombie

[pankajmay]

<quote><p>People can (and do) write incomprehensible code in any language; that's not something specific to C++.  My point was that the fault usually lies with the developer (trying to being too clever for his own good) and not the language.</p></quote>

Yup. C++ is in my opinion, an excellent language, although with age and legacy there are signs of clear kludges worked in.

I have noticed that incompetent; or egoists are the ones who end up writing incomprehensible code which scars a generation of maintainers. C++'s folly lies in the fact that it makes it way too easy to do this.
However, within given guidelines and a programmer that may be a superstar but understands the value of writing clearly (that is the sign of a star programmer anyways -- they know their stuff but don't have to flaunt it, and when they do it is explained why and what!) --- there are very few things out there that rival the power C++ gives you.

Besides, I hate to be the party pooper --- but I do not believe statements like "Good programmer == How much they hate their primary language" are a good yardstick.

I think a Good programmer has to have at the very least 3 characteristics:
1. Knowledge --- knows the tools, knows the problem, and knows if the best tool is being used to solve the problem.
2. Knows weaknesses and strengths of his preferred language, and is not biased towards its suitability when faced with a problem in face of alternatives.
3. Finally, understands that tricks are for exceptional circumstances and have to be explained. Straight-forward code supplanted by properly named entities usually make for a self documenting code. Is not comment averse, but is not a comment junkie either (the ones who have to explain i=8 // Assigns 8 to i are the biggest pain in the butt and time wasters)

Re:Like a zombie

[jgrahn]

So glad to hear that some people actually know about D! D is great. ... D does a marvelous job fixing the syntax and the shortcomings of C++. Also, there's NO PREPROCESSOR! (Before you jump on this, there is nothing you can't do in D that you could do with a C preprocessor)

Ah, so it has all the problems caused by the preprocessor, except it doesn't call it a preprocessor?

Re:Like a zombie

[Anonymous Coward]

I only hope that user-defined literals are still in (there was a proposal to take them out). ~

Thankfully, they are in.

Re:Like a zombie

[shutdown -p now]

The most recent mailing had a paper requesting to remove them - did it not pass the vote for FDIS?

Re:Like a zombie

[shutdown -p now]

Ah, never mind, saw that exact question (and answer) in Herb Sutter's blog. Yay, my BFG is intact!

Re:Like a zombie

[JesseMcDonald]

I believe the GP is incorrect; there are some things you can do with CPP which you cannot do with native D code, such as defining part of an expression or statement in one macro and completing it in another. However, such constructs are almost never advisable, and are rarely used outside of deliberated obfuscated code. The most common case I can think of is defining some sort of table (e.g. method tables in MFC) with separate macros describing the beginning and end of an opaque array, but that is not generally required in D.

Between compile-time evaluation, templates, type introspection & pattern matching, and 'static if', macros corresponding to arbitrary well-defined branch of the abstract syntax tree—which includes nearly all C macros—can generally be described in native D without resorting to a text preprocessor. Of course, if you do find yourself in need of a preprocessor, nothing prevents you from using CPP to transform D code before it's passed to the compiler.

Re:Like a zombie

[Anonymous Coward]

Not if you work for a large software company. Some idiot could use c++ to write incomprehensible code, then leave or be sacked. You get the job of maintaining the ever so clever rubbish he left behind.

Can and does happen with any other language used in a company. Not a problem specific to C++, rather a problem with insane developers. Have a look at thedailywtf.com for some illustrious examples.

Re:Like a zombie

[Fuchsteufel]

It's sad, C# is almost an excellent replacement for C++. As a pure language, it extends C++ is many useful ways, while fixing most of its idiotic syntax and inconsistencies. The problem is the runtime model. C# at this time runs only on the .net VM architecture, which has its uses, but is _not_ a replacement for the direct machine model of C/C++. For example, C# / .net cannot be used for hardcore games: it requires the user to have the correct version of the .net runtime installed, it compiles only to an intermediate language, that is finally compiled only with a JIT, it has no provision for targeted assembly coding, it has mandatory garbage collection, with its inherent unsuitability for real-time apps, its object/memory model is high-overhead, compared to the simple stack-based model of C, etc. I love C# as a language -- much cleaner and more fun than C++. It was a fresh start, and has evolved in a much more sensible way than C++ in the intervening years. C++ has jumped the shark -- all the new features of 0x are grafted on with horrible franken-syntax, and weird exceptions and compromises abound.

Re:Like a zombie

[maxwell demon]

But Perl was designed by a linguist. Is must be readable! :-)

(Actually from what I've seen from Perl 6, they've finally noticed that certain things like sigils changing by context just were a bad idea; unlike C++, they had the balls to be intentionally incompatible to get rid of those mistakes).

Re:Like a zombie

[Anonymous Coward]

What about Ada ? It has every feature that C++ has and even few more. It is really nice language and easy to learn. And don't tell me that this language is dying as it is getting new revision ( Ada 2012 ) and there is community around Ada. In fact it has features that almost any language doesn't have ( like tasking and protected types, CPU affinity, distributed system annex to name few ( I know only of Erlang that has something like that ) ).

Re:Like a zombie

[osu-neko]

It's so easy it's not even sporting. You don't even need C++ for that.

// Suck that, bitches! #define true false

Bonus points for tucking it away into some build script as a compiler switch instead. Double bonus when build scripts are generated.

This is how I know I'm not truly evil. Something that diabolical would never even occur to me. Um... kudos?

Re:Like a zombie

[maxwell demon]

It's so easy it's not even sporting. You don't even need C++ for that.

// Suck that, bitches!
#define true false

Bonus points for tucking it away into some build script as a compiler switch instead. Double bonus when build scripts are generated.

Or have a compiler wrapper somewhere which calls the real compiler with that option added, and make sure the build scripts find that instead of the real compiler while any direct compiler call finds the real compiler ...

Re:Like a zombie

[Twinbee]

You can always use "unsafe", and there's even a way you can imitate malloc, so you can manage your own memory.

http://www.codeproject.com/KB/cs/UnmanagedArraysInCSharp.aspx

So you can get most of the speed advantage of C/C++ if you really want, and otherwise use safer, more convenient C sharpy stuff.

What do you think?

Re:Like a zombie

[Anonymous Coward]

Indeed. Add onto all of those the fact that, AFAIK, on Linux, completely static linking a project is damn near impossible.

Is this a problem with gcc/g++? Aren't those open-source compilers? You should be able to modify them to fix the issues. Isn't that what open source is about?

Re:Like a zombie

[Anonymous Coward]

#undef true
#undef false
#define true 1
#define false 0

Re:Like a zombie

[Jorl17]

Most people just don't get it. If we start to turn C++ into one of those languages that are better for some particular situations, it'll lose its speed and its reliability. Heck, with constant changes some Operating System programmers already turn only to C beause they claim "compiler X sucks at C++". I like all these C++ changes because they almost map directly to machine code -- they're almost always just syntax-based changes, with no direct implication in the way structures are stored and interpreted. If we add those things we'll have to start adding other layers to C++, eventually turning it into some sort of interpreted language or Java-like language and I don't want that. If you don't like C++ then don't you use, just don't appeal to dumbing it down from its purpose -- to fit every purpose!

Re:Like a zombie

[mikael]

You need to do the following:

Locate the files: libc.a libm.a libstdc++.a in your /usr/lib hierarchy.
I found libm.a and libc.a in /usr/lib/debug/usr/lib
These come from the debug packages for the kernel.

Create symbolic links to them in the project directory:

ln -s /usr/lib/debug/usr/lib/libm.a .
ln -s /usr/lib/debug/usr/lib/libc.a .
ln -s `g++ -print-file-name=libstdc++.a`

You now have three symbolic links to the static libraries

Linking to these must be performed by using the current directory as a load library path:

  g++ -static-libgcc -L. -o example example.cpp

Then test using 'ldd'

ldd example
        not a dynamic executable

Re:Like a zombie

[t2t10]

If we start to turn C++ into one of those languages that are better for some particular situations, it'll lose its speed and its reliability

C++ has never had "speed and reliability". Nobody can realistically write a C++ program of substantial size that doesn't have serious errors. And C++ code only runs fast if you invest a shitload of time trying to get rid of all the high-overhead crap that its standard libraries do.

If you don't like C++ then don't you use, just don't appeal to dumbing it down from its purpose -- to fit every purpose!

What concerns me is that there are a lot of people like you who live with the delusion that C++ is actually "fast and reliable", and you people write software.

Re:Like a zombie

[HiThere]

The real problem with D is lack of libraries. There are IDEs, though not fancy ones. But the lack of libraries is a constant source of grief. To the point that I started looking elsewhere. (They've also got a problem with garbage collection, and in some circumstances it can spend a hideous amount of time there. But that's rather clearly a bug that will be cleaned up. [And I don't even recall whether that's D1 or D2 [D2 is the developmental version. D1 just gets bug fixes.])

Re:Like a zombie

[HiThere]

That's a bit of a mistake. D can call routines from C libraries, but C code is not compatible with D. This can cause problems when the library wants to make callbacks. It can also be a bit difficult to figure out. It's MUCH better than the FFI interfaces found in many non-C languages, but it's far from perfect. You need to rewrite any complex header files before you can call many routines.

It *should* be relatively simple to wrap C libraries to be called by D, but because the developer community is so small, this is only occasionally done, and tends to be done once and then forgotten. Which means that after awhile it stops working, but there's no notice that it's stopped working. So there is a collection of obsolete library ports, and a few that still work. And many that were started, but never finished.

All in all, this has lead me to look for another language, even though I really like D as a language (except for the compile time features...but I don't like those in any languages, except, perhaps, LISP and Scheme).

Re:Like a zombie

[HiThere]

Ada has several problems that are difficult to overcome. The first one that occurs to me is that string literals have their length as a part of their type. One can generally work around this, but when one needs to work around something so central to the language, you've got problems. Another is that garbage collection is optional, and almost never implemented. This means you can't depend on it being present. Then there's the syntax of their object model, which clearly indicates that objects were an afterthought. It's awkward to use, even though it's powerful enough. Then there's the way they manage memory.

Ada has it's niche, where it's clearly the best language, but it's a *small* niche. It *can* be used nearly anywhere, but in many places it's quite clearly a kludge. (Databases and GUIs come to mind.)

Re:Like a zombie

[Jorl17]

Point me to benchmarks. Or, better yet, instead of arguing with the subjective concept of speed, show me benchmarks of it against other applications and affect the results with variables such as code readability, code maintainability, code freedom (=danger of falling at the hands of Oracle, Microsoft, etc), code portability (if needed for said project). Then we can talk. Until then, I'll make my money by following C++ -- which seems to be fast and reliable enough to be used nearly everywhere along with C.

Re:Like a zombie

[GooberToo]

Or for the projects where having to manage every allocation and deletion is tedious and gets in the way of actually implementing a program.

The problem with that statement is, there has long been various pointer implementations which make that level of tedium completely unneeded. If you've been having to do this for the last decade, you've been doing it completely wrong. It also likely means your C++ book collection is pretty sparse.

Yes, memory management is an important aspect to C++ coding. But anyone who has bothered to make even a tiny effort to learn C++ coding best practices over the last decade and half has long since learned various smart pointers dramatically reduce the burden and flat out prevent numerous common (and frequently the worst) memory leaks and dangling pointer issues.

Really, GC for C++ opens the door for programmers who've never had to manage much memory (example, Java and other dynamic languages). And it allows some to not worry about such details where performance is simply not an issue. But for those who use C++ for performance reasons, GC is likely not of significant interest. Of course, hybrid approaches are now possible where it makes sense to do so.

Re:Like a zombie

[GooberToo]

C++ has never had "speed and reliability". Nobody can realistically write a C++ program of substantial size that doesn't have serious errors.

Reality says you're full of shit. I've personally worked on a project which was C++. Three small teams created over 450k lines of code with roughly 100k of that being unit tests. Integration was less than 30-days. We identified two leaks. Both turned out to be in the platform's OS and standard library. And to be absolutely clear, these results are hardly unique.

And C++ code only runs fast if you invest a shitload of time trying to get rid of all the high-overhead crap that its standard libraries do.

Again, reality says you're absolutely full of shit.

When you're entire point of posting is to either prove to the world you're an idiot or worse, simply desire to troll, just don't post as it makes the world a better place.

Re:Like a zombie

[GooberToo]

Then you clearly don't have experience with perl. The reason why perl is dying on the vine is exactly the problem you describe. Perl coders love to ignorantly say the code is the documentation. Never mind anyone who says such a thing is an idiot. The reality is, perl is so wonderfully cryptic, its common for the original coder to come back to his code some six month or a year later and have no clue what the code does and then must spend several minutes or hours figuring out what they hell he coded so many months ago.

Realistically, C++ is extremely comprehensible so long as you have good coders doing your coding. If you find C++ which isn't comprehensible, it typically means you had an extremely poor coder more so than a damnation of the language. Yes, you can create some incomprehensible code in C++, but generally you have to work pretty hard at it. In fact, most of the worst C++ code I've ever seen actually comes from tutorials on C++ specifically illustrating what not to do specifically because it creates incomprehensible code; frequently with side effects and/or undefined behavior. So again, if you're finding this, it means you're replacing a really poor coder more so than C++ being the problem.

Seriously, any bad coder can create bad code in any language. Hell, I've seen really bad code in python even, and I can assure you, you have to work really hard to have incomprehensible code in python. And the vast majority of this code was from newb coders. That doesn't mean python is a bad language. Rather, it means the coders were unfit for the job.

Re:Like a zombie

[t2t10]

Reality says you're full of shit. I've personally worked on a project which was C++. Three small teams created over 450k lines of code with roughly 100k of that being unit tests. Integration was less than 30-days. We identified two leaks. Both turned out to be in the platform's OS and standard library. And to be absolutely clear, these results are hardly unique.

So you think that because your code passed 100k of unit tests it doesn't contain serious errors? You really are naive.

There is no way of ascertaining the correctness of C++ code through testing because there is no guarantee that runtime errors will have any effect. In fact, many serious errors don't even show up until you change optimization flags, a new version of the compiler comes out, or you start porting. Your code can work perfectly today and stop working tomorrow for no apparent reason.

When you're entire point of posting is to either prove to the world you're an idiot or worse, simply desire to troll, just don't post as it makes the world a better place.

You have the Dunning-Kruger problem: you know so little that you don't even realize how poor your understanding is.

Re:Like a zombie

[t2t10]

Are you really such a novice to think that this sort of thing can be benchmarked?

Tell you what: you program in whatever braindead language you want; just don't expect that other people stand by quietly when you make such ridiculous claims.

Re:Like a zombie

[Jorl17]

Then quit using false facts. That dark rhetoric only eats up idiots. Statistics are all around us, rest my case. Shall not argue anymore -- as you ruin yourself with those other languages (some of which I am also very fond of), I'll bring myself to a shining shine of a shine.

Re:Like a zombie

[t2t10]

Then quit using false facts

Why don't you come up with benchmarks support your claim? Oh, I see, there are none. The question is not decidable based on benchmarks.

Statistics are all around us, rest my case.

You want statistics? Look at C# vs C++: C# is about to overtake C++ in its popularity. Why? Because C++'s popularity was largely based on its adoption by Microsoft.

Shall not argue anymore -- as you ruin yourself with those other languages (some of which I am also very fond of), I'll bring myself to a shining shine of a shine.

Spoken like the kind of geek who writes software only for himself. Try managing larger projects in C++, try hiring experienced C++ programmers, try fixing bugs in other people's convoluted C++ pointer code for a change.

Re:Like a zombie

[euroq]

I should have clarified that there isn't anything you can't do without the preprocessor to do in a realistic or relevant sense. Defining an partial expression in a macro such as "X *" instead of "X * Y" is not something that needs to be done, or that one should be doing at all in order to solve some problem. If you really need to do "X *" you can just as easily do "X * Y" where Y can be defined in another macro (or its D equivalent).

dnf and C++0x in same year?

[Anonymous Coward]

...faints...

Re:dnf and C++0x in same year?

[Anonymous Coward]

Maybe the DNF devs were waiting for C++0x so they could clean up some spaghetti code. Once Linux Desktop achieves 10 percent market penetration they'll be able to secure the funding they need to ship.

Re:Question

[Anonymous Coward]

As someone who has written software using GObject, FUCK YOU.

That's what C++0x means

[pavon]

I've been reading about C++0x for years now, and never realized that the 0x referred to a new revision of C++ to be released in 200X, until I just now saw the FAQ entry about C++1x. I assumed it was some odd inside reference to hex number prefix that I just didn't get. I thought the Y2K bug incident had purged everyone who didn't use full dates :)

Re:That's what C++0x means

[Anonymous Coward]

To discover the meaning of stuff like this on your own, you can try potential explanations in your head until you find one that seems right.

Looks like in this case you are able to recognise that "C++ to be released in 200X" is a good explanation when you see it, but the problem was that you couldn't imagine it in the first place. I suggest that from now on you think more and imagine more. Many other discoveries await you!

Re:That's what C++0x means

[Anonymous Coward]

In 100 years the naming of C++ will be the problem of some one else.

My first question.

[140Mandak262Jamuna]

Will they resolve the question of std::list::size() function's speed? It is constant O(1) in Visual C++ implementation. In gcc people are arguing over fine distinctions between "shall" and "will" or something equally esoteric. As it stands in Linux it is Order(N). I am not kidding. My code was scaling fine in Visual C++ going form 10 elements to 10 million elements in a nice predictable N*Log(N) curve. It was frustrating to debug the scaling loss in Linux and to finally realize, the root cause of the trouble was the break conditional evaluation in the for loop. And everyone is refusing to fix the damn thing for six years. We were paying maintenance to RedHat. And they were also giving us the lawyer talk instead a fix.

Ref: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00219.html

Re:My first question.

[PhrostyMcByte]

There was nothing for RedHat to fix -- you were relying on undefined behavior. list's size() complexity is still undefined in C++0x. You're expected to use iterators and empty() when you want defined complexity.

Re:My first question.

[Anonymous Coward]

From SGI's doc:

size_type size() const

Returns the size of the list. Note: you should not assume that this function is constant time. It is permitted to be O(N), where N is the number of elements in the list. If you wish to test whether a list is empty, you should write L.empty() rather than L.size() == 0.

------------------
I agree with you though, O(N) does seem kinda brain dead. Obviously, an implementation of a list needs a header in order to support methods like back() and push_back().

This is what happens with standardization committees. Some compiler vendor insists that they do it some crazy assed way, have always done it that way and they have hundreds of paying customers, so everyone has to live with a suboptimal spec.

Re:My first question.

[Anonymous Coward]

Well, it's a list. If all the elements are the same size then it's trivial to track insertions and deletions with a single member variable. The size function is just m_elements*element_size().

If the list is heterogeneous, then I suppose you could track the size of each element on insertion and deletion. You'd have to track the size of the list as well as the number of elements. Then it's still O(1) to get the size of the list.

You pay the penalty of two integers in each list when you do this. If the lists are being used to form a tree with a lot of branches, perhaps this penalty matters.

In a classic list, you just have to traverse each element and add stuff. As always, it's a tradeoff. If you don't mind extra memory for each list object, and O(1) size matters to you, then it shouldn't be too much work to subclass the list, override insert, delete, and any other function that mods the list.

So. Not knowing much more than that, and having only skimmed the discussion you linked I think that perhaps having a simple list that requires O(N) size lookup isn't so bad. The Microsoft implementation covers the more common case but if the size of the list object itself matters to you, then how do you get rid of the tracking members which presumeably exist in each Microsoft list object?

Re:My first question.

[godrik]

The reason behind is easy. When one use a lnked list, one usually does not need to know its size frequently. Therefore counting the number of element is pretty much redundant and a performance hog in most application.

If you really need to know the size of the list, then you can do the accounting manually. It is not hard at all to do.

I am personnally very happy that std::list does not know its size. Because I never need this information and I would hate having to rewrite list just to kick the accounting out.

I understand your experience was frustrating, but most porting operation leads to stupid bugs or behavior like that.

Re:My first question.

[betterunixthanunix]

Do not rely on undefined behavior, and these things will not be a problem.

Re:My first question.

[shutdown -p now]

SGI docs do not represent the Standard, however.

Re:My first question.

[joesteeve]

Yay.. I am not the only one who got bit by this one. :)

I had assumed that std::list::size() was O(1) .. Was 'enlightened' when, two threads jumping around a container segfaulted, costing me a couple of sleepless nights.

I agree to "sticking with the standard".

Re:My first question.

[shutdown -p now]

Actually, the reason why size() is O(N) in gcc is because, if you have a counter in the list itself, then splicing the tail of another list into yours becomes an O(n) operation (because you need to count how many elements are there to splice to update the counter). Thus, you either have O(1) size(), or O(1) splice(), but not both. VC and gcc had different ideas about which one of those operations is more common.

Having the counter itself is hardly a space or performance hog, especially given that std::list is a doubly linked list, but is actually used where a singly linked one would do in the majority of cases in C++ programs (since C++03 didn't offer a singly linked list container; now we hve std::forward_list in C++0x). Keeping those back pointers around and updating them is much more of a hog than a single counter.

Anyway, in my opinion the strongest argument in favor of O(1) size() is that all other containers are O(1). Thus generic code can reliably use it regardless of type of container.

Re:My first question.

[Anonymous Coward]

And this is why code re-use is not always a good thing.

This is exactly why you'll look at the source code to any of John Carmack's games and notice he re-invented the wheel (for things like data structures, common algorithms, etc) for a very good reason, rarely using anything from the C standard library and never using the STL. More control.

Re:My first question.

[russotto]

std::list::size() is O(N) because making it O(1) makes splice O(N).

Re:My first question.

[shutdown -p now]

Will they resolve the question of std::list::size() function's speed?

Yes. From the most recent C++0x FCD, 23.l2.1[container.requirements.general] table:

Expression: a.size()
Return type: size_type
Operational semantics: distance(a.begin(), a.end())
Assertion/note pre-/post-condition: -
Complexity: constant

Re:My first question.

[Rockoon]

Here we are talking about wasting one more machine word per list for performance reasons, in a structure that wastes two machine words per list element for performance reasons.

size() should not be a member of std::list at all if the O(n) crowd is to be listened to, for its inclusion is then only a trap to be fallen into.

Re:My first question.

[insane_coder]

See Effective STL Item 5. If size() is constant, then splice() must be implemented in a slower manner. Therefore, whether size() for std::list is constant or not depends on whether you want a fast or slow splice(), and that's up to the implementation. So conversely, you'll see that splice() in Visual C++ is quite slow.

Re:My first question.

[Rockoon]

When one use a lnked list, one usually does not need to know its size frequently. Therefore counting the number of element is pretty much redundant and a performance hog in most application.

The implementation is a doubly linked list. Setting a backwards pointer on every element is pretty much redundant and a performance hog in most applications, that only iterate forwards.

Re:My first question.

[PhrostyMcByte]

Cool! I wonder when that was introduced, I didn't catch it.

Re:My first question.

[Anonymous Coward]

If you're doing cross platform support use STLPort instead of your compiler's implementation. And STLPort outperforms Visual Studio 2010's implementation in our application, so that is a nice benefit too!

Re:My first question.

[Anonymous Coward]

Well, it's a list. If all the elements are the same size then it's trivial to track insertions and deletions with a single member variable. The size function is just m_elements*element_size().

If the list is heterogeneous, then I suppose you could track the size of each element on insertion and deletion. You'd have to track the size of the list as well as the number of elements. Then it's still O(1) to get the size of the list.

I would say the obvious result would be element count in the list and not sum of sizes of each element (did not check official description).

Yes, count() would make it more obvious what size() means but in case of std::list, you only have one type of elements so it's a matter semantics mostly.

My worthless opinion if anyone cares..

Re:My first question.

[MichaelSmith]

most porting operation leads to stupid bugs or behavior like that.

Who ports these days? Java is more portable by virtue of the VM. C is more portable by virtue of its simplicity.

Re:My first question.

[shutdown -p now]

Seems to be N2909, revised as N2923, and voted into the draft in July 2009.

On a side note, the new std::forward_list does not have size() at all, so for those scenarios where having size is superfluous (either because you don't want to pay the overhead of an extra size_t for an empty list, or because you want to splice ranges), you can use forward_list for best performance.

Re:My first question.

[Anonymous Coward]

two threads jumping around a container segfaulted, costing me a couple of sleepless nights.

If misinterpreting a complexity guarantee caused your program to segfault, you had more problems than just performance.

I agree to "sticking with the standard".

The standard says empty() is constant time, whereas size() "should be" constant time. There is clearly some wiggle room. That said, the splice() method that libstdc++ does in constant time is allowed to be linear.

The GCC folks are technically "sticking with the standard" even if they've failed to follow the principle of least surprise.

Re:My first question.

[Just Some Guy]

Leaping into the middle of the conversation: why? It seems like you could implement caching logic like:

1. Initialize lists with size=0 and known_size=true.
2. When adding elements, if known_size=true, size+=1.
3. When size() is called, if known_size==true, return size. Else, set size=countedsize() and set known_size=true.
4. When splice() is called, set known_size=false.

Voila. size() is O(1) almost always, except immediately after a splice(). In the worst case, it'd be O(n) immediately after a splice(), but only the first time - and then it'd revert to O(1) behavior.

Why wouldn't that work?

Re:My first question.

[mmcuh]

If that's an issue it's an issue with the specification, not the implementation. std::list is specified to have bidirectional iterators, and you can't get those without backward links.

Re:My first question.

[insane_coder]

Er sorry, meant to say Item 4.

Re:My first question.

[Brian Feldman]

I'm sorry but caching the size of the list is a cost you add to EACH add or delete operation on the list and it is not always appropriate to need to know the size of a list beforehand and so to spend the extra computational resources on maintaining size counters on linked lists as a default is quite silly. To expect it is equally silly. You don't need to pessimize most applications just to optimize some of them. It really is trivial to make sure each access to a linked list object is done through an object that handles the counting.

Re:My first question.

[larry bagina]

STLPort doesn't (and most likely won't) support C++0x

Re:My first question.

[Brian Feldman]

He thinks that just because an implementation could read from a counter variable to provide an O(1) answer that the counter existing makes it thread-safe to perform counted operations upon the container. Concurrency is a pretty difficult concept when you're first getting introduced to it.

Re:My first question.

[140Mandak262Jamuna]

This is what I call the lawyer talk. I don't want a run around. I am not checking for size() == 0. I need to know the number of elements in the list. The standards allow splice() to be O(N). Most people expect size() to be O(1) that is how they interpret the standards. Making splice() O(N) to give size() in O(1) is the reasonable and user friendly thing to do. Hiding behind opaque english, using lawyer talk and blaming the user is antagonizing the user.

Re:My first question.

[Anonymous Coward]

Because it would be unpredicatable.

Re:My first question.

[Puff_Of_Hot_Air]

This is what I call the lawyer talk. I don't want a run around. I am not checking for size() == 0. I need to know the number of elements in the list. The standards allow splice() to be O(N). Most people expect size() to be O(1) that is how they interpret the standards. Making splice() O(N) to give size() in O(1) is the reasonable and user friendly thing to do. Hiding behind opaque english, using lawyer talk and blaming the user is antagonizing the user.

Mate, you need to pay attention to your own sig. The C++ standard is clear on where big O performance is prescribed. Where it is not, don't make assumptions. This is not some grand conspiracy against you, just suck it up and fix your code.

Re:My first question.

[Just Some Guy]

It would be unpredictably awesome. Suppose you have a million splice() calls that insert one item each, followed by a million size() calls. If size() is O(1) and splice is O(n), that would require about a million list traversals and about 500 billion (sum([1..1,000,000])) visits to items in the list. If size() is O(n) and splice() is O(1), that would take a million list traversals and a trillion visits. In my algorithm, size would be O(n) once and O(1) every other time, for exactly one traversal and one million visits.

With my idea, splice() is always O(1). In the worst case, size() would take exactly as long as it does now, plus a single conditional to see if known_size is true or false. In the average case, size() would also be O(1). It would also conform to the C++ principal of not making you pay for what you don't use: unless you specifically call size() after splice(), both algorithms would be O(1). If you do call size() after splice(), it would be no worse than what we have today.

I'm loathe to discard simple algorithm optimizations just because they don't apply to every situation, particularly when their failure mode is just as good as the original.

Re:My first question.

[SomeKDEUser]

Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".

Re:My first question.

[MORB]

It's easy to wrap std::list to do that yourself. What you propose would mean that if you get a list passed from some other opaque part of the code you have no way to predict whether size will be O(1) or O(n), because it may or may not be the result of a splice.

Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.

Re:My first question.

[drooling-dog]

The lack of a singly-linked list is aggravating, but I'm guessing the reason for not providing one was that simple things like deleting a specified node blow up to O(N) because of the need to update a pointer in the inaccessible (except by iterating from the beginning) preceeding node. I.e., if there's no elegant way to do a simple thing, just don't provide it at all, and tag everybody with the overhead of a doubly-linked list and its often superfluous back-pointers.

Anyway, thanks to the Powers That Be for std::forward_list. Maybe now I'll stop rolling my own...

Re:My first question.

[Just Some Guy]

Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".

I'm sorry, but I reject that outright. Optimizing compilers have been surprising us with unexpected gains for years, but as long as they don't worsen the situation, no one minds. I can't think of a situation where an optimization that falls back to the default behavior in the absolute worst case but offers a nice speedup in others is a bad thing.

I don't claim that I'm a supergenius and that I spent 30 seconds solving a problem that the libstdc++ guys have been working on for years, but I don't accept that the flaw in my idea is that it only gives an improvement 99.9% of the time and falls back to the old behavior in the other 0.1% of cases. In every other software realm, you'd call that a successful optimization.

Unless you depend on size() being slow for some reason, in which case you're using the wrong language. But that's a different discussion.

Re:My first question.

[Just Some Guy]

Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.

If you still document it as being O(n), but it's actually O(1) most of the time, I promise you no one will mind.

Re:My first question.

[shutdown -p now]

Yeah. That's precisely why forward_list is a bit of an oddity, with no erase() or insert(), but instead having erase_after() and insert_after(). It's not even a "sequence" in STL parlance.

Re:My first question.

[Anonymous Coward]

Performance hog? It hardly makes a difference at all. A few milliseconds at most, and that's if you insert tons of new elements into the list.

Re:My first question.

[Anonymous Coward]

Who in their right mind would use list::size() in a speed sensitive part of code anyway?

Re:My first question.

[Anonymous Coward]

Because then everybody who doesn't abuse size() gets a memory usage penalty on every list.

Re:My first question.

[Just Some Guy]

There's something to that, but that overhead would be sizeof(size_type)+sizeof(bool), which should add up to an insignificant overhead except in the case of a program that maintains millions of single-element lists.

Re:My first question.

[smellotron]

Making splice() O(N) to give size() in O(1) is the reasonable and user friendly thing to do.

No, that's not reasonable. If std::list doesn't track size internally, it is still possible to have an O(1) size() equivalent by tracking it yourself. If it does track size internally, it becomes impossible to have an O(1) splice() equivalent. That's very important for moving sections of memory around in a resource-constrained environment.

Re:My first question.

[smellotron]

Who ports these days? Java is more portable by virtue of the VM. C is more portable by virtue of its simplicity.

Apparently not you. The language doesn't help you when there are differences with the filesystem structure, environment variables, shell execution, user interface guidelines and expectations, compatibility concerns with standard library versions (mscvrt.dll, libc.so, jre version), etc. Nontrivial multi-platform software is still hard to get just right.

Re:My first question.

[m50d]

You would make the code more complex and less predictable. People would see different behaviour from size() in their real programs and their benchmarks. If someone wants this kind of size() caching they can easily implement it themselves (just makes a class that wraps std::list); if gcc followed your advice there'd be no way to turn it off.

Re:My first question.

[jgrahn]

Here we are talking about wasting one more machine word per list for performance reasons, in a structure that wastes two machine words per list element for performance reasons.

No, we're talking about ditching a O(1) splice() -- one of the defining properties of a linked list! See smellotron's posting elsewhere in the thread.

size() should not be a member of std::list at all if the O(n) crowd is to be listened to, for its inclusion is then only a trap to be fallen into.

Now *that* is something I can agree with. But it's 15 years too late for that. C++ isn't Python: once mistakes have been standardized we have to live with them.

Re:My first question.

[Anonymous Coward]

Apparently not you. The language doesn't help you when there are differences with the filesystem structure, environment variables, shell execution, user interface guidelines and expectations, compatibility concerns with standard library versions (mscvrt.dll, libc.so, jre version), etc. Nontrivial multi-platform software is still hard to get just right.

Very true.

Re:My first question.

[Anonymous Coward]

Oh my god. They decided to break programs at runtime? They should have removed the size member for std::list too. This would only break crappy code that uses it. But this would not break software that compiles.

std::list is already the most useless container of the C++ standard. And without a constant splice operation it gets worse.

Re:My first question.

[Pontobart]

I hope the GCC guys will not follow this change. This would mean that lots of programs will break at runtime. I use splice() extensively and rely on the constant behaviour given by stdlibc++. Without this std::list is a completely useless class :)

Re:My first question.

[gatkinso]

Hopefully you fixed it yourself.

PITA I know, but the fact that it is possible to do it huge.

Re:My first question.

[maxwell demon]

However it could be solved with "partial tracking": Track the size until you encounter a splice, at which point you invalidate the tracked size (causing the next call to size, and only that, to be O(N)). People who never splice will have an O(1) size, people who do splice will have an O(1) splice. People who need size after splice will have to live with O(N), but they would have to in any case. Note however that only the first call to size after splice would be O(N), because after that the size is known again.

Re:My first question.

[maxwell demon]

once mistakes have been standardized we have to live with them

Well, that's not 100% true: Exception specifications got deprecated in favour of noexcept.

Re:My first question.

[Carewolf]

Uhmm.. If you are porting C++ application then don't rely on stuff like that, or use a portable framework. I know it can seem counter-intuitive, but the standard library for C++ is NOT considered portable (especially performance wise), since it has different implementations on different platforms. If you desire portability use a framework designed for it, like Qt for instance.

Re:My first question.

[Carewolf]

As awesome as C++ is, and Bjarne is for designing it. You should not listen to Bjarne for programming advise. Close you eyes are imagine STL, exceptions and RTTI does not exist, and you have one of the fastest, most expressive and most portable languages in the world.

Re:My first question.

[maxwell demon]

There's generally no safety against two threads concurrently writing to the same container, nor against one thread writing and the other one reading. So an implementation with O(N) splice and O(1) size wouldn't have any concurrency problems. However the solution I suggested elsewhere in this thread (invalidate the size on splice() and recalculate on first subsequent call to size()) might indeed be costly to make thread safe (because logically size() is only reading and should therefore be thread safe). An option which doesn't have that problem would be to never recalculate after invalidating (so the first call on splice() would change size() to O(N) indefinitely, or at least until another mutating operation, like clearing the list, causes the size to be known again).

Re:My first question.

[ConceptJunkie]

True, with Java, you don't have to port to different platforms, you only need to port to each new JRE as it comes out.

Re:My first question.

[NoOneInParticular]

Not entirely true. I could envision an implementation of list.size() that will keep track of the size over insertions and deletions, and for which a call to splice() would set an unknown_size flag, triggering a count when set. Then the implementation of size() would be O(1) usually, and O(n) after a splice() took place. If you don't use splice() a lot, this would only add the check for the flag, if you do use splice() a lot, you should know better than to use it in combination with size().

Re:My first question.

[NoOneInParticular]

People now see different behaviour if they run their code in gcc vs. msvc vs. icc. And that is acceptable?

Re:My first question.

[shutdown -p now]

Oh my god. They decided to break programs at runtime?

Well, you can't dynamically link to the template itself, obviously. It would break if you're passing std::list between shared libraries compiled with different versions, yes, but it's generally a bad idea (I don't know how these things are in Unix land, but on Windows, C++ runtime is not compatible between major compiler releases). Removing size() from std::list would break far more code in a far more noticeable way - since a recompile wouldn't fix.

Anyway, the point about binary compat has been raised when discussing this, and it was pointed out that C++0x already introduces some ABI breakage, for example, by specifically prohibiting reference counted basic_string implementations (which exist out there).

Another point was that g++ is the only one which has O(n) size(); all other implementations have O(n) splice(). Granted, g++ is a big one, but they figured they had to decide one way or another in practice - when it's ambiguous, it's worse than useless - and having all implementations but one do it in the same way strongly hints that it is the preferred one.

std::list is already the most useless container of the C++ standard. And without a constant splice operation it gets worse.

std::list is useful whenever you need an "open-ended queue" (i.e. random insertions and removals at arbitrary points), which is rare, but it does happen. On the other hand, I don't ever recall seeing splice() in production C++ code. Even then, splicing another list completely is not affected - it's only range splice.

My personal take on this is that in vast majority of cases where splice() is useful, you want forward_list anyway.

Re:My first question.

[Anonymous Coward]

Regardless, it's always a good practice to form your loops as follows:

for(int i = 0, end = container.size(); i < end; ++i) {
...loop stuff assuming size doesn't change...
}

Instead of calculating the size every iteration, it's done once. Obviously, iterators are superior in such a case, but aren't always practical when you're not dealing with an entire collection (for example, if we only wanted to iterate over half, or sqrt(n) elements).

Re:My first question.

[alexo]

But then list iterators will have to reference their corresponding list objects, which will affect iterator invalidation... There are lots of issues involved, it isn't as trivial as you think.

Re:My first question.

[spitzak]

Anyway, in my opinion the strongest argument in favor of O(1) size() is that all other containers are O(1). Thus generic code can reliably use it regardless of type of container.

That's interesting, but it would seem to be impossible to rely on for generic code.

The fact that programmers call size()==0 rather than empty() is just something they need to fix themselves.

Code like std::vector::reserve(list.size()) is useful and I suspect the only argument for making size() O(1).

Every other use I can think of involves comparing size() to and index number, and I cannot figure out a good use of an index number in a list that is not itself O(N). Thus I don't see a fast size() as being of any use for generic code, as any use of it would then have to do a step that is slow on a list anyway.

A converse problem is that in gcc std::string(const std::string&) is fast (because they are pointers to reference-counted data) while this is slow in VC++.

Re:My first question.

[spitzak]

Actually there would be no bool, any sensible implementation would use a value such as size_t(-1) to indicate the "unknown size", so the overhead is only sizeof(size_type).

Re:My first question.

[shutdown -p now]

Every other use I can think of involves comparing size() to and index number, and I cannot figure out a good use of an index number in a list that is not itself O(N).

One interesting example given in another reply was "iterate through first half of the list". You'd still use iterators to access the elements, incrementing them as you go, but you'd also need an int counter, and to compare that against size()/2.

A converse problem is that in gcc std::string(const std::string&) is fast (because they are pointers to reference-counted data) while this is slow in VC++.

Huh, g++ still uses refcounted strings? Are you sure this is still true as of 4.x? I was pretty confident that this was purged from all major implementations quite some time ago, when various problems with making them conform to subtle Standard provisions surfaced with no surprise effects. In particular, every indexing operation and every iterator dereference has to be treated as "write" (since it returns a non-const char reference) for the purposes of COW, and what's worse, since an iterator or a reference can be kept around for later use, any string for which such has been obtained becomes "unshareable" (see http://www.sgi.com/tech/stl/string_discussion.html).

Anyway, C++0x wording makes it downright impossible to have a refcounted std::string implementation, which was very much by design.

Re:My first question.

[Just Some Guy]

I wouldn't say that. Consider that in insert(), you'd have to update the list_size value. If you use (list_size==-1) as the "unknown size" flag, then you have to check for it before incrementing. Otherwise your first insert() after splice() would result in list_size==0, or empty. If you store "unknown size" as a separate bool, then you can tell insert() to always increment list_size. I couldn't even hazard a guess as to whether "conditionally increment" or "always increment" would be faster on modern hardware.

Re:My first question.

[spitzak]

Yes I heard about C++0x wording.

I would have preferred if they just said that operator[] returns a const reference (and the iterators are const only as well). This would fix the problems with the reference counting. It would also stop programmers from trying to replace characters in strings, which is very primitive practice that is preventing modern use of multibyte encodings.

I am afraid what is going to happen if they continue with this plan is that libraries are going to start making their own string replacements, like the situation was 10 years ago. We are still stuck with QString in Qt and a bunch of other remains of this...

If somebody does replace string I would like to see it do this:

  1. copy of string is really fast.

  2. No integer index. The only access is by forward iterators, and there are different iterators and an ability to define new ones. This will allow iterators for different types of Unicode transformations, and to handle errors in UTF-8 and all kinds of other parsing operations.

  3. Construction from a C quoted string constant is really really fast. This may require compiler support, but the basic idea is for it to know that a pointer points at a C quoted string constant and thus not reference count or free it.

Re:My first question.

[shutdown -p now]

would have preferred if they just said that operator[] returns a const reference (and the iterators are const only as well). This would fix the problems with the reference counting.

That would be a fairly major breaking change, though.

I am afraid what is going to happen if they continue with this plan is that libraries are going to start making their own string replacements, like the situation was 10 years ago.

Why? I haven't heard many complaints about performance of non-COW std::string. When passing them as arguments you use const reference anyway, and when returning (N)RVO, and now also move constructors, take care of most common cases where copying would otherwise happen.

Nor have I seen popular C++ libraries with their own custom string classes in a while - all that have them now, do so mainly for back-compat purposes, or because they're largely self-contained frameworks (like Qt).

Construction from a C quoted string constant is really really fast. This may require compiler support, but the basic idea is for it to know that a pointer points at a C quoted string constant and thus not reference count or free it.

This is a QoI issue - it definitely requires compiler support (there has been a lot of discussion about whether it's possible to detect whether the value is a string literal - the consensus so far is that it is not, no matter how you twist the wording of the Standard), and compilers could do so today; it's just that they don't bothered. I agree that it would be nice, though.

No integer index. The only access is by forward iterators, and there are different iterators and an ability to define new ones. This will allow iterators for different types of Unicode transformations, and to handle errors in UTF-8 and all kinds of other parsing operations.

Well, std::string has always been "just an element container", locale and encoding independent, more or less by design; any operations that are more specific than that, and which need to know locale and/or encoding to operate, are provided as external. One could argue that this is not such a good design - it's certainly more low-level than, say, Java strings - but this has been so since C++98, and they didn't really change anything in that regard in C++0x.

By the way, it's clearly deliberate, because the new string specializations for char16_t and char32_t (which are supposed to be used strictly for UTF-16 and UCS4, respectively) do not have specialized iterators - they still iterate over code units, not over code points or logical characters.

Re:My first question.

[spitzak]

You may be right that there won't be a demand for faster strings to replace these.

I am already using const reference for all arguments. The problem is that a lot of code needs to store a copy of the string into an object (for instance a "set the name of this object" method. We were certainly relying on reference counting to make this fast. Thinking more about this it would be fairly easy to replace it with some other objects we are using that are wrappers around std::string (in particular we use hash tables for all string keys and the object in the hash table is a pointer to a std::string, but we know the keys are equal if these pointers are equal). If such wrappers are easy to make without either making it difficult or unreasonable overhead to interact with code expecting std::string, than this would work.

I agree there should be access to the code units, but even this could be done with iterators. You should be able to iterate UTF-8, UTF-16, and UTF-32 code units out of a string, no matter what the underlying storage is (though I very much recommend UTF-8 as that is the only storage that can preserve all byte sequences and most outside data is bytes no matter how much you wish it was magically limited to valid UTF-8).

Re:My first question.

[m50d]

People always see different behaviour in different C compilers; the standard simply isn't that strict. Maybe it should be, but if you want that you can use java or D or whatever.

Re:C'mon Python Users tell us why

[binarylarry]

Even naive C++ is much, much, much faster than Python and is even capable of supporting multiple threads.

It's much faster than C# and slightly faster than Java code as well.

Re:C'mon Python Users tell us why

[Anonymous Coward]

>Python

You spelled "Lisp" wrong.

Re:Question

[EvanED]

If C++ is cancer to C's something, that something is also cancer. Or maybe AIDS.

I have a love-hate relationship with C++, but one thing that I more-on-less don't waver on is the fact that I would much rather write in C++ than in C for... basically anything.

Thank you Bjarne

[whiteboy86]

Nothing comes close to C++ in terms of versatility, features, speed and overall professional appeal.

Re:Thank you Bjarne

[betterunixthanunix]

I would say that Common Lisp, with a decent compiler and some attention paid to code efficiency, is most certainly a contender on all of the above. The main selling point of C++ now is habit -- large amounts of existing C++ code and lots of programmers who were trained to use C++.

Re:Thank you Bjarne

[Anonymous Coward]

Professional appeal? Lisp? Yeah sure.

Re:Thank you Bjarne

[Anonymous Coward]

Except Common Lisp is a fucking pain with completely ass-backward syntax. It should die a swift death.

Re:Thank you Bjarne

[Anonymous Coward]

Or the number of ways to leak memory, dereference a null pointer, and create un-debuggable code.

Re:Thank you Bjarne

[Anonymous Coward]

(The ("professional" (appeal (of (forced (parentheses (is (as (bad (as (the (appeal (of (nested quotes))))))))))))))

Re:Thank you Bjarne

[arose]

Yes, it is competitive with C++, I'm not sure why you felt the need to restate this...

Re:Thank you Bjarne

[shutdown -p now]

yeah<i_totally<know<what<you> > > >::mean

Re:Thank you Bjarne

[JesseMcDonald]

Lisp, and functional languages in general, do tend to nest expressions more than imperative languages like C/C++. However, when it comes to nested function calls, the only real difference is whether the opening parenthesis is placed before or after the function name. To use your example, is

(The ("professional" (appeal (of (forced (parentheses (is (as (bad (as (the (appeal (of (nested quotes))))))))))))))

really any worse than this C equivalent?

The("professional"(appeal(of(forced(parentheses(is(as(bad(as(the(appeal(of(nested(quotes))))))))))))))

Common Lisp is no more or less intrinsically readable than any other multiparadigm language I have encountered, including C and C++.

P.S. A more analogous example, given the way the sentence should be parsed in English, would be:

(declare-as-bad-as (professional-appeal-of (parentheses :forced)) (professional-appeal-of (quotes :nested)))

Re:Thank you Bjarne

[mobby_6kl]

"Common Lisp" sounds like a disease, I don't think that's something I could use myself or advocate for use to my colleagues or management.

Re:Thank you Bjarne

[Anonymous Coward]

It's not just habit, it's the lack of an ecosystem. It's a while since I last looked at Common Lisp (maybe a decade) but it was stagnant. It was lacking essentials like bindings to standard GUI toolkits and I couldn't find a free quality compiler. Has anything changed?

Re:Thank you Bjarne

[Anonymous Coward]

Take a look at Quicklisp and the available libraries: http://www.quicklisp.org

In the past years Common Lisp has become quite a lot more popular and many libraries and bindings have been written for about any purpose, including GUI toolkits. SBCL and ClozureCL are two free libre quality implementations with optimizing native compilers.

http://www.cliki.net and http://common-lisp.net are also worth checking out.

Re:Thank you Bjarne

[Anonymous Coward]

I think you are really on to something. But there are a lot more factors then habit that causes C++ to be more popular than CL. For a lot of platforms there isn't a CL compiler or interpreter. We are lucky if we even get a C++ compiler (often it is C only). Also there are a lot more libraries and OS bindings available for C++.

I also think that some of the reasons CL is shunned are the same reasons there is a backlash against C++. There is a large class of programmers that don't want to be bother to learn how to effectively use their programming languages and tools. They would rather end up writing complex code over having to learn about all the language and library features that help keep the code simple. There is a large class of people who use C++ as if it were C, Pascal, Smalltalk, Java. They aren't able to be quite that lazy with Common Lisp.

Re:C'mon Python Users tell us why

[chichilalescu]

I cheat. I write python code that writes its own plain C code, compiles it then executes it. this way, I work once to write a C template, that I then reuse through a high level language. and when I combine the advantages of python (sympy for instance) with the speed of C, I get stuff that is ridiculously faster than what I did before. in the sense that I don't work a lot to write it, and I don't wait around a lot for it to actually run afterwards.
working with numerical simulations, I'm allowed to cheat this way...

New C++ spec....

[kmdrtako]

TL;DNR

Stroustrup C++ 'interview'

[moco]

http://www-users.cs.york.ac.uk/susan/joke/cpp.htm

This one still makes me laugh

Re:Stroustrup C++ 'interview'

[Anonymous Coward]

I was sure it was a joke but actually I was one of those who hoped it was true.

Re:Stroustrup C++ 'interview'

[Anonymous Coward]

To be funny, this parody would need to have some element of truth. The author either doesn't know or doesn't bother to make any connection with the goals or origin of C++. I am not saying it needs to be correct (it wouldn't be funny if it was), just that there needs to be some connection to reality.

Instead this is just blaming the language for the people who don't use it effectively. This could be done for any language, and it still wouldn't be humorous.

Re:Stroustrup C++ 'interview'

[notsoclever]

Sadly, for quite some time people actually believed that was real. I had several well-intentioned friends trying to convince me that I should drop C++ and learn [insert fad language here] because Stroustrup was being evil when he designed C++.

Re:Stroustrup C++ 'interview'

[Anonymous Coward]

If true, I can't help but admire Stroustrup for seeing the big picture. It is a sad world though, that we don't do and make things freely, it's almost all at the barrel of a gun for a company or a government etc.

Borland too

[grilled-cheese]

Borland has also had support for parts of the C++0x spec for some time now.

D is C++ redesigned

[peterhil]

Given all the negative comments about the complexity and misfeatures of C++, I one day decided to take a good look at D programming language.

I know Ruby, Python and Common Lisp, and as I have used Ruby's NArray and NumPy quite much, I appreciate that D language has first class Array objects and vector operations for arrays built into the language. D is also compatible with C and has two-way bridge for Objective-C. The version 2 also supports functional programming.

Overall, D seems to have taken good influences from dynamic programming languages like Ruby and Python.
I wonder why D isn't more popular? Maybe the division of the standard libraries is a big factor?

PS. I have been looking a similar library to NumPy for Common Lisp, but GSLL just doesn't cut it and Matlisp only handles two-dimensional matrices. Of course you can use map, but iterating even slices of two-dimensional matrices with map can be a hassle and is much more verbose than having a good iterator abstraction.

Re:D is C++ redesigned

[turgid]

Someone with a clue!

Re:D is C++ redesigned

[Anonymous Coward]

I like D as well. The elimination of many screwy cases from C++ and ability to just link up with C or ASM object files for speed is very nice.

It takes time for languages to gain followers, tools, maturity and stability. Python was started in the early 90s. Ruby was in 1995. I hope D and Perl 6 both become at least semi-mainstream programming languages.

Re:D is C++ redesigned

[man_of_mr_e]

D is not as popular because it largely only appeals to C++ developers who want a better C++. However, unlike C++, D is not standardized by any standards body, so the language can change on a whim by the author. There is also only one real implementation of D, as opposed by having support by multiple vendors (most likely, this is a function of its lack of standardization. Corporations don't want to take on writing compilers for non-standard languages).

Certainly, lack of standardization hasn't prevented other languages, such as Java in the past, but look what happened there. Microsoft was litigated out of the market, and now Oracle is sueing Google and possibly others. This is not very commercial compiler friendly.

There would likely be questions of intellectual property that need to be answered, and grants or licenses of such IP to ensure that third party vendors won't get sued. Yes, I know they say it's open source, but i doubt it has had a full audit and due dilligence done on whether or not it violates any IP.

Don't get me wrong, what they've done with D has been fantastic. I think Walter needs to seriously consider submitting it to a standards body if he wants to go anywhere with it.

Re:D is C++ redesigned

[man_of_mr_e]

Also, before anyone climbs down my throat about the gnu d compiler and the .net d compiler, these are really just ports of the main D code, not entirely new implemenations. That's what I meant by only one real implementation.

Re:D is C++ redesigned

[ElusiveJoe]

Yeah, like standardization really gave C++ the portability. The standard has enough vague statements to make it a headache to port the code between compilers. Two words: template metaprogramming.

Re:D is C++ redesigned

[jth4242]

There's also, *cough* C# *cough*. Compared to D, its generics are weaker, value types are always PODs and there are no reference return values. Especially the final thing is a shame. Also no const correctness and native C compatibility. It's a lot less, but with its value types and other goodies it's a lot more than Java - both performance- and convenience-wise. I used to be a hard-core C++ zealot, but I have to say - give me reference return values for C# and won't ask for more.

Re:D is C++ redesigned

[Anonymous Coward]

No solid compilers. Last time I looked at it, there was the "official" compiler (which didn't work on 64-bit, and was nonfree), a GCC frontend (which seems to be unmaintained), and a LLVM-based compiler (which I've been told is the one with the brightest future, but which still seems incomplete).

Re:D is C++ redesigned

[Anonymous Coward]

PS. I have been looking a similar library to NumPy for Common Lisp, but GSLL just doesn't cut it and Matlisp only handles two-dimensional matrices. Of course you can use map, but iterating even slices of two-dimensional matrices with map can be a hassle and is much more verbose than having a good iterator abstraction.

I agree with one of the other poster's that D's primary limitation is it's lack of multiple-implementation standardization. I'd also add that the longer D doesn't go beyond a single implementation, without a standardization body, the more likely it is to be surpassed by other languages (especially, especially Go, which is taking off like a rocket: http://golang.org/).

To address your PS, though: I'd recommend this: https://github.com/blindglobe/common-lisp-stat

I admit I haven't tried it, but it has a good heritage (and I've used xlisp-stat a lot).

Re:D is C++ redesigned

[Anonymous Coward]

I wonder why D isn't more popular? Maybe the division of the standard libraries is a big factor?

That's certainly one of the things that has put me off each time I've taken a look at it.

Re:D is C++ redesigned

[darenw]

Yeah, the deuling libraries is part of it. Also, the choice between D1 vs D2, 32 bit vs 64 bit platforms, and some other issues I've forgotten about - these are not orthogonal choices. Only certain combinations of library, 64bit etc exist. My project needed a combination that wasn't available at the time. So we wait...

Re:D is C++ redesigned

[shutdown -p now]

You need to have more than a language spec and a compiler. You need solid documentation. You need good tooling (IDEs, debuggers, profilers etc). You need rich, stable frameworks.

This either needs corporate backing (either direct, like C#, or behind the scene, like Python - so long as money gets in on the right things, it's good. Or it needs a very dedicated and persevering community, and considerable time for them to get to the point where others are interested.

Most of all, the new language doesn't just need to be better than existing offerings - it needs to be so much better that relearning it and dealing with less mature ecosystem is worth it, money-wise.

Re:D is C++ redesigned

[Anonymous Coward]

D certainly gets a lot of things right, but there are some reasons it hasn't caught on. I think someone needs to gather up Linus (whose rants about c++ are famous), a couple of numerical/scientific software wizards, a few of the best of those who've had to deal with designing improvements to the C++, Java, and C# standards, and maybe a handful of others, and lock them all in a room with Walter Bright until we have agreement on a systems programming language which will finally enable us to toss C and C++ to the curb.

Re:D is C++ redesigned

[Anonymous Coward]

C# was designed by the guy who turned Pascal from a hopeless academic basket case into a useful tool for professional programmers.

Microsoft be damned... C# is actually a pretty fucking good language. It does for Java what Delphi and its predecessors did for Pascal.

Re:D is C++ redesigned

[LizardKing]

Standardisation has brought little benefit to C++. If anything, it has codified bad ideas in such a way that they can't be fixed for backwards compatability reasons (see the adoption of the STL for the best example of this, where various areas were simply not well thought out at the time of standardisation). Java on the other hand is not standardised by a independent body, as you point out, but this has not prevented development of alternative implementations - your mention of MicroSoft being "lititgated out of the market" is a misrepresentation, as they deliberatetely set out to create a non-compatible version. As for D, it's fighting against an entrenched predecessor.

Re:D is C++ redesigned

[Randle_Revar]

Now there seems to be major movement in GDC (including maybe going into mainline GCC) and LDC, and of course last summer 2.0 became marked as stable, so things look brighter than they have in the past.

Re:D is C++ redesigned

[man_of_mr_e]

Regardless of Microsft's intentions, it doesn't change the fact that they were litigated out of the market. That is not a misrepresentation, it is what happened in fact. Sun, and now Oracle owns Java and can say what anyone can do with it. With a standarized language, that simply doesn't exist. If i want to create my own version of C++ I can, and it doesn't have to conform to the standard if I don't want it to.

My point is that this kind of freedom is what allows standardized languages to gain marketshare. Wholy owned languages, where someon controsl what you can and can't do eventually die from over-control.

Re:D is C++ redesigned

[Anonymous Coward]

yeah, one thing that still sticks out like a sore thumb (to me) is the insistence on sticking with short,long and "long long". Take a leaf out of the .Net/Java book and call it Int32 / Int64 / Int128 FFS and let us actually see what we're declaring. (/me wanders off and #defines a macro or six)

Bravo!

[Anonymous Coward]

Nothing comes close to C++ in terms of versatility, features, speed and overall professional appeal.

The way you put that, the uneducated reader may have mistaken it for a compliment.

Re:C'mon Python Users tell us why

[binarylarry]

So basically, you get around Python's performance limitations... by using C instead.

Way to go!

Re:C++ has had its day

[msobkow]

Actually I'm looking forward to re-learning C++ after GCC et. al. are updated and the spec is finalized. They've added a great deal to the standard libraries, the syntax, and the collections/containers since I last worked with C++. I've no need for C++ -- it's just something I want to do for fun.

Re:C++ has had its day

[Anonymous Coward]

Please do tell which languages do you believe are "simpler (and arguably better" than C++.

None of your business!

[Chemisor]

Yes, you hate C++. We get it. Instead of complaining about it so much, just don't use it, stick to your own favorite language, whatever it may be, and leave C++ alone. There are plenty of us who love C++ and wouldn't give it up for anything. We mind our own business, write great code, and try to avoid complaining about whatever it is you are using. Please try to do the same.

Re:None of your business!

[betterunixthanunix]

The problem is that C++ dominates the industry; people who want to use a different language, even when they can list every good reason for making that decision, often find that the pressure to stick with C++ is too much to overcome. A lot of people simply refuse to hear the arguments about better languages for a particular project, or are afraid of being unable to find programmers who know something that is not C++ (or similar enough, like Java), or do not want to have to write interfaces for an existing C++ codebase.

Re:None of your business!

[Anonymous Coward]

leave C++ alone.

Oww. Wrong mental image.

Re:None of your business!

[mfnickster]

How fucking dare anyone out there make fun of C++ after all it has been through!?

What you don't realize is that C++ is making you all this money, and all you do is write a bunch of crap about it!

Leave Bjarne alone!! You're lucky he even publishes an FAQ for you BASTARDS!!

Speaking of professionalism, since when is it professional to publicly bash a language whose standard is going through a hard time?

Anyone that has a problem with C++ you deal with ME, because it's not well right now!

Re:None of your business!

[Anonymous Coward]

There are plenty of us who love C++ and wouldn't give it up for anything.

No, there aren't that many of you!

Re:None of your business!

[Anonymous Coward]

There are plenty of us who love C++ and wouldn't give it up for anything.

No, there aren't that many of you!

Yes, there are!

Re:None of your business!

[Threni]

Perhaps you can't understand why there's `pressure` to `stick with C++` but that's just another example of why they're making the decisions, and not you. There are many places where anything other than C++ simply doesn't make sense.

Re:None of your business!

[Anonymous Coward]

Yes, you hate C++. We get it. Instead of complaining about it so much, just don't use it, stick to your own favorite language, whatever it may be, and leave C++ alone. There are plenty of us who love C++ and wouldn't give it up for anything. We mind our own business, write great code, and try to avoid complaining about whatever it is you are using. Please try to do the same.

You know, I completely agree with this. C++ is my primary language, I do use several others at times, but I don't sit here and bitch about other languages all day. Nobody I know that likes C++ does.

Re:None of your business!

[FlyingGuy]

There are many places where anything other than C++ simply doesn't make sense.

Example Please.

The entire Linux kernel is written in pure C. Just where and in what circumstance are you talking about?

Re:None of your business!

[Anonymous Coward]

How is that relevant? Nobody uses C++ for OS kernels. Linux is using the standard language for the job. That is what one would expect.

Similarly, nobody of interest uses pure C for video games. Outside the niches where other languages have some limited use, everyone in the professional game development industry uses C++. If it made sense to use other languages, you might think they'd consider it. Seeing as how they are sticking with C++ and they are among the most profitable parts of the software development world, it is not reasonable to wonder whether C++ might just be appropriate to their needs?

Re:None of your business!

[Anonymous Coward]

I know it's old, but Quake 3 uses plain C.

Re:None of your business!

[thoughtsatthemoment]

There are plenty of us who love C++ and wouldn't give it up for anything. We mind our own business, write great code.

I believe some of you are indeed doing a good job with C++. But, everyone uses C++ in a different way so you can't really speak for "C++ programmers". The OP could be a C++ programmer too.

The strong feeling against C++ is mostly because of maintenace. Each C++ feature is actually useful in some way and programmers who are learning and/or don't know how to do the same thing in plain C would almost always fall in love with it. The end result is a code base very hard to maintain. At least in my workplace, those who enthuisatically introduced fancy C++ features already quit the comany, leaving behind a pile of crap for others to digest.

Re:None of your business!

[ibbie]

How is that relevant? Nobody uses C++ for OS kernels.

That's not quite true. But close.

Re:None of your business!

[jsprenkle]

I've found that people who want to use a different language do exactly what you've said. They list every reason why they should switch. Unfortunately they do not also list every reason why they should not switch. Then they get mad when nobody will listen to them. There's also nothing specific about C++ in this argument. I've heard the same argument for other languages and for rewriting the applications in the same language. Many programmers ignore sound business decisions because they don't bother to try and understand them or think they're protecting their livelihood

Re:None of your business!

[betterunixthanunix]

There are many places where anything other than C++ simply doesn't make sense.

Can you name one that is not as trivial as, "You have a large legacy codebase written in C++ that you are maintaining and extending?"

Re:None of your business!

[Anonymous Coward]

Interesting that you take it personally.

Re:None of your business!

[Anonymous Coward]

>The problem is that C++ dominates the industry
So ask yourself why ;)

Re:None of your business!

[jgrahn]

The problem is that C++ dominates the industry;

Which industry is that? Around me it's 95% C, or else buy into the .NET or Java franchises. I'm being told C++ is gaining ground in embedded systems, but I've not seen any proof of it yet.

people who want to use a different language, even when they can list every good reason for making that decision, often find that the pressure to stick with C++ is too much to overcome. A lot of people simply refuse to hear the arguments about better languages for a particular project, or are afraid of being unable to find programmers who know something that is not C++ (or similar enough, like Java)

Ugh. Java is nothing like C++, except they both use a C-like syntax.

But you're right in at least one sense: some tasks are much better suited for languages like shell script or Python.

Re:None of your business!

[jgrahn]

There are many places where anything other than C++ simply doesn't make sense.

Example Please.

Large, long-lived applications which need to work properly and need to be maintainable, and have programmers come and go over time.

You need (IMO) static typing for this, which disqualifies most popular languages. You also need a well-known language, and you probably don't want to rely on Microsoft or Oracle not screwing you over. That leaves C and C++.

The entire Linux kernel is written in pure C.

I attribute that to some weird mental block shared by Linus and many other Unix hackers.

Re:None of your business!

[Threni]

Android games is another one. You need C/C++ for speed, and if you're going to use C you might as well use C++ and take advantage of classes.

I don't need to provide any more - it's obvious. You use it when it's the best tool, so perhaps you'd want to write something but java or .net would result in code that's too large or slow, or perhaps you want your code to run as a service, or compiled into .exes (both of which are only available as ugly hacks in Java), or you're doing some embedded coding, or a bios, or a device driver, or.... you get the idea.

You can't criticize C++ just because it's not used in the Linux kernel. You use the best tool for the job, plus you have to factor in what would happen to your code if you switched to another language. It's Linus's shout.

Re:None of your business!

[Twinbee]

Which is why language features should always be unified as much as possible to reduce the bloat. I always find it dumb the way many say: "you can do it this way, or that way, or the other way - such-and-such language gives you the choice - how wonderful!" without considering that there might be a way which takes the best of each of the approaches, and unifies them into one consistent approach.

Similar story to the way many open source projects get forked (which can be okay for experimentation purposes in the short term), and never reunify again later. It's a shame.

Re:None of your business!

[Anonymous Coward]

There are many places where anything other than C++ simply doesn't make sense.

Example Please.

Large, long-lived applications which need to work properly and need to be maintainable, and have
programmers come and go over time.

You need (IMO) static typing for this, which disqualifies most popular languages.
You also need a well-known language, and you probably don't want to rely on Microsoft or Oracle
not screwing you over.
That leaves C and C++.

There is also Ada. And IMHO it is way much better suited for "large, long lived applications which need to work properly and need to be maintainable, and have
programmers come and go over time".

Re:None of your business!

[russotto]

I believe some of you are indeed doing a good job with C++. But, everyone uses C++ in a different way so you can't really speak for "C++ programmers". The OP could be a C++ programmer too.

Of course I am. You can acquire a distaste for C++ as a non-C++ programmer (a C programmer in my case). Even a certain apprehension about it. But to really hate it, you have to work with it. The horrid syntax. The features that almost-but-not-quite do what you want, and occasionally blow up in your face. The opaque error messages (OK, maybe that's more the compiler's fault than the language, but still...).

It's templates I pick on the most, because using their full power always requires almost-incomprehensible hacks. But probably the worst gotcha is temporary object creation. You can end up with objects being created and destroyed at all sorts of unexpected times. And thanks to RVO/NRVO, it's not always obvious when that _won't_ happen.

Re:None of your business!

[t2t10]

We mind our own business, write great code

Actually, people like you write crappy code, create buffer overflows, fill up memory, and bring everybody's computers to a crawl, and you are so inexperienced, you don't even realize it.

Re:None of your business!

[t2t10]

Static typing is nice but not essential if you have decent unit tests. Much more important are type safety, fault detection, and fault isolation, and C++ lacks those. There is no way you can reliably recover from a runtime error in C++. That makes C++ an extremely poor choice for any application where the results are important.

Ideally, you want a statically typed language with type safety, fault detection, and fault isolation. Java and C# give you that, albeit they have practical problems.

The next best practical thing are dynamically typed languages with type safety, fault detection, and fault isolation, and there are a bunch of those around.

C/C++ are only reasonable choices if (1) performance is more important than correctness and reliability, and (2) you have a large supply of extremely smart, patient, and experienced programmers and no deadlines.

Re:None of your business!

[Anonymous Coward]

As I'm looking for work, I'm finding far more Java positions than C++...

Re:None of your business!

[benhattman]

Static typing is nice but not essential if you have decent unit tests.

After all, why would anyone ever want the compiler to do this work for them when they can just separately maintain a set of tests which do the same thing?

Re:None of your business!

[GooberToo]

Really, Android is a type of embedded system and C++ is gaining ground there.

I've also used C++ in several telcom embedded projects. Ironically, many of C++ features which have kept C++ out of these embedded projects because of memory footprint and CPU overhead are exactly why they are causing C++ to gain ground now that memory and CPU is far less of an issue. Exceptions are a superior error model.

Ugh. Java is nothing like C++, except they both use a C-like syntax.

I agree. While people love to bitch about C++, as someone who has worked a fair bit with Java I can honestly say, its pretty clear the creators of Java had little practical OO experience and created it from a purists' perspective. In the real world, no one does pure-OO. Java fails miserably at coming even close to pure-OO but they painfully make you aware it was their goal during its design.

Without fail, Java requires all the tedium of C++, and in some cases even more so, with very few of the advantages.

Re:None of your business!

[t2t10]

After all, why would anyone ever want the compiler to do this work for them when they can just separately maintain a set of tests which do the same thing?

You rarely need to write separate unit tests to check type correctness; other unit tests give you that for free, so there is essentially no extra work involved.

And why would you want to use a dynamically typed language and rely on unit test for type checking? While static type checking for 1970's style Pascal-like languages is simple, but static type checking for modern programming languages comes at a high cost: complex type systems, odd restrictions on language constructs and programs, bad compiler error messages, etc.

Constructors should have names

[Anonymous Coward]

We need to be able to write &T::T, just like we can do &T::somemethod and finally build dependency injection in C++.

Re:Constructors should have names

[shutdown -p now]

In C++0x, you can just use lambdas for that. Or if you insist, you could use variadic templates to implement a function that'd take a type, and return you a function object that is a factory for that type, for a given set of ctor argument types.

Re:Constructors should have names

[mbkennel]

"In C++0x, you can just use lambdas for that. Or if you insist, you could use variadic templates to implement a function that'd take a type, and return you a function object that is a factory for that type, for a given set of ctor argument types."

Fascinating.

Suppose, instead, constructors had names?

Re:Constructors should have names

[shutdown -p now]

Did you see the backlog of C++ ISO working groups? There's too much crap there already, so much so that they didn't even do half of what they wanted for C++0x. At the moment, simple syntactic sugar - especially when there is a library solution that is pretty much just as concise - is not exactly high on the priority list.

Nonetheless, if you think that this is a feature that would benefit C++, write a proposal and submit it to the WG. That's how every new feature in C++0x started its life.

Re:Clearly...

[Chemisor]

Clearly we see something about it you don't. You are welcome to love your "interesting modern languages", while we love our C++. We certainly have no obligation to help you with yours.

Re:C++ has had its day

[turgid]

Scheme, Java, Ruby, Python, D, C.

I can't understand why anyone would start a new project in C++. The only reason anyone could seriously consider it is if they have to maintain or enhance an existing C++ code base.

Re:Question

[Anonymous Coward]

I think you can easily determine the competence of any programmer by how much they hate their primary language. I've never seen this rule fail when it comes to C++. Almost every expert modern C++ programmer I've met thinks C++ is unsurpassed in a few important areas - yet they can bitch about the language for as long as you keep them talking.

Nice!

[friedmud]

As someone who spends all day developing a C++ library for massively parallel engineering simulation.... I'm really excited about this announcement. My team has played with some of the early C++0x features in Intel's compiler and GCC and we're definitely going to be adopting a few of them, but can't commit ourselves until they are a bit more universally available.... which now, they hopefully will be.

C++ certainly still has it's strong points over many other languages... especially when you need that cross section of good OO design and performance (like we do). There are many things I love using Python for but there a also a TON of times I need complete control over everything in order to get the most out of the machine I'm using.

Re:Nice!

[Anonymous Coward]

There are many things I love using Python for but there a also a TON of times I need complete control over everything in order to get the most out of the machine I'm using.

You already mentioned C++ and Python, so which language do you use for that?

Re:Nice!

[VortexCortex]

Machine code. It's not as difficult as you think, I have a bunch of macros and a program that just reads in the macros and outputs the machine code. I modify the macros for each hardware platform -- Our "cross-compile" process scales in O(n) time!

I scoff at Assembly Language programmers because they have to use a "compiler" which frequently doesn't support every op-code/instruction the machine has to offer. The instructions are just sitting there, wasting power unless you use them!

In C or C++, Python, and even higher languages there is no telling what the assembly is going to look like, and thanks to their crappy "cross platform" compilers there's plenty of opcodes that they rarely (if ever) take advantage of anymore, esp. in the x86 set...

Hell, "modern" compilers are so terrible at using the best op-codes that some hardware MFGs are starting to microcode some of the instructions that they rarely use (the ones I use for performance!) -- Some new "high-end" systems run our programs slower than our current hardware thanks to op-code neutering microcode, that's one of the main reasons I laugh at "modern" hardware salespersons...

If you want complete control, there's nothing like machine code. If we used a higher level language, any wet-behind the ears Java developer could take over MY projects! Then we would HAVE to upgrade just to get decent speeds.

Talk about job security... "Compiler", "Assembler", "Linker", HA! I'll be irreplaceable till I'm dead!

Re:Nice!

[shutdown -p now]

I'm also on a team that does a lot of C++ development (mixed with C#), though nothing nearly as cool as your description. Anyway, we've been picking up new features slowly but steadily, and it seems to be working out well. Start with small things such as using nullptr, and std::unique_ptr instead of std::auto_ptr, and new container types. Then come lambdas. Then finally some crazy TMP madness with decltype (where that is warranted).

Re:Nice!

[osu-neko]

I've never seen an assembler that didn't permit the use of every single possible bit of machine code. Granted, sometimes you needed to make a macro, but that sounds like exactly what you said you're already doing.

Re:C++ has had its day

[Anonymous Coward]

You're right. Like back to C or pure assembler.

++curmudgeon;

[mpaque]

Ah, it's articles like this that make me so glad I'm retired!

C++ programmers have it too easy. Why, in C we had to code our own bugs. C++ programmers just inherit them!

Re:C++ has had its day

[betterunixthanunix]

I can't understand why anyone would start a new project in C++. The only reason anyone could seriously consider it is if they have to maintain or enhance an existing C++ code base.

While I agree with the sentiment, the reason people keep using C++ is pretty clear: habit. Everyone knows C++ or some very similar language, there is a lot of legacy C++ code, and people are still being trained to write code in C++ (or some similar language). If you were starting a new project and you said, "Let's use Scheme," half the people in the meeting would say they had never written a single Scheme program, and that they did not have time to learn it, and that it would be easier to just use C++ (or something similar). You could list every technical advantage that Scheme has over C++ and it would not make any difference.

Do not underestimate the friction that you face when it comes to C++ and similar languages.

Still no designated initializers

[Daniel Phillips]

Some monster warts not addressed, like no designated intializers, no flexible arrays. Some backwards progress like the idiotic narrowing errors in cases like { 1, 2 } for an array of floats. But in general, a better language, I switched to -std=gnu++0x a few months back.

Re:Still no designated initializers

[mmcuh]

By flexible arrays, do you mean the variable-length arrays from C99? There is really no reason to use arrays in C++. For resizable containers you have std::vector, for fixed-size ones there is now std::array. Access times and cache properties are identical, since both of them are specified to store the data as a contiguous array internally. They don't have the stupid special problems that raw arrays do (can't be copied or assigned to directly, quietly decay to pointers when used as function arguments) but you can get raw arrays from either of them for when you need to interface with C APIs. Designated initialisers would have been nice. I miss concepts more though, but variadic templates more than make up for that.

Re:Still no designated initializers

[Anonymous Coward]

Arrays serve as a fundamental basis for a number of custom and standard conainers, including std::vector -- I agree that you should generally not use them directly. Variable-length arrays would allow you to allocate on the stack, which seems like it could be useful in some situations. I wonder what Stroustrup's aversion to them is? From the FAQ:

"Not VLAs (Variable Length Arrays; thank heaven for small mercies)."

Fortan has had them since 1990 and the C community obviously seems to think they have some use. I tend to think it's the best way to grap a chunk of temporary memory for HPC work.

Re:Still no designated initializers

[Daniel Phillips]

I did indeed mean flexible arrays. I did not know about std::array, maybe it really is always better than classic C arrays. But I am skeptical, I will try it and see. In any case, there is no plausible excuse for not supporting variable arrays, especially in their role as function arguments. They are required for C99 anyway, which typically uses the same back end as C++.

Re:Still no designated initializers

[Daniel Phillips]

I use them for a number of applications including 3D rendering and 2D filtering. In C++ such code gets ugly fast if you have to compute multidimensional indices by hand. Even buried in helper methods its still ugly and less maintainable than the C incarnation. I typically write code like that in C and call it from C++. This introduces its own awkwardness.

Re:Still no designated initializers

[shutdown -p now]

Yes, VLAs are useful to get the extra perf edge from stack allocations (and consequent lack of deallocations). The problem is that naively specified VLAs make the type system very messy, as evident in C99. Nor are they trivial to use; I mean, take C99 again:

int foo(int n, int a[n]);
...
int a[3];
foo(sizeof a, a);

Looks good, but there's absolutely nothing preventing the caller from passing in a wrong size - it's just U.B. if he does. So for VLAs the size of array is not part of the type, despite it being right there in the declarator. And yet it's magically tied to the array in question, since you can do sizeof(a) etc.

For C++, there has been some talk for adding a VLA-like type to TR2 (which will come after C++0x is finalized). The idea is to make it a library type, std::dynarray, somewhat more constrained than vector (e.g. no resize or operator=), such that the compilers would be able to implement it as VLA as a matter of quality-of-implementation. So someone (say, Boost) can provide a pure library heap-allocating version as a universally supported baseline, and then specific implementations can optimize it to their heart's content.

Re:Still no designated initializers

[maxwell demon]

Some backwards progress like the idiotic narrowing errors in cases like { 1, 2 } for an array of floats.

They actually disallow implicit int to float conversion here?
Heck, even Pascal allowed that conversion!

Actually I thing the conversion restrictions for new style initializations are wrong, despite the fact that I'm generally for more strict conversion rules (but not more strict than Pascal, mind you); but restricting them in such limited context breaks orthogonality.

Re:Still no designated initializers

[LizardKing]

There is really no reason to use arrays in C++.

Err, how about for performance? Especially seeing as that's one of the supposed reasons for wanting to use C++ over a better^W simpler language.

Re:C++ has had its day

[turgid]

You're right. Like back to C or pure assembler.

Indeed. There's so much you can do with well-written C and good libraries quicker, more reliably, more simply and much more efficiently than in C++.

With C you have a chance of being able to read and understand your source code 6 months after you wrote it. The syntax is relatively clean, If you're into syntax-highlighting editors, they usually get it right.

There aren't the ABI headaches that come with C++. The compiled code is smaller and faster.

C can fit inside your head. Unless you have an IQ of 250 and infinite time, you are never going to learn enough of C++ to become an expert.

C programs are more likely to run correctly.

Don't get me started on C++ references and const....

I write C++ when I am paid to. I write everything else for fun (mostly C and bash).

Re:Clearly...

[giuseppemag]

Yes, because the world needs more segmentation faults. And BTW I have been forced many times to use C++ in my work. I know a shitload about it, especially the various tricks about the template system; the removal of concepts from the standard proves that C++ is, has always been, and will always been a mismatched bunch of tricks held together with duct tape.

Of course you are entitled to your opinion; I know many great programs/programmers exclusively made/working with C++, so I am not implying that the language forces bad programs or diseducates developers. Unfortunately I believe that the absence of a clean idiomatic C++, the proliferation of more or less incompatible coding styles, the confusing compatibility with C (C++ is often used as "C with classes") and the excessively small standard library (I believe that anything found in Boost should never be removed from the language) make C++ an ugly creature. Once again, though, great and fast programs have been made with it, so I understand how many developers might love the feeling of power and control that C++ gives with respect to safer but more constrained languages such as C# or Java or even further ML or Haskell...

Re:C++ has had its day

[EvanED]

Just to play devil's advocate, I'd like to argue for C++ a bit. I don't completely buy my arguments here, but at the same time, I don't think it's ridiculous to use C++ for some stuff, and for some rare projects, it's a decidedly reasonable choice.

C++ sits in an area that is reasonably unique amongst languages. It is very performant (unlike Scheme, Ruby, and Python), but it also has an ability to support very rich abstractions (unlike Java and C). What other language doesn't not give you closures, but yet gives you enough syntax to make an approximation that is even as close as, say, boost::lambda? There's no reference counting provided by the C++ runtime, but it gives you enough tools that you can build your own reference counting.

There are very few languages that can claim both the speed and flexibility of C++. The only one that would be familiar to most programmers is D -- and the tool support there is not exactly stellar. About the only other languages I would say has characteristics comparable to those are Common Lisp and Haskell.

As a final point, I find it interesting that you put C into your list. If you said "I want you to do this project, and you can pick between Java and C++" or "between Python and C++" I'd have to ask for more details first, and think about it. I think I disagree with a lot of people on this point, but if you gave said "you have the choice between C and C++", I'd pick C++ in an instant with almost no qualifications. Yes, C is simpler than C++ -- but I don't think it's worth it. RAII alone is enough of a killer feature to mean that I will likely never choose plain C for any project where I have any freedom in the matter.

Re:C++ has had its day

[Daniel Phillips]

Almost any computer language is simpler than C++. If you don't know that, you haven't explored it much. As for better... well I have switched pretty much exclusively to C++ now. Love, hate.

Re:C++ has had its day

[euroq]

Agree 100% with your post.

Although technically you simply cannot do many types of programming projects with most of those languages because they are not systems-level like C/C++ are. So one may argue that those languages can't be compared to C++... except for one: D, a vastly superior language to C++ and which is also systems-level.

Re:C++ has had its day

[turgid]

Do not underestimate the friction that you face when it comes to C++ and similar languages.

I was in exactly this situation this week on a training course where we had ~12 hours to do an entire project.

We had 1 non-programmer on the team (of 6), one "software architect" and the other 4 of us were "software engineers." 4 of them wanted to use C++. I convinced them to do it in bash. Only one had sort of done some bourne shell a long time ago.

We got it done, and it worked. If we'd done it in C++ I dare say we'd still have been struggling to get it to compile by the deadline.

I organised things and coached them. They were impressed, and very surprised at how simple it turned out.

Re:C++ has had its day

[Anonymous Coward]

If you were writing an triple-A game from scratch, including a new game engine and tools and targeting multiple platforms, the most likely language would be C++. Garbage collected bytecode languages are too slow, while C does not provide adequate support for programming in the large.

Re:C++ has had its day

[turgid]

C++ sits in an area that is reasonably unique amongst languages. It is very performant (unlike Scheme, Ruby, and Python), but it also has an ability to support very rich abstractions (unlike Java and C).

True, but it hasn't been done at all well in C++. That's why I said that C++ had to happen so that people could see which ideas would work and which wouldn't.

I'm not at all convinced by these arguments. I'd much rather write performance-critical code in something like C, and the clever stuff in a much higher language.

For a trivial and contrived example, I get a lot done on my personal projects in C and bash.

I've used PERL, looked at scheme, python and ruby. I've done a bit of Java, and for quickly hacking together OOP stuff, I love it. It's so easy, it's wonderful.

I've had to learn a lot about C++ for my work. Luckily, I only have to use it mostly for writing unit tests, but some of our code base is in (not very pretty) C++ hacked together in a hurry.

Sometime soon I will try writing some D. I've done some background reading, and I really like what I see so far.

Your devil's advocacy is dutifully acknowleged.

ANN: The++

[Anonymous Coward]

After years of work, we are pleased to announce the++, a successor to the hugely popular english determiner "the". Although many people in recent times have been happy to use "the" as a determiner, we have worked hard to extend the semantics into verb, adverbial and noun forms. Thus; The the the the.

We have strived to create a professional and expressive tool and sincerely hope that english speakers and writers alike will get as much pleasure from using the++ as we had in creating it.

In closing, the++ allows the the the and the the. It is the correct the the the if the the the the clearly understood.

Re:C++ has had its day

[jopsen]

It's time to move on.

If you want to write efficient code (have control of all allocations, etc) with some OOP sugar, C++ is a fairly decent choice...

And with some coding guidelines, C++ is not bad for application development either... I would rather use Qt/C++ than C#/Windows.Forms for GUI applications... Mainly because of Qt though, but C++ is not dead... It's a perfectly fine tool for many projects... Choose a tool that is right for the job...
And C++ is certainly still an important tool, what other well established fairly-low-level languages with OOP support do you find ?

C++ is the worst lang except for all the others

[Anonymous Coward]

I hate C++. I have so many objections to it that I can't even list them here reasonably.

However, there is nothing that can replace it. Everything fails on some account or another. C++ lets you have high level power without sacrificing extremely low level control. No virtual machine, sandbox, or GC'ed language can do that.

So yes, it's a horrible language. But yes, I'm on a team writing an OpenGL based game engine, and we're using C++, because it's the only reasonable choice. We need exact control over bitfield layouts, we need inline assembly, we need good GL bindings, and so on.

Re:C++ is the worst lang except for all the others

[narcc]

I hate C++. I have so many objections to it that I can't even list them here reasonably.

However, there is nothing that can replace it.

Nothing ... except for C

Re:C++ is the worst lang except for all the others

[m50d]

Have you thought about multiple languages? You certainly need something C-like for your low-level parts, and assuming you're writing something complex you'll need a language with high level abstractions. But there's no reason these have to be the same language. (And frankly C++ isn't high-level enough; writing e.g. game AI in C++ is enormously painful)

Re:C++ is the worst lang except for all the others

[jgrahn]

So yes, it's a horrible language. But yes, I'm on a team writing an OpenGL based game engine, and we're using C++, because it's the only reasonable choice. We need exact control over bitfield layouts, we need inline assembly, we need good GL bindings, and so on.

Too bad that C++ has none of those things. You're programming in Visual C++ X.Y for x86, or something. (For bitfields, I bet you can replace those with a class containing an uint32_t or whatever, and a set of inlined functions. Unless that inline assembly forces you to disable the optimizer ...)

Re:C++ is the worst lang except for all the others

[maxwell demon]

C cannot replace C++. You don't want to do manual resource management everywhere.

And yes, C++ does provide automation of memory management. Not GC, mind you, but RAII and a set of standard library classes which cover the most important cases.

Re:C++ has had its day

[gmueckl]

Neither Java, Ruby nor Python are true contenders to C++ when it ever comes down to raw performance. They are surely more elegantly designed languages, although they have their own sets of flaws. D is an interesting language with many good ideas, but there's no decent IDE support for it and there's the standard library confusion as well (and the incompatibilities between D1 and D2). Once compilers like GDC are mature enough it'll actually be usable for serious work.

Well, C is sort of fine if you stick to really procedural code and don't do things like reinventing OO like gtk+ does (I hate that). And I really can't say anything about Scheme.

Bottom line; There's a place for C++ in between all of these languages you name: C++ programs can be amazingly fast if done right (no virtual machine and more importantly, no GC getting in the way at exactly the wrong time) and easier to get right than equivalent C programs if you're able to sacrifice some performance - you're able to do that in 90% of your code on average).

Re:C'mon Python Users tell us why

[Lord Crc]

So basically, you get around Python's performance limitations... by using C instead.

It's a very nice idea which brings the best of both worlds. FEniCS, an open-source finite element framework , uses pretty much the same technique to allow one to set up the simulation in Python, yet get the speed of hand-optimized C++ code.

And using Python capabilities one can write code which is much closer to the underlying math, which significantly improves the usability. Here's the core of an example using FEniCS:

V = FunctionSpace(mesh, 'CG', 1)
 
# Define variational problem
v = TestFunction(V)
u = TrialFunction(V)
f = Constant(-6.0)
a = inner(grad(u), grad(v))*dx
L = f*v*dx
 
# Compute solution
problem = VariationalProblem(a, L, bc)
u = problem.solve()

When calling solve() the problem is converted to C++ code, compiled as a module, imported and executed, all on the fly. The C++ generator can optimize for special cases, for example in the code above it knows that "f" is a constant function.

Why treat everything as a nail when you don't have to?

Re:Yay for C++ 0x7DB; // FTFY

[VortexCortex]

Enough said!

-Chris

Incorrect. The year 2011 A.D. is 7DB Hexadecimal A.D. Ergo, if you're going to abbreviate the numeral using the last two digits you should be heralding C++'DB or simply shorten it to C++'B.

Note: Due to the fact that legacy versions are abbreviated as YEAR mod 100 in radix (base) 10, the new hexadecimal notation should include the a prefix or suffix indicating the radix in use. For quite some time there has existed such a hexadecimal radix prefix in C and C++: 0x

Thus:
Hurray for C++ 0xB;
(Also note the above line does not parse as valid statement in C++, even though the ++ operator actually does take a dummy int parameter as the right-hand-side to differentiate it from the ++C; prefix increment operator.
operator++(int){ /* WTF! */ };

For meatball's sake people, even the ++ operator is a kludge in C++? ( "C++" translates to "C (with kludges)" to me.)

Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception? Should I wrap all such statements in a try / catch block!?) If you haven't studied the entire inheritance graph of the type that the C variable is declared as, there is really no way (beside a debugger) to know what will happen next. (What if a pointer is to a polymorphic class? *my_ptr->operator++(42); Now, it's not supposed to do anything with that "dummy" 42 value, the base type doesn't but a subclass might...)

Don't get me wrong, I code in C++ every day, and prefer it to C, but it surprises me just how messed up things have been allowed to get because we're shoe-horning in features into an existing syntax instead of just creating a new language that has less kludges.

int main() {
int my_var_a( 1 ); //Constructed an int "object" by calling it's "constructor"
// ^^^ Uh.. OK ints are object-ified now.
int my_var_b(); // DOES NOT call the int object's empty constructor.
my_var_b = 10; // ERROR, the previous line declares a function.
return my_var_a;
}
^^^^^^ Declares a new function in the function/method body WTF? (because C lets you do that, for better or worse... )
use: int myvar; to "instantiate" a new int "object" using the empty constructor instead... So, why can't I subclass an int? class my_number : public int { ... }; ARGH.

Look, it's clearly time to stop hacking extra features into the language, or stop letting it be hindered by legacy C conventions / syntax. I think that C++ could be much better than it is if it weren't pandering to C coders... It's too bad that we started down that path with C++, there's far too much time and energy invested to reboot it now.

I'm glad for some of the new C++ features, but at this point there's not much to celebrate for me -- Doing without for so long has caused us to create our own systems: the C++0x garbage collector is incompatible with my multi-threaded hybrid strategy (pool / slab & heap-like) memory manager (thank Spaghetti Monster, theirs is optional), I already have a ton of code that uses my cross platform multi-threading libraries, we've been using a HashContainer for over 10 years in our company...

C++0x7DB adoption to us means: "Oh great, they finally got around to standardizing all these things we've needed for years and made ourselves -- It's going to be a headache writing new code that conforms to the new standard while remaining compatible with our current code-base."

(And there was much rejoicing: "... yay... ")

Re:C++ has had its day

[tuffy]

I'm not at all convinced by these arguments. I'd much rather write performance-critical code in something like C, and the clever stuff in a much higher language.

I've also had quite a bit of success with this approach. For my programs, there's a small kernel of operations that need to be really fast, while the remainder is either limited by disk speed or not executed that often. By implementing the stuff that needs to be fast as C modules, I gain a massive speed boost without adding lots of complexity to everything else.

Starting with some high level scripting language and working down to low level is also a nice way to get a functional design up and running first before concentrating on making it fast.

Re:Clearly...

[betterunixthanunix]

I would agree with you...if people were willing to not use C++ when another language is a better choice. Unfortunately, all too often people refuse to write code in a language other than the one they were trained to use, and too many people are trained to use C++. It is fairly routine for an early design meeting to go like this:

"Let's use [insert non-C++ language], since it is the best fit for this project."
"Wait a minute! I don't know that language, and I do not have time to learn it! Nobody except for you has ever written a program in that language! Let's just stick with what we know!"

C++ and friends (mainly Java and C#) are routinely chosen out of habit, and the result has been an industry that has been very slow to move on to more modern (and simply better in some cases) methods of programming.

Re:Yay for C++ 0x7DB; // FTFY

[EvanED]

Also note the above line does not parse as valid statement in C++, even though the ++ operator actually does take a dummy int parameter as the right-hand-side to differentiate it from the ++C; prefix increment operator.

My mnemonic for remembering which version of ++ takes the dummy int is that postfix ++ is "ugly" in the sense that you shouldn't use it*, so the postfix ++ operator takes the ugly dummy int.

This doesn't justify the syntax which is admittedly horrid, but maybe it'll help people who have this problem.

* Take "you shouldn't use postfix ++" with a small grain of salt, though I do mostly believe it. With rare exception, I really really dislike increment operators mixed in a larger expression, which means with rare exception they are standing on their own, acting as statements. And in that context, prefix and postfix ++ do the same thing, and you should use prefix for the traditional efficiency arguments.

Declares a new function in the function/method body WTF? (because C lets you do that, for better or worse... )

What I like best about that is the standard's rule "if a statement can be interpreted as a declaration, than it is" rather than making declarations actually look different from statements. That's pretty awesome.

Re:C'mon Python Users tell us why

[Anonymous Coward]

and slightly faster than Java code as well.

Can java pack mmx registers now? I'm highly dubious of that.

Re:C'mon Python Users tell us why

[Anonymous Coward]

Um, that's what serious programmers do. Have always done. C#, Java, Haskell, Python - if it's a serious language it allows calling exported functions from shared libraries. There's no silver bullet language, and using 1 bottom-tier language for all your code is masochistic. GP's project would be as speedy as yours, way smaller, written in 1/5th the amount of time.

Self-compiling C code is... eh, questionable though, even with the "tiny" C compilers out there. Good for quick prototyping I guess.

Re:Question

[OeLeWaPpErKe]

And isn't it ? Sure, it suffers from feature bloat - to say the least. And it suffers from a lack of a coherent structure of libraries and tools - it's nothing like java. But if you want to combine high-level programming with access to low-level features. There are C++ operating system kernels that actually use the boost and/or standard libraries. You could even make the claim that a C++ program, like a C program *is* a kernel, in the sense that it can start meaningfully on bare metal (this requires 2 things for a language : being compiled, and no "runtime" that needs to be started and has all sorts of weird startup dependencies). This means it works with C (but only if you are extremely careful) and C++ (again, you can make a few stupid mistakes, but it can work)

Try doing that with Ruby, Java or PHP.

Is C++ like the Eastern Roman Empire?

[Anonymous Coward]

Bell Labs is gone, and the two most popular variants of Unix aren't officially Unix, but C++ lives on. Embedded in the name is the quirky operator that Dennis Ritchie invented some 40 years ago, as a way of shaving a few instruction cycles in inner loops from a high level language.

Re:Is C++ like the Eastern Roman Empire?

[larry bagina]

Actually, the two most popular Unix variants -- OS X 10.5 and 10.6 -- are officially Unix.

Yawn. Shrug.

[terjeber]

'nuf said.

Re:C++ has had its day

[tyrione]

Actually I'm looking forward to re-learning C++ after GCC et. al. are updated and the spec is finalized. They've added a great deal to the standard libraries, the syntax, and the collections/containers since I last worked with C++. I've no need for C++ -- it's just something I want to do for fun.

Have at it. If I have to use C++ I'll stick to LLVM/Clang/LLDB/Libc++

Re:C'mon Python Users tell us why

[SerpentMage]

I call BS!

Ok here is the deal in very very simple examples C++ is faster. Namely because you can override the safety nets. For example if I access memory using pointers. BUT if I add bounds checking, and other things that C# gives me C++ is not faster. I write MonteCarlo code in C# and have found there are things you do and don't do in C#. If you stick to those things there is absolutely ZERO advantage to C++. In fact I found that if you are very careful you can almost match raw C++ (about 10% slower). Remember the real problems in C++ are not the structural things, but the wennie that allocated memory incorrectly writes over a single byte that is used 1,000 cycles later...

What gets my goat with C++ is that I have seen this debate before. Namely I used to write Fortran code in University (hated every moment as I wanted to write C++). And in those days Fortran blew the doors off C++. But with C++ you got many things that were just downright painful in Fortran. Well we are at the same moment in time with C++.

Anybody who starts a new project in C++ is really missing the boat. There is zero reason to use it unless you are doing very low level things. If you understand what is fast and slow in Java or C# then those languages are perfect.

Re:C++ has had its day

[Anonymous Coward]

Please do tell which languages do you believe are "simpler (and arguably better" than C++.

error:Unexpected end of line.

Legacy customers

[AnotherScratchMonkey]

Now the problem is to wait for one's customers to move to the latest compilers that support this. Having a big customer that uses Visual Studio 2005 can be a headache when you want to use a new feature in your tools.

Re:C'mon Python Users tell us why

[emt377]

That's very interesting. To elaborate on your post, I think it would be very useful to have a native python compiler backend that's fed an RTL-like intermediate structure. Out comes a blob of machine code with a module interface. It doesn't have to be quite as low level as GCC RTL, but could be something closer to C++ with typing, function names, variable names, etc, so closer to the front end. (It could be expanded to GCC-like RTL in a first step of course.) Hooks could be used to apply application-specific optimizations. It should be quite possible to use gcc as a starting point for this.

Re:Question

[TheRaven64]

C is a good low-level language. If you are not addressing a problem that requires a low-level language, then you should not be using C. C++ manages to combine all of the disadvantages of a low-level language with all of the disadvantages of a high-level language.

Re:C++ has had its day

[neokushan]

^ this

A lot of people seem to be very black-and-white when it comes to C++. Some love it and think it's the best language ever, some hate it and want it abolished. C++ has its place, the gaming industry knows it extremely well and there is absolutely nothing out there to compare to it (unless you count the mobile sector, but that's a different kettle of fish). I wouldn't use C++ for a lot of things, where other languages have been created to make certain types of development easier, but where you have any kind of gap or hole that doesn't have a "tailor-made" language, C++ is there and gives you the ability to do what you've set out to do.

Re:Question

[Anonymous Coward]

There are C++ operating system kernels that actually use the boost and/or standard libraries.

There's also an OS kernel written in Java, that doesn't mean it's a good idea or an area where Java excels. You use the runtime argument yet mention boost... in this context libC and libstdc++ are runtimes, or see how far you get without them.

I dispair that C++ is used in applications, I don't want critical system level stuff done with a language where there's so many pitfalls. IMHO, C++ outgrew it's boots in that regard back when C++ compilers evolved beyond preprocessors that generated C code. Let's put it this way; Mozilla are looking to replace parts of their C++ codebase with JIT'd javascript!

Michaelangelo

[Anonymous Coward]

Q: Your code is so beautiful, how do you do it?

A: I write the first version in C++, and then I chisel away everything that is not C.

Re:C++ has had its day

[narcc]

I couldn't agree more ... strange ...

Why do I have this feeling that it's somewhere between 15 and 20 years ago, and that you're about to get flamed by the sysop?

Okay, but....

[identity0]

How do you pronounce 'C++0x', and why does my modem keep resetting when I type it?

Re:Okay, but....

[drinkypoo]

How do you pronounce 'C++0x', and why does my modem keep resetting when I type it?

The answer to both is the same: nerdgasm

Re:Question

[atlasdropperofworlds]

The new standard is very function-style friendly. C is dead meat.

Re:Yay for C++ 0x7DB; // FTFY

[Anonymous Coward]

Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception? Should I wrap all such statements in a try / catch block!?)

It's quite simple: it increments the variable C, but evaluates to the value of C before incrementing it. The fact that someone may create an operator++ that does something else isn't a problem with the language but with the programmer. C++'s operator overloads are syntactic sugar for regular function calls. Do you really know what postfix_increment(C) does anymore than operator++?

Woopdeedoo

[formfeed]

C++ Final ISO Draft approved?

That's like that couple who has been together for 20 years
and has a couple of high-school age kids
telling you that they just decided to get married.

Re:Woopdeedoo

[Anonymous Coward]

As you've pointed out, marriage is a bullshit social abstraction that wastes resources.

I'd say this is more like a couple that has been together for 20 years telling us that they have had a second child who has been kept in hiding rather than born recently.

Re:C++ has had its day

[MORB]

And yet despite all the hype I find C# incredibly more cumbersome and verbose and when I'm at work I truly can't wait to get home to work on my c++ hobby project. Part of it will be in javascript too, because it is better for some of the parts of my project.

There is no such thing as an universally simpler and better language, and some of c++ features that people love to hate such as RAII, templates (not those half-assed generics that c# offers) and operator overloading permit to make some complicated things much simpler than anything you can achieve in most of those more recent languages.

Job interviews

[StoatBringer]

Brilliant. It was bad enough in job interviews when they try to catch you out on your knowledge of the obscure bits of C++ that nobody ever uses, and now there's a whole new level of complex syntax, pitfalls and gotchas to deal with. C++ is turning into a warty freakshow. I could even start to forgive Python's idiotic indentation nonsense at this rate.

Re:Job interviews

[shutdown -p now]

On the contrary, I love those interviews - it's always fun to find and point out errors in interviewer's understanding of C++ when he tries to wrongly correct you, opening C++03.pdf on the laptop and pointing out specific paragraphs where it says how and why he's wrong. The language being so complicated and messy works both ways. ~

Re:Job interviews

[Anonymous Coward]

Python's idiotic indentation nonsense

Readability counts.
Tho; Flat is better than nested -- Sparse is better than dense.
 

Re:Job interviews

[maxwell demon]

Python's idiotic indentation nonsense

Readability counts.

Yes. And you can readily indent your C, C++, Perl, Pascal, and even FORTRAN code.
You can even do that automatically, in case your indentation got messed up. Try that with Python!

Re:Yay for C++ 0x7DB; // FTFY

[gbjbaanb]

Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception?

to be fair, all the other 'oo' languages don't let you do that either, and C can give you the same problems if you're using #defines (C's equivalent to operator overloading :) )

At least in C++, you can look at the header file for the class definition and see what its doing. In languages like C#, those overloads can be anywhere - not even associated with the class itself. Scripting languages can be the same,

Still, I don't think C++ needs more low-level features, it really needs a higher level library of useful stuff - like boost but even higher level than that. And you're right - it really needs more consistency, even if that means breaking a bit of older code. Your examples show that the language is dying of old age now, its not the lean and fit language of its youth, especially as they're adding more wrinkles to it now. This is the thing that worries me (as a C++ dev) most.

I can see why there's so much favour towards D.

Re:C++ has had its day

[drooling-dog]

On the other hand, there was the time recently that I reimplemented some old C++ simulation code in Python just for the fun of it, only to find that the Python version ran nearly 90 times slower. Of course I expected it to be a lot slower, being an interpreted language and such, but wow.

Re:C'mon Python Users tell us why

[chichilalescu]

well, for now I've only done it for stuff where the C source is tiny (using gcc), and compiling doesn't take that long. anyway, I'm talking about cases where you can't really compare the running time (> 2 minutes) to the compiling time (1 second); and for serious work only the running time will increase. in practice the time cost for dressing everything in Python (and using sympy to generate formulas in the C source) is more important (but still negligible next to the time spent running the C generated executable).
however, it is true that for one particular problem I'm already compiling a C library (it's for computing certain classes of polynomials, so I generate individual libraries for individual classes if they're not already there), and then I'm loading it with cdll from ctypes. it's a general enough class of functions that it's worth the trouble to do it. it's also relevant that the functions themselves take a number and return another number, whereas it might be more efficient to run external code when I need to generate a large amount of (binary) data.
in terms of what serious programmers do, you have to realize that, when it comes to physical sciences (I'm a physicist myself), programming abilities can be (and usually are) very limited.

pls stop cutting yourself for fun kthxbye

[jensend]

You should see a psychiatrist. That level of masochism is really unhealthy.

Header files again??

[Twinbee]

Brilliant! I assume they've got rid of those things called header files by now.

And before anyone moans that "header files provides a good overview of a project", well, it should be up to the IDE to display information (much better presented) about a project and its classes and members. Even Bjarne Stroustrup said that header files were a kludge,

Break backwards compatibility a little bit and you can do so much stuff better. Otherwise you ultimately have a dying language.

Re:Header files again??

[shutdown -p now]

No, they haven't got rid of header files yet. There was a proposal which didn't make it for C++0x, but will likely be strongly considered for TR2.

Re:Header files again??

[kthreadd]

My vi session does not agree.

Re:Header files again??

[jgrahn]

Brilliant! I assume they've got rid of those things called header files by now.

And before anyone moans that "header files provides a good overview of a project", well, it should be up to the IDE to display information (much better presented) about a project and its classes and members.

I prefer header files to having to learn some IDE.

Even Bjarne Stroustrup said that header files were a kludge,

Sure, they *are* a kludge (along with the rest of the preprocessor).

Break backwards compatibility a little bit and you can do so much stuff better. Otherwise you ultimately have a dying language.

Remove header files, and all existing C++ code would immediately stop working. All interoperability with C libraries would also stop working.

Re:Header files again??

[Anonymous Coward]

Not remove...but provide a way for compiler to extract needed information from referenced cpp files. Java does it fine with packages and their compiler is quite fast.

Re:Header files again??

[osu-neko]

And before anyone moans that "header files provides a good overview of a project", well, it should be up to the IDE to display information (much better presented) about a project and its classes and members.

The only thing the IDE should be doing is moving bits onto and off of my hard drive.

P.S. Get off my lawn... *waves cane menacingly*

Re:Header files again??

[gatkinso]

I have heard of this "IDE" you speak of... yet there are people (like myself) who work on headless embedded systems, the only access being via a serial port console.

Point is, not everyone uses (or is able to use) an IDE.

Re:Header files again??

[snemarch]

...and you develop on those embedded systems?

Nice try.

Re:Question

[telekon]

I think you can easily determine the competence of any programmer by how much they hate their primary language.

It depends as much on the language. I don't trust the competence of any PHP programmer who actually likes PHP... likewise with C++, Java, and several others.

On the other hand... Talk to the true Ruby wizards, and they won't shut up about the glory and wonder of Ruby. It also holds with Smalltalk, some Lisp flavors... and so on.

With machine-centered languages, like C, C++, PL/I, Ada, etc., to truly grok the language comes from doing battle with it. For programmer-centered languages (Ruby, Scala, Smalltalk, etc.), to truly grok the language comes from loving it for every little quirk

Then you have the languages objectionable to both programmer and machine (BASIC, Pascal, COBOL), which one doesn't discuss in polite company.

Re:C++ has had its day

[Anonymous Coward]

Actually when porting code to python there's a huge performance penalty. Rewriting the code the "pythonic" way usually yeilds unexpected performance boosts. There's a Guido text on python performance, check it out.

This is also common in matlab code (ie. code with loops when ported versus properly vectorized code).

Re:Yay for C++ 0x7DB; // FTFY

[shutdown -p now]

Just as a side note, regarding "objectified int" - the term "object" in C++ standard actually comes from plain C, and doesn't have much to do with objects in OO sense. I'll just quote the C99 spec:

3. Terms, definitions, and symbols
For the purposes of this International Standard, the following definitions apply. ...
3.14 object
region of data storage in the execution environment, the contents of which can represent values

Re:Yay for C++ 0x7DB; // FTFY

[shutdown -p now]

to be fair, all the other 'oo' languages don't let you do that either

C# has operator overloading. Granted, it prevents you from doing certain particularly stupid things (such as overloading == but not !=, or overloading &&. In case of ++, it will require the return type to be the same as argument type, but the precise meaning is still controlled by the implementor.

Re:C'mon Python Users tell us why

[ibbie]

So basically, you get around Python's performance limitations... by using C instead.

Way to go!

Why not? Use the right tool for the job. Though I'm curious if the parent has tried Cython. It seems like it might be a better fit for what they're doing.

Re:C'mon Python Users tell us why

[ibbie]

I cheat. I write python code that writes its own plain C code, compiles it then executes it. this way, I work once to write a C template, that I then reuse through a high level language. and when I combine the advantages of python (sympy for instance) with the speed of C, I get stuff that is ridiculously faster than what I did before. in the sense that I don't work a lot to write it, and I don't wait around a lot for it to actually run afterwards. working with numerical simulations, I'm allowed to cheat this way...

Might be a silly question, but have you given Cython a shot? It sounds like you're doing something very similar to what their project was built to do.

I don't think you can blame c++0x.

[jensend]

I certainly agree that it's amazing how many things in c++ flagrantly violate the principle of least surprise. A good example: read these two articles about the assignment operator and weep. The author (who by no means could be accused of being biased against c++) concludes:

I don't know about you, but there's something really scary to me about a language where copying state from one object to another is this complicated. By now, I suspect at least a dozen or two programmers have contributed something new to this discussion. If it takes this many programmers to write a simple assignment operator, think how complicated writing code that actually does something meaningful must be!

The devil truly is in the details, especially in C++ programming.

I'd have to disagree with you about c++0x though. While there is additional complication, many of the added ideas seem to have few "gotchas" relative to most of c++, and it even manages to eliminate a few "gotchas." I didn't learn c++ until last year (mostly have done my programming in Java and MATLAB, with little bits of everything from C to Scheme along the way), and I ended up using gcc's c++0x option because there were a bunch of ways in which c++0x made things less painful and made c++ seem less braindead.

Re:I don't think you can blame c++0x.

[Rei]

One of the main reasons why C/C++ are so popular is precisely the reason why there are so many complications with it. It's fast; it deals at a low level and gives you full control over what you're doing. Want something bounds-checked? Bounds check it. Don't want it bounds-checked? Don't bounds-check it. This sort of stuff falls over to assignment operators. A higher-level language, when you assign from rhs, will generally just automagically duplicate all member arrays and objects, even strings. Do you really want that? Well, it really depends on the situation. Sometimes you want it duplicated. Sometimes you want to point to it. And sometimes you'd rather seize it (thank you, C++0x move operators!). So by default, the programmer has to have flexibility in assignment. Which means that you can't count on simple assignment from any of your children if they can be arbitrary datatypes (such as from a template).

It's a feature, not a bug; it's an inherent complication from giving the programmer power to control how things happen. But, you know what? Give me that power. Contrary to what some would assert, performance *does* matter. I'm sick and tired of lazy programmers assuming that *their* app can afford to waste CPU and memory like there's no tomorrow and yielding up the gains of Moore's law to bloat.

C++ had a lot to criticize before. C++0x gets rid of most of it. You know, we no longer have other languages laughing their arses off at what passed for a foreach loop before with iterators over stl object making the for loop take 150 characters to write. C++ now has coding simplicity in many cases over a lot of languages that run at 1/10th its speed. It's still not perfect (the whole stl library needs an object-oriented makeover -- and can we finally instantiate main as "int main(std::<vector> args)"?). However, it is a big step forward.

Re:I don't think you can blame c++0x.

[Rei]

These sort of things are an inherent property of the very reason people use C/C++: performance/flexibility. A higher level language will automatically use a given assignment method for the members of an object -- usually copying. Got a member array, a member object, even member strings? They're going to be copied in memory -- enjoy your lousy performance. In C++, you can choose how to deal with them. Want to copy them? Go ahead. Want to have a second pointer reference to it? Go right ahead? Want to seize it? Thanks to C++0x move functionality, go right ahead. Deal with it however is most appropriate for your program. But obviously, this means that assignment is nontrivial. So yes, it gets more complicated -- but for a reason.

It's a feature, not a bug. And you know what? Give me that power, that performance. I'm sick and tired of programmers assuming that every program they write is going to be the only program that runs on my computer and can hog as much memory and CPU as they want to, squandering the blessing that Moore's Law has given us on bloat.

Re:I don't think you can blame c++0x.

[imthesponge]

"A higher-level language, when you assign from rhs, will generally just automagically duplicate all member arrays and objects, even strings."

Java doesn't do this. You have to either construct a new object or use clone().

Re:C++ has had its day

[shutdown -p now]

The big problem with vanilla C is that you still have manual memory management, but no RAII to automate it. Now you have to clean up on every exit path, or do the usual "foo(); if (errno) goto error: ... error: if (p) free(p); if (q) free(q)" dance in every single function you have. This is nothing but tedious plumbing that takes a lot of fun out of writing code, and makes it that much easier to make an accidental mistake.

I'd kill for C with scope guards on language level, so that I could write something like

char *s = malloc(n);
on_scope_exit { free(s); }
...
if (errno) return;
...
if (errno) return;
...

Re:C++ has had its day

[shutdown -p now]

There's so much you can do with well-written C and good libraries quicker, more reliably, more simply and much more efficiently than in C++.

Indeed; one needs not look any further than Gtk+ to see a proof of that! ~

TL;DR

[Anonymous Coward]

n/t

Re:C'mon Python Users tell us why

[Rei]

And in those days Fortran blew the doors off C++.

I'm going to take a wild guess and assume that you didn't have (or use) the "restrict" keyword?

Does it work?

[Casandro]

So, does Garbage collection work on C++ now or is that just another point on the list of features that sound good, but never worked?
Just like overloading operators, which only works for some operators. Or copy constructors.

Re:C'mon Python Users tell us why

[Anonymous Coward]

You do realize how a JIT compiler works right? Might want to pay more attention in that comp sci 101 class there chief.

Re:C'mon Python Users tell us why

[chichilalescu]

I did it once, and I got a huge C file. I didn't even have the patience to go through it, but I saw that a lot of stuff was defined that I didn't actually need. and it was for something relatively trivial. I decided it's safer to write my own C code, at least I can read the C source if there's a problem. and it's mostly just generating a couple of formulas using sympy, and then plugging them into a C template (that I write explicitely as strings in the Python file).
Cython might be good when you try to translate a large piece of Python into C, but that's not what I'm trying to do. for me, running time for the Python script is negligible when compared to the running time of the generated executable, and I'm pretty certain that if I use Cython, overall efficiency will go down.

Re:C++ has had its day

[chichilalescu]

have you heard of ctypes? write the number crunching stuff in C, and then make the OO stuff in Python. but keep in mind that in Python there is a (large) constant cost to calling any function, so you should try to call as little Python functions as possible. see my above comments (repplies to "C'mon Python users tell us why") if you're interested: I generate C code, then compile and run it through Python.

Re:C'mon Python Users tell us why

[m50d]

In theory C++'s thread support may be better than Python's, but in practice writing working multithreaded programs is much, much easier in Python, particularly if you want to be crossplatform. (At this point you talk about the GIL, but again - it's a big problem in theory, but doesn't get in the way in practice).

As for speed, sure, C++ is faster in the same way that assembly is faster than C++, and where appropriate (i.e. you've profiled it and seen that function x is taking so much CPU time) by all means write particular functions in C++. But writing a whole program in it for "performance reasons" is the worst kind of premature optimization.

Re:Question

[OeLeWaPpErKe]

There's also an OS kernel written in Java, that doesn't mean it's a good idea or an area where Java excels. You use the runtime argument yet mention boost... in this context libC and libstdc++ are runtimes, or see how far you get without them.

The big difference between C++ libraries and other languages libraries is just that they work without runtime.

And btw : there are *no* java operating systems. At least not the java you know. There are "compiled subset of java" kernels, which is not the same thing at all.

Re:C++ has had its day

[maxwell demon]

C is not better than C++. Quite the opposite: Most (not all, though) of C++'s problems are actually C problems. C is actually one of the worst languages I've ever seen. I cannot see why anyone would use C if he can use C++ and avoid at least the worst part of C.

Of the other languages:
Scheme is definitely a great language (if one isn't allergic to parentheses :-)), however the fact that it is dynamically typed is a distinct disadvantage for larger programs.

Java IMHO is definitely not better than C++, period.

Ruby I don't have any experience with, so I cannot tell anything about it. However, AFAIK it's a scripting language, and thus not applicable to all problems.

Python I've up to now avoided to learn because I simply dislike dependence on amount of whitespace. The amount of whitespace is too fragile to depend on it.

Re:C++ has had its day

[maxwell demon]

Please do tell which languages do you believe are "simpler (and arguably better" than C++.

error:Unexpected end of line.

You need to update your parser. The actual error is an unbalanced parenthesis in the quote. Except in poetry, line endings are not significant at all in the English language.

Forking

[sourcerror]

"Certainly, lack of standardization hasn't prevented other languages, such as Java in the past, but look what happened there. Microsoft was litigated out of the market, and now Oracle is sueing Google and possibly others. This is not very commercial compiler friendly."

On the other hand IBM has its own JVM and wasn't/isn't paying licensing fee to Sun/Oracle.
The license only prevents incompatible forking. As a Java developer, I don't think it's a bad thing.

Re:Forking

[man_of_mr_e]

"Incompatible" is at the whim of Oracle. I guarantee you no compiler is 100% compatible with the specifications, not even Oracles. Oracle doesn't see a value in sueing IBM (yet), that's all..

Re:C++ has had its day

[PhrostyMcByte]

I've no need for C++ -- it's just something I want to do for fun.

Thank you. I'm the same way.

C++ is such a terrifyingly complex language that you can spend 5 years writing serious code with it and still be learning new things. Not algorithms or general things that can apply in any language. New things that apply only to C++. And they're all neat as hell, impossible in most other languages, and actually useful.

This is a turn-off for most people, but some of us find it fun. The trick is in knowing how to reel it in before you piss off your co-workers with something so incomprehensible it might as well be Perl.

I love C++

[gatkinso]

It is great!

I don't know why people whine about it so much - it isn't that hard, and if you don't like it use something else.

I'm sure this will...

[Deus.1.01]

*puts on sun glasses*

BOOST productivity.

YEEEEEEA...etc, .etc.

Re:Yay for C++ 0x7DB; // FTFY

[maxwell demon]

Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception?

Only if the programmer intentionally obfuscated the code. But then, he doesn't need operator overloading of #define; tell me, what does "increase_by_1(C);" do?

Oh, and if C is an int (or another incrementable builtin type), the statement C++; will indeed increment C, with certainty.

Re:C++ has had its day

[turgid]

C is not better than C++. Quite the opposite: Most (not all, though) of C++'s problems are actually C problems.

C++'s problem is that it tries to be all things to all people, and fails.

C++ started out trying to be a superset of C. That was the first mistake. They soon found out that it wouldn't work, but had to keep most of the C features for all that old C++ still to work.

People still try to pretend that it's a "good idea" to recompiled your C source in a C++ compiler (which involves a non-trivial porting effort that they sweep under the carpet) so that you can start to "benefit" from the new C++ features.

C++ syntax is terrible and they keep making it worse. Since they tried to keep it backwards-compatible with C (and failed) they tried all sorts of dirty hacks with the syntax to put in the new features.

The older I get, the more I'm convinced by using the right language for the job. If that means Java, Ruby, PERL, C or whatever, then so be it. C++ is not usually a good choice unless you have to work with and on existing C++ code.

A language I looked at when I was 15/16, which really taught me how to write good code was Modula-2. It's spirit lives on in Borland's Object Pascal/Delphi (whatever it's called nowadays).

For an entertaining and insightful look at many of the problems with C++, have a look at the C++ Frequently Questioned Answers which is organised like (and in response to) the C++ FAQ Lite.

Finally, here is a collection of links to various criticisms of C++.

In summary, C++ is too big and too complicated, and it keeps on getting worse.

Re:C++ has had its day

[osu-neko]

Please do tell which languages do you believe are "simpler (and arguably better" than C++.

error:Unexpected end of line.

You need to update your parser. The actual error is an unbalanced parenthesis in the quote. Except in poetry, line endings are not significant at all in the English language.

Since when did parser errors ever reflect the actual error? :p

Re:Question

[Joce640k]

Why don't C programmers program in assembler...?

Their reasons for preferring C over C++ are equally applicable to "C-vs-assembly language" so I don't understand why they use C....anybody?

(Be aware that any answer you give will be instantly reworked to fit "C++ vs. C" so you'll lose by default...)

Re:Question

[Joce640k]

Sure, it suffers from feature bloat - to say the least.

So...which features could you remove without harming the language and making a whole lot of people's jobs more difficult?

I can only think of one - C++ arrays. new[] and delete[] are a dangerous blight (the C++ FAQ calls them "evil") and are made obsolete by std::vector.

And it suffers from a lack of a coherent structure of libraries and tools - it's nothing like java.

That's mostly because the world will never agree on one that's 'best'. There's plenty to choose from but none has ever become The Standard. The user interfaces in Java have only managed become the standard for mediocrity (if you disagree then where's the shrinkwrapped Java applications?)

The one thing that's hurt C++ more than anything else is the lack of a smart pointer class. It would have helped C++ a lot if a good reference-counted pointer had been in the ISO standard. Yes, there's Boost but most programmers are overwhelmed by the style of Boost and all they want is a pointer, not a new lifestyle.

Re:Question

[mswhippingboy]

Why don't C programmers program in assembler...?

Their reasons for preferring C over C++ are equally applicable to "C-vs-assembly language" so I don't understand why they use C....anybody?

Portability and productivity are the first things that come to my mind.

(Be aware that any answer you give will be instantly reworked to fit "C++ vs. C" so you'll lose by default...)

And quite rightly so. Some problem spaces are best suited for assembler, some better suited for C, others more suited for C++ and still others for Java/C#, etc. It boils down to the best tool for the job (with technical considerations as well as programmer availability, expense, etc. all factors to be considered).

Re:Question

[Twinbee]

Because even for the best developers, super-large projects would be a nightmare to code in assembler. Therefore, you'd get a juicy speed increase indeed, but the human mind isn't yet *that* good.

Re:C++ has had its day

[Twinbee]

There is no such thing as an universally simpler and better language

You see, that attitude is when we give up and stop trying to improve languages. There are loads of cases where you can improve stuff, and unify two approaches into one which is fast, consistent and terse. If C# is more cumbersome, then perhaps there's a way to make it less so while keeping flexibility and power.

Have you looked at D? For all its drawbacks, that surely seems to combine the advantages of C and C++ without many of the drawbacks of both of those.

Re:C'mon Python Users tell us why

[binarylarry]

Multithreaded programs don't really exist in Python due to the GIL, you moron.

Google's Go programming language

[Boawk]

Have any C++ programmers tried using Google's Go programming language? Any opinions?

Re:Google's Go programming language

[HuguesT]

Yes, basically interesting but very far from production-ready (slow, buggy).

Re:Yay for C++ 0x7DB; // FTFY

[petermgreen]

Do you really know what postfix_increment(C) does anymore than operator++?

Yes, unless the programmer was deliberately setting out to obfuscate things it is very unlikely they would call a function postfix_increment unless that is what it actually did and even then it would be a pretty strange way to name a function and an immediate red-flag.

In all the langauges I have experiance with there is a very limited set of operators. The result is where there is no operator that is a good fit the programmer must either give up on operator overloading entirely or (ab)use an existing operator which is a poor fit. This forced descision make operator overloading a dangerous tool. Used properly and sparingly it can make code clear and concise. Overused it will make code smaller but harder to follow.

Below are a couple of examples from the standard library of what I consider to be bad uses of operator overloading:

The streams code overloads to use to output stuff. This makes outputting stuff a little more concise but also means you have to manually keep track of variable types to tell the difference between outputting stuff and shifting bits. To make things even more confusing they made the operator return the stream so users can chain the operations.

auto_ptr uses = for assignment but has rather weird symantics which break the normal assumptions that people are likely to make about the behaviour of an assignement operator. In particular assigning something to an auto_ptr effectively destroys the original (either immediately in the case of an assingment from one auto_ptr to another or when the auto_ptr goes out of scope in the case of an assingment from a plain pointer to an auto_ptr).

octal pi

[Anonymous Coward]

"C++ is an octopus made by nailing extra legs onto a dog."

Re:C++ has had its day

[MORB]

If C# is more cumbersome, then perhaps there's a way to make it less so while keeping flexibility and power.

I only can see two clear advantages to c# over c++: garbage collection and reflection. Everything else boils down to syntactic preferences or minor features. And there's a lot of useful things that c# is missing compared to c++.

I'm sure in time both things will make their way into C++ in a way or another (garbage collection is half-way there).

I don't think that D is a good answer to the shortcomings of C++. I'm not a fan of the "let's add in everything and the kitchen sink" approach.

Re:C++ has had its day

[Coryoth]

I'd kill for C with scope guards on language level, so that I could write something like

char *s = malloc(n);
on_scope_exit { free(s); }
...
if (errno) return;
...
if (errno) return;
...
</tt></quote>

Actually, if you are using gcc you sort of can. You see gcc supports special cleanup attributes that let you specify a function to be run if a variable goes out of scope. Thus you can do things like:

void delete_string(char **to_delete) {
  printf("Cleaning up string %s\n", *to_delete);
  free(*to_delete);
  return;
}
 
int main(int argc, char **argv) {
  char *y __attribute__((cleanup(delete_string))) = malloc(10);
  snprintf(y, 10, "some text");
 
  printf("Hello World!\n");
 
  return 1;
}

This example being pointless, but hopefully gives you the idea. A few #defines to make things pretty and you can thus do whatever RAII style thing you wish.

Re:C++ has had its day

[shutdown -p now]

That's neat (though free-form code blocks would be even better).

Now to get this into the Standard...

ISO C++ Committee Approves C++0x Final Draft

[Alinabi]

Where can I donate money to help the victims?

Re:Yay for C++ 0x7DB; // FTFY

[Erys]

You have to keep in mind that one of the major advantages of C++ and most likely the thing that made it a wide used language, is it's backwards compatibility with C. And that's not because C programmers had a hard time learning C++, but because there exist enormous quantities of C legacy code that would have to be completely re-written if C++ wouldn't provide this backwards compatibility. With the C++ compiler you could continue the work on these projects with the added benefit of finding a few bugs that you didn't even knew were there.

Of course, some of the monster constructs that are allowed in C++ should not be used, they are there just so your old C code compiles. That is the reason best practice books exist, so you know what features of the language to use and when.
Instead of hating on C++ (and now C++0x) because of the features it offers, maybe decide which of those feature to use and which not in your project.

Like C++ is compatible with C, C++0x is compatible with C++, so I don't see any reason why existing projects in C++ shouldn't compile. Maybe I'm wrong here, but I'm under the impression that all the C++ code-base should compile in C++0x without modifications and should work exactly the same.

Re:Yay for C++ 0x7DB; // FTFY

[VortexCortex]

Bang: You're dead! Assumptions have that effect. My point stands that certainty is only derived from reading every flipping line of code that is ever "included" -- Who does such things? Masochists. Who designs language traps such as these? Sadists.

Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception?

Only if the programmer intentionally obfuscated the code. But then, he doesn't need operator overloading of #define; tell me, what does "increase_by_1(C);" do?

Oh, and if C is an int (or another incrementable builtin type), the statement C++; will indeed increment C, with certainty.

Unless someone has overloaded the global ++ operator for int types... Your "certainty" assumptions amuse me.

Re:Yay for C++ 0x7DB; // FTFY

[VortexCortex]

You, my friend, have arrived at the heart of the matter, and thus was my initial point:

C++ is to be regarded as "a different language than C", not as C with extensions. However, C++ was surely developed by adding features to C, then calling it a new language after the fact.

My point is that the basic C syntax could have been kept in C++ without having to limit C++ to old language constructs. The main point is this: The C++ language itself has no business compiling C code. If C++ libraries need extern "C" { ... } to provide C interfaces for their functions, then why not REQUIRE a wrapper convention for any and all C code in a C++ project, then simply let code not wrapped in a "Parse this as C" block have whatever semantics are required -- Including those that break C syntax.

You see -- C++ could have both retained a close tie with the popular C language, while at the same time isolating itself from the older C syntax.

I've actually developed a few toy scripting languages that are "somewhat" C like... In fact, my favorite of these scripting languages has this very parse_as "C" { ... } construct, which simply extracts the code, invokes a C compiler on it to build a shared C library from all such blocks, and dynamically loads those libs at run time. (The VM translates these code blocks into a "load_shared_c" instruction, followed by op codes that add function names to the context's symbol table. These symbols contain functors that call the shared C lib's function by function pointer.)

In short: It is possible to retain the power of C, and take advantage of the C install base, WITHOUT polluting your language with the C language's syntax...

// Creates new object that subclasses the ParseAs object,
// passing "C" to the ParseAs constructor.
// The new object has methods written in C.
math' = parse_as( "C" )'(){

#include <math.h>

long multiply( long a, long b){
return a * b;
}

double divide( long a, long b){
if ( b != 0 ) return a / (double)b;
return -INFINITY;
}

}

args' = ( 6, 7 );
ans' = math.multiply( args );
say( "Multiply: " + args + " = " + ans );
say( "also, " + args.join( " / " ) + " = " + math.divide( args );
----- output -----
Multiply: 6, 7 = 42
also, 6 / 7 = 8.57142857e-1

Re:Yay for C++ 0x7DB; // FTFY

[maxwell demon]

Unless someone has overloaded the global ++ operator for int types... Your "certainty" assumptions amuse me.

You cannot overload the global operator++ for int types. It is explicitly forbidden by the C++ standard, and if your compiler really allows it (I strongly doubt it), it's time to get a better compiler.

Re:Yay for C++ 0x7DB; // FTFY

[VortexCortex]

Just as a side note, regarding "objectified int" - the term "object" in C++ standard actually comes from plain C, and doesn't have much to do with objects in OO sense. I'll just quote the C99 spec:

3. Terms, definitions, and symbols For the purposes of this International Standard, the following definitions apply. ... 3.14 object region of data storage in the execution environment, the contents of which can represent values

Yes, and the instance of a Class is a "region of data storage" used in the execution environment, the contents of which can "represent" a "value". Literals are also stored in regions of data storage, and used in the execution environment, with contents that can represent values... So also may a variable of an enumeration type, or even functions (which have stack frames) for meatball's sake! -- So once again, the multi-headed snake is happy to eat any of its myriad of tails.

I don't object to the object of object oriented programming; However, I do object to, "object" being the chosen term for objects in any programming language.

It's as if the object of choosing "object" to name objects were to cause confusion and ambiguities, not resolve them. (Clearly this must be some sort of bad joke, no?)

If it were one of the objectives of an object oriented programming language, to help provide clarity of concept, one would think that the creators of such languages would have been a bit more objective and chosen less objectionable terms, such as Entity, native type, idea, concept, form, pattern, formula, design, etc.

C++ is marketed as an "Object Oriented Language". IMHO, the term "object" is a very overloaded in English -- Like C++ functions can be...

"Object Oriented Programming" could describe a language that revolves around the concept of Objections -- Like C++ does (Exceptions).

"Object Oriented Programming" could describe a language that focuses on the objectives of the logic, not the data model, similar to the procedural aspects one uses in a language such as C++.

"Object Oriented Programming" could even describe a language that allows one to group data and behavior into a single unit, like C++ classes do...

Finally, given your citation of the ambiguous "standards", C++ being capable of "Object Oriented Programming", could mean that one spends most of their time reprogramming the syntax of the language to provide different behaviors for standard built in "primitive objects"... Like C++ operator overloading does...

You know what, I take it back, "Object" is a perfect term for C++ -- It's opaque, ambiguous, and ill-suited for its purpose, in other words, par for the course in C++.

( Don't even get me started on "classes" -- Are we talking classification system, or training of AI algorithms? Perhaps we mean that classes are where you must go when the compiler objects to your code in order to learn WTF the object of the object's objects are. )

Re:Yay for C++ 0x7DB; // FTFY

[VortexCortex]

Well I must apologize, I was wrong. language native primitive types can't have global operators overridden...

So I guess there's only one predictable set of operations you can do in C++, work with the primitive types. Except, you can't really predict the size or range of the primitive types until runtime, unless you know the specifics of the platform the code will be compiled on.

I grepped my code, and couldn't find a singe use of an int, long, char, etc... Turns out that we all use stdint.h types to provide cross platform capabilities (even though it's C not C++) -- typedefs for all the primitive data types, such as uint32_t are used in place of int, because sizeof( int ) is platform dependent... Now, quick, say you're on a 32 bit system. Without looking in the stdint.h file, prove that uint32_t is not really a class that implements all the int operators, has an internal state 4 bytes in size, and can cause the following statements to do any arbitrary operation.

#include <stdint.h>
int main( void ){
uint32_t C = 0;
return C++;
}

Use tricks with Templates? xxx_cast, etc? Typeinfo? All those things work at compile time -- looking at the code, and only the code, without compiling it and running it, there's no way to tell what the hell it's going to do.

Say you do read through the stdint.h and discover that uint23_t is an alias for int... ON YOUR SYSTEM. Who knows what stdint.h will define uint32_t as on anyone else's system -- Faith is a required virtue of C++ coders. On an 8 bit system, uint32_t may be a class that wraps an array of 4 ints (8 bit each == 32bits), and simulates 32 bit integer operations... or perhaps they open network connections and ask a mainframe what the answer is... I still can't really tell what's going to happen when that simple code executes... hell, even if I take for granted a "standard" stdint.h file being available, the semantics of #include <stdint.h> vs #include "stdint.h" are platform dependent -- some compilers will look in the current directory first regardless of the angle brackets or quotes.... so... Is there a stdint.h in the local directory? Only looking at the code, I can't tell... Is it really so hard to give a C++ programmer even the most basic tools, such as a few guaranteed size integer types? ( isn't in my C++ compiler; Is it in yours? -- stdint.h is C, not C++ )

I admit that I'm wrong about the special case where you actually use the platform dependent language primitive types such as int, char, etc, however, just because sizeof uint32_t == 4, doesn't mean that's a primitive type, and short of using typeid or other such compile-time or run-time operations, I'm not sure I can predict what that code will do without reading the typedef and/or class implementation of the uint32_t type.

Conversely, in languages that don't allow operator overrides, I can be sure that +, --, ++, and other mathematical operators operate on numbers, or at least perform defined operations given a set of parameter types.

Re:Yay for C++ 0x7DB; // FTFY

[shutdown -p now]

Yes, and the instance of a Class is a "region of data storage" used in the execution environment, the contents of which can "represent" a "value". Literals are also stored in regions of data storage, and used in the execution environment, with contents that can represent values... So also may a variable of an enumeration type, or even functions (which have stack frames) for meatball's sake! -- So once again, the multi-headed snake is happy to eat any of its myriad of tails.

Literals are not stored in regions of data storage, except for string literals - and yes, those are objects (same as any other array). Variables of enumeration type are also objects - I don't see why you feel there's a contradiction here (did you mean to refer to enumeration members instead? they're not objects because they don't have any storage backing them). Functions are not objects, because they do not represent a value (though in C++ this is explicitly clarified in the spec, unlike in C).

C++ is marketed as an "Object Oriented Language".

If someone markets it to you that way, then they're clueless. C++ is a multi-paradigm language which offers OOP among many other approaches, without forcing any on you.

Oh, and even so, there's a common understanding of what OOP means in the field. You can come up with your own differing definitions, but it doesn't prove anything, as they're not the ones actually used in practice by anyone.

You know what, I take it back, "Object" is a perfect term for C++ -- It's opaque, ambiguous, and ill-suited for its purpose, in other words, par for the course in C++.

"object" is not a C++ term; it's a C term that was inherited in C++ simply because most C++ programmers were also C programmers, and it would be more confusing to change the terminology that they're using.

As for C, arguably, the term "object" there was used before OOP went truly mainstream.

Don't even get me started on "classes" -- Are we talking classification system, or training of AI algorithms?

Same as "OOP". This one has many meanings, but there is a very well established one in the context of C++, which everyone understands. There's no confusion here other than what you try to artificially induce.

Re:Yay for C++ 0x7DB; // FTFY

[maxwell demon]

So I guess there's only one predictable set of operations you can do in C++, work with the primitive types. Except, you can't really predict the size or range of the primitive types until runtime, unless you know the specifics of the platform the code will be compiled on.

Well, there are guaranteed minimal sizes, and rarely you need the exact size (unless you are doing very low-level stuff, but then you should better know your platform anyway).

Say you do read through the stdint.h and discover that uint23_t is an alias for int... ON YOUR SYSTEM. Who knows what stdint.h will define uint32_t as on anyone else's system

Given that stdint.h is a C header, it will of course define it to whatever it is defined to be in C. Of course if using a compiler you always need to put faith in the provider that he doesn't do stupid things, or have glaring bugs in the compiler or associated library.

Now, quick, say you're on a 32 bit system. Without looking in the stdint.h file, prove that uint32_t is not really a class that implements all the int operators, has an internal state 4 bytes in size, and can cause the following statements to do any arbitrary operation.

stdint.h is a standard C header, and therefore cannot use any operator overloading.

But even if it were a user-defined type, unless the programmer writing it was a complete moron who should not have been let closer than ten miles to a compiler (of whatever language), you can expect that any operator works exactly as expected.

Is it really so hard to give a C++ programmer even the most basic tools, such as a few guaranteed size integer types?

The original C89 didn't have it either. And the next version of C++ will adopt it from C. But as I said, if you need specific sizes, you obviously do low-level programming, in which case you better know your platform (which defines the sizes of C integer types) anyway. Therefore a header with pre-defined specific-size integer types, while certainly useful, is not really essential.

Conversely, in languages that don't allow operator overrides, I can be sure that +, --, ++, and other mathematical operators operate on numbers, or at least perform defined operations given a set of parameter types.

And in languages that don't allow user-defined functions I can be sure that multiply(a,b), if defined, does indeed multiply a and b. We really should disallow user-defined functions; they can completely mislead you!