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
