1. Forum
  2. Usenet
  3. COMP.LANG.C

  • Re: What is your opinion about init_malloc?

    From Richard Heathfield@21:1/5 to wij on Fri Mar 14 16:50:18 2025
    On 14/03/2025 16:31, wij wrote:
    On Fri, 2025-03-14 at 17:13 +0100, Bonita Montero wrote:
    Am 14.03.2025 um 16:56 schrieb wij:

    If it tries to exceed 'High level assembly', it could be ridiculous.
    Same as C++, if it tries to be 'not-C'.

    Thiago wants to mimic construction with new,

    I've been wondering how C would mimic ctor/dtor for long long time,...

    void * init_malloc(size_t size, void * src) looked reasonable, and
    may be necessary in 'my assembly model'.

    Why not pass it a constructor function as well? Something like:

    void * init_malloc(void *src,
    size_t size,
    int(*ctor)(void *, const void *))
    {
    void *p = malloc(size);
    if(p)
    {
    if(ctor != NULL)
    {
    if((*ctor)(p, src) == CTOR_FAIL)
    {
    free(p);
    p = NULL;
    }
    }
    else
    {
    memcpy(p, src, size);
    }
    }
    return p;
    }

    This way, you can do a "deep copy" instead of a naive bit blit,
    and one init_malloc fits all because you just write a new
    constructor for each type that needs one and pass a NULL
    constructor when a bit blit suffices.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Thiago Adams on Fri Mar 14 20:06:08 2025
    On 2025-03-14, Thiago Adams <thiago.adams@gmail.com> wrote:
    What is your opinion about init_malloc?
    One problem it solves it to initialise a const objects on heap.

    I don't think it's that useful, because I would rather write a
    type-specific allocating constructor:

    struct Mail *Mail_alloc(int id) { /* ... you know what goes here ... */ }

    No games with macros and struct literals that we hope the
    compiler optimizes away.

    What can be useful is a strdup-like function for duplicating an existing binary object (i.e. that was not just created and initialized in automatic storage just for this purpose):

    void *memdup(const void *mem, size_t size);

    which is like your init_malloc what you have as the basis of the macros.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to Thiago Adams on Sat Mar 15 09:02:33 2025
    Thiago Adams <thiago.adams@gmail.com> writes:

    What is your opinion about init_malloc?
    One problem it solves it to initialise a const objects on heap.

    #include <stdlib.h>
    #include <string.h>
    #include <stdio.h>

    void * init_malloc(size_t size, void * src)
    {
    void * p = malloc(size);
    if (p) {
    memcpy(p, src, size );
    }
    return p;
    }

    #define ALLOC(OBJ) ((typeof(OBJ)*) init_malloc(sizeof(OBJ), &(OBJ)))

    ////////// SAMPLE //////////

    struct Mail {
    const int id;
    };

    int main () {
    struct Mail* p0 = ALLOC((struct Mail){.id= 1});

    struct Mail* p1 = init_malloc(sizeof *p1, &(struct Mail){.id= 1});

    auto p2 = ALLOC((struct Mail){.id= 1});

    }

    Some facility along these lines looks like it would be useful, but
    in terms of what is shown here the implementation is ugly and the
    interface is poorly chosen. For starters the initializing function
    should be for internal use only, so all client use is through some
    higher-level macro interface. Also the interface name ALLOC is a
    terrible choice.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to Kaz Kylheku on Sat Mar 15 09:11:36 2025
    Kaz Kylheku <643-408-1753@kylheku.com> writes:

    On 2025-03-14, Thiago Adams <thiago.adams@gmail.com> wrote:

    What is your opinion about init_malloc?
    One problem it solves it to initialise a const objects on heap.

    I don't think it's that useful, because I would rather write a
    type-specific allocating constructor:

    struct Mail *Mail_alloc(int id) { /* ... you know what goes here ... */ }

    This idea is exactly backwards. It means writing a constructor
    function for every different type, and most types don't need one.
    For those types that would benefit from a type-specific constructor,
    it's easy to fabricate such functions on top of a single underlying
    allocation scheme.

    No games with macros and struct literals that we hope the
    compiler optimizes away.

    Constructors for structs are likely to use compound literals
    internally anyway. There is very little overhead to "optimize
    away", and beside that the overhead is likely to be negligible in
    comparison to the cost of calling malloc().

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)