• Create Account

### #ActualHodgman

Posted 24 October 2012 - 06:36 PM

but it would be nicer to have it directly in the class like with everything else

This is the C#/Java way of thinking ("corrupted OOP" IMO), where everything has to be in a class, not the C++ way of thinking.

The first way of thinking leads to #1 below, whereas #2 is more C++ style (in my experience).
//#1
class Foo
{
public: int Bar( int );
void UtilityHelper() { Bar(42); }
private: int m_Baz;
};
//#2
class Foo
{
public: int Bar( int );
private: int m_Baz;
};
void UtilityHelper(Foo& foo) { foo.Bar(42); }
The reason is that in #1, the private details such as m_Baz have been unnecessarily exposed to the utility/helper function. This means that if you're investigating a bug involving m_Baz, then you have to treat UtilityHelper as a suspect, increasing the amount of code to read/maintain.
In the 2nd style, the utility is known to only have access to the public interface, not the private details.

### #1Hodgman

Posted 23 October 2012 - 12:29 AM

but it would be nicer to have it directly in the class like with everything else

This is the C#/Java way of thinking ("corrupted OOP" IMO), where everything has to be in a class, not the C++ way of thinking.

The first way of thinking leads to #1 below, whereas #2 is more C++ style (in my experience).
//#1
class Foo
{
public: int Bar( int );
static void UtilityHelper() { Bar(42); }
private: int m_Baz;
};
//#2
class Foo
{
public: int Bar( int );
private: int m_Baz;
};
void UtilityHelper(Foo& foo) { foo.Bar(42); }
The reason is that in #1, the private details such as m_Baz have been unnecessarily exposed to the utility/helper function. This means that if you're investigating a bug involving m_Baz, then you have to treat UtilityHelper as a suspect, increasing the amount of code to read/maintain.
In the 2nd style, the utility is known to only have access to the public interface, not the private details.

PARTNERS