Re: [boost] coding guidelines

From: Erdei Andras (ccg_at_[hidden])
Date: 2001-07-06 03:07:37

8.8

unfortunately i have only CD2, not the standard, but 
according
to that

  7.1.2  Function specifiers  [dcl.fct.spec]

  1 Function-specifiers can be used only in function 
declarations.
          function-specifier:
                  inline
                  virtual
                  explicit

15.3

Scott Meyers wrote an article on this (the little endl that
couldn't), and his conclusion was: cout is unbuffered (or 
should
be in a standard-compliant library) so endl and '\n' are the
same for cout; and by default '\n' also flushes the buffer
(ios::unitbuf is by default on) so they are the same for 
anything
else

there was also a debate on comp.lang.c++.moderated (i don't
remember the conclusion), it may worth to take a look before
including this as a guideline

9.discussion

"occasional use of public" -- isn't that "private"?

another fairly frequent use for private inheritance is the
Adapter pattern

12.6

i more and more frequently run into a problem with this:

c.h:

struct C
  {
    void f( void ) ;
    int i ;
  } ;

c.cpp:

namespace { void f( int ) ; }

  void
C::f( void )
  {
    f( i ) ; // no such thing!
  }

there's no way to access f( int ) in C::f() -- and C::f() 
often
gets introduced long after f( int ), breaking existing code
(and usually the same name *is* the best for both functions)

11.2

aren't Alexandrescu's scope-guards often a better solution 
for
this?

4.9

this can result in the ">>" problem, so it can't be done
consistently -- are there any ramifications that still make 
it
worth to be a rule?

15.5

it prevents not only the user-defined assignment operator, 
but
also the compiler-generated one

reference members can be legitimally used e.g. in proxy
classes, which i guess are quite frequent in boost

what's the intent of this guideline?

1.7

this can also wreak havoc with explicit or implicit casts 
and
overloaded functions

    struct B {} ;
    struct D1 : public B {} ;
    struct D2 : public B {} ;
    struct DD ;

    struct C
    {
      B * first() ;
    } ;

    void f( D2 * ) ;
    void f( void * ) ;

    struct CD : public C
    {
    // at this point the casts are effectively only a C-
style
    // reinterpretation of the pointer value
    // (using static_cast<> or dynamic_cast<> is slightly 
better
    // -- at least that gives a compile-time error)
      DD * second()
        {
          return (DD*)(D2*)first() ;
        }

      void f( void )
        {
          ::f( second() ) ; // calls f( void * )
        }

    } ;

    // now any casts will be an inheritance conversion
    // (adjustment of the "this" pointer);
    // the previous casts may have generated bad code!
    // also, as it turns out CD::f should have
    // called ::f( D2 * ) instead of ::f( void * )
    struct DD : public D1, public D2 {} ;

1.6

it might be moot for boost (except if e.g. a thread library 
is
included), but esp. with windows.h it is often worth it to
violate this rule -- at least i like to postpone the 
pollution it
causes till the end of the implementation file where a few
functions actually using the windows API are residing

br,
andras