How much functionality is “acceptable” for a C++ struct?

Question

My first post so please go easy on me!

I know that there\'s no real difference between structs and classes in C++, but a lot of people including me use a struct or class

Answer 1

I might be in the minority, but I use structs to mean one thing, "the order of the bits matters". Anything that must be serialized to disk or network, or has to be compatible with some third party library and needs to be in the right order, Or if it's doing some kind of bit field magic as a processor specific optimization, that always goes into a struct. Rearranging the fields in a struct, therefore, always has some kind of consequences and should be carefully thought out.

classes, however, have fields that are only semantically meaningful. If for some reason I or someone else wants to rearrange or modify the data members of a class, this can happen pretty freely.

Answer 2

I think there are three major, coherent schools of thought:

1. People that don't care either way and use struct and class interchangeably.
2. People that use structs only to represent small POD.
3. People who use structs as records.

I can't make a conclusive argument for either of these strategies. I tend to follow path 2 but I also use structs for non-POD types when I see it fitting, especially for function objects (even if these may not fulfil POD requirements).

(Incidentally, the C++ FAQ lite has a pretty good definition of POD).

EDIT I didn't touch template metaprogramming techniques, such as using struct for placeholders (type tags) or to implement metafunctions. I guess there's absolutely no controversy in these cases: since they never contain methods (or even data), always use struct).

Answer 3

I wasn't making a distinction between member and free functions when I was thinking about the question, but I now see that this was a mistake. It now seems to me that structs should only rarely have member functions. It is pretty clear that everything in a struct should be public.

Therefore, there is generally no point in having struct member functions because any function can change the data in the struct. A member function on a struct would be a convenience rather than a necessity.

The only exceptions would be things required to be member functions for some other purpose - constructors for initialising arrays; comparisons for use with a map; things used by templates; etc.

Perhaps class and struct should be seen as opposites - a class exposes functions and hides data, whereas a struct exposes data and allows you to hide functions.

Going back to the byte swapping example:

struct S
{
    int data;
    S() {data = 1234;}
    void ByteSwap() {network::ByteSwap( &data );}
};

S s;
s.ByteSwap();

would become:

struct S
{
    S() {data = 1234;}
    int data;
};

namespace network
{
    void ByteSwap( int* i ) {/*byte swap *i*/}
    void ByteSwap( S* s ) {ByteSwap( &s->data );}

    S s;
    ByteSwap(&s);
}

This makes sense when the data and some functions do not always strongly belong together. Byte swapping would only be of interest to the network system but higher level functions can still use the struct without even knowing about low level stuff like byte swapping.

Another benefit in this case is that the related byte swapping operations are all kept together in the same place.

Answer 4

This is purely a matter of style, and what is right or wrong will be dictated by your shop. Sometimes the decision will be to make no decision but, to paraphrase Rush, they still will have made a choice.

As a rule of thumb I will generally use structs for simpler datatypes rangin from PODs to objects that have member simple functions. But there is no bright line, and once I define a struct I will not normally go back and change it to a class just because I added more functionality. I see no value in that.

Answer 5

I use classes and encapsulation when I need to maintain invariants and data integrity. If you have no invariants, and the data really is just a bucket of items, it has always been fine in our shop to use struct even if you add fancy helper constructors or functions. However the more you do decorate it, that should make you stop and think that maybe it should be a class.

If you do have to be POD compatible (for say interfacing to C code) you do still need to use struct. However you can wrap this struct in a class and expose it with a get() function for interfacing with C API's. Or create a helper function to return a proper POD struct from your class.

Answer 6

alot of people including me use a struct or class to show intent - structs for grouping "plain old data" and classes for encapsulated data that has meaningful operations.

IMHO, this differentiation is a misunderstanding but it's well understood why it is used like that. It is based on traditional conventions and built-in feeling about class vs struct. I'd follow Marshall Cline's suggestion:

7.8 What's the difference between the keywords struct and class?

Since that's the connotation most people already have, you should probably use the struct keyword if you have a class that has very few methods and has public data (such things do exist in well designed systems!), but otherwise you should probably use the class keyword.

Personally, I (over)use struct keyword for metafunctions