Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #7870 > unrolled thread

Size of bool unspecified: why?

Back to article view | Back to comp.lang.c++

Contents

  Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-16 05:33 -0500
    Re: Size of bool unspecified: why? BGB <cr88192@hotmail.com> - 2011-07-16 10:02 -0700
      Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-20 13:05 -0700
        Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-20 15:46 -0500
          Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-21 09:01 +1200
            Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-20 19:32 -0500
              Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-21 14:46 +1200
                Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-20 23:28 -0500
                  Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-21 16:43 +1200
                    Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 02:56 -0500
                      Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-21 20:19 +1200
                        Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 18:29 -0500
                          Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-22 11:40 +1200
                            Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 22:33 -0500
                              Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-22 15:46 +1200
                                Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 23:07 -0500
                                  Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-22 16:12 +1200
                                    Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-31 18:45 +1200
                          Re: Size of bool unspecified: why? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-22 00:12 -0700
                            Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-22 11:10 -0700
                              Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-22 16:52 -0500
                                Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-23 09:55 +1200
                          Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-22 11:01 -0700
                            Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-22 17:17 -0500
                              Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-23 10:46 +1200
                              Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-24 03:48 -0700
                                Re: Size of bool unspecified: why? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-24 12:40 -0500
                                  Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-30 11:22 -0700
                                    Re: Size of bool unspecified: why? "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-07-31 02:33 +0200
                                Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-30 11:34 -0700
                            Re: Size of bool unspecified: why? "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-07-25 04:46 +0200
                  Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-21 07:23 -0700
                    Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 18:52 -0500
                      Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-22 11:24 -0700
                        Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-22 17:22 -0500
                          Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-23 10:51 +1200
                    Re: Size of bool unspecified: why? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-22 00:17 -0700
                      Re: Size of bool unspecified: why? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-22 04:26 -0500
              Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-21 02:09 -0700
                Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 19:11 -0500
                  Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-22 11:58 -0700
                    Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-22 17:48 -0500
              Re: Size of bool unspecified: why? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-21 08:41 -0700
                Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 19:14 -0500
                  Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-22 12:01 -0700
                    Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-22 17:51 -0500
          Re: Size of bool unspecified: why? Noah Roberts <dont@email.me> - 2011-07-20 16:57 -0700
            Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-21 07:29 -0700
              Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 19:24 -0500
                Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-22 12:33 +1200
                  Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 22:42 -0500
          Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-21 01:59 -0700
            Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 19:42 -0500
              Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-22 12:20 -0700
                Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-22 18:21 -0500
    Re: Size of bool unspecified: why? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-16 22:23 -0500
      Re: Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-17 00:07 -0500
        Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-17 17:15 +1200
          Re: Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-17 00:24 -0500
        Re: Size of bool unspecified: why? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-17 02:02 -0500
          Re: Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-17 03:02 -0500
            Re: Size of bool unspecified: why? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-17 03:23 -0500
              Re: Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-17 05:36 -0500
                Re: Size of bool unspecified: why? "James" <no@spam.invalid> - 2011-07-17 16:24 -0700
                  Re: Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-18 06:49 -0500
                    Re: Size of bool unspecified: why? "James" <no@spam.invalid> - 2011-07-18 16:46 -0700
                    Re: Size of bool unspecified: why? Ian Collins <ian-news@hotmail.com> - 2011-07-19 11:59 +1200
                      Re: Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-19 22:18 -0500
          Re: Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-17 03:04 -0500
        Re: Size of bool unspecified: why? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-22 00:32 -0700
        Re: Size of bool unspecified: why? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-22 00:41 -0700
    Re: Size of bool unspecified: why? Juha Nieminen <nospam@thanks.invalid> - 2011-07-17 13:50 +0000
      Re: Size of bool unspecified: why? "MikeP" <mp011011@some.org> - 2011-07-18 06:50 -0500
        Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-20 13:06 -0700
      Re: Size of bool unspecified: why? Pawel Dziepak <pdziepak@quarnos.org> - 2011-07-21 12:59 +0000
        Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-21 07:11 -0700
          Re: Size of bool unspecified: why? "JBarleycorn" <jbnh2o@newsnet.org> - 2011-07-21 19:21 -0500
            Re: Size of bool unspecified: why? James Kanze <james.kanze@gmail.com> - 2011-07-22 12:28 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#7870 — Size of bool unspecified: why?

Why is the size of 'bool' unspecified? That makes bools pretty useless as 
struct members. If one foregoes bools in structs, why not then specify 
that bools should be the size of int and thereby likely to be fast to 
pass to and from functions? (Is it less efficient to pass 
less-than-word-size integers because then they have to be sign-extended 
or zero-extended, or any other reason?) 

[toc] | [next] | [standalone]

#7879

On 7/16/2011 3:33 AM, MikeP wrote:
> Why is the size of 'bool' unspecified? That makes bools pretty useless as
> struct members. If one foregoes bools in structs, why not then specify
> that bools should be the size of int and thereby likely to be fast to
> pass to and from functions? (Is it less efficient to pass
> less-than-word-size integers because then they have to be sign-extended
> or zero-extended, or any other reason?)
>

IIRC, many compilers default to making them the same size as char, or a 
single byte. this tends to be most convinient as, bigger, and they are 
just wasting space, and smaller, as messing with bits is awkward and 
costly (as well as compromising their direct addressability, ...).

as for passing smaller integer types, these tend to be promoted 
internally to the smallest convinient size (namely, int) anyways, and on 
common architectures this doesn't add any real cost (both x86 and ARM 
have instructions to load a byte from memory with sign or zero extension).

granted, yes, this does in-fact still depend on the compiler though.

[toc] | [prev] | [next] | [standalone]

#8006

On Jul 16, 6:02 pm, BGB <cr88...@hotmail.com> wrote:
> On 7/16/2011 3:33 AM, MikeP wrote:

> > Why is the size of 'bool' unspecified? That makes bools pretty useless as
> > struct members. If one foregoes bools in structs, why not then specify
> > that bools should be the size of int and thereby likely to be fast to
> > pass to and from functions? (Is it less efficient to pass
> > less-than-word-size integers because then they have to be sign-extended
> > or zero-extended, or any other reason?)

First, is size of bool unspecified?  Or just implementation
defined?  The size of all types is implementation defined (with
a minimum size).

And I don't see the issue with regards to structs.

> IIRC, many compilers default to making them the same size as char, or a
> single byte. this tends to be most convinient as, bigger, and they are
> just wasting space, and smaller, as messing with bits is awkward and
> costly (as well as compromising their direct addressability, ...).

