At Mon, 27 Sep 2010 11:18:47 -0800, Robert Ramey wrote:
My experience was in trying to apply this to the serialization library.
That is, admittedly, a tough one.
My example was
ar << t;
where t is of serializable type T and ar is an instance of an Archive class
The "archive concept" would admit a wide variety of semantics. The archive classes included in the library include code for deep copy/recover of pointers to polymorphic classes. But in another context, such as one which only displays data for debugging, one might implement this functionality as just a top level display so that he can make a header only version.
Well, there's license to break almost any rule when debugging :-) Try to come up with a non-debugging example.
So here one has two useful widely varying implementation symantics with exactly the same syntax requirements. Is it wrong to use concepts here?
No, but you'll need decide what the abstraction's (abstract) semantics are if you're going to document/understand the code as anything more than an English-language translation of its exact implementation (which would be pretty useless as documentation). As soon as your documentation is something more than that, there are abstract semantics involved. You can build and use concepts that have no attached semantics, but you can't say anything interesting about what the code using those concepts "does."
Is it wrong to make such a library? Is is wrong, to "hijack" a types concepts for unintended uses?
I don't have a moral judgement about this. The only right/wrong position I'm taking here is about the interpretation of the term Concept. I happen to know what it was intended to mean, so I can speak with authority on that.
I concluded that it not really possible to specify symantics and any formal or rigorous way without actually writing the code itself.
I recall a conversation on this list where someone (named Sebastian?) successfully, and impressively, described a semantic relationship required between the load/save operations of a read/write archive pair. The fact that it's hard to do doesn't make it a pointless affair. Until you've done it, you have at best an "intuitive feel" for the problem your library is solving.
It doesn't make the idea of validation of template parameters useless, it just puts a limit of one can realistically expect from it.
That's unrelated to the rest of the conversation, because as I have stated many times, validation of template parameters by computer can never check semantic constraints. It's equivalent to solving the halting problem.
Of course the nomenclature doesn't help any either.
Sorry, I don't know what you're talking about here.
I was referring to the usage of the word "concept" in this context. I found this to be very misleading and not at all descriptive of the the function of "checking template parameters at compile time"
Because that's not what a concept is. That's just one of the most important things you can do with a concept. Concepts are about mathematical abstraction. -- Dave Abrahams BoostPro Computing http://www.boostpro.com