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