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)!

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

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)!

I would actually refer to them like this:
vector<CBase*> a; --> Type is here vector of pointer-to-CBase, or vector of CBase pointers.
vector<CDerived*> b; --> Type is here vector of pointer-to-CDerived, or vector of CDerived pointers.

I didn't include "of" because the vector is part of the type.
It's not an array OF pointers and it's not a vector OF pointers.
It's a vector-to-pointers, aka the vector is part of the type so it's not an array.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

I didn't include "of" because the vector is part of the type.
It's not an array OF pointers and it's not a vector OF pointers.
It's a vector-to-pointers, aka the vector is part of the type so it's not an array.

Huh? That didn't make any sense.

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

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 "

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?

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

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.

Because, if it was OF, then it technically would be the same as

Code:

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.)

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?

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.

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.
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

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.

Originally Posted by CornedBee

And even if the previous quote made any sense, where is it written that an underscore means "to" and not "of"?

Not really. It was just an example way to decorate the name to distinguish it from a native array.

For the record, this does work:

Code:

mybase.assign(myderived.begin(), myderived.end());

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.

Of course, but then we're talking about an entirely different issue altogether.
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

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?

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.

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.

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.