Go Down

Topic: Garbage when drawing level map (Read 674 times) previous topic - next topic

arduarn

I didn't understand the modification to the Tile constructor at first, as I thought the colon was used to pass parameters to an inherited class, but I now understand that this is the only way to modify the value of a const variable. Is that right?
The colon syntax in the constructor is the initialisation list syntax and is the most correct way of initialising data members. For const data members you can initialise them in the initialisation list, or directly where they were declared, eg. const int myclassconst_a = 3;.
If you initialise members in the constructor body instead of the init list it can result in inefficiency, as they will be firstly default constructed and then assigned to.

Is it necessary for the unsigned char to be const though? I tested without it being const and putting pTileTexture = pTexture in the body of the constructor and it still works. Is it just a case of being best practice to keep types consistent?
You declared it in Bitmaps.h as const, so yes, it should be const. You'd normally need to explicitly remove the constness with a const_cast to avoid a compile error, but the -fpermissive compile option that the Arduino build environment uses (to help beginners shoot themselves in the feet) implicitly allows it. If you turn on full warnings in your IDE preferences you'll likely see a warning about it. I recommend turning on full warnings anyway.
Even if you were to cast away the const, you still wouldn't be allowed to modify the const data - that would be undefined behaviour.

With regard to the assignment with pointers:
  • const byte* ptr; is a variable pointer to a constant byte(s)
  • byte* const ptr; is a constant pointer to a variable byte(s)
  • const byte* const ptr; is a constant pointer to a constant byte(s)

So the assignment was allowed because pTileTexture is a variable, but *pTileTexture is constant.

The other thing I'm slightly unsure of is the dereferencing. Why do I not need the dereferencing operator (*) when calling the sprite.Draw function? Is it because the pTileTexture pointer is pointing at an array?
pTileTexture is already of the correct type to pass in to Sprite::Draw() so no need to dereference it. If you do, you end up with a single unsigned char.

andylatham82

Thanks for all the explanations arduarn, it's very helpful :)

Go Up