on not casting malloc

[Jordan Abel]

Was wondering what people think of this header file:

#ifdef MALLOC_H
#define MALLOC_H
# ifdef __cplusplus
# include <cstdlib>

struct voidptr_ {
void *x;
template <typename T> inline operator T * () {
return ((T *) x);
}
};

static inline voidptr_ malloc_(size_t n)
{
return (voidptr_) {
malloc(n)
};
}

# define malloc(x) malloc_(x)

template<typena me T> static inline void free(T *x) {
free((void *)x);
}

template<typena me T> static inline T *realloc(T *x, size_t n) {
return (T *)realloc((void *)x,n);
}

# else /* C */
# include <stdlib.h>
# ifdef __GNUC__
# define realloc(p,s) ((__typeof__(p) )(realloc(p,s)) )
# endif /* GNU C */
# endif /* C++/C */
#define tcalloc(n,T) ((T*)(calloc(n, sizeof(T))))
#endif /* incl guard */

[Victor Bazarov]

Re: on not casting malloc

Jordan Abel wrote:[color=blue]
> Was wondering what people think of this header file:
>
> #ifdef MALLOC_H
> #define MALLOC_H
> [...][/color]

And how do you think it's going to benefit its user?

V
--
Please remove capital As from my address when replying by mail

[Jordan Abel]

Re: on not casting malloc

On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:[color=blue]
> Jordan Abel wrote:[color=green]
>> Was wondering what people think of this header file:
>>
>> #ifdef MALLOC_H
>> #define MALLOC_H
>> [...][/color]
>
> And how do you think it's going to benefit its user?[/color]

Allowing valid C code to compile as valid C++

Allowing one to use malloc/free [if you want to, who should stop you]
without breaking C style rules, yet still preserving the type-safety
that is allegedly the reason void * can't be implicitly converted in
c++.

[Ben Pope]

Re: on not casting malloc

Jordan Abel wrote:[color=blue]
> On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:[color=green]
>> Jordan Abel wrote:[color=darkred]
>>> Was wondering what people think of this header file:
>>>
>>> #ifdef MALLOC_H
>>> #define MALLOC_H
>>> [...][/color]
>> And how do you think it's going to benefit its user?[/color]
>
> Allowing valid C code to compile as valid C++
>
> Allowing one to use malloc/free [if you want to, who should stop you]
> without breaking C style rules, yet still preserving the type-safety
> that is allegedly the reason void * can't be implicitly converted in
> c++.[/color]

Take a closer look at the bit Victor quoted.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Victor Bazarov]

Re: on not casting malloc

Ben Pope wrote:[color=blue]
> Jordan Abel wrote:
>[color=green]
>> On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:
>>[color=darkred]
>>> Jordan Abel wrote:
>>>
>>>> Was wondering what people think of this header file:
>>>>
>>>> #ifdef MALLOC_H
>>>> #define MALLOC_H
>>>> [...]
>>>
>>> And how do you think it's going to benefit its user?[/color]
>>
>>
>> Allowing valid C code to compile as valid C++
>>
>> Allowing one to use malloc/free [if you want to, who should stop you]
>> without breaking C style rules, yet still preserving the type-safety
>> that is allegedly the reason void * can't be implicitly converted in
>> c++.[/color]
>
>
> Take a closer look at the bit Victor quoted.[/color]

Well, that's probably a simple typo. It's good that you've caught it,
but my question was in general, not about those particular two lines.

V
--
Please remove capital As from my address when replying by mail

[Victor Bazarov]

Re: on not casting malloc

Jordan Abel wrote:[color=blue]
> On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:
>[color=green]
>>Jordan Abel wrote:
>>[color=darkred]
>>>Was wondering what people think of this header file:
>>>
>>>#ifdef MALLOC_H
>>>#define MALLOC_H
>>>[...][/color]
>>
>>And how do you think it's going to benefit its user?[/color]
>
>
> Allowing valid C code to compile as valid C++
>
> Allowing one to use malloc/free [if you want to, who should stop you]
> without breaking C style rules, yet still preserving the type-safety
> that is allegedly the reason void * can't be implicitly converted in
> c++.[/color]

