Re: libsupc++ nit picks

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20020103231712.79430.qmail@web20005.mail.yahoo.com> you write:
[...]
>  In libsupc++ I see the idiom:
>	if (ptr)
>	  free (ptr)

FYI, some idioms are used in the library to avoid common portablility
issues.  This is a case where it doesn't matter what the standards
say; without the 'if' check, the code will fail on some platforms that
people still care about.

> Also, the use of qualified names, usings, and extern
> vs #include seem inconsistent.
> To use the above example again, del_op.cc and
> del_opnt.cc refer to ::free, where eh_globals.cc uses
> std::free.
> del_op.cc uses an extern to find free, where
> eh_globals.cc #include <cstdlib>

This is my own opinion (and it does not override the rule that you
don't touch what isn't broken ;-), but prototypes for system functions
should rarely if ever be declared with extern in a source file.

> new_handle.cc uses std:: for some names
> (std::nothrow_t), but usings for others
> (std::new_handler).

This is probably OK.

> Is this just a result of many different authors?

Probably.  It is also true that some of the code is a lot older than
other parts.

> Should this part of the library fall under the same
> coding rules as the rest?

There are coding rules for all of the C++ library implementation but
(if I remember the history) libsupc++ was developed outside the
context of those rules and then later moved under libstdc++.

Regards,
Loren