First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.
OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.
Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong, and I think that most of you agree. Plus, it's
still too large.
"int some_bool = 0;" is what I -- and everyone else, I assume -- use
for bools. But an int is a very large data type for something that will
only ever be true or false (1 or 0). This really, really bugs me.
Why, back when C was designed, didn't they see a reason to build in a
boolean type into the language? Now it matters less, I guess, but back
then, there should have been very strong technical reasons. It just
doesn't make any sense whatsoever to me.
I have asked many people about this for quite some time, and they are
all just telling me that I'm silly for bringing it up. Why? It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.
So... can somebody properly explain this to me once and for all? I'm
sure there MUST be a logical explanation that nobody seems to really
understand. The madness must end.
bool some_bool = 0; /* How great it would be... */
51  2851 
"AommiK" <no****@nospam.comwrote in message
Why, back when C was designed, didn't they see a reason to build in a
boolean type into the language? Now it matters less, I guess, but back
then, there should have been very strong technical reasons. It just
doesn't make any sense whatsoever to me.
C is portable assembly. Generally there is no way of manipulating single
bits with assembly instructions, though of course you can do so with a
combination of instructions.
So bool wasn't included.
We've moved on a little since, and there is quite a good case for it, since
it doucments that a variable is flag, and that is frequently what we want.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
AommiK wrote:
First of all: I love C and think that it's beautiful. However, there
is at least one MAJOR flaw: the lack of a boolean type.
At best this is a minor irritation, not a major flaw IMHO.
OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.
It was not a badly felt need during much of C's evolution and still is
not.
Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong, and I think that most of you agree. Plus, it's
still too large.
Use bitfields.
"int some_bool = 0;" is what I -- and everyone else, I assume -- use
for bools. But an int is a very large data type for something that
will only ever be true or false (1 or 0). This really, really bugs me.
Why, back when C was designed, didn't they see a reason to build in a
boolean type into the language? Now it matters less, I guess, but back
then, there should have been very strong technical reasons. It just
doesn't make any sense whatsoever to me.
Because bool is too often an overrated type. In anycase with most
machines bool is simulated by either a byte of a packed type.
If you're bothered about space why not use bitfields?
I have asked many people about this for quite some time, and they are
all just telling me that I'm silly for bringing it up. Why? It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.
This can be done. It wasn't important enough to be Standardised.
bool some_bool = 0; /* How great it would be... */
You can do this since C99.
On Nov 3, 10:56 pm, AommiK <nos...@nospam.comwrote:
First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.
Why is that a MAJOR flaw? I have trouble seeing it as even a minor
flaw.
OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.
Why?
Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong,
Why?
and I think that most of you agree.
I doubt that very much.
Plus, it's still too large.
It's typically the smallest addressable type. If you want smaller
(with the added overhead of more code to implement it) use a bit
field.
"int some_bool = 0;" is what I -- and everyone else, I assume -- use
for bools.
Why do you assume that?
But an int is a very large data type for something that will
only ever be true or false (1 or 0). This really, really bugs me.
Why, back when C was designed, didn't they see a reason to build in a
boolean type into the language?
That's a very silly question. They didn't see a need for it because
they didn't see a need for it. You need to explain why you think they
should have seen a need for it.
Now it matters less, I guess, but back
then, there should have been very strong technical reasons. It just
doesn't make any sense whatsoever to me.
A value of zero is false, non-zero is true. Why do you need a
particular type to hold the value?
I have asked many people about this for quite some time, and they are
all just telling me that I'm silly for bringing it up. Why?
You're not necessarily silly for bringing it up, but you're doing it
in a silly way. You need to explain why you think it was needed, and
why anyone should have seen a need for it. You seem to assume that
everyone shares your view of C and its history and agrees with you for
some reason.
It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.
How would it save resources? A boolean type smaller than char would
require more resources to implement and at run time. How would it make
coding any prettier?
So... can somebody properly explain this to me once and for all? I'm
sure there MUST be a logical explanation that nobody seems to really
understand. The madness must end.
I've no idea what you're talking about.
bool some_bool = 0; /* How great it would be... */
It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?
AommiK <no****@nospam.comwrites:
First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.
OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.
Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong, and I think that most of you agree. Plus, it's
still too large.
"int some_bool = 0;" is what I -- and everyone else, I assume -- use
for bools. But an int is a very large data type for something that will
only ever be true or false (1 or 0). This really, really bugs me.
[...]
On typical systems, allocating 8 or more bits to an object intended
only to hold the values 0 and actually saves space. Accessing a
single bit, without disturbing the rest of the byte or word that it's
a part of, is more expensive than accessing the entire byte or word.
Most CPUs can't directly address single bits.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
AommiK wrote:
First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.
It's probably this "MAJOR" flaw that has kept C on the
sidelines and prevented it from gaining any noticeable following.
OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.
Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong, and I think that most of you agree. Plus, it's
still too large.
"int some_bool = 0;" is what I -- and everyone else, I assume -- use
for bools. But an int is a very large data type for something that will
only ever be true or false (1 or 0). This really, really bugs me.
If you'll spend several dozens of hours and many thousands
of dollars to lie on a couch and chat with a professional about
your dreams and your early childhood memories, your obsession
may turn out to be curable.
Why, back when C was designed, didn't they see a reason to build in a
boolean type into the language? Now it matters less, I guess, but back
then, there should have been very strong technical reasons. It just
doesn't make any sense whatsoever to me.
I sympathize. For me, the thing that makes no sense whatsoever
is quantum entanglement. However, the fact that it makes no sense
to me doesn't impel me to the belief that QE is a "MAJOR" flaw in
Nature. You seem to attach more importance to your own befuddlement
than I do to mine.
I have asked many people about this for quite some time, and they are
all just telling me that I'm silly for bringing it up. Why? It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.
Kidding aside, there's the crux: You declare that you do not
need a Boolean type "to get anything done."
Say your words over again, slowly: You claim you
DO
NOT
NEED
a Boolean type. Why, then, is C deficient in a "MAJOR" way for
lacking what you DO. NOT. NEED? C also lacks quaternions, nested
functions, three-way ifs, and the kitchen sink -- "MAJOR" omissions
all, I guess you'd say, whether you would use them or not.
So... can somebody properly explain this to me once and for all? I'm
sure there MUST be a logical explanation that nobody seems to really
understand. The madness must end.
The "madness," if you choose to think of it that way, ended
eight years ago. Haven't you grown weary of tearing your hair
and rending your clothing? Aren't the sackcloth and ashes
getting a little tiresome? Your stamina is admirable, but ...
bool some_bool = 0; /* How great it would be... */
Go ahead. No one is stopping you, except possibly your peers
in code review who will (1) object to your idiosyncratic way of
spelling `false' and (2) ask what the purpose of `some_bool' is.
In my experience, programs in all programming languages use Boolean
*values* all the time, but the use of Boolean *variables* is far
rarer.
--
Eric Sosman es*****@ieee-dot-org.invalid
AommiK wrote:
First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.
OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.
Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong, and I think that most of you agree. Plus, it's
still too large.
Do you have an example of a language with a boolean type which will
store the boolean in a location smaller than a byte?
(C optimizers are allowed to reduce the size used by bool types; but I
would guess that the performance hit by requiring all those extra
bit-twiddling operations would generally be considered to much.)
I agree that it's useful to have a bool type for code readability
purposes; but you have always been able to typedef one. However I'm just
not convinced that a bool should be stored by default in a single bit,
within a byte shared with other bool values.
--
Philip Potter pgp <atdoc.ic.ac.uk
On Sun, 04 Nov 2007 09:53:31 +0000, Philip Potter wrote:
(C optimizers are allowed to reduce the size used by bool types; but I
would guess that the performance hit by requiring all those extra
bit-twiddling operations would generally be considered to much.)
They can't. See 6.2.6.1p2.
Also, I must be allowed to access them as arrays of unsigned char,
if several _Bool are stored in the same byte
memset(&bool_var, 0, sizeof bool_var) could affect other ones,
which 6.2.4p2 forbids. Also, if the bytes of an object are
themselves objects, if I do *(unsigned char *)&bool_var = '/';
that byte will stay the same until I access bool_var again (it
could change even if I just *read* it, because '/' could be a
trap representation for _Bool causing UB, but if I don't access it
at all, it can't change).
As I see it, _Bool is required to have at least seven padding
bits. (Anyway, I think that if a _Bool is declared as register, or
if the compiler pretends that it is because its address is never
taken, it might not actually store them anywhere.)
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.
On Sat, 03 Nov 2007 19:05:56 -0700, J. J. Farrell wrote:
It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?
The fact that the implementation can choose which one it is.
(So can it with enum { false, true }, but the latter in some
implementations turns out to be much larger.)
Also, (char)0.1 and (int)I are zero, whereas (_Bool)0.1 and
(_Bool)I are one.
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.
On Sat, 03 Nov 2007 19:05:56 -0700, J. J. Farrell wrote:
It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?
The fact that the implementation can choose which one it is.
(So can it with enum { false, true }, but the latter in some
implementations turns out to be much larger.)
Also, (char)0.1 and (int)I are zero, whereas (_Bool)0.1 and
(_Bool)I are one. (But one could simply write
char foo = (bar != 0); so that doesn't buy much...)
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.
On Sun, 04 Nov 2007 12:09:26 +0100, Army1987 wrote:
On Sun, 04 Nov 2007 09:53:31 +0000, Philip Potter wrote:
>(C optimizers are allowed to reduce the size used by bool types; but I
would guess that the performance hit by requiring all those extra
bit-twiddling operations would generally be considered to much.)
They can't.
They can for those booleans that never have their address taken.
"J. J. Farrell" <jj*@bcs.org.ukwrites:
On Nov 3, 10:56 pm, AommiK <nos...@nospam.comwrote:
>First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.
Why is that a MAJOR flaw? I have trouble seeing it as even a minor
flaw.
I see it as a flaw. A minor one. But a flaw nonetheless.
>
>OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.
Why?
Because C is a programming language that applies all sorts of rules on
other types and a C program uses boolean decision making every other
line or so ....
>
>Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong,
Why?
Because it's not a true "boolean". When you see a char its not obvious
fro the type that it's a binary indicator. Fairly obvious I would have
thought.
>
>and I think that most of you agree.
I doubt that very much.
Lets turn it around. Why would you think having a real boolean is NOT a
good idea?
$)CHarald van D)&k wrote:
On Sun, 04 Nov 2007 12:09:26 +0100, Army1987 wrote:
>On Sun, 04 Nov 2007 09:53:31 +0000, Philip Potter wrote:
>>(C optimizers are allowed to reduce the size used by bool types; but I
would guess that the performance hit by requiring all those extra
bit-twiddling operations would generally be considered to much.)
They can't.
They can for those booleans that never have their address taken.
Yes, I was relying on this and the as-if rule.
--
Philip Potter pgp <atdoc.ic.ac.uk
On Nov 4, 4:09 pm, Richard <rgr...@gmail.comwrote:
"J. J. Farrell" <j...@bcs.org.ukwrites:
On Nov 3, 10:56 pm, AommiK <nos...@nospam.comwrote:
First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.
Why is that a MAJOR flaw? I have trouble seeing it as even a minor
flaw.
I see it as a flaw. A minor one. But a flaw nonetheless.
OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.
Why?
Because C is a programming language that applies all sorts of rules on
other types and a C program uses boolean decision making every other
line or so ....
Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong,
Why?
Because it's not a true "boolean". When you see a char its not obvious
fro the type that it's a binary indicator. Fairly obvious I would have
thought.
and I think that most of you agree.
I doubt that very much.
Lets turn it around. Why would you think having a real boolean is NOT a
good idea?
Richard wrote:
"J. J. Farrell" <jj*@bcs.org.ukwrites:
>On Nov 3, 10:56 pm, AommiK <nos...@nospam.comwrote:
>>OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently)
to get a real "bool". This isn't my point, however -- it should have
been there from the beginning.
Why?
Because C is a programming language that applies all sorts of rules on
other types and a C program uses boolean decision making every other
line or so ....
And in C boolean decision making doesn't require a boolean type.
>>Char is a small int. We all know that. However, "char some_bool =
0;" simply feels wrong,
Why?
Because it's not a true "boolean".
C defines zero as boolean false and any other value as boolean true, in
a boolean context. A specific boolean type isn't necessary except for
aesthetic purposes.
When you see a char its not obvious
fro the type that it's a binary indicator.
That's what typedefs are for. Also the object's name should convey it's
intended boolean usage.
Fairly obvious I would have thought.
It's also fairly obvious that unlike languages like C#, C doesn't
require a boolean type; any value is interpreted as true or false
according to a simple rule.
Anyway the latest C standard _has_ mandated a boolean type, for whatever
it's worth.
However the OP was complaining about the lack of single bit boolean
types and the supposed wasted storage by using a char or int or
whatever.
Now, as far as I can see, there is no readily apparent reason against
implementing a bit type in C. However the fact that C conveniently
treats any integer value as either true or false, when in a boolean
context, combined with the probable loss of execution efficiency in
manipulating a bit type, meant that a specific boolean bit type was not
(and is not) felt as very essential to the language.
Lets turn it around. Why would you think having a real boolean is NOT
a good idea?
No one said it was not a good idea. Probable reasons were supplied for
why it was not built into the language from it's beginning. That does
not imply that boolean types are either good or bad.
santosh <sa*********@gmail.comwrites:
Richard wrote:
>"J. J. Farrell" <jj*@bcs.org.ukwrites:
>>On Nov 3, 10:56 pm, AommiK <nos...@nospam.comwrote:
>>>OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently)
to get a real "bool". This isn't my point, however -- it should have
been there from the beginning.
Why?
Because C is a programming language that applies all sorts of rules on
other types and a C program uses boolean decision making every other
line or so ....
And in C boolean decision making doesn't require a boolean type.
Obviously. But that isn't the issue.
>
>>>Char is a small int. We all know that. However, "char some_bool =
0;" simply feels wrong,
Why?
Because it's not a true "boolean".
C defines zero as boolean false and any other value as boolean true, in
a boolean context. A specific boolean type isn't necessary except for
aesthetic purposes.
Bingo! You've got it. Aesthetic purposes. Also for things like *cough*
variable tagging and debugging it is useful.
>
>When you see a char its not obvious
fro the type that it's a binary indicator.
That's what typedefs are for. Also the object's name should convey it's
intended boolean usage.
So shall we get rid of ALL types and use typedefs?
>
>Fairly obvious I would have thought.
It's also fairly obvious that unlike languages like C#, C doesn't
require a boolean type; any value is interpreted as true or false
according to a simple rule.
This is true of ANY language I have dealt with.
if(x) .....
>
Anyway the latest C standard _has_ mandated a boolean type, for whatever
it's worth.
Aha. So not so silly and "useless" after all?
>
However the OP was complaining about the lack of single bit boolean
types and the supposed wasted storage by using a char or int or
whatever.
I would agree that is silly.
>
Now, as far as I can see, there is no readily apparent reason against
implementing a bit type in C. However the fact that C conveniently
treats any integer value as either true or false, when in a boolean
context, combined with the probable loss of execution efficiency in
manipulating a bit type, meant that a specific boolean bit type was not
(and is not) felt as very essential to the language.
>Lets turn it around. Why would you think having a real boolean is NOT
a good idea?
No one said it was not a good idea. Probable reasons were supplied for
why it was not built into the language from it's beginning. That does
not imply that boolean types are either good or bad.
It is fairly clear to me that a boolean type would only make code
cleaner. Would I use them? Probably not :-; I'm too entrenched in zero
and non zero.
Richard wrote:
santosh <sa*********@gmail.comwrites:
>Richard wrote:
>>"J. J. Farrell" <jj*@bcs.org.ukwrites:
On Nov 3, 10:56 pm, AommiK <nos...@nospam.comwrote:
>>>>OK. Some of you might refer to C99 and its _Bool (what's up with
the uppercase 'B' anyway?) and the header you can include
(apparently) to get a real "bool". This isn't my point, however --
it should have been there from the beginning.
Why?
Because C is a programming language that applies all sorts of rules
on other types and a C program uses boolean decision making every
other line or so ....
And in C boolean decision making doesn't require a boolean type.
Obviously. But that isn't the issue.
However it is one possible reason why C's designers did not consider a
dedicated boolean type as important.
<snip>
>>When you see a char its not obvious
fro the type that it's a binary indicator.
That's what typedefs are for. Also the object's name should convey
it's intended boolean usage.
So shall we get rid of ALL types and use typedefs?
You cannot get rid of some types without destroying the core language.
Also note that typedef cannot be used without the presence of at least
one preexisting type.
>>Fairly obvious I would have thought.
It's also fairly obvious that unlike languages like C#, C doesn't
require a boolean type; any value is interpreted as true or false
according to a simple rule.
This is true of ANY language I have dealt with.
if(x) .....
The following is an excerpt from Wikipedia's article on C#:
C# supports a strict boolean type, bool. Statements that take
conditions, such as while and if, require an expression of a boolean
type. While C++ also has a boolean type, it can be freely converted to
and from integers, and expressions such as if(a) require only that a is
convertible to bool, allowing a to be an int, or a pointer. C#
disallows this 'integer meaning true or false' approach on the grounds
that forcing programmers to use expressions that return exactly bool
prevents certain types of programming mistakes.
>Anyway the latest C standard _has_ mandated a boolean type, for
whatever it's worth.
Aha. So not so silly and "useless" after all?
I never said a boolean type was silly or useless. It's just not an
essential type however.
>However the OP was complaining about the lack of single bit boolean
types and the supposed wasted storage by using a char or int or
whatever.
I would agree that is silly.
OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between
various competing considerations and C had, until C99, chosen not to
implement a boolean type. Now it has one, but not, apparently, to the
OP's satisfaction.
<snip>
It is fairly clear to me that a boolean type would only make code
cleaner.
It might. OTOH the "type explosion" introduced by C99 can also be argued
as, to an extent, damaging one of C's strengths - it's simplicity.
Would I use them? Probably not :-; I'm too entrenched in zero
and non zero.
Personally I use boolean objects only occasionally. I use C99's
definition when it's available or define it myself. As Malcolm notes,
there is a small possibility of a non-Standard definition conflicting
with another definition in library code, but I haven't encountered that
problem yet.
Richard wrote:
santosh <sa*********@gmail.comwrites:
>Richard wrote:
>>santosh <sa*********@gmail.comwrites:
<snip>
>>>However the OP was complaining about the lack of single bit boolean
types and the supposed wasted storage by using a char or int or
whatever.
I would agree that is silly.
OP's statement isn't silly. A multi bit boolean type _does_ waste
some space. As in many other things, it's a matter of trade-off
between
There is no multibit boolean type,
Most typedefs for a boolean type use a multi bit base type.
<snip>
Richard <rg****@gmail.comwrites:
santosh <sa*********@gmail.comwrites:
[...]
>OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between
There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.
[...]
Can you clarify that statement?
I'll ignore bit fields in the following; note that bit fields can only
be members of structs or unions, so they're not useful if you want to
declare single object.
All C types are multi-bit. Every C object has a size that's a whole
number of bytes, where each byte must be at least 8 bits. If you
declare an object of a boolean type, whether it's C99's _Bool or
soemthing you've defined yourself, that object must occupy at least 8
bits. Note that C doesn't have zero-sized objects.
(This "waste" of space isn't a problem in practice; using only a
single bit would typically require much more code to access it than
the data space you'd save.)
I see no straw man argument in what santosh posted above.
If you think that a programmer "can use his own [boolean type] with no
bits wasted if he so chooses", please demonstrate how you'd declare
such a type.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson <ks***@mib.orgwrites:
Richard <rg****@gmail.comwrites:
>santosh <sa*********@gmail.comwrites:
[...]
>>OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between
There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.
[...]
Can you clarify that statement?
That there exists no multibit boolean type. Nothing more nothing
less. Anything else is personal preference/implementation.
>
I'll ignore bit fields in the following; note that bit fields can only
be members of structs or unions, so they're not useful if you want to
declare single object.
All C types are multi-bit. Every C object has a size that's a whole
Yes. But there is no boolean type : multibit or not.
number of bytes, where each byte must be at least 8 bits. If you
declare an object of a boolean type, whether it's C99's _Bool or
soemthing you've defined yourself, that object must occupy at least 8
bits. Note that C doesn't have zero-sized objects.
(This "waste" of space isn't a problem in practice; using only a
single bit would typically require much more code to access it than
the data space you'd save.)
Exactly. Hence my comment on it being a silly issue.
>
I see no straw man argument in what santosh posted above.
If you think that a programmer "can use his own [boolean type] with no
bits wasted if he so chooses", please demonstrate how you'd declare
such a type.
I don't think that and never suggested otherwise.
santosh <sa*********@gmail.comwrites:
Richard wrote:
>santosh <sa*********@gmail.comwrites:
>>Richard wrote:
santosh <sa*********@gmail.comwrites:
<snip>
>>>>However the OP was complaining about the lack of single bit boolean
types and the supposed wasted storage by using a char or int or
whatever.
I would agree that is silly.
OP's statement isn't silly. A multi bit boolean type _does_ waste
some space. As in many other things, it's a matter of trade-off
between
There is no multibit boolean type,
Most typedefs for a boolean type use a multi bit base type.
<snip>
So, OT then :-;
Richard wrote:
santosh <sa*********@gmail.comwrites:
>Richard wrote:
>>santosh <sa*********@gmail.comwrites:
Richard wrote:
santosh <sa*********@gmail.comwrites:
<snip>
>>>>>However the OP was complaining about the lack of single bit
>boolean types and the supposed wasted storage by using a char or
>int or whatever.
>
I would agree that is silly.
OP's statement isn't silly. A multi bit boolean type _does_ waste
some space. As in many other things, it's a matter of trade-off
between
There is no multibit boolean type,
Most typedefs for a boolean type use a multi bit base type.
<snip>
So, OT then :-;
Only if their definition or use involve non-Standard constructs.
Richard <rg****@gmail.comwrites:
Keith Thompson <ks***@mib.orgwrites:
>Richard <rg****@gmail.comwrites:
>>santosh <sa*********@gmail.comwrites:
[...]
>>>OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between
There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.
[...]
Can you clarify that statement?
That there exists no multibit boolean type. Nothing more nothing
less. Anything else is personal preference/implementation.
[snip]
>All C types are multi-bit. Every C object has a size that's a whole
Yes. But there is no boolean type : multibit or not.
Your statement that "there is no multibit boolean type" could easily
be taken to imply that there is a boolean type that's not multibit.
In fact, that's exactly how I read it. If you had said "there is no
boolean type" from the beginning, you could have avoided a great deal
of confusion.
It just didn't occur to me that you would ignore the existence of
_Bool and bool in C99, which have been discussed in this very thread.
In C90, you can easily declare your own boolean type; numerous
examples have been posted here. Any such type is going to be multibit
(barring the use of compiler extensions that might allow for one-bit
types). Such a type is a "boolean type" by any reasonable definition
of that phrase.
In C99, a predefined boolean type already exists, and like all other
types (ignoring bit fields), it must be multibit.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On Nov 4, 3:05 pm, "J. J. Farrell" <j...@bcs.org.ukwrote:
It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?
Example 1:
if ( 0x35A & 0x100 )
foo();
Example 2:
bool result = 0x35A & 0x100;
if ( result )
foo();
Example 3:
bool bar() { return 0x35A & 0x100; }
/*...*/
if ( bar() )
foo();
If bool is a typedef for char then foo will not be called
in examples 2 and 3. If 'bool' were a true boolean type,
then foo will be called in all cases.
IMHO, using the word 'bool' for a non-boolean type is
obfuscated.
On Nov 4, 10:36 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Nov 4, 3:05 pm, "J. J. Farrell" <j...@bcs.org.ukwrote:
It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?
Example 1:
if ( 0x35A & 0x100 )
foo();
Example 2:
bool result = 0x35A & 0x100;
if ( result )
foo();
Example 3:
bool bar() { return 0x35A & 0x100; }
/*...*/
if ( bar() )
foo();
If bool is a typedef for char then foo will not be called
in examples 2 and 3. If 'bool' were a true boolean type,
then foo will be called in all cases.
IMHO, using the word 'bool' for a non-boolean type is
obfuscated.
Granted, but you are assuming a particular interpretation of what is
meant by "a boolean type"; in particular, you're assuming well-defined
conversion from other types. What you describe here is certainly
useful, but is not necessarily what everyone would think of as "a
boolean type". I was thinking in terms of an object which holds the
traditional C concept of a boolean - if it's value is zero it is
false, else it is true - without automatic conversion from other
types. Your concept is more powerful and useful, and does require a
fundamental type built in to the language.
Keith Thompson <ks***@mib.orgwrites:
Richard <rg****@gmail.comwrites:
>Keith Thompson <ks***@mib.orgwrites:
>>Richard <rg****@gmail.comwrites:
santosh <sa*********@gmail.comwrites:
[...]
OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between
There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.
[...]
Can you clarify that statement?
That there exists no multibit boolean type. Nothing more nothing
less. Anything else is personal preference/implementation.
[snip]
>>All C types are multi-bit. Every C object has a size that's a whole
Yes. But there is no boolean type : multibit or not.
Your statement that "there is no multibit boolean type" could easily
be taken to imply that there is a boolean type that's not multibit.
In fact, that's exactly how I read it. If you had said "there is no
boolean type" from the beginning, you could have avoided a great deal
of confusion.
Since the entire thread is based on there being no boolean type I felt
that somewhat unnecessary.
Keith Thompson wrote:
[...]
I agree that the lack of a boolean type it's not a major flaw, but I'm
glad C99 added it.
If I were designing C from scratch today, I'd probably make bool a
built-in type from the beginning, make the relational and equality
operators yield bool results, and require bool expressions for
conditions. (I personally wouldn't provide implicit conversions to
bool; others would want that.)
_Bool is ugly, using <stdbool.his ugly, providing bool/true/false via
macros are ugly
The fear of breaking existing code in C99, was IMO not a sufficient
reason for bringing such ugly constructs forward. How hard would it have
been, to grep an existing project for bool/false/true?
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Keith Thompson said:
Richard <rg****@gmail.comwrites:
>santosh <sa*********@gmail.comwrites:
[...]
>>OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between
There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.
[...]
Can you clarify that statement?
Feeding trolls is of course your prerogative, Keith, but it seems to me to
be strange behaviour from one who encourages others to starve them.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jack Klein wrote:
Tor Rustad <to********@hotmail.comwrote:
.... snip ...
>>
_Bool is ugly, using <stdbool.his ugly, providing
bool/true/false via macros are ugly
Nowhere in the mandate of the standard committee is there any
requirement to avoid keywords or other identifiers that Tor
Rustad, or Jack Klein, or any other C programmer or group of
C programmers considers ugly.
However there is a strong urge to not create new reserved words in
the user namespace, which can in turn necessitate large amounts of
editing.
A useful solution for this sort of problem is ID2ID-20, which can
easily make the same changes over a list of files. It is written
in purely standard C, and available at:
<http://cbfalconer.home.att.net/download/>
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrites:
Jack Klein wrote:
>Tor Rustad <to********@hotmail.comwrote:
... snip ...
>>>
_Bool is ugly, using <stdbool.his ugly, providing
bool/true/false via macros are ugly
Nowhere in the mandate of the standard committee is there any
requirement to avoid keywords or other identifiers that Tor
Rustad, or Jack Klein, or any other C programmer or group of
C programmers considers ugly.
However there is a strong urge to not create new reserved words in
the user namespace, which can in turn necessitate large amounts of
editing.
A useful solution for this sort of problem is ID2ID-20, which can
easily make the same changes over a list of files. It is written
in purely standard C, and available at:
<http://cbfalconer.home.att.net/download/>
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
Most decent C IDEs support renaming/refactoring within the IDE : no need
for 3rd party hacks.
e.g for Eclipse: http://www.ibm.com/developerworks/library/os-ecref/
AommiK wrote:
I have asked many people about this for quite some time, and they are
all just telling me that I'm silly for bringing it up. Why? It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.
If the point is just pretty coding, then:
typedef int bool;
Or better:
typedef unsigned bool;
(Operations on unsigned values are often less expensive than signed ones)
JJ
João Jerónimo wrote:
AommiK wrote:
>I have asked many people about this for quite some time, and they are
all just telling me that I'm silly for bringing it up. Why? It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.
If the point is just pretty coding, then:
typedef int bool;
Or better:
typedef unsigned bool;
(Operations on unsigned values are often less expensive than signed ones)
They are?
Which operations, how much, and how often?
--
Chris "afflicted with a failure of imagination" Dollin
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
On Monday 05 Nov 2007 10:22 pm Richard <rg****@gmail.comwrote in
article <qb************@news.individual.net>:
João Jerónimo <j_*******@yahoo.com.brwrites:
<snip>
> - C doesn't have built-in Garbage Collection because ASM languages
don't
support the concept either.
No, C doesnt have it because it didnt exist when C was invented and it
makes a mockery of efficiency IMO.
No. Garbage collection existed before C. LISP had it.
<snip>
Chris Dollin wrote:
>Or better:
typedef unsigned bool;
(Operations on unsigned values are often less expensive than signed ones)
They are?
Which operations, how much, and how often?
In reality, they don't matter for bools...
Multiplications and divisions.
JJ
On Monday 05 Nov 2007 10:59 pm João Jerónimo <j_*******@yahoo.com.br>
wrote in article <47***********************@news.sunsite.dk>:
Richard wrote:
>João Jerónimo wrote:
>> - C, natively, only knows how to deal with logical and arithmetic
data. That's because most processors only know that.
Is this without the standard library?
No! Don't tell me that C needs the standard library to do arithmetic!
I don't think so!
Some arithmetic operations may however be implemented as "magic"
function calls, essentially compiler magic, invisible from the
standpoint of Standard C. Extended width arithmetic is typically done
this way.
<snip>
santosh wrote:
On Monday 05 Nov 2007 10:22 pm Richard <rg****@gmail.comwrote in
article <qb************@news.individual.net>:
>João Jerónimo <j_*******@yahoo.com.brwrites:
<snip>
>> - C doesn't have built-in Garbage Collection because ASM languages
don't
support the concept either.
No, C doesnt have it because it didnt exist when C was invented and it
makes a mockery of efficiency IMO.
No. Garbage collection existed before C. LISP had it.
<snip>
I'm shocked! Can it be true that someone actually reads post from rg****@gmail.com?
João Jerónimo wrote, On 05/11/07 17:49:
Chris Dollin wrote:
>>Or better:
typedef unsigned bool;
(Operations on unsigned values are often less expensive than signed ones)
They are?
Which operations, how much, and how often?
In reality, they don't matter for bools...
Multiplications and divisions.
On the processors where I have had an interest in the speed those were
no slower for signed than for unsigned. This shows that at the very
least your assertion is not true for all implementations.
--
Flash Gordon
Martin Ambuhl wrote:
santosh wrote:
>Richard <rg****@gmail.comwrote:
.... snip ...
>>
>>No, C doesnt have it because it didnt exist when C was invented
and it makes a mockery of efficiency IMO.
No. Garbage collection existed before C. LISP had it.
<snip>
I'm shocked! Can it be true that someone actually reads post from
rg****@gmail.com?
Once in a while I find he has made a direct reply to me (which
hasn't been quoted) and become curious about any improvement. Then
I mark that reply unread, and my next connection to the news-server
gets it. In general I find no improvement.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
João Jerónimo <j_*******@yahoo.com.brwrites:
Richard wrote:
<snip (some attribution manual replaced)>
>>João Jerónimo <j_*******@yahoo.com.brwrites:
>> - C doesn't have built-in Garbage Collection because ASM languages don't
support the concept either.
No, C doesnt have it because it didnt exist when C was invented and it
makes a mockery of efficiency IMO.
Yes.
<snip>
- And, of course, it didn't exist when C was invented
Marvin L. Minsky. A Lisp garbage collector algorithm using serial
secondary storage. Technical Report Memo 58 (rev.), Project MAC, MIT,
Cambridge, MA, December 1963.
I don't claim that this is the first paper on GC, just that it
pre-dates C. There are dozens of papers about GC from the 60s and DMR
cites 1969-73 as the key design time for C.
--
Ben.
Ben Bacarisse <be********@bsb.me.ukwrites:
João Jerónimo <j_*******@yahoo.com.brwrites:
>Richard wrote:
<snip (some attribution manual replaced)>
>>>João Jerónimo <j_*******@yahoo.com.brwrites:
- C doesn't have built-in Garbage Collection because ASM languages don't
support the concept either.
No, C doesnt have it because it didnt exist when C was invented and it
makes a mockery of efficiency IMO.
Yes.
<snip>
> - And, of course, it didn't exist when C was invented
Marvin L. Minsky. A Lisp garbage collector algorithm using serial
secondary storage. Technical Report Memo 58 (rev.), Project MAC, MIT,
Cambridge, MA, December 1963.
I don't claim that this is the first paper on GC, just that it
pre-dates C. There are dozens of papers about GC from the 60s and DMR
cites 1969-73 as the key design time for C.
What languages used GC at the time that C and its forefathers were
evolving? How do you see GC fitting into the "style" of C?
Putting GC into C would have been like interpreting assembler IMO ....
Chris Dollin wrote:
Richard wrote:
>What languages used GC at the time that C and its forefathers were
evolving?
Lisp, Algol W, Algol 68, Snobol (I think that's in the frame), Simula 67.
Off the top of my head, and not intended to be exhaustive by any means.
Argh! How could I forget POP2!
--
Chris "bows to Poplog" Dollin
Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England
Chris Dollin <ch**********@hp.comwrites:
Chris Dollin wrote:
>Richard wrote:
>>What languages used GC at the time that C and its forefathers were
evolving?
Lisp, Algol W, Algol 68, Snobol (I think that's in the frame), Simula 67.
Off the top of my head, and not intended to be exhaustive by any means.
Argh! How could I forget POP2!
Yup all very C-like. What were the designers of C thinking!!!
In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:
Marvin L. Minsky. A Lisp garbage collector algorithm using serial
secondary storage. Technical Report Memo 58 (rev.), Project MAC, MIT,
Cambridge, MA, December 1963.
>I don't claim that this is the first paper on GC
The OED's first citation for "garbage collector" is 1960, McCarthy's
LISP I Programmer's Manual.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
In article <fg**********@murdoch.hpl.hp.com>,
Chris Dollin <ch**********@hp.comwrote:
>I think the timing fits, but I can't remember when RSRE did the first
A68 implementation. Certainly the technology was "well known".
It was RRE in those days. The "first published" date in the
ALGOL 68-R Users [sic] Guide is 1972.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
>Chris Dollin wrote:
>>Richard wrote:
What languages used GC at the time that C and its forefathers were
evolving?
Lisp, Algol W, Algol 68, Snobol (I think that's in the frame), Simula 67.
Off the top of my head, and not intended to be exhaustive by any means.
Argh! How could I forget POP2!
Yup all very C-like.
Was somebody asking for /C-like/ GCed languages? And what does "C-like" mean,
in the era before C?
--
Chris "BCPL" Dollin
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>Chris Dollin <ch**********@hp.comwrites:
>>Chris Dollin wrote:
Richard wrote:
What languages used GC at the time that C and its forefathers were
evolving?
Lisp, Algol W, Algol 68, Snobol (I think that's in the frame), Simula 67.
Off the top of my head, and not intended to be exhaustive by any means.
Argh! How could I forget POP2!
Yup all very C-like.
Was somebody asking for /C-like/ GCed languages? And what does "C-like" mean,
in the era before C?
We are talking about GC for C. Not for Lisp. Not for Algol. This is
getting to look like one of those fighting for points threads. I'll bow
out.
There was no need and no desire for GC in C. It would be like hanging an
anchor off the back of a skateboard.
Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
>Richard wrote:
>>Chris Dollin <ch**********@hp.comwrites:
Chris Dollin wrote:
Richard wrote:
>
>What languages used GC at the time that C and its forefathers were
>evolving?
>
Lisp, Algol W, Algol 68, Snobol (I think that's in the frame), Simula 67.
Off the top of my head, and not intended to be exhaustive by any means.
Argh! How could I forget POP2!
Yup all very C-like.
Was somebody asking for /C-like/ GCed languages? And what does "C-like" mean,
in the era before C?
We are talking about GC for C. Not for Lisp. Not for Algol.
It was you, was it not, who asked "What languages used GC at the time that
C and its forefathers were evolving?" Someone -- I've lost track of who --
claimed that "it didnt exist when C was invented". They were wrong, and I
took you to be asking for examples.
I answered that question.
There was no need and no desire for GC in C.
I've not said otherwise (and I think that "was" may be important).
It would be like hanging an anchor off the back of a skateboard.
Indeed.
One doesn't get motorcycles by merely adding engines to bicycles; effective
language design is holistic.
--
Chris "BSA Starfire, many years ago" Dollin
Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England
Ben Bacarisse wrote:
I don't claim that this is the first paper on GC, just that it
pre-dates C. There are dozens of papers about GC from the 60s and DMR
cites 1969-73 as the key design time for C.
Ok. Thank you for the information...
I was basing on Richard's words when I wrote that (I didn't know when GC
had been invented).
JJ
On Sun, 04 Nov 2007 09:53:31 +0000, Philip Potter
<pg*@see.sig.invalidwrote:
<snip>
Do you have an example of a language with a boolean type which will
store the boolean in a location smaller than a byte?
Pascal can use only 1 bit for a BOOLEAN and only the needed bits for a
(small) subrange or enum within an array or record, especially if you
declare it PACKED. At least in classic Pascal there is no way to take
the address of these so it doesn't matter that they aren't on a byte
(or word) boundary.
PL/I can do both of those for BIT(1), but AFAIK there's no syntax to
specify packing, so IMLE it is usually the default. (You can
explicitly declare padding, but it's hard to get it portably correct.)
PL/I also has BIT strings (fixed or variable-length=counted) which are
inherently packed, and whose elements cannot be pointed to (but can be
selected by SUBSTR).
Ada rather like Pascal has BOOLEAN and subrange/enum types, a general
option (pragma) for packing, and also more verbose options for exact
representation which allow you to really force desired packing.
- formerly david.thompson1 || achar(64) || worldnet.att.net
On Nov 4, 2:05 am, "J. J. Farrell" <j...@bcs.org.ukwrote:
On Nov 3, 10:56 pm, AommiK <nos...@nospam.comwrote:
First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.
It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.
How would it save resources? A boolean type smaller than char would
require more resources to implement and at run time. How would it make
coding any prettier?
An array of Bool could save considerable resources, typically 87.5%,
if implemented as a bit-array. There would be implementation issues in
C however as a bit wouldn't be directly addressable.
Bart This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Pierre Espenan |
last post by:
A have a long integer class. The built integer type within a conditional
statement returns bool false for int i=0 and bool true for any other non
zero value. I want my long integer class to have...
|
by: daniel |
last post by:
1)
is C++ smart enough to automatically use "bits" for bool or will
a bool have the size of a charcter (byte).
2) The index of a vector is it an integer (4 byte) or a "long long"
with 8 bytes or...
|
by: ORC |
last post by:
Is the bool type actually an Int32 with 0 as false and non zero as true? The
reason for my question is that I've seen a lot of API calls that return a
Int32 implemented in C# as an bool like:
...
|
by: zl2k |
last post by:
hi, there
I am using a big, sparse binary array (size of 256^3). The size may be
changed in run time. I first thought about using the bitset but found
its size is unchangeable. If I use the...
|
by: shaanxxx |
last post by:
I have code which says
#define MYBOOL int
This code is very old. people who have written is not avaible. I was
thinking what could be reason.
1) bool datatype was not available that time (10...
|
by: markb |
last post by:
Hi
My C# app is being called from a callback from an unmanaged DLL. One of
the parameters of the callback is of type BOOL. I am using PInvoke to
marshal this to a (managed) bool. The problem is...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
