plib-devel

Re: [Plib-devel] C++ Philosophy Question

[Dave M. <dp...@ef...>]

I recently asked some related questions so i'll share what I know:

*** Naming conventions:

for public symbols in PLIB module 'XX' (where 'XX' is: SL, SSG, SG, PU, FNT):

#define's, enum tags                 XX_ALL_CAPITALS 
functions/classes/structs/typedefs   xxMixedCase

For private symbols, I use all_lowercase unless they would pollute
the name space - in which case I use a leading underscore _xxMixedCase

*** Dependencies

To use PLIB you need only GLUT, OpenGL and C++.
keeping more dependencies out of PLIB is a design goal

STL would just be another dependency
If you just need a list you can make it yourself
like the ssgVertexArray

*** templates, exceptions, references, operator overloading

like honey. icky sticky stuff.  can't see why pooh bears like it
once in a while it can be handy but
might as well keep it simple in a portable library like PLIB

*** namespaces

i like them. any thoughts?

RE: [Plib-devel] C++ Philosophy Question

[Paul B. <pbl...@di...>]

> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> 
> I'm told that STL will be a part of the C++ standard in
> the next revision of the ANSI spec - that means that it'll
> be usable in a couple of years when all the older compilers
> catch up.

STL is part of the ANSI C++ spec now.  The next revision will
include a number of clarifications on implementation of some
of the STL containers (like vector will be required to be
contiguous memory, etc...).

However, I agree with you that it is still not uniformly and
consistently supported without resorting to either crazy 
configuration macros and/or relying on a particular implementation
(i.e. sgi-stl, stlport, etc...)

Paul

Re: [Plib-devel] C++ Philosophy Question

[Bill W. <bil...@ch...>]

Well, I started this thread because I wanted to know what to stick to in coding for plib, and I appreciate the info.  I do have a few parting shots^H^H^H^H^Hthoughts on this, however.

(I've kind of mixed up Dave's and Steve's replies, sorry).

>> STL would just be another dependency
>> If you just need a list you can make it yourself
>> like the ssgVertexArray

Reinventing  (or reimplementing) the wheel?-

>
>So far, nothing in STL seems worth the hassle. There are
>still too many incompatible versions floating around out
>there - and systems that don't have it installed, etc.
>
>I watched the L-O-N-G thread that went on in the FGFS
>mailing list when STL was first used.  It convinced me
>that I can do without it.
>

There _are_ problems with STL across implementations (even using Visual C++ 6.0, you'd better be using Service Pack 3).  This is unfortunate, because you can write a lot of nice, concise code quickly using the STL containers.  I've come to like STL, but I agree that portability is a problem (which I sort of realized as soon as I posted the question).  Oh well...

>
>> *** templates, exceptions, references, operator overloading
>
>Well, some of these things are just eye candy. (eg Operator
>overloading) - some obfuscate code to a dangerous degree (eg
>References) - others are STILL not portable enough for my
>liking (Templates, exceptions).

I agree about exceptions (but preferable to unceremonious exits ;), templates can be OK if you stick to basics, references are more precise/less error prone than pointers when e.g. a function arg. or member cannot/should not be NULL (and cannot/should not be changed dynamically), and I think there are cases where not overloading operator = (or at least hiding it) for a class can cause trouble. 

> 
>> *** namespaces
>> 
>> i like them. any thoughts?

I suspect namespaces are (at least currently) a bit too subtle; I recall seeing some hair-raising examples of their potential for misuse in CUJ/C++ Report (one of those).  I'll try to dig them up if anyone's interested.

Anyway, that's it for religion, time to write some code.

Bill

Re: [Plib-devel] C++ Philosophy Question

[Steve B. <sjb...@ai...>]

Bill Weiland wrote:

> references are more precise/less error prone than pointers
> when e.g. a function arg. or member cannot/should not be
> NULL (and cannot/should not be changed dynamically)...

The thing I *really* dislike about ref parameters is that it's
possible to see this in the header for a library somewhere:

   void some_funtion ( int x ) ;

...you go and write code to use 'some_function' *knowing* for
sure that:

   x = 6 ;
   some_function ( x ) ;

*CANNOT* change the value of 'x'.

What's nasty about 'ref' arguments is that some subsequent
version of that library can change the parameter of
'some_function' to be 'ref' and then change the value of x
inside the function without the author of the application
code being aware that the libraries' policy has changed.
The old call to some_function still compiles!  Eeeekkkkk!

Also, I like to be able to look at some complex code
that uses 'some_function' and *know* that the parameter
isn't altered by the the function just by looking at the
call.  I don't even have to go off and read the manual
for 'some_function' in order to know that.

The nice thing about good old fashioned C-style pointers
is that when you see:


   x = 6 ;
   some_function ( & x ) ;

...that '&' shouts loudly to you to bear in mind that x may
well have been changed by the call.  If you don't see an '&'
then you don't need to know much about some_function in order
to see that it doesn't change 'x'.

That makes code MUCH more readable.

I think 'ref' is *EVIL* because its syntax doesn't make it
obvious.

> Anyway, that's it for religion, time to write some code.

Indeed.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] C++ Philosophy Question

[<Va...@t-...>]

Steve Baker wrote:
> 
> The thing I *really* dislike about ref parameters is that it's
> possible to see this in the header for a library somewhere:
> 
>    void some_funtion ( int x ) ;
> 
> ...you go and write code to use 'some_function' *knowing* for
> sure that:
> 
>    x = 6 ;
>    some_function ( x ) ;
> 
> *CANNOT* change the value of 'x'.

But you should have written then

  void some_function ( const int x );

instead. This showes the programmer that the function won't change x in
any circumstances. And when you've got a const you are also able to use
a ref as it won't change the variable - the compiler guarantees it. But
when you use a pointer there's no guarantee that the function won't
change the value - even if it's using the pointer only for the reason
that the parameter is too big to be copied efficiently. E.g.:

class foo
{
private:
  long big_array[10000];

public:
  /* ... */
};

void my_func1 ( foo x );	//can't change x. X will be copied
				//which is extremly unefficient.

void my_func2 ( foo& x );	//can change x, x won't be copied
				//=> fast but dangerous

void my_func3 ( foo* x );	//can change x, x won't be copied
				//=> fast but dangerous

void my_func4 ( const foo& x );	//can't change x, x won't be copied
				//=> fast and secure
> 
> What's nasty about 'ref' arguments is that some subsequent
> version of that library can change the parameter of
> 'some_function' to be 'ref' and then change the value of x
> inside the function without the author of the application
> code being aware that the libraries' policy has changed.
> The old call to some_function still compiles!  Eeeekkkkk!
> 
> Also, I like to be able to look at some complex code
> that uses 'some_function' and *know* that the parameter
> isn't altered by the the function just by looking at the
> call.  I don't even have to go off and read the manual
> for 'some_function' in order to know that.
> 
> The nice thing about good old fashioned C-style pointers
> is that when you see:
> 
>    x = 6 ;
>    some_function ( & x ) ;
> 
> ...that '&' shouts loudly to you to bear in mind that x may
> well have been changed by the call.  If you don't see an '&'
> then you don't need to know much about some_function in order
> to see that it doesn't change 'x'.
> 
> That makes code MUCH more readable.
> 
> I think 'ref' is *EVIL* because its syntax doesn't make it
> obvious.

IMHO you should use refs only in combination with const to increase the
speed and decrease the required memory. If you want to modify an object
you should use pointers. That the best of the two worlds - IMHO.

> > Anyway, that's it for religion, time to write some code.
> 
> Indeed.

That's programming style always. But this discussion makes at least
sense at it's about the code. It gets much more religious if people
start to discuss diferent styles of comments. 

<hiding mode=";-)">
To open the discussion: AFAIK does Steve hate the '//' comments...
</hiding>

CU,
Christian

Re: [Plib-devel] C++ Philosophy Question

[Steve B. <sjb...@ai...>]

Christian Mayer wrote:

> <hiding mode=";-)">
> To open the discussion: AFAIK does Steve hate the '//' comments...
> </hiding>

#define PI 3.14159  // Yes, Steve does hate these comments

 ...150 lines of code later...

   x = PI + 1 + 2 + 3
          + 4 + 5 + 6 ;

...this really happened to me once.  :-(

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] C++ Philosophy Question

[Loring H. <ls...@cs...>]

> >So far, nothing in STL seems worth the hassle. There are
> >still too many incompatible versions floating around out
> >there - and systems that don't have it installed, etc.
> >
> >I watched the L-O-N-G thread that went on in the FGFS
> >mailing list when STL was first used.  It convinced me
> >that I can do without it.
> >
> 
> There _are_ problems with STL across implementations (even using Visual C++
> 6.0, you'd better be using Service Pack 3).  This is unfortunate, because
> you can write a lot of nice, concise code quickly using the STL containers.
> I've come to like STL, but I agree that portability is a problem (which I
> sort of realized as soon as I posted the question).  Oh well...

My biggest issue with STL is that it has been hard to debug various STL data
structures...

In addition to STL being inconsistent, sometimes it isn't natively available
for some platforms.  I've used STLport to deal with this - I have gotten
STLport 3.2.2 beta 3 (http://www.stlport.org/) working with the native
compilers under AIX and Solaris, and it should work for many other platforms
as well.

Loring

Re: [Plib-devel] C++ Philosophy Question

[Steve B. <sjb...@ai...>]

Dave McClurg wrote:
> 
> I recently asked some related questions so i'll share what I know:
> 
> *** Naming conventions:
> 
> for public symbols in PLIB module 'XX' (where 'XX' is: SL, SSG, SG, PU, FNT):
> 
> #define's, enum tags                 XX_ALL_CAPITALS
> functions/classes/structs/typedefs   xxMixedCase
> 
> For private symbols, I use all_lowercase unless they would pollute
> the name space - in which case I use a leading underscore _xxMixedCase

Right.

> *** Dependencies
> 
> To use PLIB you need only GLUT, OpenGL and C++.
> keeping more dependencies out of PLIB is a design goal
> 
> STL would just be another dependency
> If you just need a list you can make it yourself
> like the ssgVertexArray

So far, nothing in STL seems worth the hassle. There are
still too many incompatible versions floating around out
there - and systems that don't have it installed, etc.

I watched the L-O-N-G thread that went on in the FGFS
mailing list when STL was first used.  It convinced me
that I can do without it.

I'm told that STL will be a part of the C++ standard in
the next revision of the ANSI spec - that means that it'll
be usable in a couple of years when all the older compilers
catch up.

Remember, portability is the number one goal of PLIB.

> *** templates, exceptions, references, operator overloading
> 
> like honey. icky sticky stuff.  can't see why pooh bears like it
> once in a while it can be handy but
> might as well keep it simple in a portable library like PLIB

Well, some of these things are just eye candy. (eg Operator
overloading) - some obfuscate code to a dangerous degree (eg
References) - others are STILL not portable enough for my
liking (Templates, exceptions).
 
> *** namespaces
> 
> i like them. any thoughts?

Still rather new.  Don't forget that people use PLIB
on systems like Solaris, MSVC 5, Irix 5.x - some of
those compilers are pretty old.
 
Having made all those excuses - I also have to confess
to being something of a minimalist when it comes to
coding.  C++ (like UNIX, OpenGL, HTML and others)
had 99% of what it needed in the very first version.

Once the design got out of the hands of the original
author, design-by-committee took over.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)