«

On 04/26/2012 07:57 AM, Eric Sosman wrote:
> On 3/27/2012 12:53 PM, mathog wrote:
....
>> My point exactly, even if a bool in some implementation is stored more
>> or less the same way as an integer type, none of the integer operations
>> should be applicable to it.
>
> bool expensive(), complicated(), long_winded();
> switch (4*expensive() + 2*complicated() + long_winded()) {
> case 0: ...
> case 1: ...
> case 2: ...
> case 3: ...
> case 4: ...
> case 5: ...
> case 6: ...
> case 7: ...
> }
>
> I'll grant that this sort of situation doesn't arise all that often,
> and I'll grant that there are other ways to write the logic (there's
> usually more than one way to do something in C), but I think you're
> going overboard in trying to legislate the pattern out of existence.

If bool were a strictly logical type, on which no arithmetic could be
performed, that pattern would still be allowed, the syntax would just be
slightly more complicated:

(expensive()?4:0) + (complicated()?2:0) + (long_winded()?1:0)




--
James Kuyper

On 4/26/2012 9:09 AM, James Kuyper wrote:
> On 04/26/2012 07:57 AM, Eric Sosman wrote:
>> On 3/27/2012 12:53 PM, mathog wrote:
> ...
>>> My point exactly, even if a bool in some implementation is stored more
>>> or less the same way as an integer type, none of the integer operations
>>> should be applicable to it.
>>
>> bool expensive(), complicated(), long_winded();
>> switch (4*expensive() + 2*complicated() + long_winded()) {
>> case 0: ...
>> case 1: ...
>> case 2: ...
>> case 3: ...
>> case 4: ...
>> case 5: ...
>> case 6: ...
>> case 7: ...
>> }
>>
>> I'll grant that this sort of situation doesn't arise all that often,
>> and I'll grant that there are other ways to write the logic (there's
>> usually more than one way to do something in C), but I think you're
>> going overboard in trying to legislate the pattern out of existence.
>
> If bool were a strictly logical type, on which no arithmetic could be
> performed, that pattern would still be allowed, the syntax would just be
> slightly more complicated:
>
> (expensive()?4:0) + (complicated()?2:0) + (long_winded()?1:0)

"I'll grant that there are other ways to write the logic," as
a person I deeply respect once wrote.

Here's another example where arithmetic on bool is handy:

