const reference Parameter Problem

[insa]

Hey Guys,

I get this compiler error:

error C2664: 'Map::initMap' : cannot convert parameter 4 from 'const PlayerD' to 'PlayerD &'

on that code:

Code: [Select]

Map::Map(int x,int y,ImageHandler& ih,const PlayerD& p) {
initMap(ih,p);
}

initMap is supposed to take a const PlayerD& as well...

[Laurent]

You shoud show the initMap function.

[G.]

Could you show the initMap prototype as well ?

[insa]

.cpp

Code: [Select]

void Map::initMap(ImageHandler& ih,const PlayerD& p) {
std::vector<Tile> tmp;
float tmpPosX = p.getPosition().x;
float tmpPosY = p.getPosition().y;
int tmpTileX = p.getActTile().x;
int tmpTileY = p.getActTile().y;
}

.hpp

Code: [Select]


public:
Map(int x,int y,ImageHandler&,const PlayerD&);
private:
void initMap(ImageHandler&,const PlayerD&);

[Laurent]

What line of code does the error refer to? Are you showing your real code?

The error says that you try to call Map::initMap with a const PlayerD as parameter 4 instead of a PlayerD&, but that doesn't match the code that you show.

[insa]

This is the Code as intend it to use in the future, at the moment I also pass the two integers (x and y) to initMap() (therefore it expects to get 4 parameters).

And after my four lines of assigning the temporary int/float vals, i do not touch p anymore.

Should i declare the functions I call from p as well as const?


Edit:

I just solved the problem... I thought my functions WERE const, but in fact only the return type was const.

Code: [Select]

const sf::Vector2f& getPosition(); //as i had id before, wrong

Code: [Select]

const sf::Vector2f& getPosition() const; //as i have it now, correct

Anyway, would be a const sf::Vector2f be the better choice for the return type instead of a reference to it (in terms of speed/code size)?

[Laurent]

I just solved the problem... I thought my functions WERE const, but in fact only the return type was const.

So I guess that the error was pointing to these lines of code, not to the call to initMap... Don't forget to mention it in the future

Anyway, would be a const sf::Vector2f be the better choice for the return type instead of a reference to it (in terms of speed/code size)?

Vector2f contains only 2 floats, so it doesn't really matter if you return it by value of by reference. However for bigger objects, use const references to avoid unnecessary copies.

[insa]

The problem was that I was 100% sure that my functions were const... but in fact only the return type was :/

Thanks for the fast answers =)

[Nexus]

Vector2f contains only 2 floats, so it doesn't really matter if you return it by value of by reference. However for bigger objects, use const references to avoid unnecessary copies.

In the meantime, I got used to copy sf::Vector2f always. I don't think it will be slower. As a parameter, you can directly modify the copy and don't have to instantiate a local object. Besides, copies are syntactically more beautiful...

However, returning a copy instead of a const reference has a real advantage. Let's look at a const reference implementation, there seems to be everything fine.

Code: [Select]

const sf::Vector2f& Player::GetPosition() const
{
    return MyPosition;
}
Okay, due to an implementation change, MyPosition isn't a member anymore. Instead, the position is calculated from the tile index at which the player is standing (just an example).

Code: [Select]

const sf::Vector2f& Player::GetPosition() const
{
    return sf::Vector2f(MyTileX * TileSize, MyTileY * TileSize);
}
Now we get a problem because we return a reference to a local temporary object*. This wouldn't happen when using a copy. Like this, you can keep the interface. This is particularly important at virtual functions inside a polymorphic hierarchy.

By the way, sorry for little off-topic
____
*) Note that the C++ rule which allows const-references to be bound at temporary objects doesn't apply here because we're dealing with return values.

The temporary to which the reference is bound [...] persists for the lifetime of the reference except as specified below. [...]
A temporary bound to the returned value in a function return statement (6.6.3) persists until the function exits.