Re: [pdf-devel] Programming conventions doubts

[jemarch]

   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?

Look in pdf_base.h (file intended to be included by any other header
file):

#ifdef HAVE_INLINE
#define INLINE inline
#else
#define INLINE
#endif /* HAVE_INLINE */

autoconf (via HAVE_INLINE in config.h) already tell us if the compile
does support the inline keyword. So yes, all the inline qualifiers
should be subst with INLINE.

   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.

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.

   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.

In fact it is temporal. I am pondering with Brian Cough the
convenience of using the GNU Scientific Library, that provides
convenient vector and matrices implementations.

   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.

The codebase is still small and we are few developers (I am alone
writing code in a continous way). Lets wait for more interested
developers before to write such a guide. Right now it would be a waste
of time.

-- 
Jose E. Marchesi  <address@hidden>
                  <address@hidden>

GNU Spain         http://es.gnu.org
GNU Project       http://www.gnu.org