Re: Examples of the inconsitency in PenguinPlay

["Peter Burns" <pburns@firstdata.com.au>]

>Ok. good point. Possible solution (more or less the current implicit
>convention): The primary header of each Part (subpart), i.e.
>Penguin2D.h, PenguinFile.h, ...  - no pp prefix (The Penguin... is enough
>and it's clearer).
>All others: pp<partletter> prefix (i.e. "ppf" for PenguinFile, "ppg" for
>PenguinGraphics, "pps" for PenguinSound).

>Adrian, Derek, Peter, Christof, Stephane, your voices?

For penguin sound I've prefixed each class with "pps" and named the
file after the class. When we do the primary header it should probbly be
the same as the others ie include it as <penguinplay/PenguinSound.h>


>>This kind of thing shouldn't be in a coding convention document. It's a
>>higly personal remark that doesn't say anything about what people should
do,
>[...]
>>part, not a coding convention document. A coding convention document must
>>be *formal* in the way it *dictates* how people *must* do things. This is

>Agreed. more or less. coding.html will be made more formal. -> later

I think you should standardise on things that make the project more
portable.
Things like - don't declare variables in for loops (ie for(int i; i < 256;
i++) )
and expect that the scope is only with in the for loop.

Who cares about indentation. If somebody needs the code indented in a
particular way so that they can read it then they should obtain a tool that
does this for them. There is a program called "indent" that can do this.
In Visual Studio you can select the region you want indented in a
particular
way using "Format Selection" (<ALT> F8)

>Correct. Peter, Derek, can you stick to the ".cc" we use? Not urgent, but
>you know... Also ".h" for headers.
>BTW using something other than ".cc" or ".C" for C++ sources effectively
>disables some of make's mechanisms (automatically compiling all sources of
>known type).

Automake has no problem generating makefiles for files with the .cpp
extension.

Here is what msdn has to say about file extensions.

>CL accepts files with names that follow FAT, HPFS, or NTFS naming
>conventions. Any filename can include a full or partial path.
>A full path includes a drive name and one or more directory names.
>CL accepts filenames separated either by backslashes (\) or forward
>slashes (/).  A partial path omits the drive name, which CL assumes
>to be the current drive. If you don

’t specify a path, CL assumes
>the file is in the current directory.
>
>The filename extension determines how files are processed.
>C and C++ files, which have the extension .C, .CXX, or .CPP, are
>compiled. Other files, including .OBJ files, libraries (.LIB), and
>module-definition (.DEF) files, are passed to the linker without
>being processed.

I have two platforms that I can develop in windows and linux.
Under linux either .cc or .cpp is acceptable.
.cc files are very annoying to compile in MSVC. Since I am
using MSVC to develop for windows (since there are a lot
of windows game developers) I will not change the .cpp
extension to .cc . The use of .hpp is just a question of style.




Before you wrote the coding standards I had a look at the other
coding standards floating around on the net.


The mozilla c++ portability guide has a few suggestions. It has a bit about
      the

extension to use for c++ files.

http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html


>C++ filename extension is .cpp.
>This one is another plain annoying problem. What's the name of a C++ file?
 file.cpp, file.cc,
>file.C, file.cxx, file.c++, file.C++? Most compilers could care less, but
some are very
>particular. We have not been able to find one file extension which we can
use on all
>the platforms we have ported Mozilla code to. For no great reason, we've
settled on file.cpp,
>probably because the first C++ code in Mozilla code was checked in with
that extension.
>Well, it's done. The extension we use is .cpp. This extension seems to
make most compilers
>happy, but there are some which do not like it. On those systems we have
to create a wrapper
>for the compiler (see STRICT_CPLUSPLUS_SUFFIX in ns/config/rules.mk and
ns/build/*),
>which actually copies the file.cpp file to another file with the correct
extension, compiles
>the new file, then deletes it. If in porting to a new system, you have to
do something like
>this, make sure you use the #line directive so that the compiler generates
 debug information
>relative to the original .cpp file.


Heres what the wxWindows coding standards has to say on the subject

http://web.ukonline.co.uk/julian.smart/wxwin/standard.htm

>Use .cpp for C++ source file extension
>There is, unfortunately, no standard exceptions for C++ source files.
>Different people use .C, .cc, .cpp, .cxx, .c++ and probably several others
 I
>forgot. Some compilers don't care about extension, but there are also
>other ones which can't be made to compile any file with "wrong"
>extension. Such compilers are very common in DOS/Windows land,
>that's why the .cpp extension is the least likely to cause any
>problems - it's the standard one under DOS and will probably be
>accepted by any Unix compiler as well (any counter
>examples?). The extension for the header files is .h.

There is also http://www.doc.ic.ac.uk/lab/cplus/c++.rules/
I don't agree with what it has to say on the subject of c++ extensions.
It suggests either .cc or .C for compilers that wont compile .cc files.
As you are probably aware of windows is not case sensitive so if you
change the name to .C then MSVC thinks that the files is a c file and
complains about all the c++ stuff in it.

The one important thing that hasn't been touched on is the build process
for the entire project. Some projects hand code their makefiles others
use autoconf. I've started using automake which generates the Makefile.in
for autoconf. Automake makes it very easy to build shared libraries. It
also
generates the dependencies for you and generates a target for building
a source distribution. Its not too hard to get it to build a target for
packages like rpm and deb. When some body gets the entire source
for penguinplay they expect to be able to just type ./configure and make
to get all the projects to build. They might prefer to get prebuilt rpm or
deb
packages if they only care about the using the libraries and not developing
them.

Peter Burns