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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#8111

"James Kanze" <james.kanze@gmail.com> wrote in message 
news:1d131f6b-ea70-4af3-ac28-0a5cde03a267@m10g2000yqd.googlegroups.com...
> 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.
>

If you meant endianness, why not just say so? (And don't those allow 
choice of endianness upon system setup?). 

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

#8112

On 07/23/11 09:52 AM, JBarleycorn wrote:
> "James Kanze"<james.kanze@gmail.com>  wrote in message
> news:1d131f6b-ea70-4af3-ac28-0a5cde03a267@m10g2000yqd.googlegroups.com...
>> 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.
>>
>
> If you meant endianness, why not just say so? (And don't those allow
> choice of endianness upon system setup?).

No and yes.

-- 
Ian Collins

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

#8097

On Jul 22, 12:29 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> Ian Collins wrote:
> > On 07/21/11 07:56 PM, JBarleycorn wrote:
> >> "Ian Collins"<ian-n...@hotmail.com>  wrote :
> >>> On 07/21/11 04:28 PM, JBarleycorn wrote:
> >>>> "Ian Collins"<ian-n...@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?

Who does?  In over thirty years of experience in C and C++, I've
yet to see any application which uses such a header.  I'm
tempted to say that someone who uses such a header doesn't
understand the basic philosophy behind C and C++.

> > 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.

Sure there is: signed char, short, int and long are all similar
types, with potentially different widths.  (Don't ask me why
bool is a signed integral type, rather than an unsigned one.)

> 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.

Exactly like every other integral type.

> >> 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.

