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..
and with the problem of keyword coupling (because of the integer
indices).
What do you mean by coupling? That we need to supply unique integer id?
Yes. You can't develop keywords independently.
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! It has to be coupled with the function. Keywords needs to be reusable between different functions.
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? -- Daniel Wallin