const int days_in_month[2][12] = {
{ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
};
bool is_leap_year = ...;
int month = ...;
int days = days_in_month[is_leap_year][month - 1];

"One (int) cast and all's well," but don't forget the skeptical
glance one usually casts upon casts...

--
Eric Sosman
d

On 04/26/2012 09:29 PM, Eric Sosman wrote:
....
> "I'll grant that there are other ways to write the logic," as
> a person I deeply respect once wrote.
>
> Here's another example where arithmetic on bool is handy:
>
> const int days_in_month[2][12] = {
> { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
> { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
> };
> bool is_leap_year = ...;
> int month = ...;
> int days = days_in_month[is_leap_year][month - 1];
>
> "One (int) cast and all's well," but don't forget the skeptical
> glance one usually casts upon casts...

In a hypothetical C-like language where bools were truly a separate
type, a cast to int would not be allowed. Instead, use
(isleap_year ? 1 : 0).
--
James Kuyper

On 4/26/2012 9:58 PM, James Kuyper wrote:
> On 04/26/2012 09:29 PM, Eric Sosman wrote:
> ...
>> "I'll grant that there are other ways to write the logic," as
>> a person I deeply respect once wrote.
>>
>> Here's another example where arithmetic on bool is handy:
>>
>> const int days_in_month[2][12] = {
>> { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
>> { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
>> };
>> bool is_leap_year = ...;
>> int month = ...;
>> int days = days_in_month[is_leap_year][month - 1];
>>
>> "One (int) cast and all's well," but don't forget the skeptical
>> glance one usually casts upon casts...
>
> In a hypothetical C-like language where bools were truly a separate
> type, a cast to int would not be allowed. Instead, use
> (isleap_year ? 1 : 0).

"I'll grant ..." (Is there an echo in here?)

The question that burns in my feeble brain is: "Why?" What is
the benefit that a "No arithmetic on booleans" rule would bring?
In what way would the hypothetical C-like language be superior to
C-where-ints-work-just-fine-thanks? I'm not inclined to accept
unsupported assertions like "Cleanliness is next to Godliness,"
but would attend to concrete, measurable, or estimatable advantages,
or to credible first-person anecdotes.

So far, the only thing I've heard is the O.P.'s complaint
that the compiler allowed him to get himself in trouble by making
code changes without first understanding the code he was changing.

Well, golly.

If you're looking for a language with seat belts, training
wheels, airbags, and padded walls, C shouldn't be your first
choice, and restrictions on arithmetic wouldn't change matters.

--
Eric Sosman
d

On 04/26/2012 10:32 PM, Eric Sosman wrote:
> On 4/26/2012 9:58 PM, James Kuyper wrote:
....
>> In a hypothetical C-like language where bools were truly a separate
>> type, a cast to int would not be allowed. Instead, use
>> (isleap_year ? 1 : 0).
>
> "I'll grant ..." (Is there an echo in here?)
>
> The question that burns in my feeble brain is: "Why?" What is
> the benefit that a "No arithmetic on booleans" rule would bring?

It makes syntax errors out of constructs that are conceptually
meaningless, forcing the use of alternative constructs that say more
precisely what is actually going on. As such, it makes it easier to
detect erroneous constructs.

....
> If you're looking for a language with seat belts, training
> wheels, airbags, and padded walls, C shouldn't be your first
> choice, and restrictions on arithmetic wouldn't change matters.

A C-like language with few more barriers between conceptually distinct
things like numbers, characters, and bools than C has, would make it
slightly easier to avoid writing nonsense. Those barriers wouldn't cause
the loss of any truly valuable characteristic of C.
--
James Kuyper

On Apr 26, 10:32*pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 4/26/2012 9:58 PM, James Kuyper wrote:
>
>
>
>
>
>
>
>
>
> > On 04/26/2012 09:29 PM, Eric Sosman wrote:
> > ...
> >> * * * "I'll grant that there are other ways to write the logic,"as
> >> a person I deeply respect once wrote.
>
> >> * * * Here's another example where arithmetic on bool is handy:
>
> >> * * * *const int days_in_month[2][12] = {
> >> * * * * * *{ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
> >> * * * * * *{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
> >> * * * *};
> >> * * * *bool is_leap_year = ...;
> >> * * * *int month = ...;
> >> * * * *int days = days_in_month[is_leap_year][month - 1];
>
> >> "One (int) cast and all's well," but don't forget the skeptical
> >> glance one usually casts upon casts...
>
> > In a hypothetical C-like language where bools were truly a separate
> > type, a cast to int would not be allowed. Instead, use
> > * *(isleap_year ? 1 : 0).
>
> * * *"I'll grant ..." *(Is there an echo in here?)
>
> * * *The question that burns in my feeble brain is: "Why?" *What is
> the benefit that a "No arithmetic on booleans" rule would bring?

The benefit is that one avoids mixing semantics with types that other
people may use differently. If you commonly use bool as an index to
an array, someone else may look at that and wonder, "What on earth is
that? Why aren't you using an int or size_t because those are my
conceptual types to use as an index." Either will get the job done,
but a careful choice of type can reduce the amount of confusion other
readers have to deal with, and provide more context to detect defects
in the presence of bugs.

Best regards,
John D.

Le 27/04/2012 12:31, James Kuyper a écrit :
> On 04/26/2012 10:32 PM, Eric Sosman wrote:
>> On 4/26/2012 9:58 PM, James Kuyper wrote:
> ...
>>> In a hypothetical C-like language where bools were truly a separate
>>> type, a cast to int would not be allowed. Instead, use
>>> (isleap_year ? 1 : 0).
>>
>> "I'll grant ..." (Is there an echo in here?)
>>
>> The question that burns in my feeble brain is: "Why?" What is
>> the benefit that a "No arithmetic on booleans" rule would bring?
>
> It makes syntax errors out of constructs that are conceptually
> meaningless, forcing the use of alternative constructs that say more
> precisely what is actually going on. As such, it makes it easier to
> detect erroneous constructs.
>
> ...
>> If you're looking for a language with seat belts, training
>> wheels, airbags, and padded walls, C shouldn't be your first
>> choice, and restrictions on arithmetic wouldn't change matters.
>
> A C-like language with few more barriers between conceptually distinct
> things like numbers, characters, and bools than C has, would make it
> slightly easier to avoid writing nonsense. Those barriers wouldn't cause
> the loss of any truly valuable characteristic of C.

I think you mean ADA.

James Kuyper wrote:
) On 04/26/2012 10:32 PM, Eric Sosman wrote:
)> The question that burns in my feeble brain is: "Why?" What is
)> the benefit that a "No arithmetic on booleans" rule would bring?
)
) It makes syntax errors out of constructs that are conceptually
) meaningless, forcing the use of alternative constructs that say more
) precisely what is actually going on. As such, it makes it easier to
) detect erroneous constructs.

It also makes syntax errors out of constructs that are perfectly
meaningful, forcing the use of needless extra boilerplate code
that only serves to muddle what is actually going on.

