[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] Programming conventions doubts
From: |
jemarch |
Subject: |
Re: [pdf-devel] Programming conventions doubts |
Date: |
Wed, 12 Sep 2007 02:04:26 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.1.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) |
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