Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2003-06-23 04:11:28

----- Original Message -----
From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, June 20, 2003 12:38 PM
Subject: [boost] Re: BOOST_STATIC_ASSERT - a little better

> "John Torjo" <john.lists_at_[hidden]> wrote in message
> news:00ef01c33687$02720ea0$01211bac_at_PEOPLEFIRST...
> > Hi all,
> >
> > I was just thinking (actually, I needed this, while doing some coding),
> that
> > STATIC_ASSERT could get a little of the SMART_ASSERT flavour.
> >
> > What am I talking about?
> > In case a STATIC_ASSERT fails, how about dumping some data that was
> involved
> > in the expression?
> >
> SMART_ASSERT is very useful to provide context information for hard to
> reproduce errors. STATIC_ASSERT error can be reproduced reliably during
> every compilation.

True, but:
- just consider a very complicated library (like MPL, for instance), dealing
with traits, etc., and a STATIC_ASSERT fails. In case the one debugging is
not the author of the library, it might be very hard for him to actually
undrestand what happened.

- Imagine that your library is compiled on a different platform, and a
STATIC_ASSERT occurs (for instance, the other compiler is broken), and the
user that tested this is sending you the compiler output (the errors).
Wouldn't you find the more information he sent you the better it is?

Just look at the following and tell me if you knew what to do if any fails
(taken from boost libraries):

// boost/half_open_range.hpp

// boost/graph/connected_components.hpp
  template <class Graph, class ComponentMap, class P, class T, class R>
  inline typename property_traits<ComponentMap>::value_type
  connected_components(const Graph& g, ComponentMap c,
                       const bgl_named_params<P, T, R>& params)
    typedef typename graph_traits<Graph>::vertex_descriptor Vertex;
    function_requires< WritablePropertyMapConcept<ComponentMap, Vertex> >();
    typedef typename boost::graph_traits<Graph>::directed_category directed;
    BOOST_STATIC_ASSERT((boost::is_same<directed, undirected_tag>::value));

// boost/graph/isomorphism.hpp
  template <typename Graph1, typename Graph2, typename IsoMapping,
    typename Invariant1, typename Invariant2,
    typename IndexMap1, typename IndexMap2>
  bool isomorphism(const Graph1& G1, const Graph2& G2, IsoMapping f,
                   Invariant1 invariant1, Invariant2 invariant2,
                   std::size_t max_invariant,
                   IndexMap1 index_map1, IndexMap2 index_map2)

    // Graph requirements
    function_requires< VertexListGraphConcept<Graph1> >();
    function_requires< EdgeListGraphConcept<Graph1> >();
    function_requires< VertexListGraphConcept<Graph2> >();
    function_requires< BidirectionalGraphConcept<Graph2> >();

    typedef typename graph_traits<Graph1>::vertex_descriptor vertex1_t;
    typedef typename graph_traits<Graph2>::vertex_descriptor vertex2_t;
    typedef typename graph_traits<Graph1>::vertices_size_type size_type;

    // Vertex invariant requirement
    function_requires< AdaptableUnaryFunctionConcept<Invariant1,
      size_type, vertex1_t> >();
    function_requires< AdaptableUnaryFunctionConcept<Invariant2,
      size_type, vertex2_t> >();

    // Property map requirements
    function_requires< ReadWritePropertyMapConcept<IsoMapping, vertex1_t>
    typedef typename property_traits<IsoMapping>::value_type
    BOOST_STATIC_ASSERT((is_same<IsoMappingValue, vertex2_t>::value));

The list could go on.
Please note that this was not in any way an offense at the authors of the
files above.

The idea is that I consider useful a little more information, in cases like
this. Of course, I'm not asking that BOOST_STATIC_ASSERT is *modified*, just

What do you think?


> /Pavel
> _______________________________________________
> Unsubscribe & other changes:

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