C++ Why isn't the second expression valid?

Question

Suppose you have the following object hierarchy:

class Vehicle {
public:
  virtual ~Vehicle() {}
};
class LandCraft: public Vehicle {};
class Truck: public LandCraft {};

Now, we have the two expressions:

Truck truck;
Vehicle& vehicle = truck;

According to a solution to a homework, the second expression is not valid. But why? My compiler doesn't complain at all, and I don't see what should be wrong here.

Which compiler? Have you tried the `-pedantic` flag (or equivalent)? — suszterpatt, Feb 28 '11 at 16:12
Seems correct to me as well, as you are avoiding the 'Slicing' problem by using a reference to a `Vehicle` (http://stackoverflow.com/questions/2822146/references-and-the-slicing-problem). — James, Feb 28 '11 at 16:13
Looks good to me. Does the question actually use `Vehicle&`? If it just uses `Vehicle` then you would have the slicing problem. — Martin York, Feb 28 '11 at 16:13
Compiles fine on pedantic and I don't see any issues with it. — Winston Ewert, Feb 28 '11 at 16:16

JaredPar · Accepted Answer · 2011-02-28T17:51:51.923

6

It sounds like the homework solution is incorrect then. There is nothing wrong with initializing a reference to a base type from an instance of a derived.

EDIT

As several people have pointed out (Slaks in particular) while there is nothing wrong with this statement in itself, it does provide the potential for future errors down the road. It allows you to arbitrarily put any Vehicle into a place which expects a Truck. For example consider the following

Truck truck;
Vehicle& reallyATruck = truck;
reallyATruck = LandCraft();

Whoops!

edited Feb 28 '11 at 17:51

answered Feb 28 '11 at 16:15

JaredPar

733,204
149
1,241
1,454

I don't see anything unsafe here. That's just a slicing issue and has nothing to do with references, just polymorphism. – GManNickG Feb 28 '11 at 19:55

score 1 · Answer 2 · answered Feb 28 '11 at 16:16

The second expression is perfectly valid. You may be misinterpreting something the solution is saying. Maybe it's not saying it's syntactically invalid, but has some other problem.

It does seem a little odd and suspicious to do that when the classes you're working with have no virtual functions.

My inclination is that the homework solution is just flat out wrong. But it seems odd for it to get something so simple wrong.

score 1 · Answer 3 · answered Feb 28 '11 at 16:17

1

Sorry, but I have verified that your codes works well in Visual Studio 2010, except you missed a semicolon at the end of class Vehicle.

answered Feb 28 '11 at 16:17

wenqiang

954
1
5
14

score 1 · Answer 4 · answered Feb 28 '11 at 16:18

1

SLaks has explained why that expression isn't safe, but it is legal.

According to Comeau, the only error is a missing semicolon on the end of class Vehicle {} /* HERE */.

answered Feb 28 '11 at 16:18

Ben Voigt

277,958
43
419
720

@SLaks: after your edit it's correct, and I would hope that people start reversing their downvotes. – Ben Voigt Feb 28 '11 at 16:22
The expression is not unsafe by any means, and in fact is very widely used in argument passing. The fact that you can slice a different type of object (which SLaks demonstrated) is unrelated to the expression. And to make it clear, I have only read SLaks answer after the edit and downvoted for this particular reason. – David Rodríguez - dribeas Feb 28 '11 at 17:12
@David: As I commented on SLaks answer, references and pointers are safely covariant only when the target is `const` (considering the pointer, not the object). Read-only interfaces are covariant, write-only interfaces are contravariant. – Ben Voigt Feb 28 '11 at 20:09

C++ Why isn't the second expression valid?

4 Answers4