leech@cs.unc.edu (Jon Leech) writes:

>    If there's a very portable subset of C++ that a program can be written
>in, said program able to compile a test program determining whether or not
>the compiler itself supports bool, I'd be interested in hearing more about
>it.

Yes, there is.  (For example, the C subset.  You'll need to use `system()'.)
What do you want to hear about it?

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <9426717.19348@mulga.cs.mu.oz.au>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>leech@cs.unc.edu (Jon Leech) writes:
>>    If there's a very portable subset of C++ that a program can be written
>>in, said program able to compile a test program determining whether or not
>>the compiler itself supports bool, I'd be interested in hearing more about
>>it.
>Yes, there is.  (For example, the C subset.  You'll need to use `system()'.)
>What do you want to hear about it?

    How to make it work under MacOS, MS/DOS, and other non-Posix OSs, with
whatever the underlying C++ compiler happens to be.
    Jon
    __@/

leech@cs.unc.edu (Jon Leech) writes:

>Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>>Yes.  Your configuration process should just simply attempt to compile
>>a trivial program using bool, for example
>
>    Yes, that would work for the specific problem at hand. But it starts
>down the primrose path to building autoconf scripts.

I agree that the solution is not without pain.

>I'd really like a
>solution using the language itself, not relying on the external environment
>(note "portable", which configuration scripts are not).

Note that I quite deliberately said "configuration process" not
"configuration script".  There's nothing stopping you from writing your
configuration program in C++ rather than as a shell script.  Of course,
you'll have to be careful to ensure that it uses only a very portable
subset of C++.

So it's technically quite possible.  That doesn't necessarily mean that
it is advisable.  You'll need to weigh up the advantages and
disadvantages in comparison to less portable schemes.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <35lhc3$mop@harbinger.cc.monash.edu.au> kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
|It's quite ugly in general. I wish sizeof (or some other compile time
|functions) could be used during preprocessing. Unfortunately, this breaks
|the concept of the preprocessor and compiler being separate entities. CPP
|shouldn't understand types. It would be nice if it could though :-)

Ideally, cpp should be eliminated from the language.  It is a real
headache when writing source-to-source translators, and it makes
smart compilation schemes a real pain.

Most of the functionality of cpp has been subsumed by templates.
It should be possible to integrate the remaining functionality,
token concatenation, compile-time conditionals, interface and
implementation file inclusion, into the language.

This might be possible by adding syntactic constructs to C++ that
look like cpp directives and are mostly backwards compatible, but
can occur only in somewhat more limited contexts.  Alternatively,
a new set of related constructs could be defined.

Haven't there been proposals to do this?  What happened to them?

    Thomas.

In article <9426316.9175@mulga.cs.mu.oz.au>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>leech@cs.unc.edu (Jon Leech) writes:
>
>>Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>>>Yes.  Your configuration process should just simply attempt to compile
>>>a trivial program using bool, for example
>
>>I'd really like a
>>solution using the language itself, not relying on the external environment
>>(note "portable", which configuration scripts are not).
>
>Note that I quite deliberately said "configuration process" not
>"configuration script".  There's nothing stopping you from writing your
>configuration program in C++ rather than as a shell script.  Of course,
>you'll have to be careful to ensure that it uses only a very portable
>subset of C++.

    If there's a very portable subset of C++ that a program can be written
in, said program able to compile a test program determining whether or not
the compiler itself supports bool, I'd be interested in hearing more about
it. If you mean something else, I don't understand what you're saying.
    Jon
    __@/

In article <TMB.94Sep20121045@arolla.idiap.ch> tmb@arolla.idiap.ch
(Thomas M. Breuel) writes:

|> In article <35lhc3$mop@harbinger.cc.monash.edu.au> kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
|> |It's quite ugly in general. I wish sizeof (or some other compile time
|> |functions) could be used during preprocessing. Unfortunately, this breaks
|> |the concept of the preprocessor and compiler being separate entities. CPP
|> |shouldn't understand types. It would be nice if it could though :-)

|> Ideally, cpp should be eliminated from the language.  It is a real
|> headache when writing source-to-source translators, and it makes
|> smart compilation schemes a real pain.

|> Most of the functionality of cpp has been subsumed by templates.
|> It should be possible to integrate the remaining functionality,
|> token concatenation, compile-time conditionals, interface and
|> implementation file inclusion, into the language.

|> This might be possible by adding syntactic constructs to C++ that
|> look like cpp directives and are mostly backwards compatible, but
|> can occur only in somewhat more limited contexts.  Alternatively,
|> a new set of related constructs could be defined.

|> Haven't there been proposals to do this?  What happened to them?

