c++ Bad Practise??

[marcUK2]

Learning my way though C++ and WXWidgets

In a constructor (or anywhere) is it bad practise to paste in a bunch of code by using an include, so that I can keep the meat in a separate header file.???

cFrame::cFrame
(wxWindow *parent, wxWindowID id, const wxString& title, const wxPoint& pos, const wxSize& size, long style, const wxString& name)
: wxFrame(parent, id, title, pos, size, style, name) //list contructor override
{

#include "MenuBar1.h"

}

 

[NTMBK]

I wouldn't recommend it that way. If you want to do something like that, put the code in a preprocessor macro in the header... But you should be really thinking about why you need to duplicate code.

 

[marcUK2]

I'm not really duplicating the code, I just thought it would be easier to work with a huge constructor for a window gui if I separated the menus, toolbars, etc into their own files and #included them in.

It works and at the moment while I'm learning wx, it's good enough, but I wondered if there was a reason not to do it like this.

I guess in a real app I could create interface builders and factories, but for a single window app is that really necessary?

 

[NTMBK]

I'm not really duplicating the code, I just thought it would be easier to work with a huge constructor for a window gui if I separated the menus, toolbars, etc into their own files and #included them in.

It works and at the moment while I'm learning wx, it's good enough, but I wondered if there was a reason not to do it like this.

I guess in a real app I could create interface builders and factories, but for a single window app is that really necessary?

No, not really worth messing around with factory pattern for a simple case- but you could probably just factor out a lot of the code into functions, and call those from the constructor.

 

[Cogman]

The reason not to do this is because it is both fragile, hard to debug, and atypical. I've seen some code that pulls this trick and it's generally really hard to get a full picture of what's going on. You are seriously often better off just duplicating the code from a maintenance standpoint.

NTMBK's recommendation is the way to go. Make function or templates to do the same thing. Those will both be easier for a passerby to understand and more maintainable in the future.

This is also the place to create "interface" classes (that is, abstract classes with only virtual methods and no state).

IDK if this is still the case, but IIRC, it's usually recommended that you avoid any sort of control statement or function call in a constructor in C++. Why? Because when exceptions happen the interplay between those and the language semantics are really tough to correctly unwind. That's specifically why the "noexcept" keyword was added to the language.

The solution, AFAIK, is to do all your allocation in the constructor and your initialization in a seperate init function. Though someone that's done more C++ can feel free to correct me if I'm wrong about this being a current best practice.

 

[bertgang]

Don't want to repeat after guys above, I just want to let you know my considerations. I think that the code must be clear and as simple as possible to let another programmer understand what's going on in every line of your code. Don't get used to the 'duct tape' way, especially don't use it in your real projects.