RE: header locations and things.

[Stephane Peter <Stephane.Peter@linux-france.com>]

On 03-May-98 Adrian Ratnapala wrote:
> 
> ISSUE 1:  HEADER LOCATIONS.
> 
> So far we have been assuming that PenguinPlay header's should
> go in some directory which is in the header search path of
> the user.  Wouldn't it be cleaner to have an include/PenguinPlay
> directory.
> 
> i.e Users would do
> 
>#include <PenguinPlay/SomeHeader.h>
> 
> rather than just
> 
>#include <SomeHeader.h>
> 
> A quick disicion on this would be nice, so that I can change
> my own sources before putting them into the CVS tree.

Hum, why not. After all, this is more of an installation issue (I mean when the
user does a "make install" to install the libraries and headers). It's not
really important to compile anything within the same subdirectories I think...

> ISSUE 2:  Pointers vs. References
> 
> When designing a C++ API we get to chose between pointers and
> referances when we do call-by-value.  It is important to have
> some consistent logic throught the whole of pPlay as to what
> we choose.
> 
> Most API designs I've seen use referances as much as possible.
> But I elected to go for pointers since there are some situations
> in which I can't use references at all, so using pointers throught
> gives a more consistent interface.  Also I found I needed fewer
> * and & operators when I switched from references to pointers.
> 
> So my opinion is to use pointers even in cases where references would
> look more elegant, but those are just my thoughts.  What does everyone
> else think?

I'd rather say that we should use references whenever possible, and pointers
elsewhere. After all, references are just some hidden pointers ;). If you want
to make C++ programs, then do *clean* C++ :-)



-------------------------------------------------
           Stephane Peter - ESSI 2
       French Computer Science Student
    e-mail: Stephane.Peter@linux-france.com
   IRC: MEGASTeP   http://www.essi.fr/~speter/
-------------------------------------------------
linux linux linux linux linux linux linux linux