[boost] Re: Named params lib review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-11-16 20:54:47

"Daniel Wallin" <dalwan01_at_[hidden]> wrote in message
news:cne6k4$dpl$1_at_sea.gmane.org...
> Gennadiy Rozental wrote:
> [snip]
> >
> > 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:

gcc 2.95.3
gcc 3.2.3
gcc 3.4.2
borland 5.6.4
cw 8.3
vc7.1(+/-stlport)
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
unique id
> > 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