[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dont! Re: stdbool macro, take 2
From: |
Guido Draheim |
Subject: |
Re: dont! Re: stdbool macro, take 2 |
Date: |
Sat, 10 Nov 2001 00:15:02 +0100 |
just read through that message reference, bruce, and I do agree
of course - I think the real problem with stdint/stdbool and
friends is that it is just a nuisiance to make projects be
portable to platforms that are not strictly up at '99 or better,
and w.r.t. gstdint I can point to the fact that inttypes were
introduced in 1992, being later part of unix98, and folded into
C99. But I am not supposed to use these inttypes because there
are many compilers and systems out there that do not have them,
- I could adapt my local source code but I am not allowed to put
them into public header files. It's making me sick, really :-( ...
and in way the same account to bool/true/false series of defines,
since one should think that all this is actually established
programming practice but for the merits of portability, I do have
to avoid that and start using those mylib_bool defines all over
the public interfaces.
Of course, instead of doing a mylib_bool for every project of
mine, I could just as well extract that part into a seperate
project (e.g. "autoposix" ;-)) and let my local one be dependent
on it. And in a way, I would not be suprised that many people
start using libglib just for the reason that it flattens the
differences of the supported systems and returns, among other
stuff, an up-to-date system interface to such established
programming schemes like inttypes, dlopen and lwp-threading,
and not to forget, gboolean.
@paolo
I agree with you too but on one thing: a programmer does not
specifically need to copy stuff in over and over again,
instead it is possible to make an #ifdef series like
#if defined HAVE_STDBOOL_H
#include <stdbool.h>
#elif defined HAVE_GSTDBOOL_H
#include <gstdbool.h>
#error could not get either of stdbool or gstdbool, sorry
#endif
and let user code (of such a header file) be required to
check for these. This happens to be of established autoconf
practice to search in multiple headers for things that we
need, and AC_HEADER_DIRENT might serve as an example for it.
And in a way, it was also the reason I started with that
gstdint microproject that is based on my m4 macro to check
into the various possible locations for inttypes and have now
a last resort being a dependency on the file that gstdint
could install all out of itself. I have to admit that I am
not quite convinced that it is the final answer to all the
problems in this area but just a step more to detach myself
from the problems there are around with multiple lib-headers
to try to define stdxxx types in different locations all
over again.
So, in a way I would ask you to start such a microproject for
gstdbool too - other projects could then check for bool in
it's normal locations (possibly being predefined in the
compiler) and have a third-party check for gstdbool.h, and
just make a note in your project docs that you declare the
bool-types as a precondition to be it around, and hint the
user that this might be in the compiler, from a system extension
or from that microproject one can hand out the url for. And
autoconf could get a standard-macro ac_header_stdbool that
would work just like header_dirent with one exception - it
will also check for the header from from the microproject
that has settled around the autoconf-people, and in a way
it is the reason that I placed gstdint in a subdir of the
ac-archive sfnet-fork as I see it as a thing very close to
autoconf but not just in it.
Anyway, even that I do not feel your stdbool macro should
live in the autoconf core itself, I feel it could be great
contribution to be memorized in the ac-archive, so that
people shall not need to reinvent it. Amongst the various
effects I could not that one would be able to make a
standard for an is-already-defined macro that other header
could check so they do not redefine the same symbols. Such
a thing has been done for inttypes all the way long (since
it overlaps with the bsdtypes stemming from network code),
and it could be used for generated-header too, so that the
generated header contains
#ifndef _GENERATED_STDBOOL_H
#define _GENERATED_STDBOOL_H
xxxx
#endif
which will avoid redefinitions even when the macro and the
header-generation is used in multiple places around the
software world. Actually, it's another lesson that I had
to learn around stdint and friends. And to emphasize it
again, I am not sure if it is the last lesson I have to
learn the hard way....
sorry for such a long talk on it,
'hope the things do not look that foggy
as they do look to me sometimes, cheers, guido
Es schrieb Bruce Korb:
>
> Guido Draheim wrote:
> > being a person who has been doing some tricky stuff with a generated
> > file called stdint.h, I would like to oject on generating a stdbool.h
> <<reasons elided>>
> I agree, with arguments about project focus and project bulk
> to boot: http://sources.redhat.com/ml/autoconf/2001-11/msg00033.html
>
> > p.s. references are
> > http://ac-archive.sf.net/gstdint
> > http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html
>
> The downside to "gstdint" or "gstdbool" is that they are just
> the tip of an ugly iceberg. If you were to assemble one project
> for every fixable compatibility issue, you would find yourself
> with a lot of projects. In my code sourcery contest entry I
> proposed a single project that ran through the million known
> compatibility issues and installed whatever was needed so that
> a consistent interface was available for all supported platforms.
> This would mean that a "stdint.h" and a "stdbool.h" headers
> would be part of it and installed as needed. Then, instead of
> bulking up every autoconf-ed project in the world with 300K
> of duplicated configury overhead, a project can just have a
> dependency on a minimum revision of the compatibility library.
> Way, way, way simpler. Smaller distributions. "configure"
> could focus on the with/without/enabled/disabled options for
> each package. autoconf users would not need to be M4 quoting
> experts. I suppose I'm just whistling in the wind? ;-)
-- guido http://freespace.sf.net/guidod
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)