Function Implementation Inside Class Specification

Started by
3 comments, last by hplus0603 18 years, 4 months ago
Is it considered bad style to include short, one-line member function implementation in the specification of a class? Take, for example, the constructor, and active and quit functions in the following:
class GameStack
{
public:
	// Constructor
	GameStack() : m_active(true) {}

	...

	bool active() { return m_active; }
	void quit()   { m_active = false; }

private:
	...

	bool m_active;
};

Advertisement
I personally find it more of a matter of taste... the problem with putting the implementation right in line with the definition though is that if (for whatever reason) you want to extend the implementation a bit... then your header fill will get messy...

i think that it is just a matter of preference... I am also pretty sure that it causes the function to be inlined

i usually always do this for my Accessors(Gets) and Mutators(Sets) ....
I tend to put all my simple getters and settings in the header, but try to put anything that is likely to change in the cpp. For example, your quit() function is probably likely to change, and isn't likely to be called often, so I would put it in the cpp file. Probably the same with that constructor as well.

If I know the class is going to be used very often (like a 3D vector class), then I will inline almost all of it.
The draw-back of putting accessors in the header is that you get more compile-time coupling, and thus more re-compiles in response to a change. Also, it does not allow you to export that class member from a DLL, because all users will use the inline version, so future changes will not be binary compatible.

If you link statically and don't mind the physical coupling, then it'll work fine.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement