This chap isn't impressed

http://www.theregister.co.uk/2009/05/07/verity_stob_cplusplus/

There are some funny quotes in his other posts:
"The day they change the language name to ++C, that's the day I'll start taking pre-incrementing seriously."

C++0x is pronounced 'sucks' ;-).

I don't know, C++0x looks like a pretty distant reach at this point. I mean {}... seriously? Why not just automatically initialize it like most other sane languages at this point. There's no good reason not to. This is stupid.

Whining about {}?

#include <stdio.h>

int main()
{
    int n = {0};
    printf("%d", n);
    return 0;
}

This appears to be quite fine in C (you can't omit the 0 though, as you can with arrays).

If it does solve the "most vexing parse" in C++, is it such a bad thing? It's not like it would take days to learn the new initialization syntax...

It is stupid and pointless. Why can't it be automatic?

Some of that sounds useful. Some of it made no sense. The {} thing included.

I vote pointless. In fact, I expect C and C++ to retreat to the inner sanctums of systems programming and other deep internal stuff — platforms are diverging and C/C++ sits at a suboptimal position in the application development hierarchy for 90% of the code for 99% of applications. C-like languages will thrive, but with either massively improved runtimes (C#, Objective-C) that ease the various binding/fragile base class/etc problems or in areas where code is short and performance is still the major objective (OpenCL, GLSlang/HLSL, device drivers). Even games have been following this path for years, with the C/C++ stuff doing graphics and physics and LUA-or-similar entrusted with all the interesting per-level stuff.

I'm sure it'll be a lengthy transition and C/C++ won't suddenly be irrelevant tomorrow, but I don't see any real worth in attempts to further extend C++ at this stage. Take what works and re-engineer the rest ala C# if you're going to do anything — damn backwards compatibility.

I can only imagine it makes sense with templates, as it allows you to initialize a variable of an unknown base type to its own default value.
(that was about {})

C# automatically initializes variables, making junk like {} useless. C++0x should do the same if its a serious language. But then you couldn't write major applications in it, so I don't know.

Because you can expect the revenge of former C programmers? For years they have been promised that there is no extra overhead if they don't want to have their POD initialized at this point. Can you imagine that now when they have been almost won over, C++ can suddenly turn its back to them and bring in that overhead?

Former C programmers can take a hike then. If they like their ancient archaic crap, they can keep using it. Why limit usefulness of new languages because of the rare case where some masochistic C/asm programmer wants to control when their variable is initialized?

I have been playing around with C# for a couple of days now, and it seems to me that it is not entirely true. It is an error to try to use uninitialized local variables, though, and since they need to be explicitly initialized, crap like {} (or any other syntax, which is really just a minor detail) is still necessary.

It seems rather stupid to argue which of the two is that much better:

int i{}; //perhaps more obscure but useful with templates
int i = 0;

Some people can't work in C# or Python (for example: people who write drivers for hardware.)
I know next to nothing of C++0x, but if it is a new (improved?) tool available for them, I consider it a good thing.

How many drivers are written in C++ anyway? I doubt C++0x will be used for drivers.

I am sure that GCC will add a bunch of extentions that will allow you to write a mixture of C++98 and C++0x.

If I'm not mistaken, the language will be (mostly) backward compatible with the earlier standards. You will be able to write old-style C++ all along, there will just be better ways.

Depending on your definition of better. I define better as changing languages all together.

If everyone is dead set against c/c++, why are we all (THarte Excepted) writing our allegro games in c/c++ and what are we doing at allegro.cc anyway

I don't know about you, but I haven't done much game programming at all. I've been using C# almost exclusively for a while now.

I still prefer C and C++ to C#, actually. C# is the better tool a lot of times simply because it's higher level and has the .NET framework to build from (I don't dare subject myself to Microsoft's managed C++), but there are often times when the power to do something is taken away from me because of the way the language was designed. I've seen and even written, against my own intentions, a lot of really ugly C# code. C++ would benefit from a richer standard library and some more syntactic sugar. I think overall C++0x will be a good thing.

It's supposed to be an attempt to unify the syntax of object construction. You'd use it anytime except when existing constructors would interfere with added constructors. E.g

std::vector<int> vec{4}; //contains one element with value 4
std::vector<int> vec(4); //contains four elements with value 0

Where it is useful?

std::vector<int> vec(std::istream_iterator<int>(std::cin), std::istream_iterator<int>()); //that's called vexing
std::vector<int> vec{std::istream_iterator<int>(std::cin), std::istream_iterator<int>()}; //much better

I thought you were a C# boy nowadays? And I was also under the impression that a bunch of other people were, quite beside the few I know for certain are in the iPhone Objective-C realm.

There is absolutely no way I will be able to avoid c/c++ in my line of work. The problem with c++0x is that it is too little too late IMO. These things should have been included 10 years ago so I would have a hope of using them by now. By the time code-bases like ITK start accepting the changes I will be an old man.

I am at work (well, depends what I'm doing - which at the minute I have no idea as I'm working drip-feed week by week, plus almost all coding is now offshored to clueless Indian students so that's ramping down as wel), but at home I do c++ (or try to) which is predominantly allegro.

If it weren't for allegro I wouldn't be using it at all, however I do see c/c++ as the syntax father of all the languages I currently use (c#, java, php) so it's best to keep up I think.

I'm still trying to figure out why the hell you would ever want to write "auto someFunc() -> int {}" instead of just "int someFunc() {}" - my mind fails to produce any scenario where this would even be close to useful. It seems like they introduced syntax stupidities such as this (which is even worse than ={};) just for something to do because they ran out of intelligent ideas.

The Wikipedia article quotes this usage:

template< typename LHS, typename RHS> 
  auto AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) {return lhs + rhs;}

Apparently you'll only need it when the return type would depend on the types of the arguments.

Ok then. I think we've exhausted the {} debate for now.
How about we discuss something else that's new in C++0x?

I'm not gonna do the discussing though, I just think it's getting boring to follow the thread when you just argue over a single feature.

Can't you do that already with templates without that syntax though?

It makes sense, although that's probably the only time it should be used (and anybody that tries to use it unnecessarily should be shot).

They were actually just arguing about a different feature.

If you don't know what the types are then how can you know what adding them together will give you? I think that's why this exists. So the compiler knows the return type is the result of adding these types together.

It seems like quite a stretch to me.

It seems evil, but a necessary evil.

Please give a useful example of how it is useful then. The example anonymous gave is quite a stretch, how often does your return value depend on mroe than one template parameter?

In C#/.NET, when you use the + or - operator with two System.DateTimes, the result is a System.TimeSpan.

What's POD? The closest definitions I could find were Portable On Demand and Prince Of Darkness.

http://en.wikipedia.org/wiki/Pod#Computers

Plain Old Data Structures? That's PODS.

If you don't use C/C++, you shouldn't be posting in this thread, because, clearly, you don't need the special features those two languages provide.

That article is yet another FQA-like bit of nonsense... except it's about C++0x. Yes, it's not perfect, but what other choice is there when you want to do numerical programming?

Any of these would also do the job I am sure, But Fortran 2003 comes to mind.

Yeah, FORTRAN is the only serious alternative to my knowledge, but I would scarcely say that it is all that much more user friendly than the C/C++ duo.

C/C++/C++0x aren't in that list at all.

That's not a good example. I mean a useful example where you would even want to do something like the original snippet.

I remember a thread in Gamedev where someone wanted to make Vector<int> + Vector<double> return Vector<double> (or generally Vector<the_type_that_the_result_is_promoted_to>). It can be simulated (at least to some extent) with some metaprogramming, but C++0x would allow this quite simply.

It is probably not a very practical example, just something that a zealous library-writer thought would be cool.

Another thing is that perhaps it can provide a small shortcut to things that are tedious to type:

template <class T>
typename std::vector<T>::const_iterator foo(const std::vector<T>& vec);

template <class T>
auto foo(const std::vector<T>& vec) -> decltype(vec.end());

Ok, not that much shorter, and probably not entirely clear (This, I believe, would actually be simplified by template typedefs.)

It is quite likely that its main usefulness would be in template metaprogramming or with some new features like variadic templates.

In practice it's happening every time you add values of different type: they are promoted to something but you'll just assign (cast) them to some type to store the result.

-----

If I'm not mistaken, all the features don't come from some committee. Real programmers like you and me can (could) make suggestions, and then the committee would discuss which are actually good ideas, which are feasible to implement, which would break existing code etc.

auto someFunc() -> int
{ // function body...

It would be nice without the auto keyword. It looks more like a return value.

Someone who wants to do this should re-think their coding habits.
The proper solution is a utility function that takes one Vector<int> and one Vector<double> and returns a Vector<double>. Even with vectors of the same contained type, operator+ isn't intuitive - addition could be understood to mean any of:
- append all elements of A to C, then append all elements of B to C, then return C
- append all elements of A to C, then append all elements of B that are not elements of A to C, then return C
- for each element in A, find the element at the same position in B, calculate their sum, and append it to C; then return C

Facilitating something like this isn't cool, it leads to the kind of unmaintainable convoluted code the C folks are so proud of, or the kind of template abuse some C++ programmers seem to love so much.

Allegro# 2.0 this summer. (Well, 1.9 until A5 officially comes out.)

Also, I'm not digging C++0x.

The question was about the geometrical vector, not the container.

I understand that it was an entirely theoretical discussion, since in practice it probably won't be that necessary, but C++0x would allow one to implement it like this:

template <class T, class U>
auto operator+(const Vector<T>& a, const Vector<U>& a) -> Vector<decltype(a.x + b.x)>
{
    return {a.x + b.x, a.y + b.y}; //another advantage of new constructor syntax?
}

Right now what you could do is:

//lots of metaprogramming here

template <class T, class U>
Vector<promote<T, U>::type > operator+(const Vector<T>& a, const Vector<T>& b)
{
    return Vector<promote<T, U>::type >(a.x + b.x, a.y + b.y);
}

Or perhaps support just a few vector types (who needs many different types anyway) and define the int + int -> int and double + double -> double versions (if the implicit conversions work, if not also int + double -> double and double + int -> double).

I'd go for overloading just operator +=. This way, the return type is obvious, and it's up to the user to decide which return type they want:

template <class T> 
class Vector<T> {
   //...
   template <class U> 
   Vector<T> operator+=(const Vector<U> rhs) {
     x += rhs.x;
     y += rhs.y;
     return *this;
   }
}

Or ditch the overloading for incompatible types and use a static method:

template <class T> 
class Vector<T> {
   //...
   template <class U, class V> 
   static Vector<T> add(const Vector<U> a, const Vector<V> b) {
     return Vector<T>((T)(a.x + b.x), (T)(a.y + b.y));
   }
}

Or choose maintainability over cleverness and do everything with just Vector<double>, except at the very last stage, where you use Vector<int>. Then all you need is a templated copy constructor that can initialize a Vector<T> from a Vector<U>, and you're done.

But this is against convention. If the types support +=, they should also support equivalent +

Except the calls would be rather awkward:

c = Vector<double>::add(a, b);

If one is writing a library to be used often, I'm all for the one-time investment to make things more pleasant for the end user.

I've never said that the whole thing is meant to be practical... but isn't it nice if you can do it simply?

I prefer languages that discourage impractical code.

Todays C++ also discourages it.

In practice it seems that it can simplify your prototypes (a bit like I showed above, but instead with a out-of-line member function definition involving nested types as the return value) and it may have something to do with SFINAE (well, not my line).

I guess it is also a compromise with compiler implementators (if I'm not mistaken the standard committee is trying to avoid repeating the "export" mistake - a very useful feature which practically all compiler writers found too difficult to implement).

I'm not sure this argument entirely holds water. I obviously get a special pass because I'm using a superset of C/C++, but couldn't it be that someone considers the special features highly desirable rather than absolutely essential, so has an interest in the language but nevertheless on balance may find themselves not using it?

Anyway, is the linked-to article right that the optional new method of providing return-value-like functionality is designed to make more efficient use of the call stack?

Yeah, I retract that statement.

What exactly do you have in mind? This?

This is supposed to allow to avoid unnecessary copying of objects. E.g you have a local object in a function and eventually you return it. Now, rather than having it destructed at the end of the function and a copy made for returning, you can have it "moved" right into the receiving object at the point of call.

I'm not too familiar with that idea to know if there are going to be any new horrible pitfalls. It's probably also to compensate that in newer languages most everything is a reference and copies should be rather few, while not making everything a reference (perhaps that would simply make C++ something completely different than what it is, and I don't see much point in wanting it to become another C# or whatever).

With C covering the low-level, and languages like C#, Javascript covering the high-level, there's no need for the inbetween oddities like C++0x.

That's my biased C-programmer opinion.

Judging from the auto_ptr fiasco that had move semantics, I say that this moving thing will be a disaster. Imagine a move operation in the middle of a complex expression!

The academics say that destructive updating in programs is bad and should be avoided. And then comes C++0x and introduces even more destructive updating...

From the Wikipedia article:

Not that I understand these things perfectly, it seems that the point of rvalue references is to allow implementing move semantics, rather than making things move around implicitly.

P.S I'm very new to C#, but it appears such unexpected destruction of stuff is also possible (it won't lead to undefined behaviour, but shooting yourself with a rubber bullet isn't nice either):

So does this mean that low-level programming should be almost as hard as possible and high-level should insulate you from all lower-level details and there is never a case for a middle way?

Having only pure high level and low level languages would mean you need to use two different languages in your project if you wish to use high and low in different places.

I very much like C++ because it lets you go high and low whenever you need. Even though the language has some troublesome issues. I'd like to use a language that solves the issues but keeps that ability.

All of the convenience of a low-level language along with the performance of a high-level language.

I am of the opinion that C++ (or C++0x for the matter) is a great choice for those who want abstraction without sacrificing performance.
C doesn't even support the abstraction of simple classes.
A reason against using higher level languages for performance sensitive applications can be the following: In Java or C# if one creates a simple class to abstract a simple concept one necessarily incurs the overhead of having to create it on the heap. Such a little class may be used extensively and impact performance in unacceptable ways.

I am cautiously optimistic. I read some of the features, a few appear useful. However, until a commercial developer decides to implement it (like Microsoft) I doubt I will be using it in the next few years. Mostly for home made testing, but nothing serious.

This is not true.
First of all, Java runs in a virtual machine, and the implementation can use all sorts of optimizations in the JIT compilation, which may or may not allocate an object at all (just like in C++ compilation, local variables may even be optimized away completely).
Second; C# has "value types" which are always passed by value, which is the same as passing a C++ object by value. C# also offers "unsafe" mode with C++ style pointer semantics.

Stack vs. heap is rarely a performance killer these days, and if it is, the solution is to write a utility library that does the dirty work in a low level language, say, C++, and call its functions from a higher level language.
If you ask me, C++ is complicated enough as it is, with too many features and too many ways of doing the same thing for a maintenance programmer to efficiently master, and throwing more obscure features at it isn't going to make things any better.

The real performance killer is not being able to properly optimize the data cache. Doesn't matter what language.. if the generated code sucks then it sucks.

The real performance killer is arguing over this sort of stuff all of the time instead of making games with Allegro.

Funny to read that on a game programming forum of all places. Modern games (I'm talking AAA titles here, not little hobbyist projects) can benefit massively from C++'s features that C lacks, but they usually can't afford the overhead of a language like Java or C#. Even if everyone else ditched C++, I'd expect game devs would probably be some of the last holdouts.

The moving operation may be buried deep inside a function and not be visible at all.

You mean something like:

template <class T>
void swap(T& a, T& b)
{
    T tmp = move(a);
    a = move(b);
    //oops, forgot to put anything back in b
}

I guess it will add ways to shoot yourself in the foot but what I gather is that objects will not start vanishing on their own if you don't explicitly tell them to, and hopefully you'll test your functions anyway. (If this was regular swap, and you forgot the third assignment, it would be broken too.)

It seems that mostly one would provide overloads for rvalue references is for copy constructors and assignment operators. (But not all classes need them.) I wonder if those overloads would be automatically generated, if my class is entirely composed of classes that already implement those (like normal copy constructor/assignment operator today). If it was so, that would be super: I'd write code the same way as before, except STL has become more efficient...

-------
<edit>
Also, when it comes to functions having side-effects, you wouldn't call them in complex expressions even today - at least when the side-effects would concern the same value.

E.g, you wouldn't call a function that takes two strings, like this:

foo(s = to_upper(s), s);

since it would be unknown whether the second s would end up being as originally or in upper-case.
</edit>

Except if you don't know that there is a side effect, or how it works, or what data the side effect handles.

EDIT:

I've read the examples considering move constructors a thousand times, but I still can't understand why are they needed. If I wanted to quickly return a vector, I'd return it as a pointer, not as a value type.

Move semantics is silly and a disaster waiting to happen. It makes an unnecessarily complex language even more complex.

If you don't know that you'd be screwed even in today's C++. (How can you even program anything in any language if you don't know what's the effect of the functions you are calling?)

You seem to have some irrational fears that with C++0x you'd be suddenly forced to give up the common sense that you've had so far. Even now you can delete a pointer passed to any function, except you won't do that because it wouldn't make sense.

But sometimes the knowledge is not passed from one programmer to the other.

EDIT:

My advice is to forget move semantics and go with shared ptrs instead.

You still sound a bit like you worried that someone implemented render(BITMAP* buffer) in terms of destroy_bitmap. Common sense tells you that functions shouldn't have completely unforeseeable side-effects. Unless the purpose of the function is to obliterate an object, it just shouldn't do it - and the standard seems to have safeguards that this won't happen by accident.

shared_ptr is nice but probably not many people would enjoy vector<shared_ptr<string>> or even shared_ptr<vector<shared_ptr<string>>> instead of vector<string>.

Programs are not static entities, they evolve. In the evolution of a program, having to think about copy/move semantics just makes the task more difficult. And it does not scale well.

For example (I don't know if this is correct, so I apologize if it is not, but to my current understanding it seems ok):

void foo(vector<int> &data) {
    vector<int> moved_data = std::move(data);
}

int main() {
    vector<int> data = {1, 2, 3};
    foo(data);
}

What happens in the above piece of code? data is emptied at function 'foo'.

Suppose now that the call to foo is deep inside the call stack; a major problem has been created.

Typedef is your friend.

That function would be broken, unless it clearly indicates that it is supposed to obliterate your vector.

It's the same like:

class Character
{
    //...
    void render(BITMAP* buffer)
    {
        blit(image, buffer, ...);
        destroy_bitmap(buffer);
     }
};

Suppose this happens to be called deep down in a call stack...

OK, C++ is "expert friendly" and that is not going to change. You just need to know the consequences of what you are doing, e.g of calling std::move.

C++0x seems to make it more "expert friendly" in two ways: 1) you need to learn even more to become an "expert"¹, 2) when you eventually become an "expert", things look somewhat friendlier.

¹ I'd imagine the leap is not too hard for those that already are "experts" in C++.

Broken by what standards? perhaps it's a legitimate function coded by another programmer in the same project.

No, it's not the same. It's not always as obvious as in your example.

Perhaps we all need to ditch programming languages and use raw assembly then, which is expert friendly and one should know the consequences of what he is doing.

Here is another interpretation: C++ lacks garbage collection, languages like Java and C# are faster in certain algorithms due to not excessive copying like C++ does, Stroustrup and Co. are too stubborn to put garbage collection in C++, and therefore the rvalue references+move semantics is born, which simulates pointers while not being pointers.

The whole problem of copying could have been solved by providing a simple function which moves the contents of one container to another.

If you move things around incorrectly and in unwanted ways, I suppose it is just as explicit and bad as calling free on a pointer in an arbitrary function (e.g in straight C). Eventually, what language prevents you from clearing the contents of a string, where it shouldn't be cleared?

Isn't std::move exactly that? Except there has to be a way to specify what it means for user-defined objects.

void foo(X&& a);
void foo(std::auto_ptr<X> x);

If I understand correctly, these will not be destructive similarly. In the first case, this will only move from unnamed temporaries, whereas named values will be passed by reference as before.

Quite possible but how many Javas and C#'s do you think we'll need? I sort of like the deterministic behaviour of C++ programs, which I supposed would be harder to achieve with garbage collection.

You should consider the problem in the context of a group of people and code evolving over the years. For a single person and a few thousands of lines of code, the problem is small. But as the code grows larger, and more people are involved, these little changes do not scale well.

Do you know about the auto_ptr fiasco? people did not use it because of the problems it introduces, i.e. wrongful destruction of objects, especially in STL containers.

Move semantics are bad. If you read the literature about destructive updating, the academia considers it bad. Imagine then what destructive reading is.

It is, but it could have been introduced without a new type of reference.

Nope, it is not. Check out my collector here: gc1.zip

Boost members don't want garbage collection, even if it is 100% a library solution, and even if it solves the problem of finalization...

I'm not sure I quite understand the difference between copy and move for a stack allocated object...

It seems that the new kind of reference (which mostly has to do with binding to temporaries) behaves quite differently from auto_ptr.

Or, probably all the people behind the standards committee are all just a bunch of lunatics: they realize the problems with std::auto_ptr and deprecate that(?) and then go on to introduce an even more hideous feature with all the same problems and many more!

I'm still not quite sure, though, how a misplaced std::move would be more likely than a misplaced delete, free or destroy_bitmap.

It's interesting but am I not supposed to get the destructor message printed from this code?

int main() {
    gc_ptr<Foo> p = gc_new Foo;
    return 0;
}

If you mean something like an int, then move is probably same as copy.

How could it be otherwise? Every possible combination of bits in a 32 bit word maps to a valid long int. There's no way to mark it as an "invalid int" except to make it non-readable memory, which would affect the neighbors.

It's not the rvalue references that behave differently from auto_ptr, it's that they are redundant in the context of the move operation (which is the only reason they were introduced in the first place).

Or they simply wanted the STL to win back the benchmark race from Java and C#.

A lot more likely, because of the nature of the operation: programmers will try to 'optimize' the code by inserting move operations here and there, and then other programmers that their code will shoot their feet with that code.

Only if the object is garbage collected.

It's not for stack-allocated objects, it's for the contents of stack-allocated objects that are allocated on the heap.

In short, in current C++ many containers are passed as 'const' in functions, and their contents need to be duplicated. This has a high performance cost. By moving the containers instead of copying them, the code would be faster.

All of this is because copying is expensive, moving is not. Of course, you could always return a pointer, but please don't tell the C++ committee that...

Even for a complex user-defined type. What's the difference? It doesn't make sense that it could cause problems to me. It's either going to copy the object or a pointer to it. There's no way to move the memory cells.

Maybe I should just RTFM...

For example, if you have a std::string (or any pimpl object), the move constructor would look like this:

std::string(std::string&& source)
{
    pimp_string = source.pimp_string;
    source.pimp_string = nullptr;
}

It could be used to prolong the lifetime of a temporaries (or rather move the pointer over from one temporary to another without any memory allocations or deallocations) in statements like:

s = s1 + s2 + s3 + s4 + s5;

It is supposed to be mostly for moving around temporaries, that you can't have any other references to anyway. To move around named object, you'll need to be more explicit about it.

Anyway, it is (going to be) available in VC10 and GCC 4.3, and it is probably a bit hard to learn about theoretically without the means of actually trying things out.

Sadly, C++ doesn't support voodoo programming that well, even without C++0x. I still get the impression that you expect people to go completely crazy and lose common sense overnight - but I'm not a professional, so what do I know...

So in that simple program the object was not collected?

The {} "junk" is one of the best features of 0x. Clearly you do not understand its value, as there is no popular language with a remotely similar feature.

You guys should send Bjarne an email with some of your opinions (despite most of them being very short-sighted and, lets be frank, stupid). He answers and responds to most emails.

A lot of the time C++ gets caught up these arguments of "should languages be designed for just smart people or should they include dumb people?" If you feel it should include dumb people, say so. Don't project that motivation onto its features, which many very intelligent people appreciate.

It seems you are entangled in your own thoughts about common sense and stuff. Have you ever worked in a team were each programmer develops a different part of the program? I am not saying that people will lose common sense, I am saying that moving data around might make things a hell of lot more complicated than they already are.

Not if you don't invoke the collector (it's test code to prove that destructors and gc play well).

He responds, but you'll achieve nothing. The best he will say is 'perhaps for the next standard'.

{} is stupid, but it is stupid because the normal construction does not work as it should work.

I haven't, so you perhaps you are right.

However, I still don't see how it can make it that much more complicated given that there are countless ways to screw up (and not just in C++). As you said, moving can already be implemented with existing language features. Why aren't people already moving things around? OK, perhaps it just hasn't occurred to them that this could be done. But if you stay away from std::move, these references are supposed to move around only unnamed temporaries?

Reading more on the issue, there seem to be some potential annoyances:

1) It seems move constructors and move assignment will not be automatically generated. So, if you compose your classes of RAII components, this means some rather repetitious coding if you want this to happen:

2) It seems that there may be an explosion of overloads (if you want to make a super-fast library). E.g there would be swap(T&, T&), swap(T&&, T&) and swap(T&, T&&) (it wouldn't make sense to swap two temporaries).

I also looked at the draft and counted 7 new overloads for string::operator+ in addition to the existing 5 overloads.

Everywhere you have const T& now, you'll need an overload with T&& (if you want to provide for nameless temporaries).

It will give some work to library writers, but I suppose cases where you would implement this amount of overloads are limited. (I think I'm planning to take advantage of this rather passively - this should benefit STL a lot, there might be a few places where I'd use it myself, but most of the code would still be as before.)

Ok. So anything that is still in scope needs to be zeroed explicitly and _collect needs to be called?

It's all rather impressive but doesn't it mean that only one kind of shared ownership is forced on me? I'd still use a weak_ptr if some object is to be in control of how long something stays alive? Eventually, wouldn't I just end up using a large variety of resource management systems (automatic, weak_ptr, scoped_ptr, gc_ptr and perhaps some libraries which want to manage pointers for you in their own way) as before?

Nah, that's probably just your point (shared_ptr for everyone - without worries of cycles) and may be good enough for many things.

It seems to me that the sole motivation is not the "most vexing parse" (and default constructors).

Initial quote removed to cut back on post length

Actually, he responds with an intelligent reply that is rationally constructed and has accurate information about language design. Can you say that about the haters around here?

Below is taken from C++0x FAQ by Bjarne Stroustrup.

  vector<double> v = { 1, 2, 3.456, 99.99 };
  list<pair<string,string>> languages = {
    {"Nygaard","Simula"}, {"Richards","BCPL"}, {"Ritchie","C"}
  }; 
  map<vector<string>,vector<int>> years = {
    { {"Maurice","Vincent", "Wilkes"},{1913, 1945, 1951, 1967, 2000} },
    { {"Martin", "Ritchards"} {1982, 2003, 2007} }, 
    { {"David", "John", "Wheeler"}, {1927, 1947, 1951, 2004} }
  };

  void f(initializer_list<int>);
  f({1,2});
  f({23,345,4567,56789});
  f({});  // the empty list
  f{1,2};  // error: function call ( ) missing

  years.insert({{"Bjarne","Stroustrup"},{1950, 1975, 1985}});

  template<class E> class vector {
  public:
       vector (std::initializer_list<E> s) // initializer-list constructor
       {
          reserve(s.size());  // get the right amount of space
          uninitialized_copy(s.begin(), s.end(), elem);  // initialize elements (in elem[0:s.size()))
      sz = s.size();  // set vector size
       }
     
    // ... as before ...
  };

  void f(initializer_list<int> args)
  {
    for (auto p=args.begin(); p!=args.end(); ++p) cout << *p << "\n";
  }

^[1]

  void incr(int& a) { ++a; }
  int i = 0;
  incr(i);  // i becomes 1
  incr(0);  // error: 0 in not an lvalue

  template<class T> swap(T& a, T& b)    // "old style swap"
  {
    T tmp(a);  // now we have two copies of a
    a = b;    // now we have two copies of b
    b = tmp;  // now we have two copies of tmp (aka a)
  }

  template<class T> class vector {
    // ...
    vector(const vector&);       // copy constructor
    vector(vector&&);       // move constructor
    vector& operator=(const vector&);  // copy assignment
    vector& operator=(vector&&);    // move assignment
  };  // note: move constructor and move assignment takes non-const &&
    // they can, and usually do, write to their argument

  X a;
  X f();
  X& r1 = a;    // bind r1 to a (an lvalue)
  X& r2 = f();    // error: f() is an rvalue; can't bind

  X&& rr1 = f();  // fine: bind rr1 to temporary
  X&& rr2 = a;  // also fine: bind rr2 to a (an lvalue)

  template<class T> 
  void swap(T& a, T& b)  // "perfect swap" (almost)
  {
    T tmp = move(a);  // could invalidate a
    a = move(b);  // could invalidate b
    b = move(tmp);  // could invalidate tmp
  }

  template<class T> void swap(T&& a, T& b);
  template<class T> void swap(T& a, T&& b);
  template<class T> void swap(T& a, T& b);

  vector<double> v = {1, 2, 3, 4, 5, 6 }
  swap(v,{});  // clear v
      // v's old elements are implicitly deleted

^[2]

Dustin Dettmer,

thank you, very enlightening posts.

If you refer to the other thread about nuking the USA, don't pay attention to silly things like that.

But the lists have to be homogeneous...which is a lost chance for doing something like this:

Button *btn = new Window({"Close", bind(&close)});

An initializer list is a subset of tuple. They should have formalized tuple syntax...a tuple {x, y ... z} where all the members are of the same type is an initializer list.

Big caveat in my opinion.

But the constructor for Window doesn't have to take a std::initializer_list?

axilmar seems to be complaining that you can't do stuff like this:

#include <tuple>

int test(std::tuple<int, float> t)
{
    return std::get<0>(t);
}

int main()
{
    test(std::make_tuple(5, 3.05f));//works fine
    test({5, 3.05f});//errors, but theoretically a desired sort of syntax

    return 1;
}

In principle, the functionality desired is there, just using a substandard syntax.

Yeap, that's it.

I meant the people in this thread. But I was overreacting a bit anyway

There is this movement among people to hate C++ for illogical and bizarre reasons. It struck a cord in me, hearing people be so dismissive towards it.

Personally, I don't hate C++. At all. I just see myself using it less and less, because its relative advantages over other languages (runtime performance, detailed low-level control, manual memory management) are, for my purposes, being outweighed by its disadvantages (less comfortable syntax, tedious header / implementation separation, limited standard libraries, platform specific issues, diverging coding standards, manual memory management); and from what I read here, C++0x isn't going to make things much better. The new features seem to open doors to yet more of those "most obscure syntax to achieve everything in one line of code" contests, instead of stimulating best practices and maintainable, readable code.
But then, C++ shouldn't be competing with Java or C# anyway, so maybe this is a good thing. After all, C++ is not the general purpose programming language of the future, it is the programming language of choice for applications where low-level access and runtime performance are the most important decision factors, but where a high level of organisation is still desired because of the complex nature of the problem, or the sheer size of the project and / or team.

Am mentioned in the other thread. Hate is a strong word. And we use it too much. Mostly people saying "I hate" instead of "I don't like". Id do this sometimes, too. It's not good. But easy on a platform where you're hidden.

It's like Mircrosoft. Their software isn't that bad but often hated, because they are dominating the market. The letter C is dominating the Market, too. In different forms ( C, C++, C#, Objective-C, Java ). C-ish languages aren't bad. But there are other languages out there which aren't bad, too. But they are ignored by the community. Even the newer ones ( C# ) are fought.

An example:

Apple decided to use smalltalk syntax. But instead of using this nice language they created this monster, called Objective-C, mixing two really different syntaxes for C compatibility. Why they don't create a smalltalk compiler, able to create fast executables, instead?

So you can say there's movement among people to love C++ for illogical and bizarre reasons.

Curly-bracket languages (the "C-ish" ones) dominate the scene for one simple reason: They are similar enough to make the transition between them ridiculously easy.
When I learned C (after Pascal and some Basic) it took me about a year or so to really become productive.
I picked up C# in about a week to a comparable level - enough to pass a test and get hired as a C# developer anyway. I don't think I'd be able to pull this off with, say, Haskell.

In business terms; when your developers need to learn a new language, it is cheaper to pick one that resembles what they already know. And they are very likely to know some kind of curly-bracket language.

I think that when Stepstone invented Objective-C — which now happens to be primarily used by Apple — they were thinking it would be nice to be able to call the existing standard libraries immediately. In fact, this makes a whole bunch of people very happy; it makes me happy because when I'm programming OpenGL for the iPhone it still looks exactly the same as OpenGL and it makes companies like Adobe happy because all that C/C++ code they've built up over the past 20+ years for Photoshop can continue to be used.

Isn't Objective C the same as C++, only done differently? As in, extend C to natively support an OOP paradigm?

Objective C is C with the Smalltalk message passing model thrown in.

I've been doing a little of Objective C lately because our boss wants to make apps for the iPhone. Guess what? on the iPhone, Objective C does not have garbage collection! all you can do is manually increment and decrement references. And it has all sorts of crazy rules, like not throwing an exception in constructors, 'alloc' setting the ref count of an object to 1, etc.

C++ is much better in memory management in this regard. RAII is a huge huge win in productivity.

Nope, same objective and superficially similar, but the runtime is very different (mostly because Objective-C is fully reflective) and the usage patterns related to the libraries that usually go with each language (ie, STL versus the NextStep stuff) are very different.

For example, in Objective-C you can do this:

   NSString *name = <string from somewhere>;
   [self performSelector:@selector(name)];

Or indeed:

   NSArray *arrayOfObjects;

   // fill arrayOfObjects somehow

   [arrayOfObjects performSelector:@selector(name)]; // all objects in the array get a chance to perform the selector

Furthermore, the result of this:

   NSObject *object = nil; //or NULL, they're interchangable
   [object doWhatever];

Is fully defined (it'll do nothing and return nil) even though the object you're calling the method on is set to nil and that type of object doesn't explicitly declare that it responds to doWhatever. You'll get a compiler warning because of the latter, but not an error.

The former means you can chain a bunch of functions at runtime and care only about the end result, e.g.

   Texture2D *texture = [[[object property1] property2] property3];

Assuming property1, property2 and property3 are getters for classes, you don't need to test whether any of them returns nil. That's the equivalent of calling three functions and setting texture to nil if you encounter a nil anywhere along the way.

The latter is because the program is linked at runtime, not at compile time, so there's no need to generate an error. In addition, an object may implement methods it doesn't publicly declare or may want to catch any requests for it to run methods that it doesn't have. Or, in the above example, you may have a bunch of objects in an NSArray of completely different types, some of which respond to a selector, some of which don't, so the runtime needs to be able to gracefully handle attempts to call non-existent methods.

I think a lot of this stuff is what the proprietary QT precompiler achieves to massage QT onto C++. For all I know, C++ people can do broadly similar things with BOOST or something if they're willing to write all their code in the correct way, but I'll wager that if so it's more fiddlesome and much more recent than Objective-C's 1986 launch.

My understanding is also that the dynamic binding stuff is why OS X and NextStep don't have anything like the scale of issues maintaining ABIs that Win32 does. Though it's probably also because Apple are more able and therefore more willing to go through major technology upheavals and as a side effect dump all their old stuff, what with being able to control the hardware and the software.

Also, as of Version 2.0 (which is very recent), the Objective-C runtime also has optional garbage collection. But I've not looked into it, so I've no real idea about that. It certainly works so that you can write reference counting code, compile it with garbage collection on and have all the usual reference counting stuff compile to NOPs, allowing you to use the same code in garbage collected projects and non-garbage collected projects or to repurpose existing code into a garbage collected project without modifying it. But that's pretty much everything I know.

EDIT:

A lot of Objective-C is informal usage norms. To allocate a new object that takes no arguments, you could do either:

   Object *NewObject = [[Object alloc] init];

Or:

   Object *NewObject = [Object new]; // calls alloc and init

Since in Objective-C, all classes are their own class factories; you call a class method (ie, the same as a C++ static method) to allocate all new instances of a class. Subsequently, you can declare that you want to hang onto an object (ie, increment its reference count) using:

   [NewObject retain];

Or declare that you're done with an object (ie, decrease its reference count and cause it to deallocate itself if the count goes to zero) with:

   [NewObject release];

All objects are ultimately derived from NSObject, so in your init code you'd put:

   [super init]; // calls init in whatever you inherited from

Then, in your dealloc:

   [super dealloc];

There's also an autorelease pool, which you can assign objects to as the equivalent of doing a retain with no intention to subsequently do a release so that their memory does not eventually leak.

I guess you're technically incrementing and decrementing a reference count somewhere, but it's not as low level as axilmar makes it sound.

EDIT2:
Oh, alloc & initing does an implicit retain, if you see what I mean. So if you created an object and used it briefly you might have:

   MyObject *obj = [MyObject new];
   [obj doThing1];
   [otherobj doFunctionWith:obj];
   [obj release];

So you can use it at the C/C++ level if you want. The difference is that supposing doFunctionWith: had decided to keep 'obj' for later, it could have called retain and kept a pointer to the thing. As a result, it won't be deallocated when you call release and it'll be up to otherobj to free it when it is done.

Obviously you need to be careful about when you decide to take a copy of something and when you simply retain it, depending on whether you're expecting other parts of the program to mutate the value.

That why I said that the ref count is initially 1 when alloc returns.

I prefer C++ which does a 'release' automatically via shared ptrs.

I wasn't correcting you, I was expanding on what you said since I believed that at least some pure-C/C++ people would take the manual reference count changes to mean really really low level stuff. Since you've professionally researched the topic, I'd be surprised if you didn't have a thorough understanding.

I don't know shared ptrs, presumably they do something like overload the assignment operator and fix things up otherwise in their constructor and destructor?

There's another difference between Objective-C and C++ — you can't overload operators in Objective-C. And the 'standard libraries' (which I'm still taking to be the NextStep-derived stuff, including GNUStep, based on real-world usage of the language) are just generally extremely verbose.

I think my feeling about the pre-2.0 Objective-C memory handling is that it's better than C but still clearly performance oriented from the age when the 68000 was the predominant target for progressive computing. And the iPhone is just all-over weird with memory management, both the absence of garbage collection after it took so long for Apple to work it into a system that plays nicely with their desktop OS libraries and the weirdo virtual memory arrangements.

I do a lot of c++ and I'm really starting to look for alternatives. Generally i don't make "coding mistakes".. but it's really painful hunting down logic and other mistakes in c++. First of all, there is a lot of boiler plate code hiding what is going on for quick reading. Secondly, there are enough things to keep track of in the small function case yet alone for the big connected one.

Very true.

I have to type almost twice the code in C++ than in Java to achieve the same thing (except when I use Swing - then I have to type more code than Qt, but that's just the API).

Why don't you like D then? D seems to have nicer syntax, and can be more terse. You seem to be alternating between not liking small implementation details of C++, and not liking the imperative paradigm altogether. Is it something like "I'd prefer not to have C++, but if I am stuck with it, I'd prefer it to have nicer syntax", in which case I fail to see how D does not solve your issue.

1) Our customer will not accept D.

2) there are some issues with it.

I can follow this argumentation. I benefit from it, too. There is always a fight between standardization and innovation. Standardization is important. But if you standardize too much you kill the innovation.

Any innovation in one language is adopted quickly by the other similar languages, becoming a standard?

Per this post from another thread, I wonder if there are any revisions to the exception specification implementation in C++0x. Anybody know? They sound like a really good thing, but as the links point out, they end up being more of a burden or curse in current implementations.