|
Boost : |
Subject: Re: [boost] Formal Review Request: TypeErasure
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-06-08 06:58:04
Nevin Liber wrote:
> On 7 June 2012 16:14, lcaminiti <lorcaminiti_at_[hidden]>
> wrote:
>
> > What if this were possible? Would this be an acceptable way
> > to add custom concepts?
> >
> > BOOST_TYPE_ERASURE_CONCEPT(
> > concept (sable) ( class S )
> > (
> > void member_body(S, f) ( void ) ,
> > void member_body(S, g) ( void ) ,
> > void member_body(S, h) ( void )
> > )
> > )
>
> It would certainly help a lot. If we want people to replace
> the common idiom of creating AbstractS and storing the
> instantiated object in unique_ptr<AbstractS> (or a different
> smart pointer), the replacement needs to be almost as easy, at
> least for that very common case.
Given the current language constraints, that would be a help. However, the question was what should be added to the language to make this nicer. What's more, the use of such macros compounds the problems of templates (long backtraces, no concepts, etc., some of which Steven may well have addressed), by putting everything on one, obscure line (so far as the compiler sees it).
I agree with you, Nevin, that it should be little more difficult, if any, than just declaring an ABC for the interface. Sebastian's suggestions of compile-time reflection and declaration injection, if feasible, might be just the ticket. Whatever turns out to be most general, without exposing too much implementation detail which ties implementer's hands, would be nice.
_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP http://www.sig.com
________________________________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk