At Wed, 15 Dec 2010 16:52:10 -0500, Matt Calabrese wrote:
On Wed, Dec 15, 2010 at 4:06 PM, Matt Calabrese <rivorus@gmail.com> wrote:
Marcin Zalewski answered this in a more recent reply in this thread -- apparently the last draft with concepts specifies that the two concept maps are checked for compatibility. There is an error if there is conflict. I should probably be able to do something similar in Generic, though it may end up being complicated (and complicated is a relative term with respect to the library already). With the implementation I'm imagining I can already see an ODR issue that would be tough, but not impossible, to account for.
Actually, I'm going think about this for a while. Even though Steven's answer wasn't accurate, at least with respect to the last draft with concepts,
There was never a draft that required maps for all the parent concepts.
I think his answer is much more feasible to implement
Well, that's an important criterion.
and should be just as capable, even though it unfortunately requires those who are writing concept maps to split up the implementation among the refinements. Given that concept map definitions are often empty anyway, I don't think this should be too horrible. Which direction I go can mean the difference between having things implemented in a couple of weeks vs months, so I'll probably end up using Steven's approach for now, but I'll try to leave open the possibility for more true-to-c++0x behavior in the future, since I think that would ultimately lead to the most concise code for programmers creating concept maps.
If anyone notices a problem with Steven's solution please bring it to my attention as soon as possible since I'm likely going to devote a bit of time to implementing it.
I think from a usability perspective it's problematic, and could impair adoption, but I see nothing wrong with using it as a stepping-stone. -- Dave Abrahams BoostPro Computing http://www.boostpro.com