The boundary between the two is purely a matter of taste.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Lanarcam <> writes:
> Le 27/04/2012 12:31, James Kuyper a écrit :
>> On 04/26/2012 10:32 PM, Eric Sosman wrote:
[...]
>>> If you're looking for a language with seat belts, training
>>> wheels, airbags, and padded walls, C shouldn't be your first
>>> choice, and restrictions on arithmetic wouldn't change matters.
>>
>> A C-like language with few more barriers between conceptually distinct
>> things like numbers, characters, and bools than C has, would make it
>> slightly easier to avoid writing nonsense. Those barriers wouldn't cause
>> the loss of any truly valuable characteristic of C.
>
> I think you mean ADA.

I think *you* mean Ada (the name is not an acronym).

But one could have a C-like language with fewer implicit conversions
without going as far as Ada, which doesn't even have implicit
conversions between otherwise identical integer types.

I can imagine a C-like language with, say, the following features:

- C-like implicit conversions among all numeric types, signed, unsigned,
and floating-point -- or maybe only allow implicit conversions within
each of the three kinds of numeric types (yes, I'm ignoring _Complex
for now)

- bool is treated as a scalar but non-numeric type

- Each enumerated type is treated as a scalar but non-numeric type
(bool could be a special-case enumerated type, with false and true as
enumerated constants)

- No implicit conversions between numeric and non-numeric types (but
casts work as in C)

- 0 is not a null pointer constant; instead, there's a keyword (say,
"nil") that is the language's *only* null pointer constant

- Relational and equality operators yield bool results

- Contexts that require conditions (if, for, while, do-while, !, &&, ||,
?:, and whatever else I've forgotten) require a bool expression

Some implications:

- The NULL macro is unnecessary, and is replaced by the nil keyword.

- You'd have to write "if (num != 0)" rather than "if (num)".

- You'd have to write "if (ptr != nil)" rather than "if (ptr)".

- There are undoubtedly more implications that would have to be worked
out.

This hypothetical language would be closer to Ada than C is, but
it's still much closer to C than it is to Ada. Think of a scale
with C at 0, Ada at 1, and this language at perhaps 0.05 or 0.1.

I do not suggest for a moment that C itself should be changed like this.
It would break almost all existing C code, and that's clearly unacceptable.

But personally, I think I'd like it a little better than I like C. (And
if I ever actually invented such a thing, I'd probably also clean up the
treatment of arrays and pointers.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Le 27/04/2012 20:28, Keith Thompson a écrit :
> Lanarcam<> writes:
>> Le 27/04/2012 12:31, James Kuyper a écrit :
>>> On 04/26/2012 10:32 PM, Eric Sosman wrote:
> [...]
>>>> If you're looking for a language with seat belts, training
>>>> wheels, airbags, and padded walls, C shouldn't be your first
>>>> choice, and restrictions on arithmetic wouldn't change matters.
>>>
>>> A C-like language with few more barriers between conceptually distinct
>>> things like numbers, characters, and bools than C has, would make it
>>> slightly easier to avoid writing nonsense. Those barriers wouldn't cause
>>> the loss of any truly valuable characteristic of C.
>>
>> I think you mean ADA.
>
> I think *you* mean Ada (the name is not an acronym).
>
> But one could have a C-like language with fewer implicit conversions
> without going as far as Ada, which doesn't even have implicit
> conversions between otherwise identical integer types.
>
> I can imagine a C-like language with, say, the following features:
>
> - C-like implicit conversions among all numeric types, signed, unsigned,
> and floating-point -- or maybe only allow implicit conversions within
> each of the three kinds of numeric types (yes, I'm ignoring _Complex
> for now)
>
> - bool is treated as a scalar but non-numeric type
>
> - Each enumerated type is treated as a scalar but non-numeric type
> (bool could be a special-case enumerated type, with false and true as
> enumerated constants)
>
> - No implicit conversions between numeric and non-numeric types (but
> casts work as in C)
>
> - 0 is not a null pointer constant; instead, there's a keyword (say,
> "nil") that is the language's *only* null pointer constant
>
> - Relational and equality operators yield bool results
>
> - Contexts that require conditions (if, for, while, do-while, !,&&, ||,
> ?:, and whatever else I've forgotten) require a bool expression
>
> Some implications:
>
> - The NULL macro is unnecessary, and is replaced by the nil keyword.
>
> - You'd have to write "if (num != 0)" rather than "if (num)".
>
> - You'd have to write "if (ptr != nil)" rather than "if (ptr)".
>
> - There are undoubtedly more implications that would have to be worked
> out.
>
> This hypothetical language would be closer to Ada than C is, but
> it's still much closer to C than it is to Ada. Think of a scale
> with C at 0, Ada at 1, and this language at perhaps 0.05 or 0.1.
>
> I do not suggest for a moment that C itself should be changed like this.
> It would break almost all existing C code, and that's clearly unacceptable.
>
> But personally, I think I'd like it a little better than I like C. (And
> if I ever actually invented such a thing, I'd probably also clean up the
> treatment of arrays and pointers.)
>
I agree, one could think also of C + MISRA, the coding standard for
safety devices in automotive with many restrictions that try to avoid
the unsafety of C.