opaque types without malloc?

[Ark Khasin]

I'd like to have something functionally equivalent to, say,
void make_it_happen( void)
{
struct T t;
for(start(&t); !done(&t); doit(&t));
}
The function has no business knowing what's inside struct T; it just
provides a "holder". Ideally, I'd say e.g.
struct T;
to pass an incomplete type, but that's not enough for instantiation of t.
A dynamic-memory-allocation-inspired scheme like
void make_it_happen( void)
{
struct T *p = start_newT();
for(; !done(p); doit(p));
free(p);
}
is not an option on a small (embedded) target, not to mention the overhead.

Is there a clever way not to drag around the complete definition of
struct T but still be able to create a holder and point to it as to
struct T* ?

Likewise, is there a clever compile-time constant equivalent to
sizeof(struct T), all without exposing complete definition.

[I suspect both are silly questions, but I'd take my chances.]

Thank you,
--
Ark

[Richard Heathfield]

Re: opaque types without malloc?

Ark Khasin said:

<snip>

Is there a clever way not to drag around the complete definition of
struct T but still be able to create a holder and point to it as to
struct T* ?

Not as far as I'm aware, but there may be an easy way.

Your problem seems to be that you can't afford malloc. Well, you *have*
to be able to afford the object itself, so why not make it a static
object in the module that knows about struct Ts:

static struct T t;

struct T *get_T(void)
{
return &t;
}

Or, if you feel so inclined:

static struct T t[MAX_T];

with all the gubbins involved in providing controlled access to the
members of that array.

Likewise, is there a clever compile-time constant equivalent to
sizeof(struct T), all without exposing complete definition.

Not as far as I know.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Re: opaque types without malloc?

Ark Khasin wrote:

>

.... snip ...

>
Is there a clever way not to drag around the complete definition
of struct T but still be able to create a holder and point to it
as to struct T* ?

It's not especially clever, but it works. Use pointers, and let
the module that knows about the struct T do the mallocing. For an
example, see hashlib.zip, and the way of assigning the basic hash
table in hshinit(), at <http://cbfalconer.home .att.net/download/>

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>



--
Posted via a free Usenet account from http://www.teranews.com

[Richard Tobin]

Re: opaque types without malloc?

In article <eRpGi.4368$Z33 .1218@trndny08> ,
Ark Khasin <akhasin@macroe xpressions.comw rote:

>I'd like to have something functionally equivalent to, say,
>void make_it_happen( void)
>{
> struct T t;
> for(start(&t); !done(&t); doit(&t));
>}
>The function has no business knowing what's inside struct T; it just
>provides a "holder". Ideally, I'd say e.g.
> struct T;
>to pass an incomplete type, but that's not enough for instantiation of t.

It can't be an incomplete type, or you wouldn't be able to declare an
instance of it. Perhaps we can arrange for a complete type that is
nonetheless useless. So you need a way to declare something whose
memory is suitable for storing a struct T in. It needs to be the
right size, and have the right alignment.

Just declaring a struct containing char dummy[N], where N is the size
of the real struct, won't necessarily work because of the alignment.
Is a structure guaranteed to have the alignment of its first member?
(That's not a rhetorical question.) If so, you could declare the
"opaque" type as having a first member the same type as the real one,
and the right number of padding bytes after it.

Of course you'll have to count the determine the size by hand for each
platform if you don't want the "real" type to be visible, as it would
have to be to use it with sizeof().

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.