Stroustrup's talk on C++0x

[Regan Heath]

Bill Baxter wrote:
> 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.

Funny, after reading you post I was thinking that you would provide a 
way to fallback by returning a reference :P

eg.

ref T opDereference()
{
   return ptr;
}

which would then automatically be called when using [] . etc on a T*

I guess we wait and see what Walter cooks up for us in 2.0 :)

Regan