Subject: Re: Code guidelines, state of C++ compilers used, and general C++ comments
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Mon May 08 2000 - 20:28:51 CDT
-----BEGIN PGP SIGNED MESSAGE-----
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
#endif
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 2.7.8.2 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
sam@uchicago.edu
http://sam.rh.uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5F2nUt+kM0Mq9M/wRApxHAJ9eTdKo2+SH2QDuklb9DmVFOXP1RQCfZi3M
pj6fKUMXUke+0P5DSYILbyY=
=Ohs3
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b25 : Mon May 08 2000 - 20:29:50 CDT