Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #7870 > unrolled thread
| Started by | "MikeP" <mp011011@some.org> |
|---|---|
| First post | 2011-07-16 05:33 -0500 |
| Last post | 2011-07-22 12:28 -0700 |
| Articles | 20 on this page of 78 — 12 participants |
Back to article view | Back to comp.lang.c++
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 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | James Kanze <james.kanze@gmail.com> |
|---|---|
| Date | 2011-07-22 11:58 -0700 |
| Message-ID | <ae9d1f57-53cc-4f41-8a1e-ea12ea3d151b@n28g2000vbs.googlegroups.com> |
| In reply to | #8067 |
On Jul 22, 1:11 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> James Kanze wrote:
> > On Jul 21, 1:32 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> >> "Ian Collins" <ian-n...@hotmail.com> wrote in message
[...]
> >>> 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.
How you determine is by reading the standard. The distinction
is formally important: something that is implementation defined
must be fully defined and specified by the implementation, so if
you are writing for a specific implementation, you can count on
it. The size of an int is a good example: it may vary between
different implementations, but for a given implementation, it
will be the same every time you compile your code (at least with
the same options), and (at least in theory), you can find out
exactly what it is in the documentation. Something which is
unspecified needed be documented, and can vary. The classical
example is order of evaluation: if you write something like 'f()
+ g()', and f() and g() have side effects, the order those side
effects occur is unspecified, and might be different from one
compilation to the next (and often will be different if you
change the optimization options).
> > 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.
'bool' is an integral type. In the rare cases where you need
fixed-width types, you can specify int32_t, and assign a bool to
it, with no problem.
> > 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.
So what's the other half?
[...]
> >> 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.
Well, the C++ definition of bool isn't broken. IMHO, the C
definition is, but the C committee obviously doesn't agree with
me on that:-). In both cases, the type has been "weakened" by
considerations of backwards compatibility: implicit conversions
in C++ (so that e.g. 'if (p)', where 'p' is a pointer, still
works---the original proposal would have deprecated this, but
the final version didn't), and in C, the need to include a
special header to "activate" bool, and the fact that it is still
a typedef to another integral type.
> > [...]
> >> 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.
I can't speak for all 64 bit machines, of course, but at least
on an Intel or a Sparc, there should be no speed difference for
an isolated instance.
> >> 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?
The most important one is probably the cost of testing one, i.e.
the execution time for 'if ( aBooleanValue )'. In some
contexts, the cost of handling large arrays (where the number of
instances you can fit in a cache line is important) may be
significant.
Note that on most of the systems I currently use, the effective
size of a bool will vary: although the value is effectively
maintained on a single byte, they will pass a bool into a
function as a 4 or 8 byte value, and in a struct, the effective
size (including padding) will depend on what comes after the
bool in the struct, and may be one, two, four or eight bytes.
> > 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.
No. In practice, it tends to vary, and even depend on the exact
model of the chip being used. Still, in my current work (which
includes a lot of high performance number crunching), we
consistently find that reducing the size of each element in an
array improves performance accross the board, on all of our
different machines. In one particular case, for example,
replacing:
struct Something { bool isValid; double value; };
std::vector<Something> theData;
with:
std::vector<double> theValues;
std::vector<unsigned char> theIsValidFlags; // 8 flags per entry
resulted in a significant speed-up, despite the additional
effort needed to extract the flag. (Note that I'm not
recommending this in general. It just happened to improve
performance in one particular critical case in our code.)
--
James Kanze
[toc] | [prev] | [next] | [standalone]
| From | "JBarleycorn" <jbnh2o@newsnet.org> |
|---|---|
| Date | 2011-07-22 17:48 -0500 |
| Message-ID | <j0cuoh$jlj$1@dont-email.me> |
| In reply to | #8101 |
"James Kanze" <james.kanze@gmail.com> wrote in message
news:ae9d1f57-53cc-4f41-8a1e-ea12ea3d151b@n28g2000vbs.googlegroups.com...
> On Jul 22, 1:11 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> James Kanze wrote:
>> > On Jul 21, 1:32 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
>> >> "Ian Collins" <ian-n...@hotmail.com> wrote in message
>
> [...]
>> >>> 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.
>
> How you determine is by reading the standard.
Ha! It's not easy to find what you're looking for in there. That's more
(only?) for implementers than users.
> The distinction
> is formally important: something that is implementation defined
> must be fully defined and specified by the implementation, so if
> you are writing for a specific implementation, you can count on
> it. The size of an int is a good example: it may vary between
> different implementations, but for a given implementation, it
> will be the same every time you compile your code (at least with
> the same options), and (at least in theory), you can find out
> exactly what it is in the documentation. Something which is
> unspecified needed be documented, and can vary. The classical
> example is order of evaluation: if you write something like 'f()
> + g()', and f() and g() have side effects, the order those side
> effects occur is unspecified, and might be different from one
> compilation to the next (and often will be different if you
> change the optimization options).
>
>> > 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.
>
> 'bool' is an integral type. In the rare cases where you need
> fixed-width types, you can specify int32_t, and assign a bool to
> it, with no problem.
You're not listening.
>
>> > 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.
>
> So what's the other half?
Data. (It's obvious now that I said it, huh).
>
> [...]
>> >> 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.
>
> Well, the C++ definition of bool isn't broken.
That's not just an opinion, it's a C++er's opinion. The qualification
*is* needed. You know, "consider the source".
> IMHO,
In your C++er's opinion...
> the C
> definition is, but the C committee obviously doesn't agree with
> me on that:-). In both cases, the type has been "weakened"
"weakened", LOL. Lame try at trying to alleviate the issue: that C++ bool
is *broken* beyond repair. Replacement, where possible, is the only
option.
> by
> considerations of backwards compatibility: implicit conversions
> in C++ (so that e.g. 'if (p)', where 'p' is a pointer, still
> works---the original proposal would have deprecated this, but
> the final version didn't), and in C, the need to include a
> special header to "activate" bool, and the fact that it is still
> a typedef to another integral type.
>
>> > [...]
>> >> 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.
>
> I can't speak for all 64 bit machines, of course, but at least
> on an Intel or a Sparc, there should be no speed difference for
> an isolated instance.
I suspect that the case between 16-bit and 32-bit types on a 32-bit
platform will behave similarly, so I can profile that and "extrapolate".
>
>> >> 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?
>
> The most important one is probably the cost of testing one, i.e.
> the execution time for 'if ( aBooleanValue )'. In some
> contexts, the cost of handling large arrays (where the number of
> instances you can fit in a cache line is important) may be
> significant.
And the other 10?
>
> Note that on most of the systems I currently use, the effective
> size of a bool will vary: although the value is effectively
> maintained on a single byte, they will pass a bool into a
> function as a 4 or 8 byte value, and in a struct, the effective
> size (including padding) will depend on what comes after the
> bool in the struct, and may be one, two, four or eight bytes.
>
>> > 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.
>
> No. In practice, it tends to vary, and even depend on the exact
> model of the chip being used. Still, in my current work (which
> includes a lot of high performance number crunching), we
> consistently find that reducing the size of each element in an
> array improves performance accross the board, on all of our
> different machines.
That's not testing the things I mentioned and was immediately concerned
with though. I was looking for insight about the performance of the
common mechanisms (passing back and forth and arith ops, mostly the
former though).
> In one particular case, for example,
> replacing:
>
> struct Something { bool isValid; double value; };
> std::vector<Something> theData;
>
> with:
>
> std::vector<double> theValues;
> std::vector<unsigned char> theIsValidFlags; // 8 flags per entry
>
> resulted in a significant speed-up, despite the additional
> effort needed to extract the flag. (Note that I'm not
> recommending this in general. It just happened to improve
> performance in one particular critical case in our code.)
>
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-07-21 08:41 -0700 |
| Message-ID | <aec569b6-fa89-4f80-a476-9654a6396454@g16g2000yqg.googlegroups.com> |
| In reply to | #8016 |
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? <snip> > Why is "unspecified" necessary? Does anyone think that not specifying the > size of a bool is a good thing? me! Didn't a previous poster give you good reasons? > How can bools be used in structs if every implementation can define it > differently? in what way does bool differ from the other C++ (and C) types. All of them have implementation defined sizes! > >>> 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. anyone using structs for data transfer is in a state of sin. <snip>
[toc] | [prev] | [next] | [standalone]
| From | "JBarleycorn" <jbnh2o@newsnet.org> |
|---|---|
| Date | 2011-07-21 19:14 -0500 |
| Message-ID | <j0afcb$ur3$1@dont-email.me> |
| In reply to | #8044 |
Nick Keighley 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? > > <snip> > >> Why is "unspecified" necessary? Does anyone think that not >> specifying the size of a bool is a good thing? > > me! Didn't a previous poster give you good reasons? Apparently not. > > >> How can bools be used in structs if every implementation can define >> it differently? > > in what way does bool differ from the other C++ (and C) types. All of > them have implementation defined sizes! See my response to JKazne for it should answer your question. > > >>>>> 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. > > anyone using structs for data transfer is in a state of sin. > Try it sometime. Your paradigm may be holding back your potential.
[toc] | [prev] | [next] | [standalone]
| From | James Kanze <james.kanze@gmail.com> |
|---|---|
| Date | 2011-07-22 12:01 -0700 |
| Message-ID | <4d23df3d-dd09-48d0-8daf-bf33ff3dcb53@o4g2000vbv.googlegroups.com> |
| In reply to | #8068 |
On Jul 22, 1:14 am, "JBarleycorn" <jbn...@newsnet.org> wrote: > Nick Keighley wrote: > >>>>> And I don't see the issue with regards to structs. > >>>> C compatibility where layout, then, matters? Data transfer/storage. > > anyone using structs for data transfer is in a state of sin. > Try it sometime. Your paradigm may be holding back your potential. I suspect the reason Nick argues against it is that he has tried it. I can remember when Microsoft changed the layout of a long between versions of a compiler. Update the compiler, and none of your data was readable. Unless, of course, you'd written the serialization code correctly. And of course, a lot of companies today are migrating from Solaris Sparc or IBM AIX to Linux on a PC. -- James Kanze
[toc] | [prev] | [next] | [standalone]
| From | "JBarleycorn" <jbnh2o@newsnet.org> |
|---|---|
| Date | 2011-07-22 17:51 -0500 |
| Message-ID | <j0cusv$kfg$1@dont-email.me> |
| In reply to | #8100 |
"James Kanze" <james.kanze@gmail.com> wrote in message news:4d23df3d-dd09-48d0-8daf-bf33ff3dcb53@o4g2000vbv.googlegroups.com... > On Jul 22, 1:14 am, "JBarleycorn" <jbn...@newsnet.org> wrote: >> Nick Keighley wrote: >> >>>>> And I don't see the issue with regards to structs. >> >>>> C compatibility where layout, then, matters? Data >> >>>> transfer/storage. > >> > anyone using structs for data transfer is in a state of sin. > >> Try it sometime. Your paradigm may be holding back your potential. > > I suspect the reason Nick argues against it is that he has tried > it. I can remember when Microsoft changed the layout of a long > between versions of a compiler. Update the compiler, and none > of your data was readable. Unless, of course, you'd written the > serialization code correctly. And of course, a lot of companies > today are migrating from Solaris Sparc or IBM AIX to Linux on a > PC. > Is the practice bad or the practicianer? (rhetorical). The dangers of making assumptions and then not controlling/testing them.
[toc] | [prev] | [next] | [standalone]
| From | Noah Roberts <dont@email.me> |
|---|---|
| Date | 2011-07-20 16:57 -0700 |
| Message-ID | <4e27688b$0$11117$cc2e38e6@news.uslec.net> |
| In reply to | #8010 |
On 7/20/2011 1:46 PM, 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? Implementation defined has to be documented, unspecified does not. Both are behaviors defined by the implementation.
[toc] | [prev] | [next] | [standalone]
| From | James Kanze <james.kanze@gmail.com> |
|---|---|
| Date | 2011-07-21 07:29 -0700 |
| Message-ID | <f7daf01d-a5c2-41f9-b7da-b3a0c06ac09f@gc8g2000vbb.googlegroups.com> |
| In reply to | #8014 |
On Jul 21, 12:57 am, Noah Roberts <d...@email.me> wrote: > On 7/20/2011 1:46 PM, 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? > Implementation defined has to be documented, unspecified does > not. Both are behaviors defined by the implementation. Unspecified means not undefined in the sense of the standard, but not only does it not have to be documented, it may vary. At least in principle, if bool is unspecified, it could be 32 bits one time you ran the program, 8 another time. Or 32 bits in one part of the program, and 8 elsewhere. (I can't imagine how this could be the case practically. But then, I think the size of bool is implementation defined, and not unspecified. Unspecified is generally reserved for things where different optimizations could result in different behavior, e.g. whether the results of a floating point operation are in extended precision, or strictly double.) -- James Kanze
[toc] | [prev] | [next] | [standalone]
| From | "JBarleycorn" <jbnh2o@newsnet.org> |
|---|---|
| Date | 2011-07-21 19:24 -0500 |
| Message-ID | <j0ag0k$29g$1@dont-email.me> |
| In reply to | #8040 |
James Kanze wrote: > On Jul 21, 12:57 am, Noah Roberts <d...@email.me> wrote: >> On 7/20/2011 1:46 PM, 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? > >> Implementation defined has to be documented, unspecified does >> not. Both are behaviors defined by the implementation. > > Unspecified means not undefined in the sense of the standard, > but not only does it not have to be documented, it may vary. At > least in principle, if bool is unspecified, it could be 32 bits > one time you ran the program, 8 another time. Or 32 bits in one > part of the program, and 8 elsewhere. (I can't imagine how this > could be the case practically. But then, I think the size of > bool is implementation defined, and not unspecified. > Unspecified is generally reserved for things where different > optimizations could result in different behavior, e.g. whether > the results of a floating point operation are in extended > precision, or strictly double.) Can anyone here say definitively whether bool is this "unspecified" thing or ""implemetation defined" or... ? (!)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-07-22 12:33 +1200 |
| Message-ID | <98rurjFroiU9@mid.individual.net> |
| In reply to | #8070 |
On 07/22/11 12:24 PM, JBarleycorn wrote: > > Can anyone here say definitively whether bool is this "unspecified" thing > or ""implemetation defined" or... ? (!) From 5.3.3 1 "[Note: in particular, sizeof(bool) and sizeof(wchar_t) are implementation-defined]" -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "JBarleycorn" <jbnh2o@newsnet.org> |
|---|---|
| Date | 2011-07-21 22:42 -0500 |
| Message-ID | <j0arie$rdk$1@dont-email.me> |
| In reply to | #8071 |
Ian Collins wrote: > On 07/22/11 12:24 PM, JBarleycorn wrote: >> >> Can anyone here say definitively whether bool is this "unspecified" >> thing or ""implemetation defined" or... ? (!) > > From > > 5.3.3 1 > > "[Note: in particular, sizeof(bool) and sizeof(wchar_t) are > implementation-defined]" Thx. That's still not good enough though to make bool unbroken, though. It *is* what makes bool broken.
[toc] | [prev] | [next] | [standalone]
| From | James Kanze <james.kanze@gmail.com> |
|---|---|
| Date | 2011-07-21 01:59 -0700 |
| Message-ID | <ca187bb0-9ac3-460c-b68c-b9167bc1edb4@g12g2000yqd.googlegroups.com> |
| In reply to | #8010 |
On Jul 20, 9:46 pm, "JBarleycorn" <jbn...@newsnet.org> 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? No. Unspecified means that you cannot know or depend on the size; it might change from one compilation to the next. Implementation defined means that each implementation must define it, and document how it is defined. > > 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. C didn't have bool, so there can't be an issue of C compatibility. As for data transfer and storage, you treat it like any other type: you define the external format, and implement the conversion. In practice, it's probably simpler to handle than most other types, since it's relatively trivial to handle all possible values separately. > >> 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? That's why I said: on a byte addressable machine. > > 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. That's one of the arguments for making it the same size as a word. On a machine which isn't byte addressable. (Such machines are fairly rare today.) > >> 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. If the representation is a single byte, and the both the caller and the callee agree, there's no need for extension. Extension is only necessary if you have a smaller size, and need to pass a larger one. Depending on the architecture, it may be necessary, or more efficient, to pass par a register, rather than to push directly onto the stack, if the bool is in an array (and thus misaligned). > >> 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. Have you actually verified that? I would expect almost every compiler to do so when it is advantageous. > > 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. Even common practice depends on the platform. Common practice on an Intel will be different than common practice on a Sparc. For that matter, common practice under Windows is different than common practice under Linux, even when both run on a 32 bit Intel. -- James Kanze
[toc] | [prev] | [next] | [standalone]
| From | "JBarleycorn" <jbnh2o@newsnet.org> |
|---|---|
| Date | 2011-07-21 19:42 -0500 |
| Message-ID | <j0ah1j$7fk$1@dont-email.me> |
| In reply to | #8028 |
James Kanze wrote: > On Jul 20, 9:46 pm, "JBarleycorn" <jbn...@newsnet.org> 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? > > No. Unspecified means that you cannot know or depend on the > size; it might change from one compilation to the next. So is the list of unspecified things in the standard very long? I'd like to know what those things are. I surely hope bool is not unspecified, but even if it is, I don't care, because I don't use it directly. I know that bool is broken, I just don't know how broken it is. > Implementation defined means that each implementation must > define it, and document how it is defined. > >>> 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. > > C didn't have bool, so there can't be an issue of C > compatibility. Indeed. > As for data transfer and storage, you treat it > like any other type: you define the external format, and > implement the conversion. Unnecessary tedium. Use bool though, and it becomes necessary tedium. > In practice, it's probably simpler to > handle than most other types, since it's relatively trivial to > handle all possible values separately. > >>>> 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. > > If the representation is a single byte, and the both the caller > and the callee agree, there's no need for extension. > Extension > is only necessary if you have a smaller size, and need to pass a > larger one. > I have a feeling that "most" compilers by default expand all arguments less than the "word" size to the "word" size. Surely for simplicity of implementation... stack offsets, etc. > Depending on the architecture, it may be necessary, or more > efficient, to pass par a register, rather than to push directly > onto the stack, if the bool is in an array (and thus > misaligned). > >>>> 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. > > Have you actually verified that? I said "probably", as I wouldn't expect that, and I don't know why, but I must have had something in mind when I wrote that. Certainly easy enough to check: just look for the extending instructions instead of the non-extending instructions. "movzx" vs. "mov" on x86, for example. > I would expect almost every > compiler to do so when it is advantageous. > >>> 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. > > Even common practice depends on the platform. Not always, and not necessarily usually (it depends on the area of interest) and surely I was asking about cross-platform commonality *if* there was any. > Common practice > on an Intel will be different than common practice on a Sparc. > For that matter, common practice under Windows is different than > common practice under Linux, even when both run on a 32 bit > Intel.
[toc] | [prev] | [next] | [standalone]
| From | James Kanze <james.kanze@gmail.com> |
|---|---|
| Date | 2011-07-22 12:20 -0700 |
| Message-ID | <06bd239a-85d2-4b0c-bd8a-f435ef8cb3a6@ft10g2000vbb.googlegroups.com> |
| In reply to | #8072 |
On Jul 22, 1:42 am, "JBarleycorn" <jbn...@newsnet.org> wrote:
> James Kanze wrote:
> > On Jul 20, 9:46 pm, "JBarleycorn" <jbn...@newsnet.org> wrote:
> >> James Kanze wrote:
> >>> On Jul 16, 6:02 pm, BGB <cr88...@hotmail.com> wrote:
> >>>> On 7/16/2011 3:33 AM, MikeP wrote:
[...]
> > No. Unspecified means that you cannot know or depend on the
> > size; it might change from one compilation to the next.
> So is the list of unspecified things in the standard very long?
Definitely more than I'd like. The two which seem to cause the
most problems in the code I've seen is order of evalutation:
something like:
std::cout << f() << ' ' << g() << std::endl;
, for example, where both f() and g() use and modify the same
global variable, and whether intermediate values in a floating
point expression are in extended precision or not: the trickiest
case I saw of that was where someone had defined:
bool operator<( MyClass const& lhs, MyClass const& rhs )
{
return lhs.doubleCalule() < rhs.doubleCalule();
}
and used it as an ordering operator for 'sort'. (The compiler
he was using returned the floating point value in a register
with extended precision, but truncated to double when it spilled
to memory. Which resulted in the function returning true when
lhs and rhs designated the same object.)
[...]
> > As for data transfer and storage, you treat it
> > like any other type: you define the external format, and
> > implement the conversion.
> Unnecessary tedium. Use bool though, and it becomes necessary tedium.
Only unnecessary if you don't need to read the data later (in
which case, writing it out in any format is unnecessary tedium).
Of course, normally, all serialization code will be generated by
other programs anyway. The only thing that is hand written is
the low level code to handle the basic types.
> > If the representation is a single byte, and the both the caller
> > and the callee agree, there's no need for extension.
> > Extension
> > is only necessary if you have a smaller size, and need to pass a
> > larger one.
> I have a feeling that "most" compilers by default expand all arguments
> less than the "word" size to the "word" size. Surely for simplicity of
> implementation... stack offsets, etc.
Most compilers do insert padding, since not doing so will either
slow the code down significantly (Intel) or cause the program to
crash (most other processors) because of misaligned data.
Inserting padding is not expanding an argument to word size;
when a compiler inserts padding, the bytes in the padding have
unspecified (and often random) values. If I have something
like:
void f( char ch );
char aChar;
f( aChar );
I expect a compiler on an Intel to generate either:
push aChar
(if `aChar` is correctly aligned), or
mov al, aChar
push eax
to pass the argument. Four bytes end up on the stack, but only
one is significant, and read by the called code. (On a Sparc,
of course, arguments are passed in registers, and there are no
byte registers, so you end up with something like:
ldsb aChar, %o0
---load signed byte to register o0.)
--
James Kanze
[toc] | [prev] | [next] | [standalone]
| From | "JBarleycorn" <jbnh2o@newsnet.org> |
|---|---|
| Date | 2011-07-22 18:21 -0500 |
| Message-ID | <j0d0ld$45b$1@dont-email.me> |
| In reply to | #8102 |
"James Kanze" <james.kanze@gmail.com> wrote in message news:06bd239a-85d2-4b0c-bd8a-f435ef8cb3a6@ft10g2000vbb.googlegroups.com... > On Jul 22, 1:42 am, "JBarleycorn" <jbn...@newsnet.org> wrote: >> I have a feeling that "most" compilers by default expand all arguments >> less than the "word" size to the "word" size. Surely for simplicity >> of >> implementation... stack offsets, etc. > > Most compilers do insert padding, VC++ 2010 zero-extends unsigned ints of 8-bit before pushing them onto the stack as an arg. I just tested it because the documentation just says it "widens" and I had taken that, for some reason, to mean "by zero or sign extension" and wanted to know now if that was indeed the case, and it is so. Here's the doc: http://msdn.microsoft.com/en-us/library/984x0h58.aspx > since not doing so will either > slow the code down significantly (Intel) or cause the program to > crash (most other processors) because of misaligned data. > Inserting padding is not expanding an argument to word size; > when a compiler inserts padding, the bytes in the padding have > unspecified (and often random) values. If I have something > like: > > void f( char ch ); > > char aChar; > f( aChar ); > > I expect a compiler on an Intel to generate either: > > push aChar > > (if `aChar` is correctly aligned), or > > mov al, aChar > push eax > > to pass the argument. No, it (VC++) does zero or sign extension before pushing the arg on the stack. Here is the relevant portion of the result of my test code: ; 26 : pass8arg = Pass8(pass8arg); movzx ecx, BYTE PTR _pass8arg$[ebp] push ecx call ?Pass8@@YGEE@Z ; Pass8 mov BYTE PTR _pass8arg$[ebp], al
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-07-16 22:23 -0500 |
| Message-ID | <k8l42713pf7pjfu8ocutt3o08u2dniih12@4ax.com> |
| In reply to | #7870 |
On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <mp011011@some.org> 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?) How does the unspecified size of bool make them useless in structs? The size of ints is also unspecified*, and I use ints in structures all the time. *except being at least 16 bits - although clearly a minimum exists for bools as well.
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-17 00:07 -0500 |
| Message-ID | <ivtqlu$ji6$1@dont-email.me> |
| In reply to | #7900 |
Robert Wessel wrote:
> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <mp011011@some.org> 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?)
>
>
> How does the unspecified size of bool make them useless in structs?
How doesn't it?
> The size of ints is also unspecified*, and I use ints in structures
> all the time.
Well, there are structs, and then there are structs.
>
> *except being at least 16 bits - although clearly a minimum exists for
> bools as well.
On VC++ 2010 it is one byte. In some version long ago, it was the size of
int, but probably because that was before the standard declared it could
be unspecified. Let's play a game ("Would you like to play a game? How
about a nice game of chess?" ;) ). If you could have your bool and eat it
too... let me rephrase that: if you could create your own boolean type,
describe it. Describe 2 if you want to: one for C++, and one for your
ideal language that does not yet exist.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-07-17 17:15 +1200 |
| Message-ID | <98f9hoFi81U5@mid.individual.net> |
| In reply to | #7905 |
On 07/17/11 05:07 PM, MikeP wrote: > Robert Wessel wrote: >> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP"<mp011011@some.org> 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?) >> >> >> How does the unspecified size of bool make them useless in structs? > > How doesn't it? It's never bothered me. Why would the size be important? If size and alignment is important to an environment, the sizes will be specified. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-17 00:24 -0500 |
| Message-ID | <ivtrmj$nqd$1@dont-email.me> |
| In reply to | #7906 |
Ian Collins wrote: > On 07/17/11 05:07 PM, MikeP wrote: >> Robert Wessel wrote: >>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP"<mp011011@some.org> 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?) >>> >>> >>> How does the unspecified size of bool make them useless in structs? >> >> How doesn't it? > > It's never bothered me. Why would the size be important? If size and > alignment is important to an environment, the sizes will be specified. I'll return to your post after RW replies.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-07-17 02:02 -0500 |
| Message-ID | <p11527h614drljjk2sda2r8bnlrkqivtoh@4ax.com> |
| In reply to | #7905 |
On Sun, 17 Jul 2011 00:07:19 -0500, "MikeP" <mp011011@some.org> wrote:
>Robert Wessel wrote:
>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <mp011011@some.org> 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?)
>>
>>
>> How does the unspecified size of bool make them useless in structs?
>
>How doesn't it?
>
>> The size of ints is also unspecified*, and I use ints in structures
>> all the time.
I give up - how does it? I've used bools in structs. Seemed to work
just fine. I've used bit fields in structs too, and they're also
undefined as to what they're actually stored in. That also seemed to
work.
Both of those, the size of bools, and the storage of bit fields, are
defined for a particular implementation.
>Well, there are structs, and then there are structs.
True, but less than informative. I personally find structs containing
long doubles to be particular impressive - now *those* are *structs*!
>>
>> *except being at least 16 bits - although clearly a minimum exists for
>> bools as well.
>
>On VC++ 2010 it is one byte. In some version long ago, it was the size of
>int, but probably because that was before the standard declared it could
>be unspecified. Let's play a game ("Would you like to play a game? How
>about a nice game of chess?" ;) ). If you could have your bool and eat it
>too... let me rephrase that: if you could create your own boolean type,
>describe it. Describe 2 if you want to: one for C++, and one for your
>ideal language that does not yet exist.
Are you talking about interfacing code compiled with different
versions of the compiler? As a general rule, you shouldn't be mixing
code from different versions of a C compiler (or equivalently,
invocations of the C compiler with certain different options), unless
you restrict yourself to things specified by the system ABI or some
other ABI that's specified to be valid between the versions in
question. There are plenty of potential (and allowed)
incompatibilities in that scenario. Everything from padding to
alignment, to the storage of bit fields, to the size of ints, to the
signedness of chars, to calling convention, to name decoration, to the
format of vtables, to...
Errr... and my "ideal" boolean stores one of two values, and I care
little about its internal representation. I'd probably pick something
the size of an int (or whatever my languages equivalent for that is)
if I cared about speed, a byte or a bit if I cared more about space.
And I really don't mind if you reply to Ian before I reply to you.
Really I don't.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c++
csiph-web