Thread: Why can't this method take derived class?

I don't know if the above examples makes any more sense?
The vector object is part of the type, which was what I was trying to imply by naming it vector-to-A.

Originally Posted by Elysia

Perhaps the problem is that "to" has a different meaning to you than me.

Probably. Frankly, though, past experience gives me confidence that my meaning would be understood by more people. But perhaps you would care to explain your meaning.

Here's mine: A vector is a container. A container cannot be "to" something, because that doesn't make semantic sense. Containers, like buckets, bowls, arrays etc. are "of" something.

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.

I don't know what you're getting at. First, vector is a class template, not a class, but that's a minor quibble and not the point at all.
But "vector is not a native array" - well, duh!

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

No. vector<A> is vector<A> and A[] is A[]. (And more specifically, A[N] is A[N], since A[] is an incomplete type.)

The problem is that the vector sees vector<A> and A[] as something else entirely.

That's just sane behaviour. Why should it treat vectors (dynamically expanding arrays) and built-in arrays (statically fixed-size arrays) the same?

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 still don't see your point. Read my first post in this thread again: such an assignment MUST be illegal, by the rules of object-oriented design and its must fundamental idea, the Liskov Substitution Principle. A mutable container of a type is not a subtype of a mutable container of its supertype, no matter what kind of container it is.

Let it be said then. I don't we'll get any further and I think the answer has already been given, by more than one. Though using C++ terms such as your last statement, I think, is confusing to a lot of people.
Not everyone is a master.

I know english and I'm not confused.

YOU may think that. Doesn't mean everyone does. Manav understood the example perfectly fine.
Don't put everyone on the same level as you.

And if some Americans can't even spell language right, who is to say they can differentiate between "to" and "of"? They may have different means for different people.

Not everyone are geniuses. Don't eat me every time you can't understand something I write.

Who is arrogant now?
I'm not top o' the world, but I do have a right to try explaining things the way I see without someone breathing down my neck.

I never claimed to always be right, I am not always right, I don't know everything and I'm often wrong and I do accept that.
Now let's stop this stupid argument because it's only going to get the thread locked.

To be honest Elysia, I think your English is very good, and as far as I could tell English was your first language. If it's not well it's certainly better than some people's English who are native English speakers anyway.

I think we all understand the point you were trying to make, but it wont stop anyone from using the more natural name for std::set<int> "a set of ints".