There has been some discussion concerning an `include' statement (not
preprocessor statement), but I don't know if there is/was a formal
proposition.  And I fear it is really a bit late for this go round.

Still, add this, and all that is left for the preprocessor is
conditional compilations, and a few minor odds and ends like token
pasting, and built-in macros like __FILE__ and __LINE__.  Not much
standing in the way of getting rid of it.  (Except maybe how many
lines of existing code:-).)
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

>>>>> "RFG" == Ronald F Guilmette <rfg@netcom.com> writes:

RFG> In article <35ca9i$5pp@watt.cs.unc.edu> leech@cs.unc.edu (Jon
RFG> Leech) writes:
>> g++ 2.6.0 supports the new bool type. Because this type introduces
>> false and true in the global namespace for its own purposes, it's
>> breaking old code of mine that defined false and true as part of a
>> 'boolean' enumeration.

If you just remove your definitions of "bool", "false", and "true",
how much code breaks?  Have you encountered any problems where your
program changes meaning because of the built-in boolean datatype?

RFG> ... and I plan on leaving my declaration of:
RFG>
RFG>  typedef enum bool { False, True } Bool;
RFG>
RFG> in my code permanently.  Heck?  Why shouldn't I?

The reason I see is that "Bool" is already used by some libraries, so
you will get a conflict anyway (eventually).  If you don't intend to
mix your code with other libraries, that point is moot, of course.


      -- Dag Bruck

leech@cs.unc.edu (Jon Leech) writes:

>The code needs to be compilable under compilers that both do and do not
>support the builtin bool type.
[...]
>is there any portable way to automatically detect whether bool is supported,
>so I can change my boolean definition accordingly?

Yes.  Your configuration process should just simply attempt to compile
a trivial program using bool, for example

 bool b = true || false;
 int main() { return 0; }

If compilation of this program is successful, then you can safely assume
that the compiler supports bool.  The configuration process should create
a file, say config.h, which contains #defines that you can use to
conditionally define bool, true, and false for compilers that don't
support bool.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <9426301.19706@mulga.cs.mu.oz.au>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>Yes.  Your configuration process should just simply attempt to compile
>a trivial program using bool, for example

    Yes, that would work for the specific problem at hand. But it starts
down the primrose path to building autoconf scripts. I'd really like a
solution using the language itself, not relying on the external environment
(note "portable", which configuration scripts are not).

    Jon
    __@/

>>>>> Jon Leech <leech@cs.unc.edu> writes:

>     g++ 2.6.0 supports the new bool type. Because this type introduces false
> and true in the global namespace for its own purposes, it's breaking old
> code of mine that defined false and true as part of a 'boolean' enumeration.
> The code needs to be compilable under compilers that both do and do not
> support the builtin bool type.

>     I do not want to globally change false and true to something else if I
> can avoid it, not do I want to place the burden of determining whether the
> compiler supports bool on people building my code at other sites. Therefore,
> is there any portable way to automatically detect whether bool is supported,
> so I can change my boolean definition accordingly?

You can test at configure time, like libg++ does.  Or you can

#define bool int
#define true 1
#define false 0

and ignore the problem until more compilers support bool.

Jason

In article <35ke0m$mu0@watt.cs.unc.edu> leech@cs.unc.edu (Jon Leech) writes:
>    Yes, that would work for the specific problem at hand. But it starts
>down the primrose path to building autoconf scripts. I'd really like a
>solution using the language itself, not relying on the external environment
>(note "portable", which configuration scripts are not).

"The language itself" will just describe the final, standardized language.
Since the standard has no control over implementations that predate it,
it's difficult for the standard to specify how you distinguish all the
various versions.  As with the ANSI C __STDC__ macro, it's relatively easy
to have a flag that indicates the standard version itself; legislating a
slew of macros like __HAS_TEMPLATES__, __HAS_BOOL__, etc. is beyond the
scope of the standard -- any compiler that conforms to the standard will
necessarily have all these features, and a compiler that doesn't conform is
under no requirement to set the appropriate flags.

--

Barry Margolin
BBN Internet Services Corp.
barmar@near.net

Jon Leech (leech@cs.unc.edu) wrote:

>     Yes, that would work for the specific problem at hand. But it starts
> down the primrose path to building autoconf scripts. I'd really like a
> solution using the language itself, not relying on the external environment
> (note "portable", which configuration scripts are not).

Configure scripts are a pain when you leave Unix. Within Unix I usually
find they're ok.

The only thing I can think of is to use something like:
#if __GNUC_MINOR__ >= 6

It's very compiler/version specific but it will work for now. I don't think
there is any other way. #if sizeof(int) is invalid.

We solved the problem in autoconf like this:
AC_COMPILE_CHECK(for builtin bool type, ,[
bool x = true;
bool y = false;
], AC_DEFINE(BOOL_DEFINED))

It's quite ugly in general. I wish sizeof (or some other compile time
functions) could be used during preprocessing. Unfortunately, this breaks
the concept of the preprocessor and compiler being separate entities. CPP
shouldn't understand types. It would be nice if it could though :-) This
has led to some big arguments before as to whether CPP should understand
'const int' in C++. Borland allows it. Unix compilers don't.

--
[==================================================================]
[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]

In article <35ca9i$5pp@watt.cs.unc.edu> leech@cs.unc.edu (Jon Leech) writes:
>    g++ 2.6.0 supports the new bool type. Because this type introduces false
>and true in the global namespace for its own purposes, it's breaking old
>code of mine that defined false and true as part of a 'boolean' enumeration.
>The code needs to be compilable under compilers that both do and do not
>support the builtin bool type.
>
>    I do not want to globally change false and true to something else if I
>can avoid it...

Why not?  Changing `true' to `True' and  `false' to `False' and `bool' to
`Bool' globally over even a very large set of source files is reasonably
easy.  You could ever write simple shell script to do it.

I have already done this to a lot of my own code.  It seemed the best
and simplest way to insulate myself from the level of conformance to
the CURRENT draft standard displayed by various compilers... and I plan
on leaving my declaration of:

 typedef enum bool { False, True } Bool;

in my code permanently.  Heck?  Why shouldn't I?


--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

    g++ 2.6.0 supports the new bool type. Because this type introduces false
and true in the global namespace for its own purposes, it's breaking old
code of mine that defined false and true as part of a 'boolean' enumeration.
The code needs to be compilable under compilers that both do and do not
support the builtin bool type.

    I do not want to globally change false and true to something else if I
can avoid it, not do I want to place the burden of determining whether the
compiler supports bool on people building my code at other sites. Therefore,
is there any portable way to automatically detect whether bool is supported,
so I can change my boolean definition accordingly?

    Jon
    __@/