A bool is required to be addressable; sizeof(bool) is also
required to return an integral value.  So a bool can't be
smaller than a char.  On a byte addressable machine, there's
also no reason to make them bigger, and I would expect them to
usually be the same as a char.  On a word addressable machine,
accessing single bytes may be more expensive than accessing a
complete word, and there are arguments both ways.

> as for passing smaller integer types, these tend to be promoted
> internally to the smallest convinient size (namely, int) anyways, and on
> common architectures this doesn't add any real cost (both x86 and ARM
> have instructions to load a byte from memory with sign or zero extension).

Depending on the context: on many machines, it may be just as
fast to simply pass an int, with garbage in all but the low/high
order byte (depending on endianness).  The garbage doesn't
matter, of course, because the callee won't ever look at it.

> granted, yes, this does in-fact still depend on the compiler
> though.

As does just about everything else.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#8010

James Kanze wrote:
> On Jul 16, 6:02 pm, BGB <cr88...@hotmail.com> wrote:
>> On 7/16/2011 3:33 AM, MikeP wrote:
>
>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>> useless as struct members. If one foregoes bools in structs, why
>>> not then specify that bools should be the size of int and thereby
>>> likely to be fast to pass to and from functions? (Is it less
>>> efficient to pass less-than-word-size integers because then they
>>> have to be sign-extended or zero-extended, or any other reason?)
>
> First, is size of bool unspecified?  Or just implementation
> defined?

Isn't that the same thing?

> The size of all types is implementation defined (with
> a minimum size).
>
> And I don't see the issue with regards to structs.

C compatibility where layout, then, matters? Data transfer/storage.

>
>> IIRC, many compilers default to making them the same size as char,
>> or a single byte. this tends to be most convinient as, bigger, and
>> they are just wasting space, and smaller, as messing with bits is
>> awkward and costly (as well as compromising their direct
>> addressability, ...).
>
> A bool is required to be addressable; sizeof(bool) is also
> required to return an integral value.  So a bool can't be
> smaller than a char.  On a byte addressable machine, there's
> also no reason to make them bigger,

Efficiency?

> and I would expect them to
> usually be the same as a char.  On a word addressable machine,
> accessing single bytes may be more expensive than accessing a
> complete word, and there are arguments both ways.

See, efficiency.

>
>> as for passing smaller integer types, these tend to be promoted
>> internally to the smallest convinient size (namely, int) anyways,

Right, but a type that need not be promoted does not need that extra 
step.

>> and on common architectures this doesn't add any real cost (both x86
>> and ARM have instructions to load a byte from memory with sign or
>> zero extension).
>
> Depending on the context: on many machines, it may be just as
> fast to simply pass an int, with garbage in all but the low/high
> order byte (depending on endianness).

But compilers probably don't do that.

> The garbage doesn't
> matter, of course, because the callee won't ever look at it.
>
>> granted, yes, this does in-fact still depend on the compiler
>> though.
>
> As does just about everything else.

What is common practice though is the real concern because just about 
everything in C++ is platform-dependent. 

[toc] | [prev] | [next] | [standalone]

#8012

On 07/21/11 08:46 AM, JBarleycorn wrote:
> James Kanze wrote:
>> On Jul 16, 6:02 pm, BGB<cr88...@hotmail.com>  wrote:
>>> On 7/16/2011 3:33 AM, MikeP wrote:
>>
>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>> useless as struct members. If one foregoes bools in structs, why
>>>> not then specify that bools should be the size of int and thereby
>>>> likely to be fast to pass to and from functions? (Is it less
>>>> efficient to pass less-than-word-size integers because then they
>>>> have to be sign-extended or zero-extended, or any other reason?)
>>
>> First, is size of bool unspecified?  Or just implementation
>> defined?
>
> Isn't that the same thing?

Not in terms of the standard.  Implementation defined things have to be 
defined by the implementation.

>> The size of all types is implementation defined (with
>> a minimum size).
>>
>> And I don't see the issue with regards to structs.
>
> C compatibility where layout, then, matters? Data transfer/storage.

Then C++ added bool, C didn't have it so there was no layout 
compatibility to maintain.

>>> IIRC, many compilers default to making them the same size as char,
>>> or a single byte. this tends to be most convinient as, bigger, and
>>> they are just wasting space, and smaller, as messing with bits is
>>> awkward and costly (as well as compromising their direct
>>> addressability, ...).
>>
>> A bool is required to be addressable; sizeof(bool) is also
>> required to return an integral value.  So a bool can't be
>> smaller than a char.  On a byte addressable machine, there's
>> also no reason to make them bigger,
>
> Efficiency?

Maybe, but efficiency isn't only dependent on size.  If it were, we'd be 
using 64 bit ints on 64 bit machines.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8016

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:98ou27FaegU3@mid.individual.net...
> On 07/21/11 08:46 AM, JBarleycorn wrote:
>> James Kanze wrote:
>>> On Jul 16, 6:02 pm, BGB<cr88...@hotmail.com>  wrote:
>>>> On 7/16/2011 3:33 AM, MikeP wrote:
>>>
>>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>>> useless as struct members. If one foregoes bools in structs, why
>>>>> not then specify that bools should be the size of int and thereby
>>>>> likely to be fast to pass to and from functions? (Is it less
>>>>> efficient to pass less-than-word-size integers because then they
>>>>> have to be sign-extended or zero-extended, or any other reason?)
>>>
>>> First, is size of bool unspecified?  Or just implementation
>>> defined?
>>
>> Isn't that the same thing?
>
> Not in terms of the standard.  Implementation defined things have to be 
> defined by the implementation.

Why is "unspecified" necessary? Does anyone think that not specifying the 
size of a bool is a good thing?

How can bools be used in structs if every implementation can define it 
differently?

>
>>> The size of all types is implementation defined (with
>>> a minimum size).
>>>
>>> And I don't see the issue with regards to structs.
>>
>> C compatibility where layout, then, matters? Data transfer/storage.
>
> Then C++ added bool, C didn't have it so there was no layout 
> compatibility to maintain.

Oh yeah! The 2 groups should have coordinated the introduction of bool.

