David R Tribble wrote:
> I find that very little of my code (perhaps less than 1%) requires
> explicit casts.  ...  Of course, in the rare cases where I do need
> a cast, I need it badly.

Right; excessive use of casts indicates a design problem or maybe
simple programmer ineptitude, but there are legitimate uses for
casts.

If C did not have implicit type conversions (which I disdain),
you'd see a lot more casts in typical code.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau wrote:
> You would be astonished if you were to do something like pull aside
> 40 random C or C++ programmers and ask them to
> 1) explain casting to you.
>    (most cannot)
> 2) explain when they would use it
>    (most popular answer: "We're not allowed to have warnings in our code")
> 3) explain why it is good.
>    (most popular answer: "I'm not sure, but it did seem ok...
>    though I still don't know what was wrong or why it works now,
>    it was all I could think of at the time")

Sounds like a problem in programmer education and training,
not in the language facility as such.  C's casts are really
very simple (just a conversion of the value from one type to
another), and an understanding of them is tantamount to an
understanding of C's type system, which one would think is
essential to effective C programming.

C was never intended to be used by incompetent programmers.
Attempts at languages for such "programmers" in the past have
either failed dismally or produced a language that was hard
to use to implement a wide variety of applications.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <199910291141.aa19359@blaze.arl.mil>,
Douglas A. Gwyn <gwyn@arl.mil> wrote:
>
>Sounds like a problem in programmer education and training,
>not in the language facility as such.  C's casts are really
>very simple (just a conversion of the value from one type to
>another), and an understanding of them is tantamount to an
>understanding of C's type system, which one would think is
>essential to effective C programming.
>
>C was never intended to be used by incompetent programmers.
>Attempts at languages for such "programmers" in the past have
>either failed dismally or produced a language that was hard
>to use to implement a wide variety of applications.

Oh, really!  C casts are syntactically trivial, I agree.  They are
semantically fairly straightforward, though there are a pretty fair
number of "gotchas" even for the arithmetic case - and some minor
differences between "K&R", C89 and C99.  But what is REALLY foul
is trying to work out exactly which pointer casts give defined
behaviour, and exactly what the resulting pointer value may be
used for.

In this sort of area, I have frequently pointed out obscurities in
the standard, and asked what it really means, and got several
CONFLICTING answers from different members of the C committee.
This indicates that it is NOT just incompetent programmers who
have trouble working out the rules.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

(attributions too confusing to fix across deletions)
> |> > ``If you lie to the compiler, it will get its revenge.''
> |>
> |> Casts are not "lying to the compiler".  Casts convert a value
> |> from one type to another.  The need for this arises frequently.

Casts are not "lying to the compiler", they are saying "I already lied
to you, here is the truth.".

It is much better to never have lied at all.

I'll admit that this is not always possible, but I find that avoiding
cases where casts are necessary reduces bugs & improves the
maintanability of the code.  Support programmers have to deal with the
lies also.

>
> C pointer casts are saying "I know precisely what I am doing and
> I have not made a mistake, so throw away almost all of your type
> checking."  If you were a mere mortal, like Konrad Schwarz and I,
> this statement would occasionally be false.
>

Yes, it is too easy to tell the compiler a second lie by mistake, and
force it to believe you, with much error checking turned off.

Darron

--
               @  @             Darron J Shaffer
           @         @          Sr. Software Engineer
        @             @         darron.shaffer@beasys.com
      @   #           @         Voice: (972) 943-5137
    @     #          @          Fax:   (972) 943-5111
   @      #         o
  @       ####   @@@  ####      BEA Systems Inc.
  @       #   # @   @     #     The E-Commerce Transactions Company
  @       #   # @@@@@  ####     4965 Preston Park Blvd, Ste 500
   @      #   # @     #   #     Plano, TX 75093
     @ @  ####   @@@   ####     http://www.beasys.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Douglas A. Gwyn" wrote:
>
> Konrad Schwarz wrote:
>> the more casts you write, the higher the chance of a error.
>
> Not in my experience.
>
>> Henry Spencer sums it up nicely:
>> ``If you lie to the compiler, it will get its revenge.''
>
> Casts are not "lying to the compiler".  Casts convert a value
> from one type to another.  The need for this arises frequently.

I find that very little of my code (perhaps less than 1%) requires
explicit casts.  Most of the cases where I do need them fall into
these general categories:

 1. Receiving a buffer of bytes and interpreting it as being
  composed of a header structure followed by fixed or variable
  length data.  This requires special considerations beyond casting,
  such as data alignment and byte ordering.

 2. Casting "non-standard" types in order to call library functions
  (such as casting 'unsigned char' arrays to 'char' to be passed
  to strlen().

 3. Expanding values within subexpressions to avoid bit loss (e.g.,
  casting int to long int within an expression to avoid truncation
  of high bits).

 4. Casting a generic void* pointer (that is stored in, say, a 3rd
  party structure) into its actual pointer type.

I find in particular that I don't need to cast between pointer
types (which is probably the most common use of casts) very much at
all.

Of course, in the rare cases where I do need a cast, I need it
badly.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <199910261042.aa24008@blaze.arl.mil>,
"Douglas A. Gwyn" <gwyn@arl.mil> writes:
|> Konrad Schwarz wrote:
|> > the more casts you write, the higher the chance of a error.
|>
|> Not in my experience.

Well, it is in mine, and in many other people's.  As has been posted
MANY times before, C pointer casts disable almost all type checking.

For example, when chasing through complex data structures, it is
very easy to write
    *(double *)structure.value
where what should have been written was
    *(double *)*(void **)structure.value

Algol 68 made a very similar error, and it was discovered to be a
BAD idea by the early 1970s.  Until C started to dominate language
design, few later languages made the same mistake.

|> > Henry Spencer sums it up nicely:
|> > ``If you lie to the compiler, it will get its revenge.''
|>
|> Casts are not "lying to the compiler".  Casts convert a value
|> from one type to another.  The need for this arises frequently.

C pointer casts are saying "I know precisely what I am doing and
I have not made a mistake, so throw away almost all of your type
checking."  If you were a mere mortal, like Konrad Schwarz and I,
this statement would occasionally be false.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>In article <199910261042.aa24008@blaze.arl.mil>, "Douglas A. Gwyn" <gwyn@arl.mil> writes:
>Konrad Schwarz wrote:
>> the more casts you write, the higher the chance of a error.
>
> Not in my experience.

If your niche is in something like writing device drivers, sure, I can
see you saying this.  But it you are talking about other people, say
doing business programming, then you are incorrect in general.

You would be astonished if you were to do something like pull aside
40 random C or C++ programmers and ask them to
1) explain casting to you.
   (most cannot)
2) explain when they would use it
   (most popular answer: "We're not allowed to have warnings in our code")
3) explain why it is good.
   (most popular answer: "I'm not sure, but it did seem ok...
   though I still don't know what was wrong or why it works now,
   it was all I could think of at the time")

(Yes, I've done the above actually about a dozen times.)

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Konrad Schwarz wrote:
> the more casts you write, the higher the chance of a error.

Not in my experience.

> Henry Spencer sums it up nicely:
> ``If you lie to the compiler, it will get its revenge.''

Casts are not "lying to the compiler".  Casts convert a value
from one type to another.  The need for this arises frequently.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> Thus the reason for omitting the explicit cast under C89 is no longer
> valid under C9X (although it is still legal).  So we have evolved to
> a position that it is once again a good idea to use the explicit cast.
> The fallout of this is that employing an explicit cast makes the code
> more compatible with C++.
There is a second reason: the function called may be wrong one.
Omitting the cast allows the compiler to alert the user when a type
error
occurs.
--
Konrad Schwarz  konrad_schwarz@mcdDOTmot.com
Motorola Computer Group
81829 M"unchen Schatzbogen 7  Tel: +49 89 92103 828
81809 M"unchen Postfach 820960  Fax: +49 89 92103 266
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Furnanz wrote:
>
> "David" == David R Tribble <david@tribble.com> writes:
>
> > Doug Gwyn (ISTD/CNS) wrote [in news:comp.std.c]:
> >>
> >> David R Tribble wrote:
> >>> There are many of us who believe that NULL should be restricted
> >>> to having only a pointer type.  Using NULL as a floatint point
> >>> value is just another in a long list of abominations allowed by
> >>> the wishy washy wording in the standard.
> >>
> >> It's certainly not allowed in a strictly conforming program!
> >>
> >> C++ folks argue that NULL should be 0, not ((void*)0).
>
> David R Tribble:
>> C++ is a whole 'nuther can of worms.  They argue for 0 for the simple
>> reason that the stricter typing rules of C++ don't allow ((void*)0)
>> to work as a generic null pointer constant.  Several of us have
>> argued (in news:comp.std.c++) that either ((void*)0) should be
>> allowed as a special case of a generic null pointer constant, or
>> that a 'null' keyword be added to the language.  As it stands now,
>> C++ has no real null pointer constant (using 0 comes closest, but it
>> leads to ambiguities since it's an integer constant).
>
> It is easy to define a constant called 'null' that works the way you
> expect, without adding a new keyword to the language.
>
> #ifndef _NULL_H
> #define _NULL_H
>
> // This guarantees that 'null' will be interpreted as a
> // null pointer, and not as an integer.
> const struct null_t {
>    null_t() {}
>    template<typename T> operator T*() const { return 0; }
> } null;
>
> #endif // _NULL_H

Yes, yes, this was also discussed at some length.  The problem is
that, while this works fine, it is not a blessed part of the standard,
and many of us feel that it should be.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <37FE21F2.D964E0E@tribble.com>, David R Tribble
> <david@tribble.com> writes
> >C, on the other hand, is a little more well-behaved in this regard.
> >It allows void pointers to be assigned to non-void pointers without
> >the need for an explicit cast.
>
> I am not sure how you classify this as 'more well behaved'.  IMHO it is
> an example of the holes in the C type system that make it ill-suited for
> use without proper coding tools & (enforced) conventions to catch
> dangerous or down right erroneous code.

A good type system is as unobtrusive as possible.  Each time a program
needs to resort to a cast, it punches a hole in the type system: a
compiler can and will not check across that cast.  However, writing
casts is in no way less error prone than writing any other sort of code;
the more casts you write, the higher the chance of a error.
Unfortunately,
the compiler cannot warn you in this case.  Henry Spencer sums it up
nicely:
``If you lie to the compiler, it will get its revenge.''

--
Konrad Schwarz  konrad_schwarz@mcdDOTmot.com
Motorola Computer Group
81829 M"unchen Schatzbogen 7  Tel: +49 89 92103 828
81809 M"unchen Postfach 820960  Fax: +49 89 92103 266


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:
> Neither language, by the way, has a "generic null function pointer
> constant".  (Remember that data pointers and function pointers are
> not compatible.)  This is sometimes a problem.

C99 6.3.2.3p3 says:
# If a null pointer constant is assigned to or compared for equality
# to a pointer, the constant is converted to a pointer of that type.

Why wouldn't this apply to function pointer types?  Or are you saying
you want a null function pointer constant *distinct* from a null
object pointer constant?


paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:

> C++ is a whole 'nuther can of worms.  They argue for 0 for the simple
> reason that the stricter typing rules of C++ don't allow ((void*)0)
> to work as a generic null pointer constant.  Several of us have
> argued (in news:comp.std.c++) that either ((void*)0) should be
> allowed as a special case of a generic null pointer constant, or
> that a 'null' keyword be added to the language.  As it stands now,
> C++ has no real null pointer constant (using 0 comes closest, but it
> leads to ambiguities since it's an integer constant).

The C++ standard is completely unambiguous.  You can argue that it
should be changed, but there's no doubt about what it says.

NULL is "an implementation-defined C++ null pointer constant" (18.1/4).

A null pointer constant is "an integral constant expression rvalue
of integer type that evaluates to zero" (4.10/1).

The integer types are (3.9.1/7) "bool, char, wchar_t, and the signed
and unsigned integer types".  The signed integer types are listed in
3.9.1/2, and the unsigned integer types in 3.9.1/3.  The complete list
is bool, char, wchar_t, signed char, short int, int, long int,
unsigned char, unsigned short int, unsigned int, unsigned long int.
The NULL macro must expand to a constant expression whose type is one
of the types on that list.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> David R Tribble <david@tribble.com> writes:
>> C, on the other hand, is a little more well-behaved in this regard.
>> It allows void pointers to be assigned to non-void pointers without
>> the need for an explicit cast.
>
> I am not sure how you classify this as 'more well behaved'.  IMHO it
> is an example of the holes in the C type system that make it
> ill-suited for use without proper coding tools & (enforced)
> conventions to catch dangerous or down right erroneous code.

On the contrary, it actually helps catch some typing errors in C
(C89 to be precise).  I know, I know, it's counterintuitive, but
consider the famous malloc example:

    Type *  p = (Type *)malloc(sizeof(*p));

Under C89, which allows undeclared functions to be invoked (without a
prototype in scope), malloc() will be implicitly declared as a
function returning int, and the explicit cast will hide this fact,
and the code will compiler without warning.  It may not execute
correctly, though (if pointers are returned differently than ints).
Removing the cast exposes the lack of a declaration for malloc(),
since the code is now attempting to assign an int to a pointer.

This entire line of reasoning goes away in C++, and C9X, though, for
the simple reason that neither allows implicit function declarations.

Thus the reason for omitting the explicit cast under C89 is no longer
valid under C9X (although it is still legal).  So we have evolved to
a position that it is once again a good idea to use the explicit cast.
The fallout of this is that employing an explicit cast makes the code
more compatible with C++.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>>>> "David" == David R Tribble <david@tribble.com> writes:

 David> Doug Gwyn (ISTD/CNS) wrote [in news:comp.std.c]:
 >>
 >> David R Tribble wrote:
 >>> There are many of us who believe that NULL should be restricted to
 >>> having only a pointer type.  Using NULL as a floatint point value
 >>> is just another in a long list of abominations allowed by the wishy
 >>> washy wording in the standard.
 >>
 >> It's certainly not allowed in a strictly conforming program!
 >>
 >> C++ folks argue that NULL should be 0, not ((void*)0).

 David> C++ is a whole 'nuther can of worms.  They argue for 0 for the simple
 David> reason that the stricter typing rules of C++ don't allow ((void*)0)
 David> to work as a generic null pointer constant.  Several of us have
 David> argued (in news:comp.std.c++) that either ((void*)0) should be
 David> allowed as a special case of a generic null pointer constant, or
 David> that a 'null' keyword be added to the language.  As it stands now,
 David> C++ has no real null pointer constant (using 0 comes closest, but it
 David> leads to ambiguities since it's an integer constant).

It is easy to define a constant called 'null' that works the way you
expect, without adding a new keyword to the language.


#ifndef _NULL_H
#define _NULL_H

// This guarantees that 'null' will be interpreted as a
// null pointer, and not as an integer.
const struct null_t {
   null_t() {}
   template<typename T> operator T*() const { return 0; }
} null;

#endif // _NULL_H
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Jarc wrote:
> David R Tribble <david@tribble.com> writes:
> > Neither language, by the way, has a "generic null function pointer
> > constant".  (Remember that data pointers and function pointers are
> > not compatible.)  This is sometimes a problem.
> C99 6.3.2.3p3 says:
> # If a null pointer constant is assigned to or compared for equality
> # to a pointer, the constant is converted to a pointer of that type.
> Why wouldn't this apply to function pointer types?  Or are you saying
> you want a null function pointer constant *distinct* from a null
> object pointer constant?

Function pointers certainly can be represented radically
differently from object (data) pointers, which is why
they're not guaranteed to be interconvertible.

However, you're right in noting that a "null pointer constant"
is a syntactic construct of indefinite type, and can be
safely assigned to or compared against a function pointer
as well as an object pointer.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <37FE21F2.D964E0E@tribble.com>, David R Tribble
> <david@tribble.com> writes
> >C, on the other hand, is a little more well-behaved in this regard.
> >It allows void pointers to be assigned to non-void pointers without
> >the need for an explicit cast.
>
> I am not sure how you classify this as 'more well behaved'.  IMHO it is
> an example of the holes in the C type system that make it ill-suited for
> use without proper coding tools & (enforced) conventions to catch
> dangerous or down right erroneous code.

All right, but if we plug "holes" of that sort, should we not outlaw
casts as well?  And if so, do we still have a C language (worth using,
that is)?
--
Tore Lund <tl001@online.no>
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Doug Gwyn (ISTD/CNS) wrote [in news:comp.std.c]:
>
> David R Tribble wrote:
>> There are many of us who believe that NULL should be restricted to
>> having only a pointer type.  Using NULL as a floatint point value
>> is just another in a long list of abominations allowed by the wishy
>> washy wording in the standard.
>
> It's certainly not allowed in a strictly conforming program!
>
> C++ folks argue that NULL should be 0, not ((void*)0).

C++ is a whole 'nuther can of worms.  They argue for 0 for the simple
reason that the stricter typing rules of C++ don't allow ((void*)0)
to work as a generic null pointer constant.  Several of us have
argued (in news:comp.std.c++) that either ((void*)0) should be
allowed as a special case of a generic null pointer constant, or
that a 'null' keyword be added to the language.  As it stands now,
C++ has no real null pointer constant (using 0 comes closest, but it
leads to ambiguities since it's an integer constant).

C, on the other hand, is a little more well-behaved in this regard.
It allows void pointers to be assigned to non-void pointers without
the need for an explicit cast.  Hence ((void*)0) works quite well
as a generic null pointer constant in C, and is *the* logical choice
for the definition of NULL.  Allowing 0 and 0L to also be valid
definitions for NULL, i.e., allowing NULL to have a non-pointer type,
has no basis in reason, as far as I can tell, and just opens the
door to bad, and unportable, code.

I must point out that arguments for a better definition of NULL do
not preclude the continuation of the practice of using 0 for null.
We're not out to break a lot of old code; it's just that we'd like
to see new code be a little bit better.

Neither language, by the way, has a "generic null function pointer
constant".  (Remember that data pointers and function pointers are
not compatible.)  This is sometimes a problem.

All of this has been argued before, and neither the C nor the C++
committee appears to see any problem with the status quo, nor are
they willing to expend any effort to change it.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37FE21F2.D964E0E@tribble.com>, David R Tribble
<david@tribble.com> writes
>C, on the other hand, is a little more well-behaved in this regard.
>It allows void pointers to be assigned to non-void pointers without
>the need for an explicit cast.

I am not sure how you classify this as 'more well behaved'.  IMHO it is
an example of the holes in the C type system that make it ill-suited for
use without proper coding tools & (enforced) conventions to catch
dangerous or down right erroneous code.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]