> > Sorry for following up on myself, but could I have a
> quick
> > poll? Please make at most three suggestions for C++0x.
> For
> > each, give a max two lines of explanation of what is
> > wanted and max two lines of explanation why it is
> wanted.
>
> 3. Move semantics
> what: ability to "move" objects rather than copy them
> why: improved performance especially when dealing with
> containers.

There exists an "rvalue references" proposal that enables move semantics, and I think this was kind of accepted "in principle" at the Lillehammer-meeting, and sent to the the Core Working Group for further consideration. I see from the minutes of the following Tremblant meeting last fall, that they haven't yet got a chance to consider it, though: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1915.html

However, there already exists proposed wording for it: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1770.html, as well an extension to cover *this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm.

So this one is pretty certain.

"rvalue references" both enables move semantics, and solves the "forwarding problem" (at least the part involved with the type of the parameters).

As for lambda: Well, as it's not on any list of active proposals - for that matter, I haven't seen any (in)formal proposal for this... I wouldn't bet on it. :) However, if someone did the work of making and following up such a proposal, including, in particular, what it would take to implement it, such as its effect on the rest of the language, then who knows...

Modules: At least it's under active consideration (a proposal for it was presented at the Lillehammer meeting), but I don't see it mentioned in the Tremblant minutes.

> Such as optimising the program, due to the effect of the
> garbage collector? :)
>
> Sorry, I couldn't resist. :) As mentioned in another
> posting, garbage collection doesn't _remove_ the problem
> of resource management, only _changes_ it, with different
> "gotchas", and it only handles memory, which doesn't
> necessarily make resource management easier, and could
> make it harder.

I absolutely agree. But GC is very useful because many computational problems do not have other types of resources except memory. GC is important.

>
> However, as this is a suggestion for an _optional_ feature
> (and your posting wasn't intended to restart that
> discussion, I guess), then using it is at least
> voluntary.

Yes, totally optional. With C++, "you don't pay for what you don't use".

>
> Moreover, I've heard that, for some scenarios, GC may be
> faster than reference counting (some call the latter a
> kind of GC, anyway, but with GC, here, I mean a
> "traditional" one, such as no support for destructors),
> such as in a multithreaded system, due to locking issues
> (the reference count may need to be locked for each copy
> made, or at least the use of atomic instructions).

Even if GC makes programs a little slower, you have to question yourself what is better: a) to have manual memory management, utra-fast execution but very slow development or b) automatic memory management, slightly-less fast execution but quick development?

And as I have said before, GC for C++ does not mean GC for Java. Since most C++ objects live in the stack anyway, the only objects to be managed by GC in a C++ program are complex arbitrary structures, usually defined by run-time rules, and many times with cyclic references.

> May I suggest you post this poll announcement as a
> separate entry, maybe into your artima weblog? Buried like
> it is in a seven day discussion log, it might not get as
> much attention as possible.

Yes. I know. I'm kicking myself for not suggesting it earlier.

This kind of poll is something I have done many times before, mostly at users' group meetings and BOFs. In addition to giving me valuable information it tends to educate to participants about the (to them) amazing diversity of opinions/needs/suggestions. Usually, the union of 50 people's top two or three choices is 50+ distinct suggestions.

I don't have a blog.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Hello Dr. Stroustrup,

> Sorry for following up on myself, but could I have a quick
> poll? Please make at most three suggestions for C++0x. For
> each, give a max two lines of explanation of what is
> wanted and max two lines of explanation why it is wanted.

1) Portable GUI - because the need comes up so often. But since the odds aren't good here, I'll list 4 items rather than 3. :-)

2) Threads/Synchronization - because there's an increasing need for multi-threaded software.

3) Sockets - because we need portable, type-safe and exception-safe interfaces for communication between distributed systems. Finding a design that supports the right mix of exception-safety, performance, and platform-independence (while still allowing platform-specific functionality) isn't the most straight-forward of problems.

