groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] C++ solution of the char length problem


From: Werner LEMBERG
Subject: Re: [Groff] C++ solution of the char length problem
Date: Tue, 01 Apr 2003 11:59:30 +0200 (CEST)

> We had already some discussions on the bad handling of the length of
> character variables in groff.  The C solution uses a cumbersome
> preprocessor construct.

Not necessarily.  C99 provides stdint.h.

> Fortunately, there is a possibility to handle
> the variable length with an excellent C++ solution, that is even
> available in all versions of C++, but not in plain C.
> 
> The member in a `struct' or `class' can be enhanced by a so-called
> "bit-field", a `:' separated length argument appended to the variable
> name.  For example, a 8 bits integer could be defined as
> 
> struct Int8 {
>   int data: 8;
> }
> 
> or
> 
> class Int8 {
>   int data: 8;
>   ...
> }

Looks interesting.  Thanks for the info.  BUT:

> Usually, groff uses positive values for normal characters, and
> negative values for special groff properties.  So groff uses signed
> variables for representing characters.  This doubles the necessary
> space.
> 
> When we are using a `struct' or `class' anyway, this can be optimized
> by an additional Boolean member.  For example, a groff Unicode
> character type could be defined as
> 
> class GroffChar {
>   unsigned int data: 16;
>   bool special;
> public:
>   ...
> }

While I agree that separating special and normal characters with a
Boolean flag is basically a good idea, I think we don't need this
additional complexity for a very simple reason: After conversion to
Unicode, characters in groff won't be 16bit wide but 21bit.  This
means we have to use (at least) 32bit integers anyway (even ISO 10646
uses only at most 31bit wide characters IIRC -- mainly to make the
number -1 always an invalid character code).  Using negative numbers
thus appears very natural to me for representation of internal groff
characters (which will normally be accessed with symbol names).


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]