Re: [RFC] Fixes to bootstrap from a C++ compiler (part 1)

["Gabriel Dos Reis" <gdr at acm dot org>]

You Wrote Daniel Jacobowitz
> On Fri, Jun 25, 2004 at 09:27:55PM +0200, Gabriel Dos Reis wrote:
>> Mark Mitchell:
>>
>> > Well, how do people feel about this?  Is it good to rely on C's
>> implicit
>> > conversion between "void *" and other pointer types, or is OK to
>> insert
>> > casts necessary to satisfy the more restrictive C++ rule (where
>> pointer
>> > types implicitly convert to "void*" or not vice versa)?
>>
>> First of all, we should not be manipulating that many void* in the
>> first place -- if we do, that means we have serious abstraction
>> problem we should fix.  Second, I believe we should insert the
>> appropriate cast even if we know that it is unnecessary by
>> C90 rules.
>
> There's no abstraction involved.  This is the return value of xmalloc.

The point is that we should have appropriate macro to
allocating n Ts.

>>
>> I'm on the same page as you.  It is a hole in the type system
>> the C committee introduced for I don't know exactly why.  I see
>> the implicit conversion void* -> T* a highly spurious programming
>> style.  I would definitely recommend against it.
>
> In C++, you have new and delete, which have "magic" behavior in this

In C++, the allocator function of choice is operator new() and
it returns void*; but we rarely use it directly.  Rather, we
tend to hide it behind appropriate abstractions:  new-expressions
are the ones directly provided by the language.  But users can
have their own allocators, too, that they define to return
appropriate pointer types without having to spingle casts everywhere.

> area.  When you use other memory allocators, the collection of
> otherwise unnecessary casts gets a bit old.

Only if you fail to use appropriate abstraction.  For example,
there is no need to springle casts if you use std::allocator<T>.
You can also define your own allocator with same property.

Abstractions are our friend.

-- Gaby