From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-11-16 20:54:47
"Daniel Wallin" <dalwan01_at_[hidden]> wrote in message
> Gennadiy Rozental wrote:
> > Yeah. In this case keyword "value" couldn't be typed. Ok. I slightly
> > reworked my code see attached. Now it supports both typed and non-typed
> > keywords. all in 120 lines (I am sure it could be made smaller by more
> > effective mpl use).
> It's only 120 (instead of 800) lines because you haven't implemented the
> features and workarounds that our library has. It's not like we've
> written ~600 lines of useless code that can just be eliminated..
My code works without *any* modifications on:
vc6.5 (well this guy does require to change typename to
BOOST_DEDUCED_TYPENAME in couple places, but that's it)
Don't have other compilers to check.
> > I do not see to many differences from your solution. You also need
> > for the keyword, which you then organize in ordered structure. So
> > essentially getting the same result.
> But the type should never be part of the keyword!
Well, I strongly disagree here.
> It has to be coupled with the function.
> Keywords needs to be reusable between different functions.
Why would I want this: In one place parameter abc is string in another is
float? IMO it's very rarely make sence and I would use non-typed keyword in
this case. In majority of the usage cases I would use typed one though.
> >>Yeah, but you don't need PS to cause ETI and other issues on VC <= 7.0
> > Do we still care?
> I don't know if you do. But there are certainly other people who do.
> > Enough to affect the design/implementation?
> We have made NO compromises in the design of this library to help less
> capable compilers. What does it matter if the implementation contains
> workarounds? Why do you care?
I don't , but I did not bring it into discussion. My point is that it
shouldn't matter and shouldn't come up. If you do support it - good, if
not - ... also good.
> Daniel Wallin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk