<sean@f4.ca> wrote in message news:c9q3ht$rst$1@digitaldaemon.com...
> In article <c9orb9$1uc9$1@digitaldaemon.com>, Matthew says...
> >
> >Do you mean the STLSoft null? If so, cool! :) If not, what do you mean? :)
>
> I haven't seen the STLSoft null, but maybe I should wait for it :)  I saw a templatized version that IIRC Scott Meyers wrote and perhaps one other.

It's been in there for a couple of years! Look at stlsoft_null.h and stlsoft_nulldef.h. It works perfectly with 26 different compilers, enforcing that NULL is only ever copied to, or compared with, a pointer.

It's one of my favourite inventions, and has discovered hundreds of errors since I've been using it. I might humbly say that less than 20 of those were in my own code; the rest were in  library code from many famous vendors, but self-preservation prevents me from saying who. (They include companies with very large budgets, and *very* large user bases.)

It's all covered in chapter 15 of "Imperfect C++". I don't know if I've mentioned it before, but I've recently written a book ...

Rita the Repeater

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

-----------------------------------------------------

>
> It's all covered in chapter 15 of "Imperfect C++". I don't know if I've
mentioned
> it before, but I've recently written a book ...
>

Stop teasing, 3 months is a long time to wait..... :P

In article <c9ln6r$du0$1@digitaldaemon.com>, Matthew wrote:
> As you well know, from reviewing "Imperfect C++", I think C/C++ have made a grave
> mistake by not prescribing that sizeof(bool) == sizeof(int), and why compiler
> manufacturers have "utilised" that missing prescription to blunder and defined
> sizeof(bool) == 1.

Is it bad that sizeof(bool) == 1?

What should the size of bool be? The size of machine word? Byte is the minimal addressable element, so it would be logical to use it, right?

There are char, short, and byte as well...

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

In article <c9mi5r$1kiu$1@digitaldaemon.com>, Walter wrote:
> And of course, I think the way I wrote it is clearer <g>.

I suppose there's nothing wrong defining implicit casts from bool to int.

After all, we have casts from int to float as well. Even from char to int!

However, if int is implicitly castable to bool, then the infamous "while (x = 1) { ... }" raises its ugly head.

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

If I understand correctly, Walter is adamant about retaining the present boolean philosophy because it gives him the speed and flexibility he wants, it looks and smells like C, and besides, he probably doesn't want to make any changes.

I think it's also a fair statement that many of the users are equally adamant that any programming language must be type-safe with regard to conditional statements, that a conditional statement should therefore require a boolean expression, and that there should only be one boolean type, which must have an obvious name.

I don't think we can convince Walter about the language requirements, but presumably he is sensitive to the need to accommodate users' requirements.

There is a simple compromise that should satisfy everyone.  I strongly suggest a boolean type, called "boolean" or "bool", which is defined as part of the language.  Use of a nonboolean expression in a conditional statement should draw a mandatory compiler warning.

A compromise is probably the only way to fix the problem, under the circumstances.  So what do you say, Walter?  You always said this is a practical language, not for purists.  How much more practical can you get, to simultaneously satisfy both the machine-language types and those who demand type safety?