Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: MapMaker - Startproject for SFML  (Read 12241 times)

0 Members and 1 Guest are viewing this topic.

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re: MapMaker - Startproject for SFML
« Reply #15 on: September 09, 2015, 07:07:18 pm »
You should totally use getters and setters. Copying the member once is a bad idea, because it leads to a copy which wouldn't update if the original changes. If you really need to have a reference to this object, you should better use std::shared_ptr instead.
If you are spending lots of time calling getters and setters, you should think about it, maybe this member should be in a class which uses this member variable. Maybe your class is doing to much stuff and the class which holds member functions which you access frequently needs to have a member function which would do the stuff with those variables!

For example, you may have a code like this:

if(someObject.getX() > y) {
    someObject.setX(y);
}

Then maybe you can create a function which looks like this:

void SomeClass::changeXValue(Something& y) {
    if(x > y) {
         x = y;
    }
}

If you can't find a way to do this and you can make some members public or make a Struct instead of Class.
For example, class Level changes tiles a lot, that's why I have struct Tile, so I can do stuff like this in the Level member functions:

tile.x = 10;
tile.y = 20;

I strongly recommend against using friend classes, they can lead to a code that is hard to change.
For example, before I introduced chunks in levels, I stored all tiles in one std::vector<std::vector>>
I have LevelEditor class which needs to change tiles a lot. I got tired of using stuff like this:

level->setTile(x, y, id);
 
So I've decided to make class LevelEditor a friend class for Level, so I could do stuff like this instead:

level->tiles[y][x] = id;
 
This was a bad idea, because when I've decided to store tiles in chunks, all tiles were not stored in one 2d array anymore! They were stored in N (N - number of chunks) 2d arrays!
So, every line of code which used tiles vector directly, didn't work anymore.
Some other classes used setTile function. So I only changed this function to work with chunks and not 2d array and every piece of code worked without any modifications. This was a pretty valuable lesson for me. :)

Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Otherian

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: MapMaker - Startproject for SFML
« Reply #16 on: September 10, 2015, 12:14:33 am »
You should totally use getters and setters. Copying the member once is a bad idea, because it leads to a copy which wouldn't update if the original changes.
Yeah, I had quite some trouble with this problem. You forget to change both member-variables once and the whole thing reacts quite strange to certain inputs. So I already imagined that it's bad to copy some specific variables but I thought calling a getter too many times isn't a desired solution either. ^^''

If you really need to have a reference to this object, you should better use std::shared_ptr instead.
If you are spending lots of time calling getters and setters, you should think about it, maybe this member should be in a class which uses this member variable. Maybe your class is doing to much stuff and the class which holds member functions which you access frequently needs to have a member function which would do the stuff with those variables!
I haven't done much with shared_ptr's but I'm planing to experiment with them the next days. In generel they are like normal pointers but delete the object they are pointing at if deleted / overrwritten with another object-adress?! Nevertheless it looks like I have to rethink my whole structure and organise which class is capable of doing certain tasks and split the different functions accordingly. Preferably this would have been done from the start but oh well... *hehe*

One question arises though:
For example if I want to stick with my Tile- and TileMap-Class (the latter has a map with all tiles and maintains them etc). Is there a smart way that my Tiles can get informations like their current size etc from the superior TileMap-Class? The other way round I would just create a getter in Tile-Class but this doesnt work in this direction. As you mentioned a smart way would be to just use Tiles as a struct in TileMap to have immediate access to all variables neccessary but I'm just curious if thers a clever way to solve this in general :P

Thx for your feedback Elias :)