I believe that if you want to drive without buckling up, the car should
make noises about it and display the red warning light on the dashboard
that your seat belts are not engaged. What you're proposing is silencing
the warning sound signal and taping over the warning light with a piece of
duct tape. That's wrong. If somebody wants to use 'malloc' instead of
'new', they _should_ be required to also use the explicit cast.

V
--
Please remove capital As from my address when replying by mail

[peter koch]

Re: on not casting malloc

I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of C-code.

Victor Bazarov wrote:[color=blue]
> Jordan Abel wrote:[color=green]
> > On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:
> >[color=darkred]
> >>Jordan Abel wrote:
> >>
> >>>Was wondering what people think of this header file:
> >>>
> >>>#ifdef MALLOC_H
> >>>#define MALLOC_H
> >>>[...]
> >>
> >>And how do you think it's going to benefit its user?[/color]
> >
> >
> > Allowing valid C code to compile as valid C++
> >
> > Allowing one to use malloc/free [if you want to, who should stop you]
> > without breaking C style rules, yet still preserving the type-safety
> > that is allegedly the reason void * can't be implicitly converted in
> > c++.[/color]
>
> I believe that if you want to drive without buckling up, the car should
> make noises about it and display the red warning light on the dashboard
> that your seat belts are not engaged. What you're proposing is silencing
> the warning sound signal and taping over the warning light with a piece of
> duct tape. That's wrong. If somebody wants to use 'malloc' instead of
> 'new', they _should_ be required to also use the explicit cast.
>[/color]
I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of existing C-code. In that case I do find some value in
it, so long as it is not meant to be a permanent solution. If the
purpose is to allow C++ code to call malloc, I agree that this is ugly
and should be forbidden.

/Peter

[color=blue]
> V
> --
> Please remove capital As from my address when replying by mail[/color]

[Victor Bazarov]

Re: on not casting malloc

peter koch wrote:[color=blue]
> I believe (and sincerely hope) that Jordans hack was a means to ease
> the porting of C-code.
>
> Victor Bazarov wrote:
>[color=green]
>>Jordan Abel wrote:
>>[color=darkred]
>>>On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:
>>>
>>>
>>>>Jordan Abel wrote:
>>>>
>>>>
>>>>>Was wondering what people think of this header file:
>>>>>
>>>>>#ifdef MALLOC_H
>>>>>#define MALLOC_H
>>>>>[...]
>>>>
>>>>And how do you think it's going to benefit its user?
>>>
>>>
>>>Allowing valid C code to compile as valid C++
>>>
>>>Allowing one to use malloc/free [if you want to, who should stop you]
>>>without breaking C style rules, yet still preserving the type-safety
>>>that is allegedly the reason void * can't be implicitly converted in
>>>c++.[/color]
>>
>>I believe that if you want to drive without buckling up, the car should
>>make noises about it and display the red warning light on the dashboard
>>that your seat belts are not engaged. What you're proposing is silencing
>>the warning sound signal and taping over the warning light with a piece of
>>duct tape. That's wrong. If somebody wants to use 'malloc' instead of
>>'new', they _should_ be required to also use the explicit cast.
>>[/color]
>
> I believe (and sincerely hope) that Jordans hack was a means to ease
> the porting of existing C-code. In that case I do find some value in
> it, so long as it is not meant to be a permanent solution.[/color]

I am honestly disappointed that you would find "some value in it". If I
were to port existing C code, I would expect the C++ compiler to _scream_
at me for every use of 'malloc' so that I would be *forced* either to
change it to 'new' or at least put an explicit cast that can be searched
later and weeded out...

Of course, I can later search the code for 'malloc' and take care of it...

So the point is moot, I guess. Possibly it's just my knee-jerk reaction
to the original proposal
[color=blue]
> If the
> purpose is to allow C++ code to call malloc, I agree that this is ugly
> and should be forbidden.
>
> /Peter[/color]

V
--
Please remove capital As from my address when replying by mail

