How not to write C++

[Krice]

Since I see people not getting C++ (more specific: OOP) I'm going to spill it out. Let's take this example from C::B (app.cpp):

Code

class Splash
{
    public:
        Splash(const bool show) : m_pSplash(nullptr)
        {
            if (show)
            {
                wxBitmap bmp = cbLoadBitmap(ConfigManager::ReadDataPath() + _T("/images/splash_1312.png"));
                wxMemoryDC dc;
                dc.SelectObject(bmp);
                cbSplashScreen::DrawReleaseInfo(dc);
                dc.SelectObject(wxNullBitmap);
                m_pSplash = new cbSplashScreen(bmp);
                Manager::Yield();
            }
        }
        ~Splash()
        {
            Hide();
        }
        void Hide()
        {
            if (m_pSplash)
            {
                m_pSplash->Destroy();
                m_pSplash = nullptr;
            }
        }

    private:
        cbSplashScreen* m_pSplash;
};

If this is a local code where you get resources, show them and release right after it, you don't even need a class. This class works a lot like function anyway which is a common mistake. But if it is a dynamic resource (the splash screen is kept in memory) then you always want to avoid conditional construction. Do not pass that show boolean to the constructor, but construct the object's data and release it in the destructor. Then use a Show function to show the splash screen. If you are resetting some pointer to nullptr you are most likely doing it wrong. By following constructor/destructor rule you don't have to check out pointers etc.

As a side note this class probably also has a missing delete, at least there is a new but no delete. Might be some wx magic, but not sure about it.

But the main point is that this is not a class. It's a function and if you have something like this you don't even need a function, you could simply write the code inside a if block (if the resources are local and used only in one place).

[oBFusCATed]

Can you show a working patch which makes the code better? 
But make sure to test at least on two operating systems.

[Krice]

I don't know anything about wx to code a patch, and even if I did it wouldn't change the fact that the entire source code is what I call "old school C wrapped in classes". If you use classes like that you miss the important things in object-oriented programming, in particular using classes the way they were designed. I think so many programmers miss the point, because C++ is a multi-paradigm language which doesn't force to OOP style only. That's why the bulk of code can be ancient C style "linear" (no generic concepts or data-driven approach) code with macros etc.

In my opinion OOP benefits from generic style programming where classes are mostly used as datatypes that reduce the amount of specific, bulky coding style of C. OOP also works well with modular programming - another concept a lot of programmers don't actually get in a way that would help them to manage large projects. It's something that even I have discovered only recently. But after all things said, it is possible to write better procedural code, too, with generic/modular style. The problem with old school C is not that it works, it does work obviously, but that it creates more code than you would need and a bigger project is always harder to maintain. It's quite clear this is a problem in many of these large and even medium size C open source projects. That's why developers often tell to "patch" them, because it's the only way they can work around the big problem.

[oBFusCATed]

A-ha, I understand. 

[sodev]

I see people who never coded a GUI application or have seen an event loop ...

As a side note this class probably also has a missing delete, at least there is a new but no delete. Might be some wx magic, but not sure about it.

Yes, it is wx magic, dont delete stuff or the event loop might access deleted objects.

But the main point is that this is not a class. It's a function and if you have something like this you don't even need a function, you could simply write the code inside a if block (if the resources are local and used only in one place).

If you can show how to transfer control flow from that local block to a different location, execute an arbitrary number of operations and then return back into that local block to clean up, go ahead.

In my opinion OOP benefits from generic style programming where classes are mostly used as datatypes that reduce the amount of specific, bulky coding style of C.

I always thought OOP is about attaching behavior to data instead of beeing just plain data?

That's why developers often tell to "patch" them, because it's the only way they can work around the big problem.

And the big problem is? Features don't code themself?

You don't happen to work in one of these consulting companies and are more busy tying a tie than coding code?

[Krice]

I see people who never coded a GUI application or have seen an event loop ...

I have programmed a light-weight GUI on top of SDL2. It means I have made menus, dialogs, buttons etc. myself from scratch. It's not something I would recommend if you can avoid it, but it's a good way to understand GUI in a deeper level. And in fact I find even today there aren't many GUI libraries that work with C++ and aren't a size of an operating system (way too large).

Yes, it is wx magic, dont delete stuff or the event loop might access deleted objects.

The object should be an instance of Splash in this case, not anything it owns. If wx is doing something that breaks C++ then it may have been designed for C in the first place. You should be able to keep an instance in memory during the event loop. If wx has some magical memory management it's a sign it was written for C and that it has a bad design. The problems people have with wx would suggest such things to be true.

I always thought OOP is about attaching behavior to data instead of beeing just plain data?

You got this one right, but the problem is that programmers don't always follow that rule the way you should. The Splash class here is a good example of it: if you give away the ownership of something in the class, why have a class in the first place?

You don't happen to work in one of these consulting companies and are more busy tying a tie than coding code?

You should stop guessing, because you are not good at it.

[stahta01]

I see people who never coded a GUI application or have seen an event loop ...

I have programmed a light-weight GUI on top of SDL2. It means I have made menus, dialogs, buttons etc. myself from scratch. It's not something I would recommend if you can avoid it, but it's a good way to understand GUI in a deeper level. And in fact I find even today there aren't many GUI libraries that work with C++ and aren't a size of an operating system (way too large).

If you wish to complain about GUI toolkits not following C++ OOP ways I suggest you look at Qt5 because they are more C++ OOP than wxWidgets. That is likely because they do not have much legacy code from when C++ compilers were much less feature complete.
The wxWidgets toolkit is improving their C++ OOP usage; but, it is very slow to improve. And, the C++ Compilers seem to be moving faster. But, since you seem to have never used an C++ GUI toolkit; I suggest you remain silent instead of risking being thought a fool on the subject. NOTE: SDL is neither a tookit nor C++. Edit3: SDL is a graphics library.

Edit2: GUI Libraries and GUI Toolkits are not the same thing; wxWidgets and Qt5 are GUI Toolkits.

Tim S.
 

[Krice]

But, since you seem to have never used an C++ GUI toolkit; I suggest you remain silent instead of risking being thought a fool on the subject.

I think it should be obvious that if the library (or whatever) doesn't work with the language itself then why use it in the first place? It's surely not going to help write stable source code. If you ask me all these memory management things built on top of C++ are the worst. C or C++ was not designed to have automatic memory management, but notably in C++ if you strictly follow constructor/destructor rule (preferably with ownership rule) it's going to be much easier to avoid memory management bugs.