July 2009 - Boost - lists.boost.org

[gil] gcc 4.4 fix
by Christian Henning 06 Jul '09

06 Jul '09

Hi there, on 2009-06-25 Philipp Schwaha posted a fix for some namespace issues with gcc 4.4. I just got the latest trunk but the issues remain. Could someone please commit the fix? http://article.gmane.org/gmane.comp.lib.boost.devel/191191 Thanks, Christian

1 0

[iterator] zip_iterator equality comparison
by Jeremiah Willcock 05 Jul '09

05 Jul '09

It is standard in STL to have two ranges that are zipped together (such as in the two-input-sequence version of std::transform at http://www.sgi.com/tech/stl/transform.html) where the first range has begin and end iterators and other ranges have only begin iterators. However, boost::zip_iterator does not support this capability because it compares all iterators in the iterator tuple. Therefore, it is not possible to write std::transform on two sequences by using a zip_iterator to join the sequences. Allowing this by only comparing the first elements in the iterator tuples would simplify the code for zip_iterator, although it would no longer allow the zipping of zero sequences unless that was special-cased. Is this a reasonable feature to allow? I could probably put together a patch for it in the next few days if people wanted it. -- Jeremiah Willcock

1 0

Mark throw_exception as noreturn?
by Andrey Semashev 05 Jul '09

05 Jul '09

Hi, I was wondering why the throw_exception function is not marked as noreturn? This makes it troublesome to use it as a drop-in replacement for throw statements as it starts to flag compiler warnings about missing return statements in non-void functions. I suggest to mark the function as noreturn at least for compilers that support it. GCC has __attribute__((noreturn)), MSVC has __declspec(noreturn).

4 6

Library namespace guidelines
by Neil Groves 05 Jul '09

05 Jul '09

Boosters, I have read both the "Library Requirments and Guidelines" and specifically examined the "Boost Header Policy" and the section on naming consistency but have yet to understand how I should choose to use namespaces for the next version of Boost.Range, that incorporates the accepted Boost.RangeEx proposal. It feels indecent and naughty (in a bad way!) to be putting the library into the top-level boost namespace. More importantly I am concerned that general functions such as "find" will clash when combined with other boost libraries both now and in the future. Would the ideal scenario for new libraries be to have a library related namespace under boost in a manner akin to Boost.Filesystem? Is there already a strategy that is well-known that I am ignorant of? Is there an existing strategy to migrate libraries that pollute the top-level boost namespace that maximises backward compatibility? Any assistance with this matter would be greatly appreciated. Thank you in anticipation, Neil Groves

2 2

[proto] grammar compile error
by Felipe Magno de Almeida 05 Jul '09

05 Jul '09

Hello, When I have a grammar like this: struct create_table_grammar : boost::proto::shift_left < boost::proto::shift_left < boost::proto::terminal<tags::create> , boost::proto::terminal<tags::table> > , boost::proto::terminal<const char*> > {}; And this expression: create << table << "lala"; Where create and table are terminals with the respective tags. I have this compile error: examples/test1.cpp: In function ‘int main()’: examples/test1.cpp:12: error: no match for ‘operator<<’ in ‘sql::keywords::create << sql::keywords::table’ If I don't inner expressions, then (create << table) works. But I can't define a more restricted grammar this way. I want create << table to work only when preceded with another specific expression. I wanted create << table to be enabled, but to disable everything else except (create << table) << ""; Is this possible? Thanks, -- Felipe Magno de Almeida

3 7

is_base_of<int, int> behaviour.
by John Maddock 03 Jul '09

03 Jul '09

Folks, Some time ago we made is_base_of<int,int>::value true, for reasons that escape me, and the TR1 followed this. However, C++0X makes is_base_of<non_class, non_class>::value to be false, which seems all round more logical to me. While I'm sorting out what is_base_of<T, const T> does, it's a good time to fix this as well. Are there any objections to changing the behaviour of is_base_of to match C++0X? Cheers, John.

2 1

v2.0 of Identification library
by joel 03 Jul '09

03 Jul '09

I've uploaded an updated version of the identification library in the Vault some weeks ago and IIRC I forgot to mention it. From the doc : "Boost.Identification is a library which aims at providing a simple solution for building a textual representation of a type as a string that can be manipulated at run-time. Such a feature is often desirable when someone wants to dynamically debug large template class instantiation or use a easy to use `type string representation` to use in serialization process or exception display. Those tasks are often done using the typeid operator but its output is compiler dependant and often produce strings which are usually hard to decipher." Comments and remarks are most welcome. I'll also ask vicente to add it to the Library In Progress wiki page. Thanks in advance. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

6 8

boost::spirit -- semantic values
by Anand 03 Jul '09

03 Jul '09

I couldn't find a way to associate a semantic value with a non-terminal. Bison/yacc allows this. For example, here is a rule in Bison that says an expression can be the sum of two subexpressions: expr: expr '+' expr { $$ = $1 + $3; } ; The action says how to produce the semantic value of the sum expression from the values of the two subexpressions. Having semantic values for non-terminals is useful to build an expression tree. For, e.g, I can create a new node in the tree by passing in the semantic values of child nodes in the action. expr: expr '+' expr { $$ = makeNode($1, $3, "+"); } ; In this case the semantic value for each expression is of type Node*. Spirit provides parse trees and ASTs and also semantic actions that take the first last iterator pair. But is there some way I can associate a semantic value with each non-terminal and pass in these semantic values to the action for the rule. Thanks, Anand

2 1

Units of data
by Zachary Turner 03 Jul '09

03 Jul '09

Has anyone extended (even privately) Boost.Units to include support for units of data (bits, bytes, KB, MB, etc)? It seems like this would be a useful addition to Boost.Units. Assuming no, what is the minimum amount of work required to do this myself? There's not a lot of info in the docs on how to define new base units, although I've already begun looking over the source code to try to come up with something.

3 12

[BGL] on using visitor in dijkstra_shortest_path
by Sandeep Gupta 02 Jul '09

02 Jul '09

Hi, The example code for extending dijkstra via gives compilation errors. Attached below is the snippet code and the error messages using gcc-4.3.3 and boost_138_0. typedef boost::adjacency_list<vecS, vecS, bidirectionalS > graphImpl_t; //----taken for doc--- template <class PredecessorMap> class record_predecessors : public dijkstra_visitor<> { public: record_predecessors(PredecessorMap p) : m_predecessor(p) { } template <class Edge, class Graph> void edge_relaxed(Edge e, Graph& g) { // set the parent of the target(e) to source(e) put(m_predecessor, target(e, g), source(e, g)); } protected: PredecessorMap m_predecessor; }; template <class PredecessorMap> record_predecessors<PredecessorMap> //error: expected constructor, destructor, or type conversion before ‘<’ token make_predecessor_recorder(PredecessorMap p) { return record_predecessors<PredecessorMap>(p); } ///---end doc-------------- ..... ... vector<vertex_t> p(num_vertices(gg)); dijkstra_shortest_paths(gg, src, predecessor_map(preds).weight_map(weights).distance_map(dists).visitor(make_predecessor_recorder(&p[0]))); Thanks in advance. -sandeep

3 7