«

We have a system of small objects in the lines of

typedef struct {
...
} text_object;

And we have a "object master" that serves as a container for
several of these small objects, in the lines of

typedef struct {
...
text_object *text;
media_object *media;
...
} object_master;

Now, we need a generic/polymorphic way to initialise the small objects
as the initialisation is similar for all of them. I would like to use
inlined functions instead of macros for that, but currently don't see
any natural, clean way for it. A pseudo-implementation with a macro
(ALLOC_OBJ) is provided below.

Any ideas for converting that macro to an inline function?

my_error alloc_text(object_master *om, params* pms)
{
my_errcode err = 0;
text_object *to;
ALLOC_OBJ(om, to, textobj, TEXT_OBJECT_TYPE, pms);
return err;
}

my_error alloc_text(object_master *om, params* pms)
{
my_errcode err = 0;
media_object *mo;
ALLOC_OBJ(om, mo, mediaobj, MEDIA_OBJECT_TYPE, pms);
return err;
}

#define ALLOC_OBJ(objmaster, gen_obj, gen_obj_field, gen_obj_type,
params)
{
my_ASSERT(obj != NULL);
my_ASSERT(params != NULL);

gen_obj = my_malloc(sizeof(*gen_obj));
if (! gen_obj)
return ERR_OOM;

my_memset(gen_obj, 0, sizeof(*gen_obj));

gen_obj->module = my_module_find(params);
if (! gen_obj->module) {
err = ERR_MISSING_MODULE;
goto out_free_gen_obj;
}
if (my_typeof(gen_obj->module) != gen_obj_type) {
err = ERR_WRONG_MODULE;
goto out_free_gen_obj;
}

err = gen_obj->module->mod_init(gen_obj, params);
if (err)
goto out_free_gen_obj;

goto out;

out_free_gen_obj:
my_memset(gen_obj, 0, sizeof(*gen_obj));
my_free(gen_obj);
gen_obj = NULL;

out:
/* especially rigorous w/o a macro */
objmaster->gen_obj_field = gen_obj;
}

wrote:
> We have a system of small objects in the lines of
>
> typedef struct {
> ...
> } text_object;


You're trying to emulate C++, the best way is to use a plugin model.
Prepare structures that have the address of functions that do init,
deinit, etc. Then just call through them.

Tom

Tom St Denis wrote:
> wrote:
> > We have a system of small objects in the lines of
> >
> > typedef struct {
> > ...
> > } text_object;
>
>
> You're trying to emulate C++, the best way is to use a plugin model.
> Prepare structures that have the address of functions that do init,
> deinit, etc. Then just call through them.
>
> Tom

I'm sorry, but this is too vague. I can't see how function pointers can
help in this case. ALLOC_OBJECT() is the problem, as it's generic. No
use of making it a "member function" by a function pointer as there is
nothing object-specifc going on, only identifiers/types change.

Can you perhaps bring an example?

wrote:
> I'm sorry, but this is too vague. I can't see how function pointers can
> help in this case. ALLOC_OBJECT() is the problem, as it's generic. No
> use of making it a "member function" by a function pointer as there is
> nothing object-specifc going on, only identifiers/types change.
>
> Can you perhaps bring an example?

http://libtomcrypt.com

That entire library is pluggable. For instance, my HMAC message
authentication code ... er source code [hehehe] doesn't know what hash
you are using. Doesn't know how the hash even works. Just knows it
can call certain functions to handle the message being hashed.

Similarly my Public Key code has no clue how your bignum math is done
[I support three different math libraries, each with their own bignum
data types, init/deinit functions, etc].

etc, etc, etc.

You're just giving up too easily.

Tom

Tom St Denis wrote:
> wrote:
> > I'm sorry, but this is too vague. I can't see how function pointers can
> > help in this case. ALLOC_OBJECT() is the problem, as it's generic. No
> > use of making it a "member function" by a function pointer as there is
> > nothing object-specifc going on, only identifiers/types change.
> >
> > Can you perhaps bring an example?
>
> http://libtomcrypt.com
>
> That entire library is pluggable. For instance, my HMAC message
> authentication code ... er source code [hehehe] doesn't know what hash
> you are using. Doesn't know how the hash even works. Just knows it
> can call certain functions to handle the message being hashed.
>
> Similarly my Public Key code has no clue how your bignum math is done
> [I support three different math libraries, each with their own bignum
> data types, init/deinit functions, etc].
>
> etc, etc, etc.
>
> You're just giving up too easily.
>
> Tom

This is all elementary run-time polymorphism. This case is a little bit
different and I'm afraid you fail to see the point. Please look at the
initial post and give your own function version of OBJECT_ALLOCATE()
that works both with text_objects and media_objects if you want to help.

