How would you handle:
isSystemClosed = true;
You're getting into nasty looking/non-obvious code to use language-existing
features for an ability that 1) is fundamental to software and 2) should have
native support without kludges.
Many CPUs even support the write-back NOT of a flag condition natively. x86 has
the SETcc instructions, for example, which are native to this concept. ARM has
predicates. It is already there at the CPU level.
Best regards,
Rick C. Hodgin
-------- Original Message --------
From: James Dennett <james.denn...@gmail.com>
Sent: Thu, Jun 28, 2012 04:14 PM
To: Rick Hodgin <foxmuldrs...@yahoo.com>
CC: Jonathan Wakely <jwakely....@gmail.com>; gcc <gcc@gcc.gnu.org>
Subject: Re: Add corollary extension
>On Thu, Jun 28, 2012 at 12:39 PM, Rick Hodgin <foxmuldrs...@yahoo.com> wrote:
>>> Why do you want to bother with a non-standard,
>>> unportable extension instead of just writing:
>>>
>>> inline bool isSystemClosed()
>>> { return !isSystemOpen; }
>>>
>>> Which is simple, conventional, easy to understand
>>> and portable.
>>>
>>> Or in C++ just define a suitable type, instead of
>>> needing changes to the core language:
>>>
>>> struct inv_bool {
>>> bool& b;
>>> operator bool() const { return !b; }
>>> };
>>>
>>> inv_bool isSystemClosed = { isSystemOpen };
>>
>> There are certain fundamentals in data processing. The inverse bool is one
>> of them. Why not be able to reference it more naturally in code utilizing
>> something the compiler already knows about and can wield effortlessly?
>>
>> I've thought more about the syntax, and I see this making more sense:
>> bool isSystemOpen[!isSystemClosed];
>>
>> As the inverse bool relationship is fundamental in software, I hope this
>> will become a C/C++ standard.
>
>I really can't imagine that happening. As the logical not operation
>is fundamental, we already have notation for it. Why would we add the
>complexity of something that looks like a variable but acts like a
>function? In C++ you can already write
> auto isSystemOpen = [&isSystemClosed] { return !isSystemClosed; };
>and then use isSystemOpen(), without doing violence to variable
>notation. You can obscure that behind a macro in your own code if you
>wish, as in
> #define OPPOSITE(realVariable) (&realVariable] { return !realVariable; })
> auto isSystemOpen = OPPOSITE(isSystemClosed);
>but wanting to make something that's a function look like a variable
>isn't likely to get much traction in either language.
>
>-- James
