on not casting malloc

Discussion in 'C++' started by Jordan Abel, Feb 17, 2006.

  1. Jordan Abel

    Jordan Abel Guest

    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 */
     
    Jordan Abel, Feb 17, 2006
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, Feb 17, 2006
    #2
    1. Advertising

  3. Jordan Abel

    Jordan Abel Guest

    On 2006-02-17, Victor Bazarov <> 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++.
     
    Jordan Abel, Feb 17, 2006
    #3
  4. Jordan Abel

    Ben Pope Guest

    Jordan Abel wrote:
    > On 2006-02-17, Victor Bazarov <> 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...
     
    Ben Pope, Feb 17, 2006
    #4
  5. Ben Pope wrote:
    > Jordan Abel wrote:
    >
    >> On 2006-02-17, Victor Bazarov <> 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
     
    Victor Bazarov, Feb 17, 2006
    #5
  6. Jordan Abel wrote:
    > On 2006-02-17, Victor Bazarov <> 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
     
    Victor Bazarov, Feb 17, 2006
    #6
  7. Jordan Abel

    peter koch Guest

    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 <> 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
     
    peter koch, Feb 17, 2006
    #7
  8. 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 <> 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
     
    Victor Bazarov, Feb 17, 2006
    #8
  9. Jordan Abel

    Jordan Abel Guest

    On 2006-02-17, Victor Bazarov <> wrote:
    > Jordan Abel wrote:
    >> On 2006-02-17, Victor Bazarov <> 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.
     
    Jordan Abel, Feb 17, 2006
    #9
  10. Jordan Abel

    Jordan Abel Guest

    On 2006-02-17, Victor Bazarov <> 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 <> 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.
     
    Jordan Abel, Feb 17, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John
    Replies:
    13
    Views:
    734
  2. ravi
    Replies:
    0
    Views:
    481
  3. Peter
    Replies:
    34
    Views:
    2,054
    Richard Tobin
    Oct 22, 2004
  4. Johs32

    to malloc or not to malloc??

    Johs32, Mar 30, 2006, in forum: C Programming
    Replies:
    4
    Views:
    342
    Captain Winston
    Mar 30, 2006
  5. kj

    to malloc or not to malloc?

    kj, Jun 4, 2009, in forum: C Programming
    Replies:
    5
    Views:
    316
Loading...

Share This Page