[Jordan Abel]

Re: on not casting malloc

On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:[color=blue]
> Jordan Abel wrote:[color=green]
>> On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:
>>[color=darkred]
>>>Jordan Abel wrote:
>>>
>>>>Was wondering what people think of this header file:
>>>>
>>>>#ifdef MALLOC_H
>>>>#define MALLOC_H
>>>>[...]
>>>
>>>And how do you think it's going to benefit its user?[/color]
>>
>>
>> Allowing valid C code to compile as valid C++
>>
>> Allowing one to use malloc/free [if you want to, who should stop you]
>> without breaking C style rules, yet still preserving the type-safety
>> that is allegedly the reason void * can't be implicitly converted in
>> c++.[/color]
>
> I believe that if you want to drive without buckling up, the car should
> make noises about it and display the red warning light on the dashboard
> that your seat belts are not engaged. What you're proposing is silencing
> the warning sound signal and taping over the warning light with a piece of
> duct tape. That's wrong. If somebody wants to use 'malloc' instead of
> 'new', they _should_ be required to also use the explicit cast.[/color]

While the reason for forbidding implicit conversion of pointer to void
in general has been explained to my satisfaction, the explanation I was
given does not justify having to do it for malloc in particular. Note
that I did not have realloc return a "voidptr_", and I went to some
effort to provide a reasonable solution for calloc also without doing
so.

[Jordan Abel]

Re: on not casting malloc

On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:[color=blue]
> peter koch wrote:[color=green]
>> I believe (and sincerely hope) that Jordans hack was a means to ease
>> the porting of C-code.
>>
>> Victor Bazarov wrote:
>>[color=darkred]
>>>Jordan Abel wrote:
>>>
>>>>On 2006-02-17, Victor Bazarov <v.Abazarov@com Acast.net> wrote:
>>>>
>>>>
>>>>>Jordan Abel wrote:
>>>>>
>>>>>
>>>>>>Was wondering what people think of this header file:
>>>>>>
>>>>>>#ifdef MALLOC_H
>>>>>>#define MALLOC_H
>>>>>>[...]
>>>>>
>>>>>And how do you think it's going to benefit its user?
>>>>
>>>>
>>>>Allowing valid C code to compile as valid C++
>>>>
>>>>Allowing one to use malloc/free [if you want to, who should stop you]
>>>>without breaking C style rules, yet still preserving the type-safety
>>>>that is allegedly the reason void * can't be implicitly converted in
>>>>c++.
>>>
>>>I believe that if you want to drive without buckling up, the car should
>>>make noises about it and display the red warning light on the dashboard
>>>that your seat belts are not engaged. What you're proposing is silencing
>>>the warning sound signal and taping over the warning light with a piece of
>>>duct tape. That's wrong. If somebody wants to use 'malloc' instead of
>>>'new', they _should_ be required to also use the explicit cast.
>>>[/color]
>>
>> I believe (and sincerely hope) that Jordans hack was a means to ease
>> the porting of existing C-code. In that case I do find some value in
>> it, so long as it is not meant to be a permanent solution.[/color]
>
> I am honestly disappointed that you would find "some value in it". If I
> were to port existing C code, I would expect the C++ compiler to _scream_
> at me for every use of 'malloc' so that I would be *forced* either to
> change it to 'new' or at least put an explicit cast that can be searched
> later and weeded out...
>
> Of course, I can later search the code for 'malloc' and take care of it...
>
> So the point is moot, I guess. Possibly it's just my knee-jerk reaction
> to the original proposal[/color]

Sometimes when interacting with existing libraries written in C, you
_need_ to use malloc/free instead of new/delete. Some library functions
will require something that can be realloc'ed internally, or will return
something that needs to be free'd.
[color=blue]
>[color=green]
>> If the purpose is to allow C++ code to call malloc, I agree that this
>> is ugly and should be forbidden.[/color][/color]

C++ code is already permitted to call malloc. This just provides a way
to do it without adding a cast that can hide warnings that are still
needed in C. It's certainly a better solution than defining a macro that
does the cast for you.