Stroustrup's talk on C++0x

[Bill Baxter]

Bill Baxter wrote:
> Walter Bright wrote:
>> Bill Baxter wrote:
>>> Walter Bright wrote:
>>>> C++0x's new features are essentially all present in D 1.0.
>>>
>>> ..but C++98's features that were missing from D are still missing 
>>> (both good and bad ones).
>>
>> Like what? Virtual base classes? Argument dependent lookup? #include 
>> files? C++ can keep them <g>.
> 
> The things that have me banging my head most often are
> 1) the few things preventing an implementation of smart pointers 
> [destructors, copy constructors and opDot].  There are some cases where 
> you just want to refcount objects.  This is the one hole in D that I 
> haven't heard any reasonable workaround for.  I don't necessarily _want_ 
> copy constructors in general but they seem to be necessary for 
> implementing automatic reference counting.

Sorry for the self-follow-up, but I just wanted to add that really C++ 
smart pointers are themselves kind of klunky due to the fact that _all_ 
you have access to is that operator*/operator-> thing.  So for instance 
if you make a boost::shared_ptr<std::map>, you end up always having to 
dereference to do anything interesting involving operator overloads. 
mymap["foo"] doesn't work, you need to use (*mymap)["foo"]. What you 
really want most of the time is something more like "smart references".

This kind of thing is coming close to possibility with the reflection 
stuff some people are doing.  Basically shapred_ptr!(T) would do 
introspection on T and populate itself with basic foward-to-T 
implementations of all of T's methods.

But that seems kind of heavyweight to me.  All you really want to do is 
define a fallback -- when the compiler sees foo[x] and foo is a 
shared_ptr!(T), there should be a way to tell it to check T for an 
opIndex if the shared_ptr itself doesn't have one.

That would handle the access syntax.  But that still leaves the 
destructor/copy constructors necessary to get a real smart pointer.

> 2) lack of a way to return a reference.

This would also be less critical given a way to fall-back to a member's 
implementation.

> 3) From what I can tell "const ref" doesn't work for parameters in D 
> 2.0. Oh, and
> 4) real struct constructors.  Just a syntactic annoyance, but still an 
> annoyance.

--bb