On Sat, Aug 30, 2014, at 10:47 AM, Liam White wrote:

While browsing through header files in experimental I found these sort of things:

sp-object.h

unsigned int cloned : 1;

unsigned int set : 1;

unsigned int value : 1;

sp-namedview.h

unsigned int editable : 1;

unsigned int showguides : 1;

unsigned int showborder : 1;

unsigned int showpageshadow : 1;

These look very much like a holdover from C which did not have a boolean type like C does.

Is there any viable reason for not simply converting these to boolean?

There are other, similar things that I saw as well (sp-namedview.h):

unsigned int borderlayer : 2;

and I believe this variable is meant to hold an enum type. Should it just be changed to the type of the enum with no alignment or is there a reason to not do that?

Those also are a optimization for space. There is an expectation that the compiler will pack together all those specified to use a single bit into one int.

Of course that then gives a penalty for performance. For the namedview I would say that optimizing for space is not really needed since there will be relatively few of those. The question for sp-object would be to measure how many instances we encounter in various situations and documents and what kind of measured impact on memory use we might see. additionally if we can get any measurable performance difference detected that would be quite interesting.

Changing from int-plus-#defines to a real enum for things like borderlayer is probably a no-brainer since that goes to code safety and greatly reduces the chance for certain bugs. The only factor for concern would be if a member was on a struct/class that we get a significant number of instances of.

Jon A. Cruz

jon@...18...