Re: Code guidelines, state of C++ compilers used, and general C++ comments

Subject: Re: Code guidelines, state of C++ compilers used, and general C++ comments
From: sam th (
Date: Mon May 08 2000 - 20:28:51 CDT

Hash: SHA1

On Tue, 9 May 2000, Mike Nordell wrote:

> 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 (//).

Well, except for large comment blocks.
Also, we might want to put something in about the use of
#if 0


for debugging/code-switching purposes (there was some discussion about
this a while back).

> 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?

#pragma is used in 3 places

af/ev/beos/ev_BeOSToolbar.cpp - not sure of the use
af/util/xp/ut_regex.c - for AIX compatibility
af/xap/unix/xap_UnixPSParseAFM.c - for Win32 warning, as you say

the only one not hidden in ifdef's is the BeOS one.

> 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?

Compilers we use -

MSVC 6 and up
gcc/g++ probably and up
borland cc i dont know the version
Metroworks unkown version

> 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).

true true
> 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?

see above

> 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.

An excellent idea. I don't know if there are ways to find out the
compatibility and conformance levels, but it sure would be nice to have.

                                     sam th
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see


This archive was generated by hypermail 2b25 : Mon May 08 2000 - 20:29:50 CDT