Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > on not casting malloc

Reply
Thread Tools

on not casting malloc

 
 
Jordan Abel
Guest
Posts: n/a
 
      02-17-2006
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<typename T> static inline void free(T *x) {
free((void *)x);
}

template<typename 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 */
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      02-17-2006
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?

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


 
Reply With Quote
 
 
 
 
Jordan Abel
Guest
Posts: n/a
 
      02-17-2006
On 2006-02-17, Victor Bazarov <(E-Mail Removed)> 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++.
 
Reply With Quote
 
Ben Pope
Guest
Posts: n/a
 
      02-17-2006
Jordan Abel wrote:
> On 2006-02-17, Victor Bazarov <(E-Mail Removed)> 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++.


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...
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      02-17-2006
Ben Pope wrote:
> Jordan Abel wrote:
>
>> On 2006-02-17, Victor Bazarov <(E-Mail Removed)> 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++.

>
>
> Take a closer look at the bit Victor quoted.


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
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      02-17-2006
Jordan Abel wrote:
> On 2006-02-17, Victor Bazarov <(E-Mail Removed)> 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.

V
--
Please remove capital As from my address when replying by mail
 
Reply With Quote
 
peter koch
Guest
Posts: n/a
 
      02-17-2006
I believe (and sincerely hope) that Jordans hack was a means to ease
the porting of C-code.

Victor Bazarov wrote:
> Jordan Abel wrote:
> > On 2006-02-17, Victor Bazarov <(E-Mail Removed)> 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.
>

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


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


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      02-17-2006
peter koch wrote:
> I believe (and sincerely hope) that Jordans hack was a means to ease
> the porting of C-code.
>
> Victor Bazarov wrote:
>
>>Jordan Abel wrote:
>>
>>>On 2006-02-17, Victor Bazarov <(E-Mail Removed)> 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.
>>

>
> 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.


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

> If the
> purpose is to allow C++ code to call malloc, I agree that this is ugly
> and should be forbidden.
>
> /Peter


V
--
Please remove capital As from my address when replying by mail
 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      02-17-2006
On 2006-02-17, Victor Bazarov <(E-Mail Removed)> wrote:
> Jordan Abel wrote:
>> On 2006-02-17, Victor Bazarov <(E-Mail Removed)> 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.


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.
 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      02-17-2006
On 2006-02-17, Victor Bazarov <(E-Mail Removed)> wrote:
> peter koch wrote:
>> I believe (and sincerely hope) that Jordans hack was a means to ease
>> the porting of C-code.
>>
>> Victor Bazarov wrote:
>>
>>>Jordan Abel wrote:
>>>
>>>>On 2006-02-17, Victor Bazarov <(E-Mail Removed)> 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.
>>>

>>
>> 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.

>
> 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


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.

>
>> If the purpose is to allow C++ code to call malloc, I agree that this
>> is ugly and should be forbidden.


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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
to malloc or not to malloc? kj C Programming 5 06-05-2009 02:22 PM
to malloc or not to malloc?? Johs32 C Programming 4 03-30-2006 10:03 AM
Malloc/Free - freeing memory allocated by malloc Peter C Programming 34 10-22-2004 10:23 AM
free'ing malloc'd structure with malloc'd members John C Programming 13 08-02-2004 11:45 AM
Re: free'ing malloc'd structure with malloc'd members ravi C Programming 0 07-30-2004 12:42 PM



Advertisments