4) Matrix/Vector Linear Algebra - because various aspects of this functionality seem to get "re-invented" a lot. but this one's obviously a little more specialized than the others.

-Greg

> > Moreover, I've heard that, for some scenarios, GC may
> be
> > faster than reference counting (some call the latter a
> > kind of GC, anyway, but with GC, here, I mean a
> > "traditional" one, such as no support for destructors),
> > such as in a multithreaded system, due to locking
> issues
> > (the reference count may need to be locked for each
> copy
> > made, or at least the use of atomic instructions).
>
> Even if GC makes programs a little slower, you have to
> question yourself what is better: a) to have manual memory
> management, utra-fast execution but very slow development
> or b) automatic memory management, slightly-less fast
> execution but quick development?

Yes, my concern is mainly optimising developer time - trying to optimise the code in the Java project I worked on, due to it being too slow from GC-trashing, was certainly not very optimal on developer time, and in that case, I think stack-allocated objects, and perhaps some reference-counting, or other ownership strategies, like a hierachical parent-child one, would have done just fine, and saved me from that problem. But a) C++ wasn't an option (having to work in a browser), and b) GC in Java is mandatory, not optional.

However, there may well be other projects, or features, that could be hard to do well in other ways than using GC. The problem is when all you have is a hammer... :)

> And as I have said before, GC for C++ does not mean GC for
> Java. Since most C++ objects live in the stack anyway, the
> only objects to be managed by GC in a C++ program are
> complex arbitrary structures, usually defined by run-time
> rules, and many times with cyclic references.

C++/CLI has such a scheme, where you can both have stack-allocated objects and RAII, as well as GCed objects, all working well with CLI/CLR.

> This kind of poll is something I have done many times
> before, mostly at users' group meetings and BOFs. In
> addition to giving me valuable information it tends to
> educate to participants about the (to them) amazing
> diversity of opinions/needs/suggestions. Usually, the
> union of 50 people's top two or three choices is 50+
> distinct suggestions.

Maybe some of the effect is due to people not wanting to repeat what others have already suggested, so they select other proposals that haven't been proposed, yet?