>
>>>> IIRC, many compilers default to making them the same size as char,
>>>> or a single byte. this tends to be most convinient as, bigger, and
>>>> they are just wasting space, and smaller, as messing with bits is
>>>> awkward and costly (as well as compromising their direct
>>>> addressability, ...).
>>>
>>> A bool is required to be addressable; sizeof(bool) is also
>>> required to return an integral value.  So a bool can't be
>>> smaller than a char.  On a byte addressable machine, there's
>>> also no reason to make them bigger,
>>
>> Efficiency?
>
> Maybe, but efficiency isn't only dependent on size.  If it were, we'd 
> be using 64 bit ints on 64 bit machines.
>

I meant efficient in time, not space. Are not 64-bit ints indeed more 
efficient (in time) than 32-bit ints, say on x86 vs. x64? Anyone have a 
good simple test for this? Probably at least 3 things need to be eval'd: 
argument passing performance, return value performance, arithmetic 
performance. I can compare the 8-bit bool vs. a 32-bit int on my machine, 
but I don't have a 64-bit machine. 

[toc] | [prev] | [next] | [standalone]

#8020

On 07/21/11 12:32 PM, JBarleycorn wrote:
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:98ou27FaegU3@mid.individual.net...
>> On 07/21/11 08:46 AM, JBarleycorn wrote:
>>> James Kanze wrote:
>>>> On Jul 16, 6:02 pm, BGB<cr88...@hotmail.com>   wrote:
>>>>> On 7/16/2011 3:33 AM, MikeP wrote:
>>>>
>>>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>>>> useless as struct members. If one foregoes bools in structs, why
>>>>>> not then specify that bools should be the size of int and thereby
>>>>>> likely to be fast to pass to and from functions? (Is it less
>>>>>> efficient to pass less-than-word-size integers because then they
>>>>>> have to be sign-extended or zero-extended, or any other reason?)
>>>>
>>>> First, is size of bool unspecified?  Or just implementation
>>>> defined?
>>>
>>> Isn't that the same thing?
>>
>> Not in terms of the standard.  Implementation defined things have to be
>> defined by the implementation.
>
> Why is "unspecified" necessary? Does anyone think that not specifying the
> size of a bool is a good thing?
>
> How can bools be used in structs if every implementation can define it
> differently?

The same way ints can be used in structs when every implementation can 
define them differently.

>>>> The size of all types is implementation defined (with
>>>> a minimum size).
>>>>
>>>> And I don't see the issue with regards to structs.
>>>
>>> C compatibility where layout, then, matters? Data transfer/storage.
>>
>> Then C++ added bool, C didn't have it so there was no layout
>> compatibility to maintain.
>
> Oh yeah! The 2 groups should have coordinated the introduction of bool.

C++ had bool 10 years before it found its way into C.

>>>>> IIRC, many compilers default to making them the same size as char,
>>>>> or a single byte. this tends to be most convinient as, bigger, and
>>>>> they are just wasting space, and smaller, as messing with bits is
>>>>> awkward and costly (as well as compromising their direct
>>>>> addressability, ...).
>>>>
>>>> A bool is required to be addressable; sizeof(bool) is also
>>>> required to return an integral value.  So a bool can't be
>>>> smaller than a char.  On a byte addressable machine, there's
>>>> also no reason to make them bigger,
>>>
>>> Efficiency?
>>
>> Maybe, but efficiency isn't only dependent on size.  If it were, we'd
>> be using 64 bit ints on 64 bit machines.
>>
>
> I meant efficient in time, not space. Are not 64-bit ints indeed more
> efficient (in time) than 32-bit ints, say on x86 vs. x64? Anyone have a
> good simple test for this? Probably at least 3 things need to be eval'd:
> argument passing performance, return value performance, arithmetic
> performance. I can compare the 8-bit bool vs. a 32-bit int on my machine,
> but I don't have a 64-bit machine.

Efficient in time can be the same as efficient in space.  The most 
valuable resource on modern CPUs is the cache, the bigger a data type, 
the quicker the cache overflows.  That's why performance of some 
applications is better built 64 bit and worse for others.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8021

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:98pi8pFroiU1@mid.individual.net...
> On 07/21/11 12:32 PM, JBarleycorn wrote:
>> "Ian Collins"<ian-news@hotmail.com>  wrote in message
>> news:98ou27FaegU3@mid.individual.net...
>>> On 07/21/11 08:46 AM, JBarleycorn wrote:
>>>> James Kanze wrote:
>>>>> On Jul 16, 6:02 pm, BGB<cr88...@hotmail.com>   wrote:
>>>>>> On 7/16/2011 3:33 AM, MikeP wrote:
>>>>>
>>>>>>> Why is the size of 'bool' unspecified? That makes bools pretty
>>>>>>> useless as struct members. If one foregoes bools in structs, why
>>>>>>> not then specify that bools should be the size of int and thereby
>>>>>>> likely to be fast to pass to and from functions? (Is it less
>>>>>>> efficient to pass less-than-word-size integers because then they
>>>>>>> have to be sign-extended or zero-extended, or any other reason?)
>>>>>
>>>>> First, is size of bool unspecified?  Or just implementation
>>>>> defined?
>>>>
>>>> Isn't that the same thing?
>>>
>>> Not in terms of the standard.  Implementation defined things have to 
>>> be
>>> defined by the implementation.
>>
>> Why is "unspecified" necessary? Does anyone think that not specifying 
>> the
>> size of a bool is a good thing?
>>
>> How can bools be used in structs if every implementation can define it
>> differently?
>
> The same way ints can be used in structs when every implementation can 
> define them differently.

You can used fixed-width integers but there is no complementary bool 
type. bool is unusable in structs in many instances then. Serialization 
is not a panacea, it's tedium.

>
>>>>> The size of all types is implementation defined (with
>>>>> a minimum size).
>>>>>
>>>>> And I don't see the issue with regards to structs.
>>>>
>>>> C compatibility where layout, then, matters? Data transfer/storage.
>>>
>>> Then C++ added bool, C didn't have it so there was no layout
>>> compatibility to maintain.
>>
>> Oh yeah! The 2 groups should have coordinated the introduction of 
>> bool.
>
> C++ had bool 10 years before it found its way into C.

Like I said, they should have coordinated the introduction of bool.

