Re: About some understanding from a book

Tech-Archive recommends: Fix windows errors by optimizing your registry

On Thu, 12 Jun 2008 14:27:29 -0700, Chris Jobson <chris.jobson@xxxxxxxxxxxxxx> wrote:

[...] (you're required to define
both, but I expect you'd generally just have one call the other and invert
the result. Any other design could start to get confusing.

I just took a look at the spec out of interest, and it appears that the
"true" operator does not necessarily have to return the inverse of the
"false" operator.

Sure, that's what I implied, by writing "generally" rather than "this is always how it'd be done" (I forgot to close my paren, but whatever :) ). My point being that doing it in some other way could be confusing. That said, the DB example you give seems reasonable (I didn't notice it when I was looking at the spec). BUT! I by "reasonable" I just mean "justified". I still think the design itself would be more confusing, even in that example.

Section 11.4.2 of the spec shows a 3-valued type (database
boolean, which can be true, false or null) where operator true means
"definitely true" and operator false means "definitely false". Thus if the
value is null both operators return false. (I don't claim to understand the
logic behind this, but I have hopes that if I read it through a few more
times it will start to make sense!)

If I may:

The point would be that code that cared about "definitely true" would check for "true"-ness, while code that cared about "definitely false" would check for "false"-ness. I would guess that in most cases, it's not so much that you'd check for "false" from both operators, but that you'd have different code keying off of "true" results from either.

That said, that brings me back to my previous supposition about how the compiler would actually use those operators. In particular, in my mind you'd write code like:

if (myClass)
{
// something we do only when it's "definitely true"
}

if (!myClass)
{
// something we do only when it's "definitely false"
}

But this would rely on the compiler _always_ using the ! operator as an indicator to use the "false" operator instead of the "true" operator. I'd have to go back and look at the spec, but unless it _specifically_ say that the compiler is required to do this, then it's entirely possible a C# compiler could just ignore the "false" operator and just always invert the result of the "true" operator when faced with the ! operator.

In that scenario, the DB example would break, unless the compiler is mandated to behave in a specific way.

Maybe if I get interested enough, later I'll look at what the spec says about that. :)

Pete
.

Relevant Pages

  • Re: memcpy() where assignment would do?
    ... this declaration actually works on our compiler, ... this is not the most confusing part of the code. ... cr_file is the array containing that header. ... I'm assuming that he didn't have a valid reason for writing ...
    (comp.lang.c)
  • Re: memcpy() where assignment would do?
    ... this declaration actually works on our compiler, ... this is not the most confusing part of the code. ... code for both ways of writing it. ... plausible reason why the developer might write such bizarre code? ...
    (comp.lang.c)
  • Re: memcpy() where assignment would do?
    ... this declaration actually works on our compiler, ... this is not the most confusing part of the code. ... plausible reason why the developer might write such bizarre code? ... particular symbolic identification, so that the memory's addresses can be ...
    (comp.lang.c)
  • memcpy() where assignment would do?
    ... this declaration actually works on our compiler, ... this is not the most confusing part of the code. ... Am I missing something? ... plausible reason why the developer might write such bizarre code? ...
    (comp.lang.c)