"Daniel Wallin" <dalwan01@student.umu.se> wrote in message news:cne6k4$dpl$1@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