Stroustrup's talk on C++0x

Bill Baxter dnewsgroup at billbaxter.com
Fri Aug 24 04:00:19 PDT 2007


Regan Heath wrote:
> 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 :)

Really I'd rather have something that gives a little more control. 
Returning a reference is like pulling down your pants in public.

--bb



More information about the Digitalmars-d mailing list