>
>>>>>> IIRC, many compilers default to making them the same size as char,
>>>>>> or a single byte. this tends to be most convinient as, bigger, and
>>>>>> they are just wasting space, and smaller, as messing with bits is
>>>>>> awkward and costly (as well as compromising their direct
>>>>>> addressability, ...).
>>>>>
>>>>> A bool is required to be addressable; sizeof(bool) is also
>>>>> required to return an integral value.  So a bool can't be
>>>>> smaller than a char.  On a byte addressable machine, there's
>>>>> also no reason to make them bigger,
>>>>
>>>> Efficiency?
>>>
>>> Maybe, but efficiency isn't only dependent on size.  If it were, we'd
>>> be using 64 bit ints on 64 bit machines.
>>>
>>
>> I meant efficient in time, not space. Are not 64-bit ints indeed more
>> efficient (in time) than 32-bit ints, say on x86 vs. x64? Anyone have 
>> a
>> good simple test for this? Probably at least 3 things need to be 
>> eval'd:
>> argument passing performance, return value performance, arithmetic
>> performance. I can compare the 8-bit bool vs. a 32-bit int on my 
>> machine,
>> but I don't have a 64-bit machine.
>
> Efficient in time can be the same as efficient in space.  The most 
> valuable resource on modern CPUs is the cache, the bigger a data type, 
> the quicker the cache overflows.  That's why performance of some 
> applications is better built 64 bit and worse for others.
>

I guess I'll just have to profile it myself and see if there is 
significant difference. 

[toc] | [prev] | [next] | [standalone]

#8022

On 07/21/11 04:28 PM, JBarleycorn wrote:
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:98pi8pFroiU1@mid.individual.net...
>> On 07/21/11 12:32 PM, JBarleycorn wrote:
>>> "Ian Collins"<ian-news@hotmail.com>   wrote in message
>>> news:98ou27FaegU3@mid.individual.net...
>>>> On 07/21/11 08:46 AM, JBarleycorn wrote:
>>>>> James Kanze wrote:

>>>>>> First, is size of bool unspecified?  Or just implementation
>>>>>> defined?
>>>>>
>>>>> Isn't that the same thing?
>>>>
>>>> Not in terms of the standard.  Implementation defined things have to
>>>> be
>>>> defined by the implementation.
>>>
>>> Why is "unspecified" necessary? Does anyone think that not specifying
>>> the
>>> size of a bool is a good thing?
>>>
>>> How can bools be used in structs if every implementation can define it
>>> differently?
>>
>> The same way ints can be used in structs when every implementation can
>> define them differently.
>
> You can used fixed-width integers but there is no complementary bool
> type. bool is unusable in structs in many instances then. Serialization
> is not a panacea, it's tedium.

The only places where sizeof(bool) matters it will be defined.

>>>>>> A bool is required to be addressable; sizeof(bool) is also
>>>>>> required to return an integral value.  So a bool can't be
>>>>>> smaller than a char.  On a byte addressable machine, there's
>>>>>> also no reason to make them bigger,
>>>>>
>>>>> Efficiency?
>>>>
>>>> Maybe, but efficiency isn't only dependent on size.  If it were, we'd
>>>> be using 64 bit ints on 64 bit machines.
>>>>
>>>
>>> I meant efficient in time, not space. Are not 64-bit ints indeed more
>>> efficient (in time) than 32-bit ints, say on x86 vs. x64? Anyone have
>>> a
>>> good simple test for this? Probably at least 3 things need to be
>>> eval'd:
>>> argument passing performance, return value performance, arithmetic
>>> performance. I can compare the 8-bit bool vs. a 32-bit int on my
>>> machine,
>>> but I don't have a 64-bit machine.
>>
>> Efficient in time can be the same as efficient in space.  The most
>> valuable resource on modern CPUs is the cache, the bigger a data type,
>> the quicker the cache overflows.  That's why performance of some
>> applications is better built 64 bit and worse for others.
>>
>
> I guess I'll just have to profile it myself and see if there is
> significant difference.

Define "it".

What part of "performance of some applications is better built 64 bit 
and worse for others" didn't you get?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8025

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:98pp2qFroiU2@mid.individual.net...
> On 07/21/11 04:28 PM, JBarleycorn wrote:
>> "Ian Collins"<ian-news@hotmail.com>  wrote in message
>> news:98pi8pFroiU1@mid.individual.net...
>>> On 07/21/11 12:32 PM, JBarleycorn wrote:
>>>> "Ian Collins"<ian-news@hotmail.com>   wrote in message
>>>> news:98ou27FaegU3@mid.individual.net...
>>>>> On 07/21/11 08:46 AM, JBarleycorn wrote:
>>>>>> James Kanze wrote:
>
>>>>>>> First, is size of bool unspecified?  Or just implementation
>>>>>>> defined?
>>>>>>
>>>>>> Isn't that the same thing?
>>>>>
>>>>> Not in terms of the standard.  Implementation defined things have 
>>>>> to
>>>>> be
>>>>> defined by the implementation.
>>>>
>>>> Why is "unspecified" necessary? Does anyone think that not 
>>>> specifying
>>>> the
>>>> size of a bool is a good thing?
>>>>
>>>> How can bools be used in structs if every implementation can define 
>>>> it
>>>> differently?
>>>
>>> The same way ints can be used in structs when every implementation 
>>> can
>>> define them differently.
>>
>> You can used fixed-width integers but there is no complementary bool
>> type. bool is unusable in structs in many instances then. 
>> Serialization
>> is not a panacea, it's tedium.
>
> The only places where sizeof(bool) matters it will be defined.

The need for fixed-width integers has been proven and therefore they are 
in the standard, but then they forget the past and create a new type and 
don't consider that width matters for that type. Either that or they 
considered it not useful in the situations where the fixed-width integers 
are a boon. They should have specified a width, as the alternative of 
having multiple booleans of different widths isn't practical I believe.

A header of an application program can check if fixed-width integer types 
are what the program expects and if not, then adjustments can be made, 
but with bool, whaddaya going to do if the size of bool doesn't meet the 
app's expectations? Use an integer of the right size? What's the point of 
having a bool at all then if it is likely that some compiler or version 
of it doesn't support the needed type?

It seems that any case you make for the width of bool being OK 
unspecified, refutes the need for fixed-width integer types, and 
vice-versa. Where is the consistency?

