Hi,

Just wondering. What do you see as the 'boundary' when you prefer a class versus a struct?

Was thinking about this when I was adding functions to my VECTOR3 struct, the number of operators has grown, and I'm thinking of also adding (inline) functions for cross- and dot- product. Included are already getting the magnitude and normalizing.

For now I don't see reasons to move from a struct to a class.

Operators work nice and do exactly what I want without to much code (not even sure how to do that within a class.....)

Somehow my mind says, as long as it's a relatively 'simple' object, just use a struct and don't 'waste classes' on it (not sure though how to explain this rationally :))

What are your thoughts?

Thanks, that's a nice addition. In my vector struct indeed the members are all accessible (and should be).

Would you add for example a function in the struct to calculate the cross or dot product? Or would you add 'Global functions' (yikes!! ) in the same header/ cpp files

As frob mentioned, in C++ a class and a struct are pretty much identical. The choice of which to use is yours to make, seeing as the following two are very much the same:

struct Vec
{
   float x, y, z;
};

class Vec
{
public:
   float x, y, z;
};

One issue i ran into when i used a mix of structs and classes was when forward declaring them. Sometimes i would simply forget if Vec was a class or a struct. Similar with Color, Rect, Transform, etc. So i settled on using classes only, and if something needs to have all of it's members public, i simply set them as public and not protected/private.

I'm going to suggest that maybe you should do some more reading on class vs. struct, and on interface design. It sounds to me like you've got an unseasoned understanding of some things. That's not a dig at you, its just something I'm picking up on, and its very common for people to have misunderstandings that lead to here.

Just for example, you say "global functions" like its a bad thing, when in fact such "free functions" should very often be prefered. This is a common misunderstanding that stems from "object-orientitis" where one believes that all interfaces belong literally inside the class, but in reality the portion of an interface that has access to a class's internal state should be as small as possible to maximize encapsulation and maximize cohesion.

All good advice above. Global functions (aka free functions) are indeed a good thing.
It really shits me (and other OOD aficionados) that Java decided to outlaw them and also push their own modified ideas about OO... But that's another rant ;)

Anyway, in classes with private state, usually there's some kinds of constraints (aka invariants) that have to be enforced by the public functions -- e.g. Resize may check for "size < 0" before changing the private member variables. If there is a bug in the private data, e.g. Size is -1 somehow, then you only have to look at these member functions to find the cause.
If a function *can* be implemented as a free function (i.e. doesn't *have* to be a member function), it's a good choice to do so. In these cases, your free function only accesses the public members of the class -- so, if there's a bug in the private details, you know your free function can't be to blame.
That's one example of why 'decoupling' is good, but it's become a general rule of thumb in software engineering to try and keep things as loosely coupled as possible.

In your struct case, the above example doesn't apply of course, because everything is public!
However, it can still be nice organizationally to keep the data structures themselves separate from the algorithms that operate on those structures.
For example, there's an endless number of operations that could be done on a vector, so it would be nice to be able to add new operations without having to edit the shared vector struct endlessly, or make vector.h over 9000 lines long.
C# has hacked around this issue by adding "extension classes" to their language...

There's many examples of this in std::, just look at the stuff in <algorithm>, such as how searching and sorting are decoupled from std::list and std::vector!

As frob mentioned, in C++ a class and a struct are pretty much identical. The choice of which to use is yours to make, seeing as the following two are very much the same:

struct Vec
{
   float x, y, z;
};

class Vec
{
public:
   float x, y, z;
};

One issue i ran into when i used a mix of structs and classes was when forward declaring them. Sometimes i would simply forget if Vec was a class or a struct. Similar with Color, Rect, Transform, etc. So i settled on using classes only, and if something needs to have all of it's members public, i simply set them as public and not protected/private.

Actually they are not pretty much identical they are identical, the code generated from them is exactly the same, a struct can have all the same things as a class.

Actually they are not pretty much identical they are identical, the code generated from them is exactly the same, a struct can have all the same things as a class.

The only difference is semantical regarding the default access rule for members (public vs private), which is why i said "pretty much identical", but yeah, the generated bytecode is the same.