Bartosz Milewski seems to like D more than C++ now :)
Szymon Gatner
noemail at gmail.com
Fri Sep 20 01:20:46 PDT 2013
On Friday, 20 September 2013 at 07:39:47 UTC, QAston wrote:
> On Thursday, 19 September 2013 at 22:46:09 UTC, Andrei
> Alexandrescu wrote:
>> On 9/19/13 3:18 PM, Szymon Gatner wrote:
>>> I had similar thoughts when watching GoingNaive 2013:
>>> http://bartoszmilewski.com/2013/09/19/edward-chands/
>>
>> Nice piece.
>>
>>> I was more and more scared with every talk and now I am
>>> valualizing my
>>> polymorphic types a'la Sean Parent
>>
>> That I think is sketchy advice.
>>
>>
>> Andrei
>
> What Sean Parent does in his value semantics talk is basically
> an interface adapter for a struct, wrapped in a struct
> providing implicit conversions.
>
> By using structs by default and adapting them to interfaces as
> needed you get to have the smallest possible overhead on a
> single function call - either no virtual dispatch or 1 virtual
> dispatch. When writing adapters to interfaces you get 2 or more.
The struct was only an example, obviously you can use proper
class implementations with data hiding etc. You will also get at
least 1 virtual call because a "concept" is always an abstract
class.
That being said, I've been using this technique in other places
in my code this far too, for example: my C++ ranges (yeah idea
stolen from D) are templates so can be composed for free but
there are abstractions like InputRange<> which "erase" (this word
is stupid btw, no type is erased really) underlying type and
provide convenient abstraction in places. I also use this
technique for my std containers. Vector is a std::vector with
polymorphic allocator, again it holds Allocator<> by value but
underlying implementation is (often composition) of allocator
templates. In allocator's case I do explicitly want container
alloc to be polymorphic type so that my interfaces never depend
on allocator type.
Difference now for me is that I did sometimes turn value types
into polymorphic types using this technique (like with
allocators) but it never occurred to me that other wan can be
beneficial too.
>
> The other benefit is that approach is reducing dependencies you
> need to know about when you use the wrapper type - the approach
> would not work in D due to lack of argument dependent lookup so
> you need to write the adapter type (for a particular type you
> want to convert) yourself anyways. And I think it's better that
> way.
>
> In the end the whole thing is just adapter design pattern
> applied to C++.
Well Adapter is suppose to *change* interface to adapt to client
needs so this is a bit of a strech to call it that here, but
yeah, this technique called ("external polymorphism" idiom) can
be used to adapt . This really just is a (smart)pointer with a
full interface of underlying object (which also adds benefit or
using "." instead of "->" on target).
More information about the Digitalmars-d
mailing list