Returning to the original question, the best two solutions I see at this point are as follows:
1)require the user to instantiate* Holder with an instance of derived using a constructor argument. This argument will always be the same.
2) Create an init macro that sets the correct value of held.
*I'm using the OO term here, not the template term.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Making functionality depend on compilation units seems like an anti-pattern to me. Compilation units/files are meant for organization, not functionality.
I'm trying to decrease dependencies. Using this method I can make code included only when two headers relevant headers or included. You can read the thread I linked to earlier, for more information on the problem.Originally Posted by robwhit
Technically, this won't make the compilation units visibly functionality different. The code will be different, but the result should be the same.
Last edited by King Mir; 05-31-2008 at 11:56 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Function definitions declared static, anything in the "anonymous" 'namespace', templates producing source relying on "private" types when instantiated, and probably others, but I'm lazy.Just covering my bases. Do you mind defining "private" definitions?
I don't doubt you one bit, but I will say that the standard is the standard. (I can't recall the example.)The book provides a remarkably similar example of how unnamed namespace objects can result in violations of the ODR, when argument defendant-lookup is involved.
I'm fine with individuals asking for clarification. (I'm fairly certain that CornedBee understood. I'm equally certain that you and Codeplug didn't.) The contention, at heart, is over the application of the "one definition" rule to constructs the rule does not list.Repetition may be called for.
This is the simplest I can phrase the idea: infinitely many template and template specialization possibilities are not listed as being subject to the rule and if the rule is applied recursively there is no point in disguising the instantiation behind a mask of template specialization.Nobody understood the first time.
*shrug*"Defining the template recursively", where is that happening?
Sorry, that was just bad grammar. "The rule is applied recursively", not "the template defined recursively".
^_^There is only one instance of holder.
Indeed? I love that you think that. I bet CornedBee is not at all happy to know that he is wrong. Just so you know though, I'm extremely glad I'm obviously as mad as a hatter. I'm off my bloody rocker. (Hint: If there is actually only one instance of 'holder' or only one instance of the target instantiation of 'holder' "ODR" definitely doesn't apply because there is only one definition and it certainly wouldn't be undefined behavior. I would tell you why you are seeing what you are seeing... but that would definitely be repeat.)
Soma
Gotcha. Then your statement from before:
What do you mean by modeled? Are you taking about having private types passed as arguements, private types that have non-dependent lookup, or private types with dependent lookup. Cause the rules for each these are different.The compiler/linker should and usually does generate a unique entity in instantiating a template modeled upon "private" types.
Since the meaning of the words in the standard was in dispute, I was sighting two of former members of the C++ Standards Committee as experts. If any body understands the standard, it's the people responsible for writing it.I don't doubt you one bit, but I will say that the standard is the standard. (I can't recall the example.)
The rule is applied to derived and to holder. For derived there is a separate entity at each of the two POIs of holder. But holder is instantiated at only one of these two points. Which POI is chosen will generally be reflected in the result of this test. But technically since the definitions conflict, the behavior is undefined.This is the simplest I can phrase the idea: infinitely many template and template specialization possibilities are not listed as being subject to the rule and if the rule is applied recursively there is no point in disguising the instantiation behind a mask of template specialization.
*shrug*
Sorry, that was just bad grammar. "The rule is applied recursively", not "the template defined recursively".
I didn't say there was only one definition of holder.^_^
Indeed? I love that you think that. I bet CornedBee is not at all happy to know that he is wrong. Just so you know though, I'm extremely glad I'm obviously as mad as a hatter. I'm off my bloody rocker. (Hint: If there is actually only one instance of 'holder' or only one instance of the target instantiation of 'holder' "ODR" definitely doesn't apply because there is only one definition and it certainly wouldn't be undefined behavior. I would tell you why you are seeing what you are seeing... but that would definitely be repeat.)
Soma
I said there is only one instance. Specifically it's the instance of holder<int>. That's how templates work. Per set of template arguments, only one instance is allowed per program. Note that more than one instance can exist before the program is linked.
The problem here is that there are two non identical definitions resulting at the two possible POI. That violates ODR. As a result the compiler/linker can't figure out which definition to use.
Last edited by King Mir; 06-01-2008 at 01:19 AM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
OK, now I'm just confused. I read the thread again very carefully, and it seems to me that we are essentially saying the same thing (the code in phantomatap's first post is undefined behaviour), but just disagreeing about what to call it. Or perhaps just misunderstanding what various statements apply to.
If the holder template is instantiated with a type in an unnamed namespace, then you get two different types in the two compilation units. No ODR violation, obviously, but neither are the two types related, which means, I think, that it doesn't help King Mir's problem.
If the holder template is not instantiated with a type in an unnamed namespace, but uses one, then you have a single type with two different definitions in the two compilation units. ODR violation.
Did I understand the gist of the discussion correctly? phantomatap, I think you have been defending a different point than the one we were attacking.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
*shrug*phantomatap, I think you have been defending a different point than the one we were attacking.
As I just recently said: I bet CornedBee is not at all happy to know that he is wrong. Just so you know though, I'm extremely glad I'm obviously as mad as a hatter.
^_^
Soma
Yes, very mature ...
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I thought so, but I have to ask: what did you expect? The last post by King Mir adds nothing to the discussion, repeats what has been said, and only really serves to say, again, that I'm wrong. Your recent post, but not this latest, adds nothing to the discussion, repeats what has been said, and only really serves to say that I may not be wrong because I may actually be agreeing with you amongst a confusion of terminology.Yes, very mature...
I know I'm not wrong. I know that "reading" invisible words doesn't make you right. I know that you misunderstood the intent of the offered examples. I know that King Mir missed the point of contention. I know that Codeplug doesn't understand the argument. Why should I continue discussing this particular issue?
Maybe this is my fault. Maybe I'm incapable of explaining the idea. I'm fine with that.
Maybe it is your fault. Maybe you are incapable of understanding. I'm fine with that.
The point is: I no longer care which. I'm willing to bash my head against the wall only so long for a given argument... and then I either wonder off looking for more amusing scenery or pretty much let my childish and blunt wit take over while my mind considers arguments that are still interesting.
Why do you still care? Why do you want to bash your head against the wall? (Believe me, you will not change anything by repeating what has been said.) Know that I'm wrong and go have a reward snack. I'm partial to those chalky sticks you get with "Fun Dip". You should go get yourself a nice "Fun Dip" chalk stick.
Soma
Last edited by phantomotap; 06-02-2008 at 03:16 AM.
My post does add to the discussion in the following ways:
1)I ask you to clairify a term in original argument, which will hopefully help me understand what you are trying to say.
2)I reaffirm the relevance of my appeal to an expert, which should make you reevaluate your position.
3)I state my understanding of how "the rule is applied recursively". Obviously my conclusions are different then yours, so we are either not talking about the same thing, or one of us is wrong.
4)I clarify a term I used that you misunderstood.
Now yes, I am also repeating the point of contention. That's important to keeping the discussion on track.
CornedBee is similarly on track in trying to get you to reassess what you are trying to argue.
phantomotap you may not be wrong in whatever it is you are trying to say. But the code example you gave is undefined, as agreed by three people.I know I'm not wrong. I know that "reading" invisible words doesn't make you right. I know that you misunderstood the intent of the offered examples. I know that King Mir missed the point of contention. I know that Codeplug doesn't understand the argument. Why should I continue discussing this particular issue?
Maybe this is my fault. Maybe I'm incapable of explaining the idea. I'm fine with that.
Maybe it is your fault. Maybe you are incapable of understanding. I'm fine with that.
I still care, because there's a small chance that you're right. And I want to be aware of what is undefined behavior, and what is defined but unsupported behavior.The point is: I no longer care which. I'm willing to bash my head against the wall only so long for a given argument... and then I either wonder off looking for more amusing scenery or pretty much let my childish and blunt wit take over while my mind considers arguments that are still interesting.
Why do you still care? Why do you want to bash your head against the wall? (Believe me, you will not change anything by repeating what has been said.) Know that I'm wrong and go have a reward snack. I'm partial to those chalky sticks you get with "Fun Dip". You should go get yourself a nice "Fun Dip" chalk stick.
Soma
Similarly you should care, because you might learn something.
Last edited by King Mir; 06-02-2008 at 04:44 AM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
This thread has become only a source of bad feelings.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
