Subject: Code guidelines, state of C++ compilers used, and general C++ comments
From: Mike Nordell (tamlin@algonet.se)
Date: Mon May 08 2000 - 20:17:57 CDT
After reading AbiSourceCodeGuidelines.abw I got some Ideas and thoughts
that I'd like to share with you to hopefully start a discussion on these
matters.
1. Prefix 'i' usually denotes an index in HN, why 'n' (both as the
mathematical integer representation, and it's the first letter of
'number') should be used as the general integer prefix. Prefix 'i' should
be used for indexes. 'sz' for zero temrinated strings (i.e. C strings).
4. Add: If you do use C++, prefer C++ style comments (//).
7. "Don't put platform specifics in XP code". This one should be obvious,
but I've found one place where an MSC #pragma is used in XP code (to
suppress a compiler warning). This is clearly wrong, but how should this
be handled?
8. Add: Loop indexes can use 'int' if it's beyond all dubt that the index
range will not overflow on any of the supported platforms.
Q: Is anyone using/aware of any compiler that we support that have int's
of less than 32 bits?
12. Add: Never EVER put a member variable under any other access
specification than private. Derived classes have NO business of probing
the baseclass' private parts (pun intended).
13. Replace the first senctence with "The curly brace goes on the next
line, and is indented to the same position as the starting position of
the expression it belongs to, i.e.
if (x)
{
". Remove the second sentence.
I also think it would be useful to know how old compilers we're supposed
to support. E.g. are we to support old proprietary MSVC 4.2 (C 10) when
there are viable (free) alternatives to use that have "a bit" more C++
standard compliance?
Point three reads "Don't use MI", but the next sentence reads "Avoid MI".
One of these are wrong.
I think it would be of use to have a a webpage at the site that states
what compilers are used, what operating systems they're used on, and what
C++ "features" (i.e. required ISO standard behaviour) we could benefit
from using that they don't support.
What initially got me thinking about this is that in AbiWord, many
classes participates in intrusive d.l.-lists [as siblings], and numerous
are the places where this code is duplicated. This adds bloat, and also
opens up the distinct possibility for copy'n'paste errors and so on.
To use an intrusive double linked list template class could really be of
benefit. An (incomplete) example of how such an interface could look like
can be found with my patch of fp_Run.
I also note that the macro DELETEP is somewhat redundant in its
implementation. It's always legal in C++ to delete a null pointer, e.g.
delete (int*)0;
The compiler does all the checking for you. To have this check once again
in a macro only produces larger binaries, and adds nothing. If it was
added to "make a point" for C++ developers that don't know this, I think
a "Code FAQ" webpage could be of use.
The REPLACEP macro should be removed completely.
The CLONEP macro should _really_ go away, since its implementation does
in no way do what its name says. (REPLACE_STRING_BY_CLONING) might be a
more correct name, but it's so ugly I'd prefer it was removed completely.
/Mike
This archive was generated by hypermail 2b25 : Mon May 08 2000 - 19:17:53 CDT