I think the struct/class decisions have mostly been restricted to public header files. Inside .cc files I think we generally use what seems most convenient (which can often be a struct for pimpl types). In the public headers we should be trying to use struct only for objects that are principally simple data containers where we are OK with exposing all the internal members, and any methods are primarily conveniences. Documenting this in the developer conventions section sounds like a good idea to me.
On Sun, Mar 14, 2021 at 1:12 AM Weston Pace <[email protected]> wrote: > > Hi, this might be a bit of a pedantic email but I'm going through and > cleaning up my code on some of my threading work and wondered about > the style guidelines around struct/class. Technically, the Google > style guide states... > > --- > structs should be used for passive objects that carry data, and may > have associated constant. All fields must be public. The struct must > not have invariants that imply relationships between different fields, > since direct user access to those fields may break those invariants. > Constructors, destructors, and helper methods may be present; however, > these methods must not require or enforce any invariants. > > If more functionality or invariants are required, a class is more > appropriate. If in doubt, make it a class. > > For consistency with STL, you can use struct instead of class for > stateless types, such as traits, template metafunctions, and some > functors. > --- > > ...this seems to be at odds with Arrow's current implementation which > uses structs in a number of places that don't follow those rules. > Using structs is certainly more convenient when possible since it > allows for aggregate types that can use list initialization. I asked > a bit on Zulip and it was recommended I bring this up here but also > that it should probably be ok to use structs in cases where access > controls are not needed. For example, a pimpl inner type (Impl) or > some other situation where there is no way to get access to an > instance of an inner type. > > 1) Does this match expectations? > 2) Is it worth dropping a note in > https://arrow.apache.org/docs/developers/cpp/development.html#code-style-linting-and-ci > ? > > -Weston
