To me, it seems like something like this:
vector<CBase*> a; --> Type is here vector-pointer-to-Base (not vector OF Base).Code:class CBase {}; class Derived: public CBase {};
vector<CDerived*> b; --> Type is here vector-pointer-to-Derived (not vector OF Derived).
CBase* pa; --> Type is here, pointer of CBase
CDerived* pb; --> Type is here, pointer of CDerived
Therefore, pa can CDerived (pa = pb is valid).
However, this does not work with a (a = b is not valid) because a's type is vector-pointer-to-Base (note that vector is part of its type)!
vector<CDerived*> did not inherit from vector<CBase*>, thus it's illegal (they are not the same)!
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
A vector is a container, right? Sort of like a conceptual bucket. Would you say "a bucket-to-apples", or "a bucket-OF-apples"?
Even passing that bucket to a function, you are still passing a "bucket of apples" to the function, or a "bucket of lemons", a "bucket of cherries", etc. And a function that expects a bucket of apples certainly won't want a bucket of lemons.
A "wardrobe-TO-Narnia" would make sense though...
abachler: "A great programmer never stops optimizing a piece of code until it consists of nothing but preprocessor directives and comments "
a side question:
what will that make?Originally Posted by jEssYcAt
If it makes any sense... if you write
mytype myname[mysize]
Then the compiler sees the type mytype[mysize].
If you, however, do
vector<mytype> myname
Then the compiler sees
vector_mytype
So in this sense, the type is vector-to-Base or Derived, and not OF.
If it was OF type Base or Derived, then the following should work:
vector<CBase*> mybase;
vector<CDerived*> myderived;
mybase = myderived;
Because, if it was OF, then it technically would be the same as
CBase* mybase[x];
CDerived* myderived[x];
mybase = myderived;
(Technically this won't work since you can't simply assign an array to an array, but I choose to do it anyway for illustration since a vector is basically an array of type.)
But the above is not correct. You cannot assign a vector with type X to a vector with type Y because the actual type the compiler sees is vector-to-X and vector-to-Y.
It's the same as the A and B struct example before. Even though they contain similar members, they aren't the same type.
Is this making sense?
Not one iota.
No, the compiler sees vector<mytype>. Where do you get the crazy idea that it sees anything else?If you, however, do
vector<mytype> myname
Then the compiler sees
vector_mytype
And even if the previous quote made any sense, where is it written that an underscore means "to" and not "of"?So in this sense, the type is vector-to-Base or Derived, and not OF.
For the record, this does work:If it was OF type Base or Derived, then the following should work:
Code:vector<CBase*> mybase; vector<CDerived*> myderived; mybase = myderived;
Whether a template member operator= that performs this action for compatible types is a good idea and should have been included is a different issue. Note that, with allocators working the way they do, the exact semantics of this operator could be argued about a lot. Given the frequency with which you need such a thing (I've never felt a need for it yet) and the ease of the replacement for the rare cases where you do (1 line of code), it's probably better not to get into the discussion and leave the operator out.Code:mybase.assign(myderived.begin(), myderived.end());
Wait. Let me just follow your trail of argument here:Because, if it was OF, then it technically would be the same as
(Technically this won't work since you can't simply assign an array to an array, but I choose to do it anyway for illustration since a vector is basically an array of type.)Code:CBase* mybase[x]; CDerived* myderived[x]; mybase = myderived;
1) If vector<T> is OF T, then compatible copying should work because of 2 & 3.
2) T[] is OF T.
3) Compatible copying of arrays works. Well, no, it doesn't. But it should.
Do you see any flaw with the way you argue? Any small, insignificant problem?
Your reasoning is deeply flawed. You seem to think that A OF B and A OF C are not distinct types, while A TO B and A TO C are. I have no idea where you got that from, but believe me, that's not the reason why assigning vector<X> to vector<Y> doesn't work, and the compiler certainly does not see vector-to-X. The compiler sees vector<X>, and it has no idea whether this means vector-to-X (as in shared_ptr<X>) or vector-of-X (as in vector<X>) or vector-with-policy-X-for-something (as in vector<int, X> where the policy X is for memory allocation) or vector-delegating-to-X (as in, perhaps, boost::spirit::not_parser<X>), or any other of the limited-by-imagination possibilities of using template parameters.You cannot assign a vector with type X to a vector with type Y because the actual type the compiler sees is vector-to-X and vector-to-Y.
Neither does it care.
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
vectors never confused me this much before.
Perhaps the problem is that "to" has a different meaning to you than me.
I was looking at the decorated name for the compiler. Since vector is a class, it is part of the mangled name the compiler/linker sees. Since my Visual Studio is borked, I can't do a test right now.
To me "vector OF type x" sounds like an array of type x. But vector is a class and is not a native array and thus isn't treated the same way by the compiler.
Not really. It was just an example way to decorate the name to distinguish it from a native array.
Of course, but then we're talking about an entirely different issue altogether.For the record, this does work:
Whether a template member operator= that performs this action for compatible types is a good idea and should have been included is a different issue. Note that, with allocators working the way they do, the exact semantics of this operator could be argued about a lot. Given the frequency with which you need such a thing (I've never felt a need for it yet) and the ease of the replacement for the rare cases where you do (1 line of code), it's probably better not to get into the discussion and leave the operator out.Code:mybase.assign(myderived.begin(), myderived.end());
C++ can handle assigning one type to another if the types are the same and you don't need to overload an operator to do that. Of course, you CAN overload an operator to do custom behaviour, but that's not what the issue is about
It's not that I argue. We both know it doesn't work and why it doesn't work, but I don't think we both see the same meaning behind the words I put.Wait. Let me just follow your trail of argument here:
1) If vector<T> is OF T, then compatible copying should work because of 2 & 3.
2) T[] is OF T.
3) Compatible copying of arrays works. Well, no, it doesn't. But it should.
Do you see any flaw with the way you argue? Any small, insignificant problem?
vector<A> is vector + A you could say.
A[] is just A (in an array, but I don't know if you could argue that's a type).
The problem is that the vector sees vector<A> and A[] as something else entirely.
And so it sees vector<A> and vector<B> as complete types respectively and because vector<B> does not inherit from vector<A>, it assignment is illegal.
It could be any object.
Code:template<typename T> class MyClass { }; class A { }; class B: public A { }; A* p; B b; p = &b; // OK MyClass<A>* p2; MyClass<B> b2; p2 = &b2; // Illegal. MyClass<B> does not inherit from MyClass<A>.
I have no idea what CornedBee said, but I think what Elysia was trying to say is that a vector is not a type until it is completed with the template argument types or something (like int in vector<int> or char in vector<char>). So the template argument types are part of the vector type. This would allow for template specialization, because now you don't assume that the code for one template argument is the same as for another template argument.
If I'm wrong, feel free to yell at me.