c++ - General advice on hierarchical structs -

edit: leave first part of question posted it, though can see phrased questions @ end poorly. take extremely literally, , surprises me others don't. know that's shortcoming of own. have attempted rephrase questions better communicate kind of answers looking for.

let me begin saying actual implementation of doesn't matter since i'm working on small-scale project i've valued theory highly develop right habits right beginning, , such tend stuck in places doesn't matter. let's pretend matters, though. i'm eager know pros , cons of different options have in situation.

i'm working on program can customize environment liking. settings 1 such environment called profile. can switch between several profiles, , 1 profile may active @ 1 time.

it possible may want update program in future means potentially try load outdated profile format settings missing. make things easier on myself , ensure backwards compatibility have decided make class called profilemanager load profile formats , update them if necessary.

i have decided make struct profile hold settings, , question comes picture.

see 3 versions have tried out here:

struct profile {     // version one: lots of variables closely related names     bool window_one_open;     bool window_one_collapsed;     int window_one_pos_x;     int window_one_pos_y;     int window_one_width;     int window_one_height;      // version two: named structs used create multiple entries of same format     struct position     {         int x;         int y;     };      struct window     {         bool open;         bool collapsed;         position pos;         int width;         int height;     };      window color_palette;     window text_editor;     window browser;      // version three: unnamed struct(s) used group variables     struct     {         bool some_setting;         bool some_other_setting;         int important_number;     } general_settings; }; 

version 1 simple, , i'm sure scores better on performance , memory usage version 2 , 3 (if there difference, is). names can long, though, , i'm not fan of long identifiers.

in version 2 can use shorter identifiers, , i'd rather identify property using profile.color_palette.pos.x profile.color_palette_pos_x. there 1 drawback, though. when type profile. suggests window not property struct , have no use when i'm not working directly inside of profile.h.

version 3 solves problems have versions 1 , 2 introduces new problem. when type profile. suggests some_setting shouldn't able access through profile, through profile.general_settings. code::blocks being weird or there fundamental don't know about?

so questions (rephrased):

• would objectively wrong choice use of sample structures? is, of them marginally worse others performance-wise? nested structs use excessive amount of memory compared version one? of versions more prone bugs others? looking yes or no answers here know if unwise of me go 1 of them. there, perhaps, else should keep in mind when deciding on structure use?
• are there unwritten rules or common knowledge people have in mind when deciding on whether or not use nested structs? again, i'm looking yes or no here.
• are there naming conventions people expect me use nested structs (like classes named likethis , getters , setters named like_this)? should declare them inside or outside of scope in intend use them? have read people advise against broader scope necessary , asking make sure because have never before worked in milieu classes inside of classes advisable or legal.

• in scenario, there structure objectively preferrable on others? (it can haven't thought of)

no, totally depends on actual use cases, , fit better solve them

• nested structs (at least, nested struct declarations) seem introduce more problems solve, , drastically reduce readability, gut tells me should avoid it. general consensus on this?

nested structs have use cases per se, of time if nested struct/class tightly coupled declaring outer class/struct (i.e. standard container iterator classes coupled associated container implementations). using them without having such tightly coupling relation, complicate things, yes.

• if use nested structs, should use naming conventions structs or variables? should declare them inside or outside of scope in intend use them?

afaik there no special naming conventions, other want have compatibility c++ standard classes' template arguments. if have such nested iterator class definition, name , fulfill contracts demanded standard algorithm , other operations.

as comes figured out in sample #2, seems interfaces (that declared outside class) might fit better assemble such relations , abstractions need

struct iposition {     virtual int x() const = 0;     virtual int y() const = 0;      virtual ~iposition() {} };  struct iwindow {     virtual bool open() const = 0;     virtual bool collapsed() const = 0;     virtual const iposition& pos() const = 0;     virtual int width() const = 0;     virtual int height() const = 0;      virtual ~iwindow() {} };  struct profile {     iwindow& windowone;     iwindow& windowtwo;      // provide appropriate iwindow implementation instances      // when constructing here     profile(iwindow& windowone_, iwindow& windowtwo_)      : windowone(windowone_)     , windowtwo(windowtwo_)     {} };