>
>>>>>>> A bool is required to be addressable; sizeof(bool) is also
>>>>>>> required to return an integral value.  So a bool can't be
>>>>>>> smaller than a char.  On a byte addressable machine, there's
>>>>>>> also no reason to make them bigger,
>>>>>>
>>>>>> Efficiency?
>>>>>
>>>>> Maybe, but efficiency isn't only dependent on size.  If it were, 
>>>>> we'd
>>>>> be using 64 bit ints on 64 bit machines.
>>>>>
>>>>
>>>> I meant efficient in time, not space. Are not 64-bit ints indeed 
>>>> more
>>>> efficient (in time) than 32-bit ints, say on x86 vs. x64? Anyone 
>>>> have
>>>> a
>>>> good simple test for this? Probably at least 3 things need to be
>>>> eval'd:
>>>> argument passing performance, return value performance, arithmetic
>>>> performance. I can compare the 8-bit bool vs. a 32-bit int on my
>>>> machine,
>>>> but I don't have a 64-bit machine.
>>>
>>> Efficient in time can be the same as efficient in space.  The most
>>> valuable resource on modern CPUs is the cache, the bigger a data 
>>> type,
>>> the quicker the cache overflows.  That's why performance of some
>>> applications is better built 64 bit and worse for others.
>>>
>>
>> I guess I'll just have to profile it myself and see if there is
>> significant difference.
>
> Define "it".
>
> What part of "performance of some applications is better built 64 bit 
> and worse for others" didn't you get?
>

I don't think it is as nebulous as you make it seem. I gave 3 instances: 
arguments, return vals and arithmetic. I don't believe that *no* 
conclusions can be drawn from analysis of those instances in regards to 
integer sizes. Yes, the assumptions (platforms, compilers...) will have 
to be stated, but that's how scientific study works: you study some 
finite subset of the universe to gain insight. That insight, as a 
practical matter, is what I was looking for. If I was building a language 
from scratch and choosing a size for the boolean type, the performance of 
that type, as a practical matter, would or might factor into the design 
of that type. Similarly, if I was introducing a boolean type into a 
language that does not yet have one, I would consider the same issue. 

[toc] | [prev] | [next] | [standalone]

#8026

On 07/21/11 07:56 PM, JBarleycorn wrote:
> "Ian Collins"<ian-news@hotmail.com>  wrote :
>> On 07/21/11 04:28 PM, JBarleycorn wrote:
>>> "Ian Collins"<ian-news@hotmail.com>   wrote:
>>>> On 07/21/11 12:32 PM, JBarleycorn wrote:
>>>>>
>>>>> How can bools be used in structs if every implementation can define
>>>>> it
>>>>> differently?
>>>>
>>>> The same way ints can be used in structs when every implementation
>>>> can
>>>> define them differently.
>>>
>>> You can used fixed-width integers but there is no complementary bool
>>> type. bool is unusable in structs in many instances then.
>>> Serialization
>>> is not a panacea, it's tedium.
>>
>> The only places where sizeof(bool) matters it will be defined.
>
> The need for fixed-width integers has been proven and therefore they are
> in the standard, but then they forget the past and create a new type and
> don't consider that width matters for that type. Either that or they
> considered it not useful in the situations where the fixed-width integers
> are a boon. They should have specified a width, as the alternative of
> having multiple booleans of different widths isn't practical I believe.

That argument doesn't make sense, given we have fixed with types, why 
should the with of any natural type be fixed?  The analogy with int 
still applies.  If I want a 32 bit signed type, I'll use int32_t. 
Whether that is an int or a long under the hood is irrelevant.

> A header of an application program can check if fixed-width integer types
> are what the program expects and if not, then adjustments can be made,
> but with bool, whaddaya going to do if the size of bool doesn't meet the
> app's expectations?

Who often have you needed to know the size of bool?  What do you do if 
sizeof(int) isn't what the program expects?  You use a different type. 
How is bool different?

> Use an integer of the right size? What's the point of
> having a bool at all then if it is likely that some compiler or version
> of it doesn't support the needed type?

Again, how often is the size of a natural type important?  How often in 
real code do you use a fixed width type?  I'm sure I use them more than 
most because a lot of my work is on embedded platforms or drivers.  I 
seldom use them anywhere else.

> It seems that any case you make for the width of bool being OK
> unspecified, refutes the need for fixed-width integer types, and
> vice-versa. Where is the consistency?

It isn't unspecified, it is implementation defined, just like int.

>>>> Efficient in time can be the same as efficient in space.  The most
>>>> valuable resource on modern CPUs is the cache, the bigger a data
>>>> type,
>>>> the quicker the cache overflows.  That's why performance of some
>>>> applications is better built 64 bit and worse for others.
>>>>
>>>
>>> I guess I'll just have to profile it myself and see if there is
>>> significant difference.
>>
>> Define "it".
>>
>> What part of "performance of some applications is better built 64 bit
>> and worse for others" didn't you get?
>
> I don't think it is as nebulous as you make it seem. I gave 3 instances:
> arguments, return vals and arithmetic. I don't believe that *no*
> conclusions can be drawn from analysis of those instances in regards to
> integer sizes. Yes, the assumptions (platforms, compilers...) will have
> to be stated, but that's how scientific study works: you study some
> finite subset of the universe to gain insight.

Thing go horribly wrong when you study the wrong subset.

> That insight, as a
> practical matter, is what I was looking for. If I was building a language
> from scratch and choosing a size for the boolean type, the performance of
> that type, as a practical matter, would or might factor into the design
> of that type. Similarly, if I was introducing a boolean type into a
> language that does not yet have one, I would consider the same issue.

So what would you do if 8 bits performed best on one platform and 32 on 
another?  You would make the size implementation defined.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8064

Ian Collins wrote:
> On 07/21/11 07:56 PM, JBarleycorn wrote:
>> "Ian Collins"<ian-news@hotmail.com>  wrote :
>>> On 07/21/11 04:28 PM, JBarleycorn wrote:
>>>> "Ian Collins"<ian-news@hotmail.com>   wrote:
>>>>> On 07/21/11 12:32 PM, JBarleycorn wrote:
>>>>>>
>>>>>> How can bools be used in structs if every implementation can
>>>>>> define it
>>>>>> differently?
>>>>>
>>>>> The same way ints can be used in structs when every implementation
>>>>> can
>>>>> define them differently.
>>>>
>>>> You can used fixed-width integers but there is no complementary
>>>> bool type. bool is unusable in structs in many instances then.
>>>> Serialization
>>>> is not a panacea, it's tedium.
>>>
>>> The only places where sizeof(bool) matters it will be defined.
>>
>> The need for fixed-width integers has been proven and therefore they
>> are in the standard, but then they forget the past and create a new
>> type and don't consider that width matters for that type. Either
>> that or they considered it not useful in the situations where the
>> fixed-width integers are a boon. They should have specified a width,
>> as the alternative of having multiple booleans of different widths
>> isn't practical I believe.
>
> That argument doesn't make sense, given we have fixed with types, why
> should the with of any natural type be fixed?  The analogy with int
> still applies.  If I want a 32 bit signed type, I'll use int32_t.
> Whether that is an int or a long under the hood is irrelevant.
>
>> A header of an application program can check if fixed-width integer
>> types are what the program expects and if not, then adjustments can
>> be made, but with bool, whaddaya going to do if the size of bool
>> doesn't meet the app's expectations?
>
> Who often have you needed to know the size of bool?  What do you do if
> sizeof(int) isn't what the program expects?