For example?  You keep saying it's important, but I've only
encountered the case in a few rare instances.  (For starters, it
can't be important in portable code.)

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

> *Very* often.

Then there's something wrong with your programming style.

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

Then there's something very wrong with your programming style.

> > 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.

Drivers are a bit special, but even in drivers, it's not rare to
use the standard types.  And of course, unless things have
changed enormously since I was writing drivers, the fixed width
types don't occur in structs.

    [...]
> 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.

That sounds like the most rational decision.  Or rather, you use
the bool the implementation gives you, until you need something
faster for your application.  (As I've mentionned earlier, I
expect that bool is a single byte on most, if not all, byte
addressed platforms.)

--
James Kanze

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

#8114

"James Kanze" <james.kanze@gmail.com> wrote in message 
news:2ba060fd-d11e-4cda-b0c8-1038a58b6cf6@a31g2000vbt.googlegroups.com...
> On Jul 22, 12:29 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> Ian Collins wrote:
>> > On 07/21/11 07:56 PM, JBarleycorn wrote:
>> >> "Ian Collins"<ian-n...@hotmail.com>  wrote :
>> >>> On 07/21/11 04:28 PM, JBarleycorn wrote:
>> >>>> "Ian Collins"<ian-n...@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?
>
> Who does?  In over thirty years of experience in C and C++, I've
> yet to see any application which uses such a header.  I'm
> tempted to say that someone who uses such a header doesn't
> understand the basic philosophy behind C and C++.

Now we're getting somewhere! You saying that you code against a 
*"philosophical"* paradigm. The word "religion" will surface soon, I'm 
sure. Then you can say that my designs are unholy and yours are holy and 
then the congregation you belong to will ... something.

>
>> > 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.
>
> Sure there is: signed char, short, int and long are all similar
> types, with potentially different widths.  (Don't ask me why
> bool is a signed integral type, rather than an unsigned one.)

Like I *said*: there is no *similar* type.

1. That C++ bool is a half-assed integral type, adds to its brokeness.
2. Full-blown integral behavior is not *similar* to boolean behavior.

(Surely it's signed so it converts to what the standard likes to view as 
ubiquitous (a broken line of reasoning IMO): int.)

>
>> 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.
>
> Exactly like every other integral type.
>

I'm not going to repeat myself. If you conveniently want to ignore what 
I've said before, fine, but don't try to keep the discussion going then 
just to "listen to your own voice". I'm giving you a convenient platform 
to propagandize? Fool me once, shame on you, fool me twice, shame on me!

>> >> 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.
>
> For example?  You keep saying it's important, but I've only
> encountered the case in a few rare instances.  (For starters, it
> can't be important in portable code.)
>
>> > How often in real code do you use a fixed width type?
>
>> *Very* often.
>
> Then there's something wrong with your programming style.
>
>> *Very* much more often than using non-fixed-width integral
>> types.
>
> Then there's something very wrong with your programming style.

Contraire: you are limited by your paradigm (or choose to promote it for 
ulterior reasons). (Or I'm so far ahead of you that you can't even see 
the dust anymore... Beep! Beep!).

>
>> > 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.
>
> Drivers are a bit special, but even in drivers, it's not rare to
> use the standard types.  And of course, unless things have
> changed enormously since I was writing drivers, the fixed width
> types don't occur in structs.
>
>    [...]
>> 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.
>
> That sounds like the most rational decision.  Or rather, you use
> the bool the implementation gives you, until you need something
> faster for your application.

1. The size of C++ bool can't be relied on.
2. C++ bool has brain-damaged behavior (promotion to int).

The only reason bool is needed at all is because relational expressions 
are of type bool. Yes, that broken, brain-damaged little boolean type is 
inextricably interleaved throughout all C++ source code. :(

>  (As I've mentionned earlier, I
> expect that bool is a single byte on most, if not all, byte
> addressed platforms.)
>

Now it is, but historically, I have an incling, that on all those 
platforms, bool was synonymous with int. In that case, you have just 
different versions (old and new) of the compiler and encounter a size 
change of type (or synonym) bool.

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

#8116

On 07/23/11 10:17 AM, JBarleycorn wrote:
> "James Kanze"<james.kanze@gmail.com>  wrote:
>> On Jul 22, 12:29 am, "JBarleycorn"<jbn...@newsnet.org>  wrote:
>>> Ian Collins wrote:
>>
>>>> Again, how often is the size of a natural type important?
>>
>>> *Very* often.
>>
>> For example?  You keep saying it's important, but I've only
>> encountered the case in a few rare instances.  (For starters, it
>> can't be important in portable code.)
>>
>>>> How often in real code do you use a fixed width type?
>>
>>> *Very* often.
>>
>> Then there's something wrong with your programming style.
>>
>>> *Very* much more often than using non-fixed-width integral
>>> types.
>>
>> Then there's something very wrong with your programming style.
>
> Contraire: you are limited by your paradigm (or choose to promote it for
> ulterior reasons). (Or I'm so far ahead of you that you can't even see
> the dust anymore... Beep! Beep!).

Come on, enough piss and wind, let's see some real examples.  If you 
have any that is...

-- 
Ian Collins

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

#8137

On Jul 22, 11:17 pm, "JBarleycorn" <jbn...@newsnet.org> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message
> news:2ba060fd-d11e-4cda-b0c8-1038a58b6cf6@a31g2000vbt.googlegroups.com...

    [...]
> > Who does?  In over thirty years of experience in C and C++, I've
> > yet to see any application which uses such a header.  I'm
> > tempted to say that someone who uses such a header doesn't
> > understand the basic philosophy behind C and C++.

> Now we're getting somewhere! You saying that you code against a
> *"philosophical"* paradigm.

I'm saying that I use data abstraction, as a tool to manage
complexity.

> The word "religion" will surface soon, I'm
> sure. Then you can say that my designs are unholy and yours are holy and
> then the congregation you belong to will ... something.

There's no religion about it: the higher the level of
abstraction, the more efficient the programmer.  Given a good
compiler (something rare), the more efficient the generated
code, too.  Against higher levels of abstraction: it's often
more work (defining a class, where just using int will do), and
some particular interfaces (including most serialization) are
defined in terms of a low level of abstraction.

> >> > 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.

> > Sure there is: signed char, short, int and long are all similar
> > types, with potentially different widths.  (Don't ask me why
> > bool is a signed integral type, rather than an unsigned one.)

> Like I *said*: there is no *similar* type.

Except all signed integral types.

    [...]
> > Exactly like every other integral type.

> I'm not going to repeat myself.

Because there's nothing to repeat?  To date, you've yet to give
any concrete reason why there's a problem with bool.  Just vague
assertations which aren't supported by actual facts.

> > That sounds like the most rational decision.  Or rather, you use
> > the bool the implementation gives you, until you need something
> > faster for your application.

> 1. The size of C++ bool can't be relied on.

So what?  If you're worried about the size of bool, you're
worried about the wrong things.

> 2. C++ bool has brain-damaged behavior (promotion to int).

I wouldn't go so far as "brain-damaged" (unless you want to
argue that C++ is brain-damaged everywhere, because it is based
on C).  It's regrettable.  It's also necessary, for reasons of
backward compatibility.  Like the original authors of the
proposal, I would have preferred that the implicit conversions
be deprecated, but there was no consensus in the committee for
this, so it wasn't.

> >  (As I've mentionned earlier, I
> > expect that bool is a single byte on most, if not all, byte
> > addressed platforms.)

> Now it is, but historically, I have an incling, that on all those
> platforms, bool was synonymous with int. In that case, you have just
> different versions (old and new) of the compiler and encounter a size
> change of type (or synonym) bool.

Historically, there wasn't a type bool, and a lot of programmers
used:
    typedef int bool;
(I wouldn't be surprised if <windows.h> still has a typedef for
BOOL.  Or maybe a macro.)  I don't think that any implementation
on a byte addressable machine has ever made it more than a byte.
(But since I've never worried about it, I could be wrong.)

--
James Kanze

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

#8146

On Sun, 24 Jul 2011 03:48:08 -0700 (PDT), James Kanze
<james.kanze@gmail.com> wrote:

>On Jul 22, 11:17 pm, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> "James Kanze" <james.ka...@gmail.com> wrote in message
>> news:2ba060fd-d11e-4cda-b0c8-1038a58b6cf6@a31g2000vbt.googlegroups.com...
>
>    [...]
>> > Who does?  In over thirty years of experience in C and C++, I've
>> > yet to see any application which uses such a header.  I'm
>> > tempted to say that someone who uses such a header doesn't
>> > understand the basic philosophy behind C and C++.
>
>> Now we're getting somewhere! You saying that you code against a
>> *"philosophical"* paradigm.
>
>I'm saying that I use data abstraction, as a tool to manage
>complexity.
>
>> The word "religion" will surface soon, I'm
>> sure. Then you can say that my designs are unholy and yours are holy and
>> then the congregation you belong to will ... something.
>
>There's no religion about it: the higher the level of
>abstraction, the more efficient the programmer.  Given a good
>compiler (something rare), the more efficient the generated
>code, too.  Against higher levels of abstraction: it's often
>more work (defining a class, where just using int will do), and
>some particular interfaces (including most serialization) are
>defined in terms of a low level of abstraction.
>
>> >> > 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.
>
>> > Sure there is: signed char, short, int and long are all similar
>> > types, with potentially different widths.  (Don't ask me why
>> > bool is a signed integral type, rather than an unsigned one.)
>
>> Like I *said*: there is no *similar* type.
>
>Except all signed integral types.
>
>    [...]
>> > Exactly like every other integral type.
>
>> I'm not going to repeat myself.
>
>Because there's nothing to repeat?  To date, you've yet to give
>any concrete reason why there's a problem with bool.  Just vague
>assertations which aren't supported by actual facts.
>
>> > That sounds like the most rational decision.  Or rather, you use
>> > the bool the implementation gives you, until you need something
>> > faster for your application.
>
>> 1. The size of C++ bool can't be relied on.
>
>So what?  If you're worried about the size of bool, you're
>worried about the wrong things.
>
>> 2. C++ bool has brain-damaged behavior (promotion to int).
>
>I wouldn't go so far as "brain-damaged" (unless you want to
>argue that C++ is brain-damaged everywhere, because it is based
>on C).  It's regrettable.  It's also necessary, for reasons of
>backward compatibility.  Like the original authors of the
>proposal, I would have preferred that the implicit conversions
>be deprecated, but there was no consensus in the committee for
>this, so it wasn't.
>
>> >  (As I've mentionned earlier, I
>> > expect that bool is a single byte on most, if not all, byte
>> > addressed platforms.)
>
>> Now it is, but historically, I have an incling, that on all those
>> platforms, bool was synonymous with int. In that case, you have just
>> different versions (old and new) of the compiler and encounter a size
>> change of type (or synonym) bool.
>
>Historically, there wasn't a type bool, and a lot of programmers
>used:
>    typedef int bool;
>(I wouldn't be surprised if <windows.h> still has a typedef for
>BOOL.  Or maybe a macro.)  I don't think that any implementation
>on a byte addressable machine has ever made it more than a byte.
>(But since I've never worried about it, I could be wrong.)


Just for variety, the Windows API has BOOL, which typedefs as an int
(and is a very old definition in Windows - back to at least Win2.x),
plus the newer BOOLEAN, which typedefs as a char (byte).

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

#8337

On Jul 24, 6:40 pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> On Sun, 24 Jul 2011 03:48:08 -0700 (PDT), James Kanze
> <james.ka...@gmail.com> wrote:
> >On Jul 22, 11:17 pm, "JBarleycorn" <jbn...@newsnet.org> wrote:
> >> "James Kanze" <james.ka...@gmail.com> wrote in message
> >>news:2ba060fd-d11e-4cda-b0c8-1038a58b6cf6@a31g2000vbt.googlegroups.com...
>
> >    [...]
> >Historically, there wasn't a type bool, and a lot of programmers
> >used:
> >    typedef int bool;
> >(I wouldn't be surprised if <windows.h> still has a typedef for
> >BOOL.  Or maybe a macro.)  I don't think that any implementation
> >on a byte addressable machine has ever made it more than a byte.
> >(But since I've never worried about it, I could be wrong.)

> Just for variety, the Windows API has BOOL, which typedefs as an int
> (and is a very old definition in Windows - back to at least Win2.x),
> plus the newer BOOLEAN, which typedefs as a char (byte).

And if I recall correctly, some of the functions which return
BOOL return 1, 0 or -1 (yes, no or maybe?  true, false, or I
don't know?).

--
James Kanze

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

#8347

On 30.07.2011 20:22, James Kanze wrote:
> On Jul 24, 6:40 pm, Robert Wessel<robertwess...@yahoo.com>  wrote:
>> On Sun, 24 Jul 2011 03:48:08 -0700 (PDT), James Kanze
>> <james.ka...@gmail.com>  wrote:
>>> On Jul 22, 11:17 pm, "JBarleycorn"<jbn...@newsnet.org>  wrote:
>>>> "James Kanze"<james.ka...@gmail.com>  wrote in message
>>>> news:2ba060fd-d11e-4cda-b0c8-1038a58b6cf6@a31g2000vbt.googlegroups.com...
>>
>>>     [...]
>>> Historically, there wasn't a type bool, and a lot of programmers
>>> used:
>>>     typedef int bool;
>>> (I wouldn't be surprised if<windows.h>  still has a typedef for
>>> BOOL.  Or maybe a macro.)  I don't think that any implementation
>>> on a byte addressable machine has ever made it more than a byte.
>>> (But since I've never worried about it, I could be wrong.)
>
>> Just for variety, the Windows API has BOOL, which typedefs as an int
>> (and is a very old definition in Windows - back to at least Win2.x),
>> plus the newer BOOLEAN, which typedefs as a char (byte).
>
> And if I recall correctly, some of the functions which return
> BOOL return 1, 0 or -1 (yes, no or maybe?  true, false, or I
> don't know?).

BOOL was used as an allround x != 0 boolean type, yes, in particular as 
result of dialog proc.

It's one of the reasons that writing x == true is a very bad habit.

Then there was/is VARIANT_BOOL, where true is -1. It's for the script 
language interface, which was originally the Visual Basic interface.

Cheers,

- Alf

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

#8336

On Jul 25, 5:49 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> James Kanze wrote:
> > On Jul 22, 11:17 pm, "JBarleycorn" <jbn...@newsnet.org> wrote:
> >> "James Kanze" <james.ka...@gmail.com> wrote in message
> >>news:2ba060fd-d11e-4cda-b0c8-1038a58b6cf6@a31g2000vbt.googlegroups.com...

> >    [...]
> >>> Who does?  In over thirty years of experience in C and C++, I've
> >>> yet to see any application which uses such a header.  I'm
> >>> tempted to say that someone who uses such a header doesn't
> >>> understand the basic philosophy behind C and C++.

> >> Now we're getting somewhere! You saying that you code against a
> >> *"philosophical"* paradigm.

> > I'm saying that I use data abstraction, as a tool to manage
> > complexity.

> No, you did not say that.

I said enough that any competent programmer would have
understood it that way.

> >> The word "religion" will surface soon, I'm
> >> sure. Then you can say that my designs are unholy and yours are holy
> >> and then the congregation you belong to will ... something.

> > There's no religion about it

> scuuze me, "philosophy", as you put it then.

It's neither philosophy nor religion.  It's effective, pragmatic
programming,

> > : the higher the level of
> > abstraction,

> Whoa, what would a C programmer like you know about that?

I'm a professional, that's all.  Regardless of the language I
use (and I haven't used C in over 20 years), I write code
professionally.  And you can obtain a pretty high level of
abstraction in C (even if a lot of programmers don't).

One of the first levels of abstraction is ignoring the number of
bits in an int.

    [...]
> >  the more efficient the programmer.  Given a good
> > compiler (something rare),

> > Against higher levels of abstraction: it's often
> > more work (defining a class, where just using int will do), and
> > some particular interfaces (including most serialization) are
> > defined in terms of a low level of abstraction.

> Don't argue my point! (I mean if you want to win!).

Who cares about "winning"?  I'm interesting in communicating and
understanding.  And in an honest presentation of the facts.

    [...]
> >>> Sure there is: signed char, short, int and long are all similar
> >>> types, with potentially different widths.  (Don't ask me why
> >>> bool is a signed integral type, rather than an unsigned one.)

> >> Like I *said*: there is no *similar* type.

> > Except all signed integral types.

> Don't mock me. I *said*, there is no similar type.

I know what you said.  And you're wrong.  (If you were honest,
you'd admit it, but that seems to be asking too much.)

> >    [...]
> And here I am "whining" about broken bool! But wait, it's just as bad!
> bool is like throwing a dog a bone, you know he wants the steak, but
> he'll knaw on that bone for...

:-)  I like the image.  In a lot of ways, C++ is just a bone.
The problem is that there isn't any steak, and in most cases,
the other languages I've seen are empty dishes.  Or as I usually
put it: C++ is about the worst language you can imagine.  Except
for all of the others.

> well, till it's gone! (Good think she has
> the umbrella now, cuz that "safety doposite box" is surely just worth of,
> deposits!

> > (I wouldn't be surprised if <windows.h> still has a typedef for
> > BOOL.  Or maybe a macro.)

> "To be honest", I am surprised you don't know that.

Why should I?  I know that at one point in time, they did, but
it doesn't seem relevant today.  I do a lot of Windows
programming, and I've never used it.

--
James Kanze

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

#8162

On 22.07.2011 20:01, James Kanze wrote:
> On Jul 22, 12:29 am, "JBarleycorn"<jbn...@newsnet.org>  wrote:
>
>> 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?
>
> Who does?  In over thirty years of experience in C and C++, I've
> yet to see any application which uses such a header.

Uh, Boost (lots of them). Not to mention C99/C++0x <stdint.h>. <g>


>  I'm
> tempted to say that someone who uses such a header doesn't
> understand the basic philosophy behind C and C++.

*hark*


Cheers & hth.,

- Alf

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

#8039

On Jul 21, 5:28 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> "Ian Collins" <ian-n...@hotmail.com> wrote in message
> news:98pi8pFroiU1@mid.individual.net...
> > On 07/21/11 12:32 PM, JBarleycorn wrote:
> >> "Ian Collins"<ian-n...@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.

The only fixed-width types I know are optional, and aren't
supported by implementations which don't have immediate hardware
support for them.  Their use is fairly limited, and I can't
think of a case where I'd use them in a struct.  (They are
convenient for certain operations, however, when their
restricted portability isn't an issue.)

> bool is unusable in structs in many instances then.

You keep saying this, but it flies in the face of actual facts.
People use bool in structs all the time, with no problems.

> Serialization is not a panacea, it's tedium.

You've mentionned serialization several times, but you've yet to
explain how the fact that the size of bool being implementation
defined affects it in any way.  The internal representation
doesn't generally affect serialization.  And it varies, not just
for bool, but for int.

--
James Kanze

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

#8066

James Kanze wrote:
> On Jul 21, 5:28 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> "Ian Collins" <ian-n...@hotmail.com> wrote in message
>> news:98pi8pFroiU1@mid.individual.net...
>>> On 07/21/11 12:32 PM, JBarleycorn wrote:
>>>> "Ian Collins"<ian-n...@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.
>
> The only fixed-width types I know are optional, and aren't
> supported by implementations which don't have immediate hardware
> support for them.

That's OK. I've been using fixed-width integral types long before there 
were such syntactic sugaring things like those defined in stdint.h.

> Their use is fairly limited, and I can't
> think of a case where I'd use them in a struct.  (They are
> convenient for certain operations, however, when their
> restricted portability isn't an issue.)

You view of the concept seems to be exactly the opposite of mine. Your 
view seems more appropriate, to me, for a 4GL rather than for C/C++.

>
>> bool is unusable in structs in many instances then.
>
> You keep saying this, but it flies in the face of actual facts.

It depends on how you program. When I say that, I mean for the way I 
program and use the language.

> People use bool in structs all the time, with no problems.

If I had to be continually faced with having to think about what the 
effect of integral type size changes would be in C++, I would not use the 
language. Though maybe I wouldn't program at all then!

>
>> Serialization is not a panacea, it's tedium.
>
> You've mentionned serialization several times, but you've yet to
> explain how the fact that the size of bool being implementation
> defined affects it in any way.  The internal representation
> doesn't generally affect serialization.  And it varies, not just
> for bool, but for int.

int and bool are in the same boat in that respect. The *only* time I use 
int, or its unsigned counterpart, is when I consciously *want* a type to 
expand across 32-bit and 64-bit platforms, and yes, I test in a header if 
my assumptions are valid on a given platform. I view fixed-width integral 
types, even if I have to synthesize them as I did before there was 
stdint.h, as the "normal" ones and the "expanding" types as the special 
ones. Try it sometime and you'll probably never go back to the other way 
of thinking. 

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

#8099

On Jul 22, 12:52 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> James Kanze wrote:

    [...]
> > Their use is fairly limited, and I can't
> > think of a case where I'd use them in a struct.  (They are
> > convenient for certain operations, however, when their
> > restricted portability isn't an issue.)

> You view of the concept seems to be exactly the opposite of mine. Your
> view seems more appropriate, to me, for a 4GL rather than for C/C++.

My view is based on Kernighan and Richie.  It was current thirty
years ago, and dominates things like Unix kernel code (which is
hardly written in the spirit of a 4GL).

> >> bool is unusable in structs in many instances then.

> > You keep saying this, but it flies in the face of actual facts.

> It depends on how you program. When I say that, I mean for the way I
> program and use the language.

I'd still be interested in seeing an actual example where the
size of bool makes a difference.  Suppose it was required to be
1: XDR requires it to be four bytes, so if you're serializing in
XDR format, you write:

    void
    writeBool( std::ostream& dest, bool value )
    {
        writeInt( dest, value ? 1 : 0 );
    }

or something along those lines.  Code which, of course, works
equally well if the size of bool is something other than 1.

> > People use bool in structs all the time, with no problems.

> If I had to be continually faced with having to think about what the
> effect of integral type size changes would be in C++, I would not use the
> language. Though maybe I wouldn't program at all then!

Who thinks of it?  Ever.  About the only thing one might
consider is whether the type is large enough: I've seen a lot of
code which uses long, rather than int, because INT_MAX is only
guaranteed to be 32767.  This even in code that will clearly
never run on a 16 bit machine.  *IF* I felt I had to take this
into consideration, I'd use things like int_least32_t or
int_fast32_t.  (But if the code clearly will never be used on a
16 bit machine, I'll just go with int.)

> >> Serialization is not a panacea, it's tedium.

> > You've mentionned serialization several times, but you've yet to
> > explain how the fact that the size of bool being implementation
> > defined affects it in any way.  The internal representation
> > doesn't generally affect serialization.  And it varies, not just
> > for bool, but for int.

> int and bool are in the same boat in that respect. The *only* time I use
> int, or its unsigned counterpart, is when I consciously *want* a type to
> expand across 32-bit and 64-bit platforms, and yes, I test in a header if
> my assumptions are valid on a given platform. I view fixed-width integral
> types, even if I have to synthesize them as I did before there was
> stdint.h, as the "normal" ones and the "expanding" types as the special
> ones. Try it sometime and you'll probably never go back to the other way
> of thinking.

Why?  It sounds like a major step backwards to me, and it
certainly isn't how the language was designed to be used.

--
James Kanze

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

#8115

"James Kanze" <james.kanze@gmail.com> wrote in message 
news:acac70e2-b8df-4f02-ac0a-6fd5d20290ad@b19g2000yqj.googlegroups.com...
> On Jul 22, 12:52 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> James Kanze wrote:
>
>    [...]
>> > Their use is fairly limited, and I can't
>> > think of a case where I'd use them in a struct.  (They are
>> > convenient for certain operations, however, when their
>> > restricted portability isn't an issue.)
>
>> You view of the concept seems to be exactly the opposite of mine. Your
>> view seems more appropriate, to me, for a 4GL rather than for C/C++.
>
> My view is based on Kernighan and Richie.  It was current thirty
> years ago, and dominates things like Unix kernel code (which is
> hardly written in the spirit of a 4GL).
>
>> >> bool is unusable in structs in many instances then.
>
>> > You keep saying this, but it flies in the face of actual facts.
>
>> It depends on how you program. When I say that, I mean for the way I
>> program and use the language.
>
> I'd still be interested in seeing an actual example where the
> size of bool makes a difference.  Suppose it was required to be
> 1: XDR requires it to be four bytes, so if you're serializing in
> XDR format, you write:
>
>    void
>    writeBool( std::ostream& dest, bool value )
>    {
>        writeInt( dest, value ? 1 : 0 );
>    }
>
> or something along those lines.  Code which, of course, works
> equally well if the size of bool is something other than 1.
>
>> > People use bool in structs all the time, with no problems.
>
>> If I had to be continually faced with having to think about what the
>> effect of integral type size changes would be in C++, I would not use 
>> the
>> language. Though maybe I wouldn't program at all then!
>
> Who thinks of it?  Ever.  About the only thing one might
> consider is whether the type is large enough: I've seen a lot of
> code which uses long, rather than int, because INT_MAX is only
> guaranteed to be 32767.  This even in code that will clearly
> never run on a 16 bit machine.  *IF* I felt I had to take this
> into consideration, I'd use things like int_least32_t or
> int_fast32_t.  (But if the code clearly will never be used on a
> 16 bit machine, I'll just go with int.)
>
>> >> Serialization is not a panacea, it's tedium.
>
>> > You've mentionned serialization several times, but you've yet to
>> > explain how the fact that the size of bool being implementation
>> > defined affects it in any way.  The internal representation
>> > doesn't generally affect serialization.  And it varies, not just
>> > for bool, but for int.
>
>> int and bool are in the same boat in that respect. The *only* time I 
>> use
>> int, or its unsigned counterpart, is when I consciously *want* a type 
>> to
>> expand across 32-bit and 64-bit platforms, and yes, I test in a header 
>> if
>> my assumptions are valid on a given platform. I view fixed-width 
>> integral
>> types, even if I have to synthesize them as I did before there was
>> stdint.h, as the "normal" ones and the "expanding" types as the 
>> special
>> ones. Try it sometime and you'll probably never go back to the other 
>> way
>> of thinking.
>
> Why?  It sounds like a major step backwards to me, and it
> certainly isn't how the language was designed to be used.
>

I'm not knocking it. If you and others want to use 30 year old paradigms, 
go for it. Just don't expect me to adopt and be enslaved by such 
limitations. 

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

#8119

On 07/23/11 10:22 AM, JBarleycorn wrote:
>
> I'm not knocking it. If you and others want to use 30 year old paradigms,
> go for it. Just don't expect me to adopt and be enslaved by such
> limitations.

More vacuous noise...

-- 
Ian Collins

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

#8080

On Jul 21, 3:23 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 21, 5:28 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> > "Ian Collins" <ian-n...@hotmail.com> wrote in message
> >news:98pi8pFroiU1@mid.individual.net...
> > > On 07/21/11 12:32 PM, JBarleycorn wrote:
> > >> "Ian Collins"<ian-n...@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.
>
> The only fixed-width types I know are optional, and aren't
> supported by implementations which don't have immediate hardware
> support for them.  Their use is fairly limited, and I can't
> think of a case where I'd use them in a struct.  (They are
> convenient for certain operations, however, when their
> restricted portability isn't an issue.)
>
> > bool is unusable in structs in many instances then.
>
> You keep saying this, but it flies in the face of actual facts.
> People use bool in structs all the time, with no problems.
>
> > Serialization is not a panacea, it's tedium.
>
> You've mentionned serialization several times, but you've yet to
> explain how the fact that the size of bool being implementation
> defined affects it in any way.  The internal representation
> doesn't generally affect serialization.  And it varies, not just
> for bool, but for int.

I'm guessing he wants to write raw structs to disk or to comms links.
Hence he cares about layout. I've spent too much time debugging
programs that did this to be keen on the idea. So I consider
serialization a necessary evil. Since it is rather tedious code its
generation can be mechanised.

I'm still baffeled as to why 'bool' is special but 'int' isn't. I
wonder what he does with floatign point... Oh wait everyone uses IEEE
so portability is trivial!  :-)

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

#8084

On Fri, 22 Jul 2011 00:17:00 -0700 (PDT), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

>On Jul 21, 3:23 pm, James Kanze <james.ka...@gmail.com> wrote:
>> On Jul 21, 5:28 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> > "Ian Collins" <ian-n...@hotmail.com> wrote in message
>> >news:98pi8pFroiU1@mid.individual.net...
>> > > On 07/21/11 12:32 PM, JBarleycorn wrote:
>> > >> "Ian Collins"<ian-n...@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.
>>
>> The only fixed-width types I know are optional, and aren't
>> supported by implementations which don't have immediate hardware
>> support for them.  Their use is fairly limited, and I can't
>> think of a case where I'd use them in a struct.  (They are
>> convenient for certain operations, however, when their
>> restricted portability isn't an issue.)
>>
>> > bool is unusable in structs in many instances then.
>>
>> You keep saying this, but it flies in the face of actual facts.
>> People use bool in structs all the time, with no problems.
>>
>> > Serialization is not a panacea, it's tedium.
>>
>> You've mentionned serialization several times, but you've yet to
>> explain how the fact that the size of bool being implementation
>> defined affects it in any way.  The internal representation
>> doesn't generally affect serialization.  And it varies, not just
>> for bool, but for int.
>
>I'm guessing he wants to write raw structs to disk or to comms links.
>Hence he cares about layout. I've spent too much time debugging
>programs that did this to be keen on the idea. So I consider
>serialization a necessary evil. Since it is rather tedious code its
>generation can be mechanised.
>
>I'm still baffeled as to why 'bool' is special but 'int' isn't. I
>wonder what he does with floatign point... Oh wait everyone uses IEEE
>so portability is trivial!  :-)


And everyone uses little-endian machines too, so that's not an issue
either...

There is certainly a place for binary external formats, but C structs
are obviously (except perhaps to JBarleycorn/MikeP) *not* the correct
tool for trying to represent them.  I've argued that being able to map
external binary formats is a common enough task, especially in a
lower-level language like C (or even C++) where stuff like that often
gets done, that there *should* be facilities to support it.  Not to
mention the general serialization task (at least for that,
boost:serialization works passably well for C++).

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

#8029

On Jul 21, 1:32 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> "Ian Collins" <ian-n...@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?

First, I don't think it's unspecified.  Implementation defined,
on the other hand, is necessary in order for C++ to be
implementable on all platforms.  (Reasonably, at least.)

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

How can ints be used in structs if every implementation can
define them differently.  On a given platform, if there is a C++
API, all reasonable implementations will adhere to it.  If there
isn't, then you can't link code compiled with different
compilers.  Bool or no.

> >>> 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.

But they didn't.  C wasn't interested (at the time).

    [...]
> I meant efficient in time, not space.

The two are related.  Locality is an important issue on today's
machines.

> 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?

It depends on how you use them, but I'd be very surprised if
there were any use cases where 64 bit ints would be faster than
32 bit ints.

> Probably at least 3 things need to be eval'd:
> argument passing performance, return value performance, arithmetic
> performance.

Plus about a dozen other parameters.  In practice, the limiting
factor for performance on today's machine is how many values fit
in a cache line.

--
James Kanze

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

#8067

James Kanze wrote:
> On Jul 21, 1:32 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> "Ian Collins" <ian-n...@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?
>
> First, I don't think it's unspecified.

This "unspecified" designation is something new to me. I don't really 
understand the point of it or how to determine if something is 
"implementation defined" or that.

> Implementation defined,
> on the other hand, is necessary in order for C++ to be
> implementable on all platforms.  (Reasonably, at least.)
>
>> How can bools be used in structs if every implementation can define
>> it differently?
>
> How can ints be used in structs if every implementation can
> define them differently.

There are a few different integral types, that are not boolean, from 
which to synthesize "fixed-width" integral types.

> On a given platform, if there is a C++
> API, all reasonable implementations will adhere to it.  If there
> isn't, then you can't link code compiled with different
> compilers.  Bool or no.

APIs are only half of the story.

>
>>>>> 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.
>
> But they didn't.  C wasn't interested (at the time).

Right, they didn't, but had they, they would have stood at least some 
chance at not implementing a boolean type that is broken.

>
>    [...]
>> I meant efficient in time, not space.
>
> The two are related.  Locality is an important issue on today's
> machines.

No need to be pedantic.

>
>> 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?
>
> It depends on how you use them, but I'd be very surprised if
> there were any use cases where 64 bit ints would be faster than
> 32 bit ints.

I was thinking that the register size and instructions on a 64-bit 
machine would somehow favor 64-bit operations.

>
>> Probably at least 3 things need to be eval'd:
>> argument passing performance, return value performance, arithmetic
>> performance.
>
> Plus about a dozen other parameters.

In usage, those probably cover enough of the territory. From a language 
implementation standpoint, some of those 12 others you have in mind may 
be important. What are the 12 others you have in mind?

>  In practice, the limiting
> factor for performance on today's machine is how many values fit
> in a cache line.

Do you know of any test suites to analyze such? That is, not the cache 
line thing, but the integral type thing, for the latter is the more 
abstract thing. 

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web