[boost] Re: Fwd: Stdint header?

From: Dietmar Kuehl (dietmar.kuehl_at_[hidden])
Date: 1999-08-05 15:55:48

Hi,
At 06:03 05.08.99 -1000, Thomas Plum wrote:
>I want to provide some arguments for making use of, and encouraging
>the use of, the <stdint.h> as defined in C9X (or indirectly thru a
>boost-specific <stdint.hpp> or whatever).

I have no problem if this header is used to get a fairly portable
implementation of the C++ version. I even think that it can be
useful for people using both C and C++ to compile their code to
retain the C typedefs and constants. However, for generic algorithms
I definitely want a template version where I can specify the number
of bits and get the corresponding exact, least, max, whatever,
type. This is, in this case, just an add on to the stuff present
in the C library, IMO an important one.

>First is a process issue.  As liaison from WG21, I communicated to
>WG14 that C++ was very unhappy with the original structure of
><stdint.h> in which typedefs and macros were all swizzled together.
>The liaison from C++ was to subdivide the header, so that C++ can
>use the typedefs without the macros.  It took some convincing, but
>this particular liaison request did pass.  I think it's bad manners
>to then decide to dump the result without a very strong functional
>reason.

Boost is not the C++ library working group. Although more or less
by pure coincidence founded and kept active by some members of this
group, it has no relation. Sure, we are thinking about submitting
proposals to the standard C++ when the libraries are mature and are
in use, but still this should not tie us to the library working
group. If a proposal for this stuff is to be handled by the C++
committee, this political argument will become a consideration and
might even lead to a rejection of the interface by the very same
persons who created it although I guess that we will consider your
thoughs already when writing up a proposal.

For now, I think we should completely ignore political arguments to
avoid limitation on a considerable smaller design space: We want to
create the best interface for the benefit of the C++ community at
large. Although the C committee made an attempt to support help the
C++ committee by changing their definition to allow for an improved
implementation in a C++ context (as far as I remember, the support
for C++ is basically a footnote which says that the macros in C might
be constants in C++ which does not effect C at all only suggesting a
conditional compilation in stdint.h) the result may not be the best
approach for C++. My interpretation of the discussion is that we are
leaning towards the use templates like 'exact<n>', 'least<n>', ...
which are then specialized for the available number of bits. These
specializations might of course use the definitions from <stdint.h>

>However, that argument might persuade no one but me, so I have 
>others.  There is a maintenance cost, and a political cost, to each
>feature of a standard or of an API.  The <stdint.h> header was one
>of the few features of C9X that was already in widespread use at
>many sites, and it was also being widely used in the C++ implementations
>at those sites.  If boost, or C++ at large, defines some alternative
>to <stdint.h>, then those two alternatives compete for maintenance
>and political support.  

Thats a better one. Since the C approach does not support generic
approaches like eg. an n-bit compression or encryption algorithm
an extension in the C++ world is necessary. A potential way to go
is supporting both the C++ and a generic approach. Anyway, a generic
approach is must IMO to avoid having everybody come up with an own
approach. Maybe we don't need a generic approach in the standard
library but we need it in Boost.

>If we were talking about important functional differences, then I
>would think differently about that competition.  But we are talking
>about the same functionality ... defining exact/least/fast/etc types
>for a specific set of integer bit widths.  Whether the name of the
>type is spelled  int_exact<32>::type  or  int32_t  or whatever, there
>must be a one-line typedef somewhere in some header that defines that
>type.  Well, actually if everyone uses <stdint.h> (or indirectly via
><cstdint> ), there exists only one such typedef per type to be maintained,
>but if C and C++ have different headers then there exist two such
>typedefs for each type.

There is a big difference between having typedefs like int/n/_t and
int_exact</n/>::type! The latter can be used in generic algorithms
where 'n' is a parameter while the former cannot. Although I have to
admit that I currently don't have an algorithm at hand where I really
need this feature, I can very well imagine that there are some like
the above mentioned compression and encryption. The reason for those
typedefs is to have types with a fixed number of bits because some
algorithms rely on the exact number of bits. I can't tell what
algorithms this are but I doubt that they might not be generic in the
number of bits.

>Just a plea to focus the creative effort upon the other problems, where
>there is clearly no opportunity for common C/C++ solutions ...

Actually, I considered this discussion basically as closed with the
resolution that the template approach is used (I guess this was also
your feeling and you didn't like the outcome due to the arguments you
mention). It is now open again...

I still consider the template approach to be the one to go, maybe in
addition to the one choosen by the C committee. If we use <stdint.h>
there is no cost in porting the template version at all because this
can be based on the C one. Also note, that the maintainance costs for
this library are not high anyway.

Dietmar