-
I started making platformer game, and I ran into a problem. It is not a big deal, but if I continue developing this game, it will probably become big problem in future (I guess).
I have struggled with this for 3 hours, without success, so I don't really feel like I want to make this code much shorter, I cut out some parts to make it simpler. It is not too long, but I have stuff in separate files so I put source to pastebin.
http://pastebin.com/2QrfRJ1b
More details about the problem:
It compiles all fine, and it draws the tiles exactly I want them to be drawn. I also have messages coming to console about stuff. And when I run the program console looks like this:
(http://puu.sh/k0ZUb/9ce158e208.png)
It says twice that WindowManager constructor was called and also window options (that windowproperties class i cut out because i didn't see it's necessary, ignore it). Reason behind this is that I call it once in core class (because i need window for game loop) and once in world class (because i need window dimensions to make calculations and stuff for the world). But I don't want that constructor is called twice... I tried to do things things that prevent it from calling 2 times, it succeeded, but then it didn't draw anything to screen? If I continue developing and this twice calling will happen more, it uses a lot of compile time in the end.
So does anyone know what I should do? The main point is that I need screenDimensions from WindowManager, but if I create instance of it, WindowManager constructor will be called twice. If you read all this, you don't even know how much I appreciate it, thank you.
-
Is it possible that you've passed the window manager by value instead of by reference or pointer?
-
You have two instances of WindowManager in your program and wonder why you have two constructor calls?
Just pass the WindowManager from Core to your world by reference/pointer.
-
Is it possible that you've passed the window manager by value instead of by reference or pointer?
Well yes, if you read the code, you see I passed it by value. But I don't know how to pass it by reference. I only know basics of pointers and passing function parameters by reference. I tried to research for it, but I just got errors, could you tell me how do I pass object by reference? (If I understood right, that's what I have to do)
You have two instances of WindowManager in your program and wonder why you have two constructor calls?
Just pass the WindowManager from Core to your world by reference/pointer.
Well I don't "wonder" why. I know why, but I don't know how to prevent this. Check my answer to Hapax.
-
These are very basic C++ questions that are not related to SFML. If you use a library like SFML, a certain knowledge of the programming language is really required... Otherwise you'll constantly get stuck and waste much more time than learning things correctly in the first place (not just bla bla, I've done the same mistake initially).
I suggest you grab a good C++ book (http://stackoverflow.com/q/388242) and read it, it will answer your current and future questions :)
-
Well yes, if you read the code, you see I passed it by value. But I don't know how to pass it by reference. I only know basics of pointers and passing function parameters by reference. I tried to research for it, but I just got errors, could you tell me how do I pass object by reference? (If I understood right, that's what I have to do)
I'm confused. Do you know how to pass-by-reference or not? Even if you only know how to use pointers, I'm not sure why you didn't use them.
http://www.cprogramming.com/tutorial/references.html (http://www.cprogramming.com/tutorial/references.html)
Also what Nexus said.
Well I don't "wonder" why. I know why, but I don't know how to prevent this. Check my answer to Hapax.
You seem to know what pass-by-reference is (even if you don't know how to use it), so why are you asking how to prevent it?
It's kinda like wanting to hammer a nail into wood and not knowing how to use the hammer, and rather than learning how to use it you simply ask How do you get the nail into the wood? only to get a Use the hammer! response. All you're doing is delaying how long it will be until you stick a piece of pointy refined metal into the beautifully stained chunk of a tree's corpse.
Bad metaphors aside:
void setToFive(int& x)
{
x = 5;
}
int x = 2;
setToFive(x);
assert(x == 5);
Using references inside of a class requires the use of an initializer list because references cannot be uninitialized:
class ClassWithReference
{
int& x;
public:
ClassWithReference(int& x_param) : x(x_param) { }
int& getX() { return x; }
}
Just make sure the class that holds the reference dies before the object it's referring to does.
But please do get a decent C++ book.
PS: Your use of "cutted" (from your source code) makes me uncomfortable
-
These are very basic C++ questions that are not related to SFML. If you use a library like SFML, a certain knowledge of the programming language is really required... Otherwise you'll constantly get stuck and waste much more time than learning things correctly in the first place (not just bla bla, I've done the same mistake initially).
I suggest you grab a good C++ book (http://stackoverflow.com/q/388242) and read it, it will answer your current and future questions :)
I wouldn't say "very basic", I've heard that even experienced programmers sometimes have problems with pointers. But anyways, I have ordered book named "C++ Primer, I guess that is good enough.
I'm confused. Do you know how to pass-by-reference or not? Even if you only know how to use pointers, I'm not sure why you didn't use them.
As I said I have learned only basics; creating a pointer and making it point to some variable. I am not comfortable using them yet.
Using references inside of a class requires the use of an initializer list because references cannot be uninitialized:
class ClassWithReference
{
int& x;
public:
ClassWithReference(int& x_param) : x(x_param) { }
int& getX() { return x; }
}
I don't understand how this helps me in this situation :( I am not passing anything to function, I just want an instance of WindowManager without calling its constructor.
PS: Your use of "cutted" (from your source code) makes me uncomfortable
Sorry, english isn't my native language, and I didn't remember that cut is irregular verb. :)
-
I wouldn't say "very basic", I've heard that even experienced programmers sometimes have problems with pointers.
Pointers are still language basics. The reason why "experienced" programmers don't know how to use them correctly is that they've skipped some chapters, thinking they wouldn't be important ;)
I just want an instance of WindowManager without calling its constructor.
That's not possible. The whole point of constructors is to enforce initialization.
-
I wouldn't say "very basic", I've heard that even experienced programmers sometimes have problems with pointers.
But they don't have problems with syntax, only with complicated memory management.
-
That's why they use smart pointers rather than raw pointers. Also, as far as I can tell, you want the same WindowManager to be in Core and World, is that right? If it is then both Core and World should have a
WindowManager& (which works almost exactly like a normal WindowManager, none of the whole dereferencing stuff).
-
Pointers are still language basics. The reason why "experienced" programmers don't know how to use them correctly is that they've skipped some chapters, thinking they wouldn't be important ;)
Probably, + what Satus said.
But they don't have problems with syntax, only with complicated memory management.
I just want an instance of WindowManager without calling its constructor.
That's not possible. The whole point of constructors is to enforce initialization.
I know that, but there must be something that allows me to use screenDimensions from WindowManager class in World class without calling constructor? I just don't know what.
PS. Many experienced programmers have said that it's better to write bad but working code, instead of writing nothing, so I thought I should even try to make something. :)
That's why they use smart pointers rather than raw pointers.
Some people say that smart pointers shouldn't be used at all, so I haven't even learned about them yet.
Also, as far as I can tell, you want the same WindowManager to be in Core and World, is that right? If it is then both Core and World should have a WindowManager& (which works almost exactly like a normal WindowManager, none of the whole dereferencing stuff).
Thank you, I will try that.
EDIT: Nevermind, I'll just wait for the book, got error:
In constructor 'Core::Core()':
error: uninitialized reference member 'Core::windowManager' [-fpermissive]
-
Some people say that smart pointers shouldn't be used at all, so I haven't even learned about them yet.
I wonder who are this "some people" you are talking about.
In constructor 'Core::Core()':
error: uninitialized reference member 'Core::windowManager' [-fpermissive]
Reference should be initialized in constructor:
class MyClass {
OtherClass& m_oc;
MyClass(OtherClass& oc) : m_oc(oc) {}
};
-
I wouldn't say "very basic", I've heard that even experienced programmers sometimes have problems with pointers. But anyways, I have ordered book named "C++ Primer, I guess that is good enough.
The problem is less due to pointers themselves and more due to problems relating to manual memory management (which utilizes pointers).
One you learn how to properly use pointers (and really, it's not that hard, maybe 30 minutes tops for some basic usage), it wouldn't hurt to learn about a couple common data structures, like dynamic arrays, linked lists, ring buffers, etc.
In C, you'd have to implement everything yourself. No RAII, no templates, every single data structure has to be manually managed with every operation. And this isn't a simple "I know this pointer points to x", this dealing with pointers that point to other pointers, pointers to point to memory held my other pointers, pointers that point to memory held by other pointers held with pointers. And no memory leaks or segmentation faults are acceptable.
In C++, there's templates so the C++ standard library can abstract away from some common data structures for you (vector, list, and queue, for example, all use pointers internally to manage their data). There's also smart pointers, which can be helpful. So you're not going to have to deal with all that chaos, at least not if you don't want to (and you might, say, if you want a custom allocater, or something).
This chaos is why people use manged languages, by the way. :) Not that C++ is bad, it's that is can get a bit hairy sometimes.
I don't understand how this helps me in this situation :( I am not passing anything to function, I just want an instance of WindowManager without calling its constructor.
You can't. That's how object creation works. It gets constructed when it's created, and destructed when it's destroyed. It's basically a contract to the object that says "You get to be able to have your initialization code run once when it's created, allowing any set of arguments you want, and your deinitialization code run once when you get destroyed, but you cannot get any arguments". It's there so that you can be 100% sure every object is as valid as it needs to be; you can't have an uninitialized object. That and every object can free every resource it has implicitly.
If you don't want it to be called twice, you create one object. You can pass a reference to this object as long as the object you're referencing doesn't go out of scope before the object holding the reference does (otherwise the object gets deleted before it's finished being used and you'll probably crash your program).
-
I've heard that even experienced programmers sometimes have problems with pointers.
[...]
PS. Many experienced programmers have said that it's better to write bad but working code, instead of writing nothing
[...]
Some people say that smart pointers shouldn't be used at all
Do you have concrete sources for those claims? What makes you consider those people experienced? You shouldn't just believe what you hear somewhere, but question what you're told. And in order to meaningfully judge whether such statements make sense or not, you need some knowledge about the language itself, so I'd probably just read the book :)
That's why they use smart pointers rather than raw pointers.
Smart pointers only manage memory and ownership. Raw pointers are still used for passive indirections, pointer arithmetic, and so on.
-
I know that, but there must be something that allows me to use screenDimensions from WindowManager class in World class without calling constructor? I just don't know what.
Pass a reference or pointer.
Some people say that smart pointers shouldn't be used at all, so I haven't even learned about them yet.
Some of the most well-known people in the C++ community, even the guy who made it, all seem to love smart pointers.
std::unique_ptr uses RAII to ensure dynamically-allocated objects gets deleted implicitly as soon as they go out of scope. No performance cost.
std::shared_ptr lets you pass around the smart pointer as a sort of "handle", so the object stays alive until the last handle gets destroyed. Acts much like objects in Java/C# do. Pretty neat if you ask me. It comes at a slight cost, and I wouldn't use unless I absolutely need it, but the cost of doing the same thing (reference counting) manually isn't any better. It's not an issue with the smart pointer, it's an issue in the nature of what it does. It's kinda like calling C++ slow if it wont calculate the meaning of life fast enough for you (even though such question wouldn't be able to be answered any faster with raw pointers). :)
-
I wonder who are this "some people" you are talking about.
Nevermind I did research and many people say it's better to use smart pointers. The guy who said it shouldn't be used was some streamer in twitch who was making cool looking game, so I believed it.
Reference should be initialized in constructor:
class MyClass {
OtherClass& m_oc;
MyClass(OtherClass& oc) : m_oc(oc) {}
};
I think I get it, I still got some errors, but I am going to try it with some very simple code.
I've heard that even experienced programmers sometimes have problems with pointers.
[...]
PS. Many experienced programmers have said that it's better to write bad but working code, instead of writing nothing
[...]
Some people say that smart pointers shouldn't be used at all
Do you have concrete sources for those claims? What makes you consider those people experienced?
1. This guy was streamer too, he have programmed for 8 years, and he said that he sometimes gets in trouble with pointers, but will eventually still fix the problems.
2. I've read article where this was said, and few streamers (I watch a lot programming live streams) have said to me I should just do something, if I do nothing I won't learn anything, and when you write bad code and you run in trouble you will learn from that what you should not do and what you should.
3. I thought so, but now when you asked about it and I did research, it seems to be false.
No; I don't have anything concrete, this is just what I have heard from different places.
Pass a reference or pointer.
I am having trouble with it, but I'm going to try this with something simpler and then try to implement it to my game code.
-
Smart pointers only manage memory and ownership. Raw pointers are still used for passive indirections, pointer arithmetic, and so on.
Just remembered this link which I think is really useful for the topic of should people be using raw pointers. http://www.lb-stuff.com/pointers
-
This guy was streamer too, he have programmed for 8 years, and he said that he sometimes gets in trouble with pointers, but will eventually still fix the problems.
Programming in a nutshell.
I thought so, but now when you asked about it and I did research, it seems to be false.
While I do agree with using smart pointers, I do recommend you research what exactly they do before using them. Using them wrong can be just as stupid as not using them.
For example:
- Pass raw pointers to functions that do not assume ownership or operate on smart pointers
- Use unique_ptr instead of shared_ptr when possible
- Pass-by-reference is always better than pass-by-pointer
That's definitely not all, but should be enough to make my point about doing research first clear.
-
@shadowmouse: Thanks for the article. The author makes some interesting observations, but he's also badly informed in several cases.
- std::optional<T&> is indeed an interesting alternative to T*, as it documents the nullability better. But it is mainly useful for optional parameters, and I'm not sure if it will gain enough acceptance because of its syntax.
- std::reference_wrapper<T> exists mainly for std::ref() and std::cref(). Using it instead of T* for passive indirections (weak references) is not the intention, which can already be seen by the fact that the class doesn't provide dereferencing operators. References cannot replace pointers because they're not rebindable and need immediate initialization.
- Even in modern C++, many APIs still use a (T* begin, std::size_t length) signature to access contiguous ranges. Providing std::vector::iterator exposes implementation details for no reason. Saying that iterators would replace pointers entirely is thus wrong.
- While function pointers lose some meaning in the presence of std::function, they're still used when initializing std::function. When used directly, they may achieve better performance than std::function.
- Interfacing with low-level libraries is a point the author is missing entirely.
Of course, the conclusion "raw pointers will be completely useless" is silly regardless of the above-mentioned issues, as all of the alternatives in the article are implemented using pointers. That also applies to developers who implement smart pointers, containers and other wrappers themselves.
-
I agree with basically all of your points Nexus (I use reference_wrapper for polymorphic containers rather than pointers and am looking forward to optional, as I hate the need to dereference), but I think the article is very useful especially for people who think that smart pointers are evil and manual memory management is necessary.
-
I wonder who are this "some people" you are talking about.
Nevermind I did research and many people say it's better to use smart pointers. The guy who said it shouldn't be used was some streamer in twitch who was making cool looking game, so I believed it.
Some real C++ experts you should listen to instead:
Bjarne Stroustrup (http://www.stroustrup.com/)
Herb Sutter (http://herbsutter.com/)
Scott Meyers (http://www.aristeia.com/)
Stephan T. Lavavej (http://nuwen.net/stl.html)
Andrei Alexandrescu (http://erdani.com/)
I can also recommend checking out the following list of links for great learning material and more:
https://isocpp.org/
https://isocpp.org/faq
http://en.cppreference.com/w/
https://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Core-C-
http://www.redblobgames.com/
http://gameprogrammingpatterns.com/
-
I completely recommend Herb Sutter out of Jesper's list (all of them are great!). I watched one of his talks, and I found him entertaining and interesting to listen to, which can be difficult to do sometimes in the computer world! So he may be a good start if you find one of the others difficult/boring to listen to (I haven't listened to talks by all in Jesper's list, I'm just adding my experience!).
-
I can also recommend checking out the following list of links for great learning material and more:
http://www.redblobgames.com/
http://gameprogrammingpatterns.com/
I am having problem with this "very simple" passing object by reference thing, and you link some game developing book and algorithm stuff ;_; I tried to search for that object pass by reference thing but I didn't find anything useful and I couldn't get it work by my own.
-
Jesper obviously didn't post those links in order to solve your current problem, but as general resources to learn... I don't think pass-by-reference is the last problem you'll ever encounter.
-
When you pass by value (default), the function effectively declares an object in local scope that is exactly the same as the one you passed, but it is a clone. When you pass by reference, the function has access to the actual object that was passed, no clone is constructed. The syntax is:
function declaration/definition
type function(paramType& paramName)
and you use it exactly as you would a normal function, no dereferencing, no address/reference operator.
-
Here's an object, constructed with some data:
std::vector<int> vi = {1, 1, 2, 3, 5, 8};
Here's a function taking that object by (const) reference and printing all its members:
void f(const std::vector<int>& obj)
{
for (const auto& elem : obj) {
std::cout << elem << std::endl;
}
}
Clear enough?
-
Jesper obviously didn't post those links in order to solve your current problem, but as general resources to learn... I don't think pass-by-reference is the last problem you'll ever encounter.
You are right, but I mean that if this is "very simple" thing and yet hard for me, there is no sense I should go learn from those sources.
Here's an object, constructed with some data:
std::vector<int> vi = {1, 1, 2, 3, 5, 8};
Here's a function taking that object by (const) reference and printing all its members:
void f(const std::vector<int>& obj)
{
for (const auto& elem : obj) {
std::cout << elem << std::endl;
}
}
Well yes I know how to do it with functions. I don't know how many times I've already said this; I just want to access Vector2f screenDimensions that is in WindowManager class, from both Core and World class, but I want constructor to be called only once. :)
Clear enough?
I have not learned c++11, but I understand what you are doing there.
-
We know you want the constructor to be called only once. Create the WindowManager outside of Core or World and pass it to both by reference.
-
Just change your WindowManager instance in World to make it a reference:
class World
{
public:
World(WindowManager& windowManager);
void createWorld();
std::vector<sf::RectangleShape> vecGrassTile;
std::vector<sf::RectangleShape> vecDirtTile;
private:
WindowManager& windowManager; //Now a reference
int tileFullSize;
sf::Vector2f tileSize;
sf::RectangleShape grassTile;
sf::RectangleShape dirtTile;
};
windowManager cannot be uninitialized, initializer lists let your initialize things before they get default-initialized:
World::World()
: windowManager(windowManager) //This is the initializer list
{
std::cout << "World constructor" << std::endl;
//here i initialize tile stuff, no problem, i cutted it out.
}
You will have to change the Core constructor:
Core::Core()
: firstMap(windowManager) //This ensures the windowManager is passed as a parameter to firstMap's constructor
{
std::cout << "Core constructor" << std::endl;
firstMap.createWorld();
windowManager.createWindow();
}
Also:
- Initializer lists are basically how you call the constructor for member variables. Since ALL members must be assigned something before the constructor is called, but it's default-initialized. If you need to pass a
parameter, reference, int, pointer, even the class itself, you have to use an initializer list.
- Always place the order of which members in the initializer list appear to the order of which they were declared (if you have more than one you need to initialize).
- This counts for anything, really, but C++ isn't Java, don't pass an object to another object (via reference or pointer) without being 100% sure the object holding the reference/pointer will die before the object the reference/pointer is referring/pointing to. If you create A, then B with a reference to A, then destroy A before B, you create undefined behavior (technically, if it's a pointer and B stops using A as soon as A dies, it's not undefined behavior, but that's a pretty specific scenario). If you don't know which will die first, A or B, then that's where shared pointers come in (A would have to be declared as a shared pointer instead of a scoped variable, though). Fortunately, as long as you declare member variables in the order of which they depend on each other, this isn't a problem since they both die alongside each other when the "host" object dies.
-
After total of almost 30 posts I get the answer I have been waiting for. :)
Only this one thing:
World::World()
: windowManager(windowManager) //This is the initializer list
{
std::cout << "World constructor" << std::endl;
//here i initialize tile stuff, no problem, i cut it out.
}
It gave me error, but I fixed it by inserting parameter WindowManager& windowManager to constructor.
Now it compiles and doesn't call the constructor twice, thank you.
So it looks like this:
World::World(WindowManager& windowManager)
: windowManager(windowManager)
Is that correct way? Or is there something I should do differently?
-
After total of almost 30 posts I get the answer I have been waiting for. :)
In his first post (answer #5), it was correct:
class ClassWithReference
{
int& x;
public:
ClassWithReference(int& x_param) : x(x_param) { }
int& getX() { return x; }
}
Anyway, such mistakes are really trivial to find, even more so when looking at compiler error messages. I can't emphasize enough how important it is to know the basic language syntax. As you see, you can waste tremendous amounts of time for nothing :)
-
After total of almost 30 posts I get the answer I have been waiting for. :)
You've gotten the answer already, you just didn't seem to have learned anything from it.
If you ever want to make anything significant with C++, or any language, you're going to have to learn how to apply knowledge of the language to your own programs yourself. You are going to run in to scenarios where things are broken in a mess of thousands upon thousands of lines of code and you have absolutely no clue what to do. Even if the problem is really simple, and was just caused by a lack of understanding in the language, you definitely will not be able to post it on a forum and have someone correct it for you.
This question shows a lack of understanding in how objects, a fundamental feature, work in C++. As well as the inability to manage how variables are accessed. This certainly will not be the last problem of yours.
World::World()
: windowManager(windowManager) //This is the initializer list
{
std::cout << "World constructor" << std::endl;
//here i initialize tile stuff, no problem, i cut it out.
}
It gave me error, but I fixed it by inserting parameter WindowManager& windowManager to constructor.
Now it compiles and doesn't call the constructor twice, thank you.
So it looks like this:
World::World(WindowManager& windowManager)
: windowManager(windowManager)
Is that correct way? Or is there something I should do differently?
Yeah, sorry, I must have missed that.
-
if you read the code, you see I passed it by value.
I didn't.
I responded to your description of your error and suggested the solution. I was unaware that you...
don't know how to pass it by reference.
Luckily, (this time) the community felt generous and taught you this one C++ thing. Googling is much quicker, I would say ;)
-
my 2 cents..
I started completely noob like too.. if it was'nt for a few patient souls telling me things i could not grasp at first i would not have gotten better... so i have a idiom, i just answer the question.
i think hengad's post was just find he did'nt understand why and actually neither did i but i do now! I knew you could change value after passing in a reference but not that constructors were not triggered. And to be honest i need to go through the one good c++ book i have on kindle and read it!!!
But i say A.T.Q, just answer. the. question.
so sorry about ranting i just felt i had to..