One way to alleviate that concern could be to have "secret voting" (however, maybe that's how you did it, sometimes). However, even then, there might be some of the same effect ("Many will probably propose feature X, and I'd like to have both X and Y, so I'll propose feature Y, giving that a chance, as well.").

At least, phrased as it was ("Please make at most three suggestions for C++0x"), it doesn't state that you should propose your three _most wanted_ features (even though that might be intended, implicitly), so the result might exhibit the above mentioned effect to some degree.

I'm sure that even without such an effect, there would still be a large number of distinct proposals, though.

> > This kind of poll is something I have done many times
> > before, mostly at users' group meetings and BOFs. In
> > addition to giving me valuable information it tends to
> > educate to participants about the (to them) amazing
> > diversity of opinions/needs/suggestions. Usually, the
> > union of 50 people's top two or three choices is 50+
> > distinct suggestions.
>
> Maybe some of the effect is due to people not wanting to
> repeat what others have already suggested, so they select
> other proposals that haven't been proposed, yet?
>
> One way to alleviate that concern could be to have "secret
> voting" (however, maybe that's how you did it, sometimes).
> However, even then, there might be some of the same effect
> ("Many will probably propose feature X, and I'd like to
> have both X and Y, so I'll propose feature Y, giving that
> a chance, as well.").
>
> At least, phrased as it was ("Please make at most three
> suggestions for C++0x"), it doesn't state that you should
> propose your three _most wanted_ features (even though
> that might be intended, implicitly), so the result might
> exhibit the above mentioned effect to some degree.
>
> I'm sure that even without such an effect, there would
> still be a large number of distinct proposals, though.

I have tried either way; that is with or without an hours discussion before the vote. A discussion sways people to pick a few top choices from the discussion, but there is still a large spread of "second or third choices". Conversely, there tend to be front runners even without a discussion, but interestingly those front runners vary from community to community. "Can you give use the data?" is an obvious question. I can't really, I simply integrate my impressions in my talks, papers, and wish lists (see my C++ page).

Obviously, the committee's choices are consistently more "technical" than the choices for any user community.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

/* but could I have a quick poll?
*/

Aside from the new use for "auto" and concepts, I'd like:

optional C++ extensions to macro system
what: Add extensions to the preprocessing macro system such that old C macros work, but that programmers can take advantage of macros defined at a "conceptual level" instead of at a textual level -- perhaps by adjusting the parse tree instead of the source code.
why: While C++ features like templates and const data can elliminate the need for many C macros, some programmers like the possibility of adding keywords to their own programs, without being constrained by template syntax, etc. This generalized construct sould then be used to define "pass by name" or similar wishes.

And, yes, I know that this is asking for quite a lot, and that any feature giving access to the parse tree would be implementation defined. I'm not holding my breath.

But, I also want:

standardized locales
what: Currently the locale system is somewhat "implementation defined," although the direction is to allow programmers to build up messages from a catalog of translated strings. Change this to have a specific interface.
why: Currently programs using locales are officially standard C++ but may not be portable.

All
overloading by result -

struct var
{
private:
	float a;
	float b;
 
public:
 
	var(float _a, float _b) : a(_a), b(_b) {}
 
	operator int() { std::cout << "get int !"; return (int(a) & (int)b); }
	operator float() { std::cout << "get float !"; return int(a * b); }
};
 
 
int main_()
{
	float x = var(1, 2);
	int  y = var(1, 2);
}

GC -
simple reference counted smart_pointers are enough in most cases. But it's possible to write overcomplicated smart pointer, which can resolve "circular dependency" problem and there are industrial GCs for C++ (Boehm GC, f.e.)

lambda - if '__typeof__' keyword will be introduced, then we can just use boost::lamda/phoenix - like libraries, which deduce all types.


auto - IT'S GREAT! I'm missing it and vomited on BOOST_FOREACH-like hacks. will typeof/decltype feature be implemented? It's even more important, because 'auto' can be emulated -

#define AUTO(var_name, initializer) (__typeof__(initializer)) var_name = initializer;

but auto can't solve problem for _type_ deduction, nor declaration variables -

----------------------------------------------------------------

template <class T> __typeof__(false ?: a : b) 
Max(const T &a, const T &b) { return a < b ? b : a }

----------------------------------------------------------------

template<class A_Function, class B_Function>
struct bind_sum_t
{
	A_Function a_foo;
	B_Function b_foo;
 
	bind_sum_t(A_Function _a_foo, B_Function _b_foo) : a_foo(_a_foo), b_foo(_b_foo) { }
 
	template <class X, class Y>
	//__typeof__(a_foo(x) + b_foo(y))
	int
	operator()(X const &x, Y const &y)
	{
		return a_foo(x) + b_foo(y);
	}
};
 
 
//mimics boost::lambda    (_1 + _2)
template<class A_Function, class B_Function>
bind_sum_t<A_Function, B_Function> bind_sum(A_Function a_foo, B_Function b_foo)
{
	return bind_sum_t<A_Function, B_Function>(a_foo, b_foo);
}

----------------------------------------------------------------

Will there be the __typeof__/decltype keyword ?

Properities -
You are bored on SetValue/GetValue?

Use overloaded function Value instead.

if name of method is noun - than it's not action, it's property.
 
class Bar
{
private:
	int m_iWidth;
 
public:
	int Width() const { return m_iWidth; }
	void Width(int w) { m_iWidth = w; }
};

usage:

m_pBar->Width(10);
int w = m_pBar->Width();

There is no syntax overhead! Neither at property declaration, nor at usage.
Operator '=' is just Delphi/C# syntax sugar. And, of course, there are lots of C++ wrappers that can do this via overloaded operator= (for example, http://www.livejournal.com/users/_winnie/17358.html ^_^ - without memory/speed overhead, without handmade tedious initialization in constructor)

C++ Demiurge

How about attributes / reflection ? Managed C++ / C++/C++ prove that it can be integrated to C++. I'm bother with thousands "C++ reflection" and "C++ serialization" and "C++ advanced C++ RTTI" projects, and "CObjectBase" in each frameworks and custom fast implementation of "IsKindOf" in each framework(because dynamic_cast is slow/insufficient).

What about 3D math?
Every company/university lab has it's own math library. Sometimes two or three :) (Look at any free game engine / quake / etc…). Of course, this is math libray use SSE. And they are all not compatible. And they all compatible via (SGI_Matrix*)(float *)&IBM_Matrix44.


Why we should complicate С++ with initializes array?
I see initialization of dynamic containers only in test/'learning exercise'/sample code, not in industrial code. And even in test there it can be solved with boost::assign for perverts or good old-fashioned

int a[] = { 1, 2, 3, 4, 5, 6 };
std::vector<int> vec(a, a + ARRAY_SIZE(a));

It's not a problem at all!

Why we should complicate С++ with '>>' template parameter list ending?
There a lot more complicated problems for beginners -
what is string literal? "hello world"? What is proper copy-constructor? How should I manage resources, so they won't leak when exception is thrown? What is pointer and why array are not pointers? Where I should use char * and where - std::string? A lot, lot, lot old-C questions about memory and pointers, but without whitch nobody can write robust C++ programs.
And >> in templates is compile-time ill formed program, so it's safe. And good compiler can warn -

And, of course the main beginner question - what is difference between . and -> and why in C# and other flooffy languages there is only . ?


error: `>>' should be `> >' within a nested template argument list

or less informative -

error C2947: expecting '>' to terminate template-argument-list, found '>>'

And why do you not eliminate "no end of line at the end of file", which is UNDEFINED BEHAVIOR, and a lot of such no meaning details, if proceed the >> in templates?

Which _really_GREAT features will be in C++0X ? Which ones can allow programmer programmer to use libraries, which will extend human ability to express his intentions to computer in C++ language. Sorry, I can't follow open-std/wg21 / n####.pdf's, there are heaps of them :(

Thank you for the greatest and fastest null-overhead all-purpose language. Which is so powerful, that he can eat and mimics any other programming language.

Thank you.

PS. sorry for my funny poor Enlish, it's more difficult than C++ ^_^

misprints:

С++ -> C++
C++/C++ -> C++/CLI

> > and there are good garbage collectors "out there".
>
> Hmm... maybe, but I think GC is such a kind of feature
> that it better have language support. Like exceptions.

Maybe, but conservative GC is far better than its reputation (in some places). For example, see Hans Boehm's website (linke here: http://public.research.att.com/~bs/bs_faq.html). He has real data, and lots of it.

One example: modern copying GC requires availability of about twice the memory that you ever use (so that you can copy). And that doesn't count data (such as indirections and per-object data) used to manage the free store objects. A conservative memory manager has much more memory to play with.

-- Bjarne Stroustrup; http://public.research.att.com/~bs

> One example: modern copying GC requires availability of
> about twice the memory that you ever use (so that you can
> copy). And that doesn't count data (such as indirections
> and per-object data) used to manage the free store
> objects. A conservative memory manager has much more
> memory to play with.
>
> -- Bjarne Stroustrup; http://public.research.att.com/~bs

The last GC I sent you did not require availability of twice the memory you ever use, and it was a copying one. It also did not use indirections, as each pointer points to the real objects and not to another pointer, and the per-object data needed where minimal (16 bytes, if I recall correctly).

Regarding the discussion about GC and developer productivity. I'm a little wary of the request for, or promotion of, GC, as it may contribute to an ignorant attitude to, or bad habit of, resource ownership management. Given that GC doesn't automate this fully, in particular not lifetime management, at all, this may lead you into more troubled water, later in the life of the project.

To use an analogy: Would it be better use of your resources, if you, in a house:

a) Fetch things from where they are stored, and put them back again when you're done with them.

b) Fetch things from where they are stored, and just drop them on the floor when you're done with them, and hire a maid to regularly clean up after you...

I remember learning Java, coming, as I did, from C++, where you're used to "clean up after yourself", and starting to just "drop things on the floor"... It just felt unnatural: "But I know I'll not need this object, anymore, can't you just delete it right away?".

This may lead into an "illusion" that you don't need to care about memory ownership issues, until you meet the wall, one day, where you run out of memory, or the GC trashes, and you learn that you may have to set long-lived references to null, or the objects they refer to won't be collected, and that if you create lots of objects, in particular big ones, that are needed for a short time (like the Image objects in my project), you may run into such problems.

So... You may come to, at least for some applications, that the memory management issues could be _easier_ with RAII and smart pointers, because you only heap-allocate what you need to heap-allocate, and you get very specific, deterministic lifetime of it (and you might use memory pools, etc.), than with an unpredictable GC.

For example, if you need to explicitly null references, for them to be collected, what have you gained? You may run into _harder_ problems, trying to figure out what references are kept where (there may be large structures "kept alive" with a reference that in reality is no more used, but can't be collected because of it).

Someone (I think it may have been Robert C. Martin in "Agile Software Development") made the analogy of keeping your code in shape, to working in a tidy kitchen: Everyone knows it goes fastest to prepare food in a tidy and clean kitchen. You may save a little time, by not cleaning up after you, but the accumulating cruft will mean that it takes longer and longer to make food (finding things, and clean them, as you need them), and ultimately you'll use much more time in this way, in total, than if you kept the kitchen tidy and clean, throughout.

It feels a little similar with GC: Sure, you can just "drop things on the floor", but it may make you slower in the long run.

> Regarding the discussion about GC and developer
> ...
> This may lead into an "illusion" that you don't need to
> care about memory ownership issues, until you meet the
> wall, one day, where you run out of memory, or the GC
> trashes, and you learn that you may have to set long-lived
> references to null, or the objects they refer to won't be
> collected, and that if you create lots of objects, in
> particular big ones, that are needed for a short time
> (like the Image objects in my project), you may run into
> such problems.

I do not think that having GC will contribute towards bad resource management habits. The "you don't pay for what you don't use" comes with "you must know what you are doing". Because it's impossible to know how to do the first without knowing the second.

>
> So... You may come to, at least for some applications,
> that the memory management issues could be _easier_ with
> RAII and smart pointers, because you only heap-allocate
> what you need to heap-allocate, and you get very specific,
> deterministic lifetime of it (and you might use memory
> pools, etc.), than with an unpredictable GC.

As I said before, GC should be optional. If the programmer wants to use RAII and smart pointers, then so be it. If he/she wants to use GC though, why not allow it?

>
> For example, if you need to explicitly null references,
> for them to be collected, what have you gained?

No, nullifying a pointer is different from deleting an object. Because when you nullify a pointer, you only mess with one reference to the object, but if you delete an object, you mess with all references to that object.

> You may run into _harder_ problems, trying to figure out what
> references are kept where (there may be large structures
> "kept alive" with a reference that in reality is no more
> used, but can't be collected because of it).

It's easier to comprehend when a reference should be nullified instead of comprehending when an object should be deleted. And the more complex the algorithm becomes, the more difficult it is to comprehend the right spot for object deletion.

And if the algorithm at hand has cyclic references, then using smart pointers requires placing weak pointers at specific places in order to avoid cyclic referencing, something which is increasingly difficult as the number of involved objects increases, and sometimes is outright impossible, since a pointer must be both a weak and a smart pointer.

/* The last GC I sent you did not require availability of twice the memory you ever use, and it was a copying one. It also did not use indirections, as each pointer points to the real objects and not to another pointer, and the per-object data needed where minimal (16 bytes, if I recall correctly).
*/

This truly sounds cool, but I can't find the post where you linked to this GC. Could you repost the link?