Printable View
Why isn't this working? it says there's no matching function.
Code:
//Have these classes (elided methods)
class Base
{
public:
Base(string name) {...}
};
class Derived : public Base
{
public:
Derived(String name) : Base( name ) {...}
};
void create(std::vector<Base>& arr)
{
...
}
int main()
{
std::vector<Derived> arr;
create( arr );
}
Because polymophism only works when you use pointers or references; and even though the vector is passed by reference, it holds Base objects instead of Base pointers.
Don't you think it's about time you get a C++ book?
So how would I make this work? Even when I do this, it doesn't work:Quote:
Originally Posted by cpjust
Code:void create(std::vector<Base*>& arr)
{
...
}
std::vector<Derived*> arr;
create( arr );
with polymorphism if you have a std::vector<Base*>, then you can add a new element as such
Polymorhism states that a reference to a base object can point to a derived object.Code:arr.push_back(new Derived(...))
No, your vector should hold Base* types in both places. Just like "because I can put an int in a double" doesn't mean that int arr[] and double arr[] are the same.
--
Mats
Thanks for the reply. I'm just trying to understand this. I thought there was a difference between "an int can be cast to a double" and "a Derived IS also type Base". I don't understand why a vector of Derived pointers can't be cast to/used-as a vector of Base pointers since all Derived objects are also by definition Base objects.Quote:
Originally Posted by matsp
You really need to bang your head on a wall until all that Java stuff falls out your ear. Then you'll be making some progress...
No, Derived is also of type Base is not true.
It's true that Derived * is compatible with Base *.
The difference is between the actual object and the address of the actual object - since the derived one has the same vtable as the base, then it's ok to replace one with the other - as long as you go "down" (towards base) when replacing.
Also, the derived type's pointer is compatible, but it doesn't mean that a vector containing the base's pointer is compatible with a vector containing the derived pointer - these are two different types and the "explore compatible types" don't even come into it - the template class is not the same instance, so they are not compatible. It's the same as:
va and vb are NOT compatible vectors, becuase the structs have different names - the content in the struct is the same, but the compiler says "You named these structs differently, so you obviously don't mean for them to be the same".Code:struct a
int x;
int y;
};
struct b
int x;
int y;
};
std::vector<a *> va;
std::vector<b *> vb;
--
Mats
I don't beleive they are so incredibly different that he has to unlearn a language just to pick this one up. I mean, programming is about the concepts, not the language. Just adapt.Quote:
Originally Posted by brewbuck
I'm not saying 6tr6tr needs to forget Java, just stop trying to apply that kind of thinking when studying C++.Quote:
Originally Posted by indigo0086
THANK YOU! That was a very clear explanation!Quote:
Originally Posted by matsp
I get it now. It's the fact that vectors, being created from a template, are compiled as completely new classes and the specializations of the template for the vector class do not inherit from other vector class templates/specializations (I don't know if my wording's quite right but I get it now)
Thanks Mats! :)
it really is hard because the similarities are there and they sometimes make it harder to "see" things under a diff. light/perspective.Quote:
Originally Posted by brewbuck
just remember, in java everything you create aside from primatives are of <Type>*. They are all pointers and thus polymorphism is automatic.
But the issue you're having is with templates (java: Generics) not following the same rules as standard polymorphic structures. A vector that holds derived objects is not automatically a subclass of a vector that holds a base object
It's all about the Liskov Substitution Principle. Everything you need to know about polymorphism can be directly derived from this simple rule: Type A is a subtype of B if, and only if, an instance of A can be used everywhere an instance of B could be used. (In the context of the C++ language, we're talking about references and pointers to such instances.)
In particular, consider this:
Consider: v is supposed to hold pointers to DerivedA instances. It is not allowed to insert pointers to DerivedB instances. foo() takes a vector<Base*> and, validly, inserts pointers to DerivedB instances.Code:struct Base { virtual ~Base() {} };
struct DerivedA : public Base {};
struct DerivedB : public Base {};
void foo(vector<Base*> &rv)
{
rv.push_back(new DerivedB());
}
int main()
{
vector<DerivedA *> v;
foo(v);
}
Since vector<Base*> allows insertion of DerivedB instances and vector<DerivedA*> does not, vector<DerivedA*> is not a subtype of vector<Base*>.
On a side note, it's exactly the same in Java's generics. ArrayList<DerivedA> cannot be passed where an ArrayList<Base> is expected.
Too bad all that nice type info gets stripped away once you compile your Java program and you just end up with a bunch of ArrayList<Object> types. :pQuote:
Originally Posted by CornedBee
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)!
Thanks, that's the funniest thing I've heard today, and probably will remain so for the rest of the day!Quote:
Originally Posted by brewbuck
I would actually refer to them like this:Quote:
Originally Posted by Elysia
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.
Huh? That didn't make any sense.Quote:
Originally Posted by Elysia
It is on this planet buddy!Quote:
Originally Posted by Elysia
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...
a side question:
what will that make?Quote:
Originally Posted by jEssYcAt
Quote:
Originally Posted by CornedBee
If it makes any sense... if you writeQuote:
Originally Posted by iMalc
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?
Absolutely!Quote:
Originally Posted by Elysia
I was also confused with your previous posts and others were also objecting. But, boy, you made the thorough explanation!
Not one iota.Quote:
Originally Posted by Elysia
No, the compiler sees vector<mytype>. Where do you get the crazy idea that it sees anything else?Quote:
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"?Quote:
So in this sense, the type is vector-to-Base or Derived, and not OF.
For the record, this does work:Quote:
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:Quote:
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.Quote:
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.
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.Quote:
Originally Posted by CornedBee
Of course, but then we're talking about an entirely different issue altogether.Quote:
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.Quote:
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. :D
How the compiler mangles names is implementation-dependent. Conceptually, a vector is a container that holds objects. What is that vector<int> holding? It's a vector of integers.Quote:
Originally Posted by Elysia
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.
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.Quote:
Originally Posted by Elysia
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.
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.Quote:
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.
But "vector is not a native array" - well, duh!
No. vector<A> is vector<A> and A[] is A[]. (And more specifically, A[N] is A[N], since A[] is an incomplete type.)Quote:
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).
That's just sane behaviour. Why should it treat vectors (dynamically expanding arrays) and built-in arrays (statically fixed-size arrays) the same?Quote:
The problem is that the vector sees vector<A> and A[] as something else entirely.
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.Quote:
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>.
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.
Real world example time. Let's imagine you went to KFC and wanted lots of chicken to share with your mom and dad. I dunno if they have that where you live, but do your best to think of a similar joint.
Now, this is important - if you ordered a bucket to chicken, the clerk will correct you just to make sure she understood your broken English. Same thing here with vectors and other containers, you can imply that a vector is part of the type (or its relation with the type it contains) simply with "of" instead of "to." "to" implies a direction like "from" does: Don't misuse your prepositions.
Maybe the fact that we have to explain it to you confuses you, but that doesn't mean that we have to explain it to anyone else.
I know english and I'm not confused.
I think part of the confusion might also have to do with English-to-X conversion. I'm not sure what Elysia's native language is, but maybe To and Of have slightly different translations, just like a lot of people here keep on saying they have a "doubt about ..." when they really have a "question about ...".
Either that or she might be thinking in terms of how the compiler sees vector<x> rather than how Humans interpret it?
I'm pretty sure that part of the reason we get into these discussions is because she is working under the assumption that everyone who asks a question here is confused. In response, she's making C++ simpler than it needs to be, infact, so simple it tends to be broken on a fundamental, logical level. For example, even if she is thinking about "how the compiler sees vector<x>," that matter has no relevance to newbies. They could care less. And as people pointed out, it's wrong to think that anyway.
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.
Back at you bud.Quote:
Originally Posted by Elysia
But you're speaking English. To make sense, you have to understand the English definitions. English is not Esperanto and what to and from might mean to you doesn't matter. If English were a contest and you were a judge, perhaps then you could disqualify all of us and then (how convenient for you!) you wouldn't have to deal with the Americans that do understand English.Quote:
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.
How convenient for you.Quote:
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.
Nobody cares how you see it. What matters is being correct.Quote:
Originally Posted by Elysia
We'll see how long your humility lasts.
Please stop with the personal critiques. It's annoying.
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".
Which was/is my point.
I was merely trying to use an appropriate name I thought best for the explanation to differentiate a vector from an array.
Everyone is free to use their own names, of course.
I still don't understand why you feel that a vector is different from an array. (Aside from the obvious part about vector being dynamic.)Quote:
the explanation to differentiate a vector from an array.
And frankly, the fact that manav claimed to understand your example worries me.
It is different in sense that it does not work exactly as an array plus that a vector is a completely different type than an array (and the compiler sees it that way).
A vector<int> is also a completely different type than a vector<char> according to the compiler, even though most of us basically see them as two buckets both the same shape, color & material, but holding different things inside.
>> I was merely trying to use an appropriate name I thought best for the explanation to differentiate a vector from an array.
The question is how they are different and whether the different terminology properly expresses those differences. They are not different in that they are containers of objects, so changing the terminology in that spot confuses that fact.
That makes an equilateral triangle in Logo.Quote:
Originally Posted by manav
vector<B*> cannot be a subclass of vector<A*> because they are both actually the same class (std::vector), just templated.
Even though they can serve the same purpose, they're not at all syntactically the same (esp. from the compiler's perspective), and the compiler won't necessarily treat them the same.Quote:
Originally Posted by CornedBee
>> vector<B*> cannot be a subclass of vector<A*> because they are both actually the same class (std::vector), just templated.
This reasoning isn't valid. You can have a class foo<T> that is a subclass of foo<U>. In the case of vector you can't, but that's not because it's not possible in general.
>> Even though they can serve the same purpose, they're not at all syntactically the same
That's not the point. The point is why can you say array of ints but not say vector of ints? They are the same in that respect, that they are containers of some type.
Woops, I wasn't aware of that...Quote:
Originally Posted by Daved
The point I was really trying to make (mainly in response to CornedBee) is that, regardless of their conceptual similarities, the compiler considers vector (which isn't anything more than a templated class) something very different than an array (which is a core language feature and has a different effect on the variable's type), meaning you do need to differentiate the two.Quote:
Originally Posted by Daved
Well, you do differentiate the two: one is an array of T, the other is a vector of T. I don't see any reason to take it further than that, and I'm still waiting for Elysia's reason to do so.
No. Contrary to what you may think, a class template is not a class. std::vector is a class template, not a class. std::vector<int> is a class, as is std::vector<float>. They're two different, unrelated classes, in fact.Quote:
they are both actually the same class (std::vector), just templated.
One term that has sown confusion here is "template class", which is why the term was declared undesirable. It has been excised from the C++0x working paper and replaced by "class template".
I see that CornedBee was a little worried about me understanding Elysia's point:
As I already mentioned in the post, I was also confused about Elysia using 'to' instead of 'of', but then as the post explained, so, it made perfect sense to me!
And, for all you concrete mind peoples I don't care either way, you call it 'to' or 'of' :D
PS: concrete mind - means hard, fixed & not easy to change!
The term is "bone-headed". ;)
But the skull is made of bones, so everybody is bone-headed? :DQuote:
Originally Posted by CornedBee
I think the term implies that there's ONLY bone all the way from the front to the back of the head - no soft grey in between. Although I have never researched the etymology of the term.Quote:
Originally Posted by manav
--
Mats
Or at least the bone is so thick that nothing can get through.
CornedBee, Ha Ha!!
In case of my brain, it goes via ears and eyes :D
PS: I can see CornedBee coming holding a Lock and Key!!!
One should strive for such a skull, should they not? At least someone who doesn't want objects to penetrate it.Quote:
Originally Posted by CornedBee
But all arguments aside, conceptually I see a Vector as what the STL describes it as, a Container. A Container which holds types. Some of those types may be pointers to types, but that distinction doesn't affect what a Vector is conceptually.