I think that your design is based on unspecified behavior, and, given
Fernando wrote: that
there are equally valid alternatives, this is unjustified.
Upon reviewing the code it turns out that I use static_cast in the implementation of mimic. I must have used reinterpret_cast originally and then changed it to static_cast after some code review with Gyuszi. static PointConcept& mimic() { return static_cast<PointConcept&>(t); } I am using autocast on the return value of yield to convert to the base type T& yield() { return *this; } Let's please rewind the conversation. Using composition instead of inheritance would require reinterpret_cast, as I understand it, so perhaps we should decide together if that is really a change I should make. Is the suggestion to use composition a bad idea? Is it based on unspecified behavior?
But the C++ type system doesn't support "mimicing". These functions, by name alone, speak by themselves: they are unusual hacks. (not the mentioned that yield is strongly associated with something different)
Well, given the widely known, well documented and proven adaptation
commonly used here in Boost, which is ignificatly different from the one >you are proposing, you need to make an unusual effort and convince us that
The C++ type system doesn't support it *yet*. I will probably change the name to something more appropriate that relates it to the c++0x proposal for concepts and concept_maps (map_to springs to mind,) doubly so for yield. I was expecting to change the names of just about everything based upon the feedback I get from boost. pattern this
"mimic" hack is a actually good example.
Keep in mind that submitting a library to boost not always means that
Again with the hack. Let's not resort to four letter words. ;) the
design/code is accepted in the form it was originally created. Sometimes, if not often, acceptance requires a complete re-design and/or re-implementation.
That same happens with software, relying on facts that "ought to be
I've had that in mind from the beginning. I am currently considering switching from inheritance to composition, and plan to try that out today to see if it causes any problems. In the end it may be that I to completely transform the library, but if there is nothing left of my original idea because I adopt all of yours, what would be the point of accepting it into boost? It is my hope that there will be some synthesis. If it is just an issue of non-member, non-friend style being in favor now vs. classes with a rich set of member functions I don't think I would ever switch. I am quite clearly encapsulating the data in the data type and using the concept type to organize the set of behaviors the concept is providing for that data. Our use of the language should be based upon an understanding of the benefits and drawbacks of what we are doing, and not simply guided by a pseudo code algorithm from one of Scott's books. true"
when we don't really know is risky, and risks are taken only when there is >a good reason for it. In your case, I don't see any.
Yes, it does happen with software. The point of the anecdote is that we ought to be able to do better than the monkeys. Luke