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)

On 2025-03-14, Thiago Adams <[email protected]> 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)

Thiago Adams <[email protected]> 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)

Kaz Kylheku <[email protected]> writes:

On 2025-03-14, Thiago Adams <[email protected]> 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)