Why would anyone expect sizeof(int) to be anything specific? int is not 
an issue. The fixed-width sizes are an issue, but you can test for it and 
do whatever is necessary to maintain consistency.

> You use a different type.

A different numeric type, which there are a number to choose from. Who 
writes a program that doesn't have a header that tests for assumptions 
based upon the platform?

> How is bool different?

If bool doesn't meet your expectations, you don't have the option to 
change to a similar type of different width, because there is no similar 
type of different width. You have to change compilers or something. *Or*, 
avoid bool from the get go noting from the start that you can't rely on 
the width of bool. What the current practice is across a wide variety of 
compilers, or just the "major" ones, I don't know: that would be good 
info and maybe some consolation, but bool does appear to be broken from 
the get go.

>
>> Use an integer of the right size? What's the point of
>> having a bool at all then if it is likely that some compiler or
>> version of it doesn't support the needed type?
>
> Again, how often is the size of a natural type important?

*Very* often.

> How often
> in real code do you use a fixed width type?

*Very* often. *Very* much more often than using non-fixed-width integral 
types.

> I'm sure I use them more
> than most because a lot of my work is on embedded platforms or
> drivers.

Well there you go then.

> I seldom use them anywhere else.
>
>> It seems that any case you make for the width of bool being OK
>> unspecified, refutes the need for fixed-width integer types, and
>> vice-versa. Where is the consistency?
>
> It isn't unspecified, it is implementation defined, just like int.

The same issue exists with int, *but* there are the alternative 
fixed-width integral types and even when their weren't the fixed-width 
types, there was still enough choice there to get what is desired. I use 
a boolean class, where I can control the width and still get the behavior 
of a boolean,  for use in structs but I have to because built-in bool is 
broken.

>
>>>>> Efficient in time can be the same as efficient in space.  The most
>>>>> valuable resource on modern CPUs is the cache, the bigger a data
>>>>> type,
>>>>> the quicker the cache overflows.  That's why performance of some
>>>>> applications is better built 64 bit and worse for others.
>>>>>
>>>>
>>>> I guess I'll just have to profile it myself and see if there is
>>>> significant difference.
>>>
>>> Define "it".
>>>
>>> What part of "performance of some applications is better built 64
>>> bit and worse for others" didn't you get?
>>
>> I don't think it is as nebulous as you make it seem. I gave 3
>> instances: arguments, return vals and arithmetic. I don't believe
>> that *no* conclusions can be drawn from analysis of those instances
>> in regards to integer sizes. Yes, the assumptions (platforms,
>> compilers...) will have to be stated, but that's how scientific
>> study works: you study some finite subset of the universe to gain
>> insight.
>
> Thing go horribly wrong when you study the wrong subset.
>
>> That insight, as a
>> practical matter, is what I was looking for. If I was building a
>> language from scratch and choosing a size for the boolean type, the
>> performance of that type, as a practical matter, would or might
>> factor into the design of that type. Similarly, if I was introducing
>> a boolean type into a language that does not yet have one, I would
>> consider the same issue.
>
> So what would you do if 8 bits performed best on one platform and 32
> on another?

I would use that information in choosing a design.

> You would make the size implementation defined.

No, not likely for then bool would be eliminated from a lot of places 
where it could be used to good effect. I think multiple-width boolean 
types can be made to work, but the complexity is not worth it, so 1-byte 
bools, even though there may be a performance penalty on most platforms, 
are probably the best choice. I have pretty much decided that where a 
"fast bool" is needed it's a profile/optimizaation thing and trying to 
find an optimum boolean type size as the best compromise across a set of 
platforms falls into the category of premature optimization. Therefore, 
the overriding concern is suitability for use as a struct field. So, my 
boolean class uses a 1-byte type as the underlying type. 

[toc] | [prev] | [next] | [standalone]

#8065

On 07/22/11 11:29 AM, JBarleycorn wrote:
> Ian Collins wrote:
>> On 07/21/11 07:56 PM, JBarleycorn wrote:
>>> "Ian Collins"<ian-news@hotmail.com>   wrote :
>>>
>>> The need for fixed-width integers has been proven and therefore they
>>> are in the standard, but then they forget the past and create a new
>>> type and don't consider that width matters for that type. Either
>>> that or they considered it not useful in the situations where the
>>> fixed-width integers are a boon. They should have specified a width,
>>> as the alternative of having multiple booleans of different widths
>>> isn't practical I believe.
>>
>> That argument doesn't make sense, given we have fixed with types, why
>> should the with of any natural type be fixed?  The analogy with int
>> still applies.  If I want a 32 bit signed type, I'll use int32_t.
>> Whether that is an int or a long under the hood is irrelevant.
>>
>>> A header of an application program can check if fixed-width integer
>>> types are what the program expects and if not, then adjustments can
>>> be made, but with bool, whaddaya going to do if the size of bool
>>> doesn't meet the app's expectations?
>>
>> Who often have you needed to know the size of bool?  What do you do if
>> sizeof(int) isn't what the program expects?
>
> Why would anyone expect sizeof(int) to be anything specific? int is not
> an issue. The fixed-width sizes are an issue, but you can test for it and
> do whatever is necessary to maintain consistency.
>
>> You use a different type.
>
> A different numeric type, which there are a number to choose from. Who
> writes a program that doesn't have a header that tests for assumptions
> based upon the platform?

Anyone who is writing for a specific platform, or who doesn't care about 
the sizes of natural types.

>> How is bool different?
>
> If bool doesn't meet your expectations, you don't have the option to
> change to a similar type of different width, because there is no similar
> type of different width. You have to change compilers or something. *Or*,
> avoid bool from the get go noting from the start that you can't rely on
> the width of bool. What the current practice is across a wide variety of
> compilers, or just the "major" ones, I don't know: that would be good
> info and maybe some consolation, but bool does appear to be broken from
> the get go.

