Efficiency of allocating RenderWindow

[bearhead]

I'm quite new to C++ and SFML so please excuse my naivete.

Say I have a class WindowManager which, on construction, allocates a RenderWindow object
and keeps a pointer to it.

Now, say in a different file, I have a main function which creates a WindowManager. Then,
it does something like this:

int main(int argc, char * argv) {
    WindowManager wm();  // a RenderWindow object is allocated on the heap in the constructor
    while (wm.getRenderWindow()->isOpen) {
        sf::Event event;
        while (wm.getRenderWindow->pollEvent(event)) {
            ...
        }
    }
}
 

Here's my question:
Because I'm dereferencing the pointer to the sf::RenderWindow object stored in my WindowManager class,
will this code be significantly slower than just creating a sf::RenderWindow on the stack (as a local variable
within main())? Is it generally bad practice to dynamically allocate the sf::RenderWindow object in SFML? I fear it might be bad practice because the RenderWindow object could potentially be huge. It probably needs to store at least one byte for each pixel in the rendered window (presumably much more). The dimensions of a window could be in the tens of millions too.

I guess this also just stems from a weak understanding of heap/stack location/speed.

By the way, the reason I'm doing this in the first place is that I'm attempting to write a game engine.

[Laurent]

Because I'm dereferencing the pointer to the sf::RenderWindow object stored in my WindowManager class,
will this code be significantly slower than just creating a sf::RenderWindow on the stack (as a local variable
within main())?

No... you'll need much more than dereferencing a pointer to impact performances

Is it generally bad practice to dynamically allocate the sf::RenderWindow object in SFML?

It is bad practice to dynamically allocate an instance when you don't need to, and this applies to everything, not just SFML.

I fear it might be bad practice because the RenderWindow object could potentially be huge. It probably needs to store at least one byte for each pixel in the rendered window (presumably much more). The dimensions of a window could be in the tens of millions too.

Oh... not really. The windows pixels are managed by the OS and graphics card, they are not stored in the window object.

I guess this also just stems from a weak understanding of heap/stack location/speed.

Don't bother with performances or optimizations, this is irrelevant (drawing an object is orders of magnitude slower than allocating or dereferencing memory...). Focus on doing things right, and avoid to introduce unnecessary complexity; ie. use dynamic allocation only when you need to (and if you don't know... then don't use it).

You should also try to make less assumptions about stuff that you don't know, it may lead to useless questions and optimizations, and more complexity for no benefit. Just focus on the design and features of your engine. Don't worry, like everybody else, you'll learn a lot with trial and error, and you'll rewrite your engine several times before it's good enough

Some people will also tell you to write a game instead of an engine, but I disagree: writing an engine is fun, especially when you're not that good at game design and art.

[Gambit]

The RenderWindow does not store rendering information such as the pixels it is rendering, that is up to the GPU to handle. The window just tells the GPU how to render it. Furthermore, you probably shouldnt be allocating anything on the heap without a good reason, especially since you are asking about it. To answer your question, however, no, there will not be any noticeable performance decrease for dereferencing a single pointer.

Edit: Damnit Laurent.

[bearhead]

Thanks for the answers guys.