RE: [boost] aligned_storage<> and optional<>

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-09-05 13:05:37

----- Original Message -----
From: John Maddock <John_Maddock_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, September 05, 2001 8:29 AM
Subject: [boost] aligned_storage<> and optional<>

> provided you are careful you can use
> BOOST_STATIC_CONSTANT (see more/int_const_guidelines.htm for all the
> workarounds you may need)

I've just read it. Great document!

The full qualification workaround didn't work in the example of my previous
post:

template<class T>
struct C0
{
  static const int v = 1 ;
  char b[v] ;
  A< C0<T>::v> n ; // <=== ERROR HERE

  typedef C0 self ;
  A< self::v> n2 ; // <== STILL ERROR HERE
} ;

But the separation workaround did!

template<class T>
struct C0_helper { static const int v = 1 ; } ;

template<class T>
struct C0
{
  char b[v] ;
  A< C0_helper<T>::v> n ; // <=== OK NOW
} ;

While I was trying to compile Doug's code, the first problem I found was
that of the dependent-type default argument you mention. Unfortunately, when
I fixed this by removing the default the compiler stop giving errors just to
start crashing.
You might want to add in your document, as an alternative workaround -a lot
harder though-, the non-type to type transformation I applied. It allows you
to retain the 'defaul't parameter, which might be necesary..

>- I've also found that while you can nearly
> always use enum's in constant expressions, they sometimes have a garbage
> value (usually zero) when used in that way.  Since this is a silent
> failure, it's generally best to use static const int's, that way you know
> when there is a problem.
>
AFAICT, this ocurrs when different translation units (typically different
DLLs) mix different enum treatments  (like 'int' and not like 'int'). But it
might happen in other contexts so avoiding enums is sound.

A last note:

There is a problem in preceding fully qualified names with the resolution
operator at global scope (::xxx).
Imagine:

some_header.hpp
~~~~~~~~~~~~

struct A
{
  BOOST_STATIC_CONST ( int, value = 2 ) ;
  char b [ ::A::value ] ;
} ;

some_user.cpp:
~~~~~~~~~~

namespace ConflictingLibrary {
  #include "some_header.h"
}

This won't compile since A is not in the global namespace anymore.

In other words, you can never know which ABSOLUTE namespace are you in. You
can only know it relative to some unknown outer namespace (unless you are
The Standard, of course).

BTW, why isn't an 'outer namespace access modifier'? This is a lot more
useful than the global scope access modifier.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com