OK, give one concrete example where the size of bool matters.

>>> Use an integer of the right size? What's the point of
>>> having a bool at all then if it is likely that some compiler or
>>> version of it doesn't support the needed type?
>>
>> Again, how often is the size of a natural type important?
>
> *Very* often.

So you are writing embedded code or drivers?  There are very few other 
places where the size of type matters.

>>> It seems that any case you make for the width of bool being OK
>>> unspecified, refutes the need for fixed-width integer types, and
>>> vice-versa. Where is the consistency?
>>
>> It isn't unspecified, it is implementation defined, just like int.
>
> The same issue exists with int, *but* there are the alternative
> fixed-width integral types and even when their weren't the fixed-width
> types, there was still enough choice there to get what is desired. I use
> a boolean class, where I can control the width and still get the behavior
> of a boolean,  for use in structs but I have to because built-in bool is
> broken.

You keep staying bool is broken, but you still haven't provided any real 
world examples to back it up.

>>> That insight, as a
>>> practical matter, is what I was looking for. If I was building a
>>> language from scratch and choosing a size for the boolean type, the
>>> performance of that type, as a practical matter, would or might
>>> factor into the design of that type. Similarly, if I was introducing
>>> a boolean type into a language that does not yet have one, I would
>>> consider the same issue.
>>
>> So what would you do if 8 bits performed best on one platform and 32
>> on another?
>
> I would use that information in choosing a design.

How would your design cope with both 8 bit MCUs and 32 bit DSPs (where 
CHAR_BIT = 32)?

>> You would make the size implementation defined.
>
> No, not likely for then bool would be eliminated from a lot of places
> where it could be used to good effect.

Please name one.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8073

Ian Collins wrote:
> On 07/22/11 11:29 AM, JBarleycorn wrote:
>> Ian Collins wrote:
>>> On 07/21/11 07:56 PM, JBarleycorn wrote:
>>>> "Ian Collins"<ian-news@hotmail.com>   wrote :
>>>>
>>>> The need for fixed-width integers has been proven and therefore
>>>> they are in the standard, but then they forget the past and create
>>>> a new type and don't consider that width matters for that type.
>>>> Either that or they considered it not useful in the situations
>>>> where the fixed-width integers are a boon. They should have
>>>> specified a width, as the alternative of having multiple booleans
>>>> of different widths isn't practical I believe.
>>>
>>> That argument doesn't make sense, given we have fixed with types,
>>> why should the with of any natural type be fixed?  The analogy with
>>> int still applies.  If I want a 32 bit signed type, I'll use
>>> int32_t. Whether that is an int or a long under the hood is
>>> irrelevant.
>>>> A header of an application program can check if fixed-width integer
>>>> types are what the program expects and if not, then adjustments can
>>>> be made, but with bool, whaddaya going to do if the size of bool
>>>> doesn't meet the app's expectations?
>>>
>>> Who often have you needed to know the size of bool?  What do you do
>>> if sizeof(int) isn't what the program expects?
>>
>> Why would anyone expect sizeof(int) to be anything specific? int is
>> not an issue. The fixed-width sizes are an issue, but you can test
>> for it and do whatever is necessary to maintain consistency.
>>
>>> You use a different type.
>>
>> A different numeric type, which there are a number to choose from.
>> Who writes a program that doesn't have a header that tests for
>> assumptions based upon the platform?
>
> Anyone who is writing for a specific platform, or who doesn't care
> about the sizes of natural types.
>
>>> How is bool different?
>>
>> If bool doesn't meet your expectations, you don't have the option to
>> change to a similar type of different width, because there is no
>> similar type of different width. You have to change compilers or
>> something. *Or*, avoid bool from the get go noting from the start
>> that you can't rely on the width of bool. What the current practice
>> is across a wide variety of compilers, or just the "major" ones, I
>> don't know: that would be good info and maybe some consolation, but
>> bool does appear to be broken from the get go.
>
> OK, give one concrete example where the size of bool matters.
>
>>>> Use an integer of the right size? What's the point of
>>>> having a bool at all then if it is likely that some compiler or
>>>> version of it doesn't support the needed type?
>>>
>>> Again, how often is the size of a natural type important?
>>
>> *Very* often.
>
> So you are writing embedded code or drivers?  There are very few other
> places where the size of type matters.
>
>>>> It seems that any case you make for the width of bool being OK
>>>> unspecified, refutes the need for fixed-width integer types, and
>>>> vice-versa. Where is the consistency?
>>>
>>> It isn't unspecified, it is implementation defined, just like int.
>>
>> The same issue exists with int, *but* there are the alternative
>> fixed-width integral types and even when their weren't the
>> fixed-width types, there was still enough choice there to get what
>> is desired. I use a boolean class, where I can control the width and
>> still get the behavior of a boolean,  for use in structs but I have
>> to because built-in bool is broken.
>
> You keep staying bool is broken, but you still haven't provided any
> real world examples to back it up.
>
>>>> That insight, as a
>>>> practical matter, is what I was looking for. If I was building a
>>>> language from scratch and choosing a size for the boolean type, the
>>>> performance of that type, as a practical matter, would or might
>>>> factor into the design of that type. Similarly, if I was
>>>> introducing a boolean type into a language that does not yet have
>>>> one, I would consider the same issue.
>>>
>>> So what would you do if 8 bits performed best on one platform and 32
>>> on another?
>>
>> I would use that information in choosing a design.
>
> How would your design cope with both 8 bit MCUs and 32 bit DSPs (where
> CHAR_BIT = 32)?

*I* don't have to for I consider anything where char is not 8 bits to be 
an exotic.

>
>>> You would make the size implementation defined.
>>
>> No, not likely for then bool would be eliminated from a lot of places
>> where it could be used to good effect.
>
> Please name one.

