Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-01 09:04:23

----- Original Message -----
From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>

> In C++, indentation/layout does not prohibit from interfacing a piece of
> with another piece of code. Therefore indentation guidelines are
> less important than identifier decoration rules. The coding conventions
> we use at work only specifies the decoration of different type of
> The most important indentation guideline is to avoid using an indentation
> is difficult to maintain. An example of a difficult to maintain layout is
> endline layout.

Agreed. Would you like to suggest a change based on this?

> The guidelines suggest that include guards should be unique, and then
> using a date and name. Another alternative is to use a 128-bit GUID per
> project. Using a GUID offers a considerably higher level of protection
> collisions. We use a single GUID for all of our libraries, which
internally do
> not have collisions, at work and I don't recall having any collisions with
> other library ever.

I think this places too high a burden on the programmer, and that the
proposed method is sufficiently unique. I don't even know how to make a

> The guidelines suggest that template parameters should be in mixed case
> without underscores. I have several issues with this:
> - I very much prefer consistent use of underscores regardless of
> capitalization.
> - I also find identifiers with underscores easier to read regardless of
> capitalization.
> - One letter words obscure mixed case identifiers without underscores.
> Example for previous issues:
> ASomewhatDifficultToReadIdentifier
> A_Significantly_More_Readable_Identifier

I agree with you about the readability part, but the guideline is designed
for consistency with the boost:: and std:: legacy.

> - IMO, parameters should be consistently decorated the same as local
> definitions - like in normal function definitions. I have broken this
> principle recently, due to differences in Boost conventions (uses lower
> typenames) and the conventions I use at work (mixed case typenames), and
> noticed this only recently. In future, I will consistently decorate
> the same as local definitions, also in my Boost libraries, regardless of
> type of the definition (whether it is a metafunction, function, class or
> whatever).

I need an example to understand this. I think my guidelines are consistent
in this regard (?)

> "8.9. Do not write the `inline' keyword on member function declarations"
> - I recall observing (IIRC, I inspected the disassembly after having link
> errors) that some compilers do not inline such functions. (IIRC, the
> was some version of MWCW.) So, I would generally advice against this
> if portability is desired.

Older versions of MWCW would only inline functions whose definitions were
visible before the caller's definition, I think. Newer versions have an
option for a kind of lookahead.

Nearly /any/ practice is justifiable at the stage of actually getting a
program to work (or work fast) on a given compiler. These guidelines are
designed to be used up until the time you prove that something else is


Boost list run by bdawes at, gregod at, cpdaniel at, john at