guillem...@gmail.com wrote:
> This is all elementary run-time polymorphism. This case is a little bit
> different and I'm afraid you fail to see the point. Please look at the
> initial post and give your own function version of OBJECT_ALLOCATE()
> that works both with text_objects and media_objects if you want to help.

Are you saying you're adding methods that aren't known at compile time?

Then just do variadic definitions and lookup by name...

func_int_t insert_int = myplugin->lookup(methodname);
insert_int(ID, blah, blah, blah);

I don't care to look at your example because I know that you can
emulate all basic functions of C++ with C structures.

You just have to rethink the approach. It won't always be as nice as
C++ [that's why they invented C++] but you can get the same job done
regardless.

Tom

Tom St Denis wrote:
> I don't care to look at your example because I know that you can
> emulate all basic functions of C++ with C structures.

Tom, why did you answer if you have nothing to say? I'll open another
thread, please don't answer there.

schrieb:
> We have a system of small objects in the lines of
>
> typedef struct {
> ...
> } text_object;
>
> And we have a "object master" that serves as a container for
> several of these small objects, in the lines of
>
> typedef struct {
> ...
> text_object *text;
> media_object *media;
> ...
> } object_master;
>
> Now, we need a generic/polymorphic way to initialise the small objects
> as the initialisation is similar for all of them. I would like to use
> inlined functions instead of macros for that, but currently don't see
> any natural, clean way for it. A pseudo-implementation with a macro
> (ALLOC_OBJ) is provided below.

You want templates for this, don't you? In C, you could use a structure,
that contains the common parts:

/* "common" or "base" object */
typedef struct
{
void* module;
} gen_object;

/* specific object */
typedef struct
{
void* module;
void* media_data;
} media_object;

my_error alloc_media(object_master *om, params* pms)
{
my_errcode err = 0;
media_object *mo;
/* ALLOC_OBJ(om, to, textobj, MEDIA_OBJECT_TYPE, pms); */
alloc_obj((gen_object**)&mo, sizeof *mo, MEDIA_OBJECT_TYPE, pms);
om->media = mo;

return err;
}

void alloc_obj(gen_object** obj, size_t size, int type, params* pms)
{
/* no error checking done */
*obj = my_malloc(size);

my_memset(*obj, 0, size);

(*obj)->module = my_module_find(params);

/* ... */
}

--
Thomas

Thomas J. Gritzan wrote:

> You want templates for this, don't you?

Exactly. I should have explicitly pointed that out.

> In C, you could use a structure,
> that contains the common parts:

Well, yes, but it is a little fragile. It seems it is safest to just
stick to the macro. Looks like templates are best emulated with macros,
even though macros are infamous. Like goto that is notoriously
ill-famed, but still useful for try/catch-like error handling. Any
objections?

Thanks for the example, it looks nice and does exactly what I wanted.
However, it seems the macro provides better compile-time safety as no
casts are involved and pointers retain their "identity". I hoped that a
function can be generically used without loosing pointer identity (i.e.
compiler knows the pointer type and hence the pointed-to struct size),
postponing the obvious though in the back of my mind --- it is
impossible. Well, it is impossible and I should not have started this
discussion at all.

wrote:
> Thomas J. Gritzan wrote:
>
> > You want templates for this, don't you?
>
> Exactly. I should have explicitly pointed that out.
>
> > In C, you could use a structure,
> > that contains the common parts:
>
> Well, yes, but it is a little fragile. It seems it is safest to just
> stick to the macro. Looks like templates are best emulated with macros,
> even though macros are infamous. Like goto that is notoriously
> ill-famed, but still useful for try/catch-like error handling. Any
> objections?
>
> Thanks for the example, it looks nice and does exactly what I wanted.
> However, it seems the macro provides better compile-time safety as no
> casts are involved and pointers retain their "identity". I hoped that a
> function can be generically used without loosing pointer identity (i.e.
> compiler knows the pointer type and hence the pointed-to struct size),
> postponing the obvious though in the back of my mind --- it is
> impossible. Well, it is impossible and I should not have started this
> discussion at all.

NO! You absolutely should have started the discussion. I enjoyed
reading the examples, so even if you didn't get exactly what you
wanted, me (and undoubtedly other thread lurkers) reaped some
benefit.

I was recently playing around with some similar ideas and
had hoped that typedef'ing the void * would generate a
compiler warning, but was unable to coerce any warnings. eg

typedef void * foo;
typedef void * bar;

void f(foo a) {return;}
void g(bar a) {return;}

int main(void)
{
foo a;
bar b;
f(b);
g(a);
return 0;
}

Does anyone know a compiler that will warn here? Better
yet, can I coerce a warning out of gcc?