Re: [pdf-devel] Programming conventions doubts

[raskolnikov]

Hi,

> It is a convenient way to get opaque types. Take a look to the
> pdf_obj_t structure, for example. It is complex, and its memory
> management requirements are not obvious. Just imagine you should
> deallocate a dictionary object containing other dictionaries and an
> array that in turn contain several PDF strings, and two PDF
> functions...
>
> BTW, it is not object-oriented programming, but abstract data types.

Well I know that it is not exactly OOP (no polimorphism there), I may
have referred to it as encapsulation or abstraction.

I actually was not against opaque types. My proposal was not against
encapsulation, or even against using dynamic memory inside the
constructor of an object. For example, we can have something like this:

typedef struct string_s
{
        char* cad;
        int used;
        int allocated;
} string_t;

void
string_create(string_t* s)
{
        memset(s, 0, sizeof(string_t));
}

void
string_create_lenght(string_t* s, int len)
{
        s->cad = xmalloc(len);
        s->used = s->allocated = len;
}

void
string_destroy(string_t* s)
{
        free(s->cad);
}

typedef struct hash_table_s
{
        string_t* table;
        int size;
        int (hash_func*) (string_t*)
} hash_table_t;

void
hash_table_create_size(hash_table_t* t, int size)
{
        int i;
        t->table = malloc(sizeof(string_t) * size);
        for (i = 0; i < size; i++)
                string_create(&t->table[i]);
        t->size = size;
        t->hash_func = &default_hash_func;
}

/*
 * You can imagine string_copy(), string_concatenate(),
 * hash_table_create(), hash_table_add(), hash_table_destroy(), etc...
 */

Sorry for such a big example, but I'm trying to explain with code what
it is harder to explain in a foreign language.

As you can see, you can malloc many things in a constructor, or call
other constructors that call malloc, etc.. But you don't call malloc for
the actual something_t, just for its contents.

My proposal just wanted to allow simple objects to follow the same
semantic conventions than the rest of the program without meaning
unnecessary mallocs.

For example:

>    I think that the most clear example of this is the pdf_point_t for
> me. Imagine that for any reason I need an array of 100000 points. It
> is quite probable that mallocating each point individually may cause
> a non-trivial overhead, as malloc is not the fastest function in the
> world.
>
> Obviously that type is not intended to be allocated in large
> quantities such as 100000. Allocate an array with a single xmalloc for
> that.

But then you can not use pdf_point_t. If you have some function taking
pdf_point_t arguments you'll need to convert your data to a
pdf_point_t, it is always better to have efficient pdf_point_t's if
there is no drawback.

I'm just saying that taking the created object as a reference
parameter in the 'create' functions instead of being the return value
may allow some simple types not to be dynamically allocated by default
and be more versatile.

I also read your other mail about 'inline', lots of thanks for fighting
my ignorance :)

Best,
JP