On the other stuff, we're going around in circles so I'll just leave it 
at that. Please my replies to JK in this thread for more insight to the 
"bool is broken" thing. I've already noted that having some kind of 
specification of fixed-width integral types in the standard shows that 
the size of a type does matter. In addition, I'll add here that 
recognition that type size matters was the motivation for modifying enums 
so that the type could be specified. Before that, enums were also broken. 
In the same vein, bool is broken, because there is no way to rely on the 
size of it (though in practice maybe it doesn't vary so much across 
platforms... I don't know). 

[toc] | [prev] | [next] | [standalone]

#8075

On 07/22/11 03:33 PM, JBarleycorn wrote:
> Ian Collins wrote:
>> On 07/22/11 11:29 AM, JBarleycorn wrote:
>>> Ian Collins wrote:
>>>>
>>>> So what would you do if 8 bits performed best on one platform and 32
>>>> on another?
>>>
>>> I would use that information in choosing a design.
>>
>> How would your design cope with both 8 bit MCUs and 32 bit DSPs (where
>> CHAR_BIT = 32)?
>
> *I* don't have to for I consider anything where char is not 8 bits to be
> an exotic.

How can something that exists in the hundreds of millions be considered 
exotic?

>>>> You would make the size implementation defined.
>>>
>>> No, not likely for then bool would be eliminated from a lot of places
>>> where it could be used to good effect.
>>
>> Please name one.
>
> On the other stuff, we're going around in circles so I'll just leave it
> at that. Please my replies to JK in this thread for more insight to the
> "bool is broken" thing.

I assume you won't give a real world example why bool is "broken" 
because you don't have one.

> I've already noted that having some kind of
> specification of fixed-width integral types in the standard shows that
> the size of a type does matter.

For specialised cases, where bool wouldn't be appropriate.

> In addition, I'll add here that
> recognition that type size matters was the motivation for modifying enums
> so that the type could be specified. Before that, enums were also broken.
> In the same vein, bool is broken, because there is no way to rely on the
> size of it (though in practice maybe it doesn't vary so much across
> platforms... I don't know).

Yet again, in most cases, the size doesn't matter.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8076

Ian Collins wrote:
> On 07/22/11 03:33 PM, JBarleycorn wrote:
>> Ian Collins wrote:
>>> On 07/22/11 11:29 AM, JBarleycorn wrote:
>>>> Ian Collins wrote:
>>>>>
>>>>> So what would you do if 8 bits performed best on one platform and
>>>>> 32 on another?
>>>>
>>>> I would use that information in choosing a design.
>>>
>>> How would your design cope with both 8 bit MCUs and 32 bit DSPs
>>> (where CHAR_BIT = 32)?
>>
>> *I* don't have to for I consider anything where char is not 8 bits
>> to be an exotic.
>
> How can something that exists in the hundreds of millions be
> considered exotic?
>
>>>>> You would make the size implementation defined.
>>>>
>>>> No, not likely for then bool would be eliminated from a lot of
>>>> places where it could be used to good effect.
>>>
>>> Please name one.
>>
>> On the other stuff, we're going around in circles so I'll just leave
>> it at that. Please my replies to JK in this thread for more insight
>> to the "bool is broken" thing.
>
> I assume you won't give a real world example why bool is "broken"
> because you don't have one.

That you wrote that and keep asking that shows you don't know what the 
discussion is all about. I refer you to read the other posts.

>
>> I've already noted that having some kind of
>> specification of fixed-width integral types in the standard shows
>> that the size of a type does matter.
>
> For specialised cases, where bool wouldn't be appropriate.
>
>> In addition, I'll add here that
>> recognition that type size matters was the motivation for modifying
>> enums so that the type could be specified. Before that, enums were
>> also broken. In the same vein, bool is broken, because there is no
>> way to rely on the size of it (though in practice maybe it doesn't
>> vary so much across platforms... I don't know).
>
> Yet again, in most cases, the size doesn't matter.

Just the opposite, to me (as I have noted in *another post*): in most 
cases, type size does matter. That you may choose not to take advantage 
of the capabilities that the language offers is up to you. I, OTOH, 
exploit it as required and as can be had. 

[toc] | [prev] | [next] | [standalone]

#8077

On 07/22/11 04:07 PM, JBarleycorn wrote:
> Ian Collins wrote:
>>
>> I assume you won't give a real world example why bool is "broken"
>> because you don't have one.
>
> That you wrote that and keep asking that shows you don't know what the
> discussion is all about. I refer you to read the other posts.

I keep asking because you keep making unsubstantiated claims.  Time to 
put up.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8354

On 07/31/11 05:52 PM, JBarleycorn wrote:
> Ian Collins wrote:
>> On 07/22/11 04:07 PM, JBarleycorn wrote:
>>> Ian Collins wrote:
>>>>
>>>> I assume you won't give a real world example why bool is "broken"
>>>> because you don't have one.
>>>
>>> That you wrote that and keep asking that shows you don't know what
>>> the discussion is all about. I refer you to read the other posts.
>>
>> I keep asking because you keep making unsubstantiated claims.  Time to
>> put up.
>
> Sounded like a demand.  Hmm?

Looks like a troll who changes his address...

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8079

On Jul 22, 12:29 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> Ian Collins wrote:

<snip>

> > Who often have you needed to know the size of bool?  What do you do if
> > sizeof(int) isn't what the program expects?
>
> Why would anyone expect sizeof(int) to be anything specific? int is not
> an issue. The fixed-width sizes are an issue, but you can test for it and
> do whatever is necessary to maintain consistency.

if you want struct with predicatable layout you have to replace all
the ints with int32_t (or int16_t). Just do the same with bools. I'm
sorry I can't see the difference.

<snip>

Why is bool in any way special?

[toc] | [prev] | [next] | [standalone]

#8098

On Jul 22, 8:12 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Jul 22, 12:29 am, "JBarleycorn" <jbn...@newsnet.org> wrote:

> > Ian Collins wrote:

> <snip>
> > > Who often have you needed to know the size of bool?  What do you do if
> > > sizeof(int) isn't what the program expects?

> > Why would anyone expect sizeof(int) to be anything specific? int is not
> > an issue. The fixed-width sizes are an issue, but you can test for it and
> > do whatever is necessary to maintain consistency.

> if you want struct with predicatable layout you have to replace all
> the ints with int32_t (or int16_t). Just do the same with bools. I'm
> sorry I can't see the difference.

That still doesn't give you a struct with predictable layout.
int32_t has a different layout on a Sparc than on a PC.  And
doesn't even exist on some mainframes.  (The standard requires
int32_t to be a 2's complement representation.  And at least two
mainframe architectures don't use 2's complement.)  Machines
without int32_t can probably be considered exotic, and I suspect
that most programmers don't have to take them into account.  On
the other hand, Intel's layout of int32_t is not the same as
that of a Sparc or a Power PC, both widespread architectures.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web