[pdf-devel] Programming conventions doubts

[raskolnikov]

Hi Marchesi,

I'm using a void hour in a public computer to snoop around the new changes
in the CVS. While reading them some questions about the programming style
used in the project arised.

The first thing that surprised me was the usage of the 'inline' keyword.
As fas as I know that is C99. However, when we were first checking my
predictors code you recommended me not to do things like initializing a
variable in the declaration to make very old compilers happy. Actually the
hole configure script and most of the projects code is made to be very
very cross-platform and very strict old C compliant, so this usage of the
inline keyword surprised me -I actually wanted to use it in a pair of
functions in the LZW but didn't for the above reasons.

So, my question is, can we use the inline keyword? Or why not do something
likethis:

#if HAVE_C99 == 1
# define _PDF_INLINE inline
#else
# define _PDF_INLINE
#endif

..

_PDF_INLINE void inline_function()


My other question is related to the way of doing object-oriented coding in
C. As far I've seen in the code, you define every object-oriented type is
the code is a pointer to something and the object is constructed via:

something_t obj;
obj = create_something(); /* This calls xmalloc() and initializes */

Maybe I'm wrong -You probably started programming before I was born!-, but
in my opinion, this causes to much coupling between the memory allocation
and the object initilization, and leaves the user of the object with no
oportunity to get the object allocated in the stack instead of the heap.

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.

For that reason, whenever doing object-oriented C I prefer to create a
function like this:
void something_constructor(something_t* sth);

In this way, a something_t may or may not be a pointer. Now you have many
new ways to implement, for example, the pdf_point_t in a more efficient
way:

typedef pdf_real_t float;

typedef pdf_real_t pdf_point_t[2];

#define P_X(p) (p)[0]
#define P_Y(p) (p)[1]

_PDF_INLINE void
pdf_point_constructor(pdf_point_t* p)
{
  P_X(*p) = P_Y(*p) = 0.0;
}

This convention of defining the constructor also allows you to allocate
the object in the constructor:

typedef pdf_real_t* pdf_point_t;

_PDF_INLINE void
pdf_point_constructor(pdf_point_t* p)
{
  *p = xmalloc(sizeof(pdf_real_t) * 2);
  P_X(*p) = P_Y(*p) = 0.0;
}

So I think it is more generic and adaptable. Maybe I'm wrong or I'm just
"haciendome pajas mentales", I just wanted to understand the why of each
design decision now that I've planned to collaborate more in the future.

Actually, now that the project has high priority in the GNU project and
more people are willing to collaborate, maybe it's time to write some
notes or coding guidelines with these details that are not in the GNU
Coding Standards so people can get used to the code faster and start
writing more useful patches.

Best,
JP