November 2011 - Boost - lists.preview.boost.org

[BGL] map_as_graph.hpp
by Shaun Jackman 04 Nov '11

04 Nov '11

Hi, In the spirit of vector_as_graph.hpp, I created map_as_graph.hpp. One useful feature is that the vertex_descriptor can be any user-defined type, such as a string or an arbitrary object. It's not in a form that's ready to be included in Boost, but I have found it occasionally useful. I though I'd post it in the case that someone else found it useful. If someone found it useful enough that he or she where interested in further developing to the point where it could be included in Boost, please be my guest. Cheers, Shaun #ifndef MAP_AS_GRAPH_HPP #define MAP_AS_GRAPH_HPP 1 #include <boost/graph/graph_traits.hpp> #include <cassert> #include <map> #include <utility> // for make_pair namespace boost { /** * A std::map is a model of a directed graph. * @author Shaun Jackman <sjackman(a)gmail.com> */ template <typename V, typename T> struct graph_traits<std::map<V, T> > { // Graph typedef V vertex_descriptor; typedef boost::directed_tag directed_category; struct traversal_category : boost::adjacency_graph_tag, boost::vertex_list_graph_tag { }; typedef boost::disallow_parallel_edge_tag edge_parallel_category; // IncidenceGraph typedef std::pair<vertex_descriptor, vertex_descriptor> edge_descriptor; typedef size_t degree_size_type; /** Iterate through the out edges of a vertex. */ struct out_edge_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; out_edge_iterator(const It& it, vertex_descriptor src) : It(it), m_src(src) { } edge_descriptor operator*() const { return edge_descriptor(m_src, It::operator*().first); } private: vertex_descriptor m_src; }; // BidirectionalGraph typedef void in_edge_iterator; // AdjacencyGraph /** Iterate through the adjacent vertices of a vertex. */ struct adjacency_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; adjacency_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; // VertexListGraph /** Iterate through the vertices of this graph. */ struct vertex_iterator : std::map<V, T>::const_iterator { typedef typename std::map<V, T>::const_iterator It; vertex_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; typedef size_t vertices_size_type; // EdgeListGraph typedef void edge_iterator; typedef void edges_size_type; }; // graph_traits<std::map> // IncidenceGraph template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::out_edge_iterator, typename graph_traits<std::map<V, T> >::out_edge_iterator> out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typedef typename graph_traits<std::map<V, T> >::out_edge_iterator out_edge_iterator; typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair( out_edge_iterator(it->second.begin(), u), out_edge_iterator(it->second.end(), u)); } template <typename V, typename T> typename graph_traits<std::map<V, T> >::degree_size_type out_degree( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return it->second.size(); } // AdjacencyGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::adjacency_iterator, typename graph_traits<std::map<V, T> >::adjacency_iterator> adjacent_vertices( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair(it->second.begin(), it->second.end()); } // VertexListGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::vertex_iterator, typename graph_traits<std::map<V, T> >::vertex_iterator> vertices(const std::map<V, T>& g) { return make_pair(g.begin(), g.end()); } // AdjacencyMatrix template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); return std::make_pair(make_pair(u, v), it == g.end() ? false : it->second.count(v) > 0); } // VertexMutableGraph template <typename V, typename T> void remove_vertex( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { size_t n = g.erase(u); assert(n == 1); (void)n; } // EdgeMutableGraph template <typename V, typename T> void clear_out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { typename std::map<V, T>::iterator it = g.find(u); assert(it != g.end()); it->second.clear(); } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename edge_property<std::map<V, T> >::type ep; return make_pair(std::make_pair(u, v), g[u].insert(make_pair(v, ep)).second); } template <typename V, typename T> void remove_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { size_t n = g[u].erase(v); assert(n == 1); (void)n; } // PropertyGraph template <typename V, typename T> no_property get(vertex_bundle_t, const std::map<V, T>&, typename graph_traits<std::map<V, T> >::vertex_descriptor) { return no_property(); } template <typename V, typename T> const typename T::mapped_type& get(edge_bundle_t, const std::map<V, T>& g, typename graph_traits<std::map<V, T> >::edge_descriptor e) { typename std::map<V, T>::const_iterator u = g.find(source(e, g)); assert(u != g.end()); typename T::const_iterator v = u->second.find(target(e, g)); assert(v != u->second.end()); return v->second; } // MutablePropertyGraph namespace boost { template <typename V, typename T> class vertex_property<std::map<V, T> > { public: typedef no_property type; }; template <typename V, typename T> class edge_property<std::map<V, T> > { public: typedef typename T::mapped_type type; }; } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, typename edge_property<std::map<V, T> >::type ep, std::map<V, T>& g) { return make_pair(std::make_pair(u, v), g[u].insert(std::make_pair(v, ep)).second); } } // namespace boost #endif

1 0

Remembering that T(a) can cause dangerous conversion like a C-style cast
by Kazutoshi Satoda 04 Nov '11

04 Nov '11

An essential question: Should boost::lambda::constructor<int>()("") compiles? It does compile with Boost 1.47.0 . But I think it shouldn't. I have crafted a general replacement of T(a) as a workaround for dangerous conversions caused by T(a) which may happen in some kinds of templates. http://ideone.com/iZE1Z unary_initialized<T>(a).value And I thought of that the above workaround (or something similar) may be suitable to be provided within boost::initialized . Now I want to share the idea and to hear interests or evaluations in the community about such extension and underlying issues, before starting further acts. Here is the background story: A while ago, I had a conversation about dangerous conversion that can be caused by the following expression with variadic templates in C++11. T(std::forward<Args>(args)...) This expression is meant to obtain a prvalue of type T which is direct initialized from any given argument list. But if a single argument was given, this becomes T(std::forward<Arg>(arg)) and further, for example, may become int("") and compiles as reinterpret_cast which is likely unexpected. Here is a relevant quote from the standard 5.2.3 p1: > ... If the expression list is a single expression, the type conversion > expression is equivalent (in definedness, and if defined in meaning) to > the corresponding cast expression (5.4). ... (Note: 5.2.3 describes the behavior of T(a), and 5.4 describes the behavior of (T)a.) To avoid the unexpected conversion, I first proposed use of T{...} . But it is not a perfect solution because it changes the meaning in some cases like std::vector<int> . After that, I crafted a tricky workaround. http://ideone.com/FLoDk pack_initialized<T>(std::forward<Args>(args)...).value The above story was about C++11. But it revealed that similar dangerous conversion can be also formed in C++98, C++03 as T(a) in some kinds of templates. Searching in the boost directory (trunk r75213), I found some occurrences of the problem: boost/lambda/construct.hpp:37: http://www.boost.org/doc/libs/1_47_0/boost/lambda/construct.hpp return T(a1); boost/xpressive/regex_actions.hpp:632: http://www.boost.org/doc/libs/1_47_0/boost/xpressive/regex_actions.hpp return T(a0); As shown in the top of this message, I picked boost::lambda::constructor as a concrete example, and verified that the problem really exists in the wild. Thinking more, I wonder why such dangerous conversion was explicitly injected to T(a) in the first place. I first thought of some C-compatibility issues. But now I think it cannot be, because T(a) is a new construct in C++. Is it possible to remove this dangerous conversion path in a future revision of the standard? Perhaps I should go to comp.std.c++ about the last question. -- k_satoda

2 2

[release][1.48] Several merge requests
by Daniel James 04 Nov '11

04 Nov '11

Hi, Please can I merge the following changes: This prevents standard containers from being forward declared for gcc's 'profile' mode: https://svn.boost.org/trac/boost/changeset/75016 Trivial change to improve a couple of quickbook warnings (obviously not vital, but simple enough): https://svn.boost.org/trac/boost/changeset/75088 In unordered, avoid using a name that clashes with a macro defined by a header included from ASIO: https://svn.boost.org/trac/boost/changeset/75123 Missing html redirect, fixes some links to Boost.Move (documentation change): https://svn.boost.org/trac/boost/changeset/75141 Unordered wasn't working on gcc 4.7 in c++0x mode because of changes to std::pair's constructor. Unfortunately, the gcc 4.7 tester hasn't run since this change and I don't have access to it, so I haven't verified that it fixes the problem. But it does work fine on everything it has been tested with. https://svn.boost.org/trac/boost/changeset/75158 This stops using a hack on Visual C++ which was breaking for certain versions (although it didn't show up on any tester). But this is moving from a hacky implementation to a slightly less capable but more reliable implementation, so I think it's a good change regardless. https://svn.boost.org/trac/boost/changeset/75167 thanks, Daniel

2 1

"Best so far" for C level i/o of Unicode text with Windows console
by Alf P. Steinbach 03 Nov '11

03 Nov '11

This may be of interest to developers of Boost libraries that deal with text. I found that the Visual C++ implementation of the C library i/o generally does not support console input of international characters. It can deal with narrow character input from the current codepage, if that codepage is not UTF-8. For example: <code> #include <stdio.h> int main() { printf( "? " ); char buffer[80]; scanf( "%s", buffer ); printf( "%s\n", buffer ); } </code> <result> d:\dev\test> chcp 1252 Active code page: 1252 d:\dev\test> utf8test ? abcæøå abcæøå d:\dev\test> chcp 65001 Active code page: 65001 d:\dev\test> utf8test ? abcæøå ��, d:\dev\test> _ </result> I placed a comment about this at the blog of Microsoft's Unicode guru Michael Kaplan, http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx In particular, with active codepage 65001 (UTF-8), functions such as wscanf just fail outright on non-ASCII characters. The IMO best compromise that I have managed to come up with is a kind of hybrid, where the active input codepage is set to 1252, Windows ANSI Western, because that's a superset of Latin 1 which is a subset of Unicode. Output is converted to UTF-8. Input from e.g. a file accepts UTF-8. This means that e.g. Norwegian text can be input interactively (restricted to Latin 1 character set) or from a pipe or file (as UTF-8) without problems, and can be automatically translated (by the C i/o level) to UTF-16 encoding inside the program. However, I'm guessing that the C level input will garble e.g. Russian text no matter what one does, if one desires some Unicode based encoding inside the program. The Windows and Visual C++ support is just full of bugs -- e.g. as the crash of `more` showed in an earlier thread. Initialization of streams for the compromize scheme: static void msvcCompatibleInit() { struct Fix { static void mode( FILE* f, char const errorText[] ) { int const fileNo = _fileno( f ); bool const isConsoleInput = (f == stdin && _isatty( fileNo )); if( isConsoleInput ) { // Bytes are received as per the active codepage in the console. // Except if that active codepage is 65001, in which case non-ASCII // characters fail. Also, _setmode just causes non-ASCII fail. // // Setting the console codepage to 1252 might be practically helpful, // since cp 1252, Windows ANSI Western, is a superset of Latin 1 // which is a subset of Unicode. However, non-Latin 1 characters will // then be incorrect, just as with web pages in the old days. } else { int const newMode = _setmode( fileNo, _O_U8TEXT ); hopefully( newMode != -1 ) || throwX( errorText ); } } }; Fix::mode( stdin, "_setmode stdin failed" ); Fix::mode( stdout, "_setmode stdout failed" ); Fix::mode( stderr, "_setmode stderr failed" ); } Cheers & hth., - Alf

3 3

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

[Boost.Endian] Review Results
by joel falcou 03 Nov '11

03 Nov '11

Hi everyone, after some delay, here is the result of the review of Beman Dawes' Boost.Endian library. First, I want to thanks all participants of the review that lead to very deep and interesting discussions on the matter. 5 votes were cast : 2 unconditionally in favor, 3 conditionally in favor after changes made and there is a mini-review. The verdict is that Boost.Endian is **CONDITIONNALY ACCEPTED** Here is what needs to be done to get the library ready for a mini-review: * Common use case scenarios should be developed. * Example programs should be developed for the common use case scenarios. * Documentation should illuminate the differences between endian integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications. * Conversion functions supplying results via return should be provided. * Platform specific performance enhancements such as use of compiler intrinsics or relaxed alignment requirements should be supported. * Endian integer (and floating) types should be implemented via the conversion functions. If that can't be done efficiently, consideration should be given to expanding the conversion function signatures to resolve the inefficiencies. * Benchmarks that measure performance should be provided. It should be possible to compare platform specific performance enhancements against portable base implementations, and to compare endian integer approaches against endian conversion approaches for the common use case scenarios. * Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the primary use case. * Support for user defined types (UDTs) is desirable, and should be provided where there would be no conflict with the other concerns. * There is some concern that endian integer/float arithmetic operations might used inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic operations should be investigated. * Stream insertion and extraction of the endian integer/float types should be documented and included in the test coverage. * Binary I/O support that was investigated during development of the Endian library should be put up for mini-review for inclusion in the Boost I/O library. From this point, I will let Beman prepare Endian for the mini-review and I already volunteer to manage the mini-review so informations are not scattered around. Regards

1 0

[tree] more questions (was: [tree] associative containers)
by Cromwell Enage 03 Nov '11

03 Nov '11

From: Erik Erlandson > I'm not entirely sure about the relative merits of that versus defining > a parallel zoology of Hierarchical Containers that is basically > isomorphic to the traditional Container hierarchy, and leaving the > cursor definition more lightweight: perhaps just "iterator plus > parent(), begin() and end()", or alternatively not having a separate > cursor type, and simply having traditional iterators over children at > any given node. I'm curious as to what tree algorithms can take better advantage of the cursor interface as-is. Also: * What are the primary differences between a plain hierarchy and a multiway hierarchy? * Why shouldn't one assume that an on-top cursor is dereferenceable? TIA, Cromwell D. Enage

1 0

[tree] associative containers
by Cromwell Enage 03 Nov '11

03 Nov '11

I've been studying the tree proposal to see how I could write adaptors in my tree_node library (now at version 0.2 in the sandbox) that conform to the current concepts. Is there anything in the proposal that is analogous to a PairAssociativeContainer? My tree_node library defines an AssociativeTreeNode concept and a couple of models that I've found to be useful, e.g. for implementing decision tree learning algorithms. Cromwell D. Enage

2 2

[1.48][math] Permission to merge to release branch
by John Maddock 03 Nov '11

03 Nov '11

I'd like to merge this Clang fix to release if possible: https://svn.boost.org/trac/boost/changeset/75152 The change basically just moves code from one header to another, so it's defined at the point of first use. Thanks, John.

2 2

[BGL] How to provide a vertex_index property for my graph
by ShNaYkHs ShNaYkHs 03 Nov '11

03 Nov '11

Hello, Since my graph use setS as a VertexList, I have to either provide a vertex_index property map for my graph to be able to use some functions requiring a vertex_index (e.g. write_graphviz). My graph is defined as: typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; Where NodeData and EdgeData are structures. Can you please give me a very simple example of how to provide a vertex_index property map for my graph ? I mean, since an adjacency_list that uses listS or setS as the vertex container does not automatically provide this vertex_id property, how can I add it to the code bellow ? I tried to use an associative_property_map to include index for vertices, but it doesn't work (errors): #include <boost/graph/iteration_macros.hpp> #include <boost/graph/adjacency_list.hpp> using namespace std; using namespace boost; struct NodeData { int label; float influance; /* etc ... */ }; struct EdgeData { int age; /* etc ... */ }; typedef map<vecS, size_t> IndexMap; IndexMap mapIndex; associative_property_map<IndexMap> propmapIndex(mapIndex); typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; typedef Graph::vertex_descriptor NodeID; typedef Graph::edge_descriptor EdgeID; int main() { Graph g; NodeID n0 = add_vertex(g); g[n0].label = -1; NodeID n1 = add_vertex(g); g[n1].label = -1; EdgeID edge; bool ok; tie(edge, ok) = boost::add_edge(n0, n1, g); if (ok) g[edge].age = 10; int i=0; BGL_FORALL_VERTICES(v, g, Graph) { put(propmapIndex, v, i++); } return 0; } Thanks for answer.

2 3

Boost.Algorithm design question
by Marshall Clow 03 Nov '11

03 Nov '11

So, what do people prefer (and why?): template<typename InputIterator, typename V> bool none_of_equal ( InputIterator first, InputIterator last, V const &val ) { for ( ; first != last; ++first ) if ( val == *first ) return false; return true; } or template<typename InputIterator, > bool none_of_equal ( InputIterator first, InputIterator last, iterator_traits<InputIterator>::value_type const &val ) { for ( ; first != last; ++first ) if ( val == *first ) return false; return true; } In the first case, I think there's (possible) conversion from V to iterator_traits<InputIterator>::value_type each time through the loop. In the second case, there is not. Of course, the (mythical?) smart compiler would do the conversion once and save the result for reuse. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

17 79

[1.48.0 Beta 1][fusion] MacTypes.h conflict with nil
by Jeff Flinn 03 Nov '11

03 Nov '11

reposted from "[1.48.0] Beta 1 is now available from SourceForge" thread for better visibilty. Mac 10.6 Xcode 3.2.6 gcc 4.2: In compiling our application, upgrading from boost_1_44_0 I get conflicts with MacTypes.h define of nil when compiling cons_fwd.hpp from fusion. Any thoughts? Jeff

3 3

Interest in boost.deepcopy
by Allan Johns 02 Nov '11

02 Nov '11

Just gauging initial interest in a boost.deepcopy library, analogous to deepcopy in python. Each type would register deepcopy behaviour with the library (there are similarities to boost.serialize). Boost.deepcopy would supply out-of-the-box registration for pod types, pointer types, arrays, stl containers and common boost containers. Example: template<typename T> void deepcopy(deepcopycontext& ctxt, const T& obj) { ...; } Why not use boost::serialize and serialize into memory then out again I hear you say? That's a great approach, but only when every object requires the same deepcopy behaviour (also, it's not too optimal). The problem is, I need specific behaviour in some types. Specifically, I need copy-on-write behaviour for a Buffer class that I'm using. For example: void deepcopy(deepcopycontext& ctxt, const Buf& b) { if(!ctxt.contains(&b)) { Buf b2(b); // doesn't copy the buf data, just holds a shared ptr internally. Data is only cloned when b/b2 is written to ctxt.insert(&b, b2); } } I attempted to model this a while ago using boost.serialize, but it turned out pretty clunky, I started needing a few decorator classes for special cases, etc. Apologies for the oversimplified examples above, just wanting to get interest in the jist of it. Please let me know if this overlaps with existing boost functionality also (I'm not aware of anything atm). Feedback appreciated. Thx, Allan

9 18

[ratio] Request for permission to merge to release branch
by Vicente J. Botet Escriba 02 Nov '11

02 Nov '11

Hi, I want to merge https://svn.boost.org/trac/boost/changeset/75240 to the release branch. The modifications are minor and correct to tickets: https://svn.boost.org/trac/boost/ticket/5724 and https://svn.boost.org/trac/boost/ticket/6082. Best, Vicente

3 3

[multi_array] Ticket#4874 "multi_array compile errors using Visual C++ 2010 in debug mode"
by Stephan T. Lavavej 02 Nov '11

02 Nov '11

Hi Boost devs, VC10 users are occasionally encountering https://svn.boost.org/trac/boost/ticket/4874 and reporting it to MS. For example, see http://connect.microsoft.com/VisualStudio/feedback/details/687655/compilati… where I've explained what's going on (I wrote this analysis back in Feb 2010 and I believe it's still correct): The problem is that multi_array iterators report themselves as input iterators, which can't be written to (e.g. as the destination of a copy()). Under IDL=0, copy() doesn't actually care how its destination iterator is marked with an iterator category tag, it just tries to write to the destination iterator, and that works. Under IDL > 0, copy() wants to know whether its source and destination iterators are both random-access, in which case it can perform a range check and unwrap the destination iterator for increased performance. It does this by overloading foo(input_iterator_tag, output_iterator_tag) and foo(random_access_iterator_tag, random_access_iterator_tag) and calling foo(category(source), category(destination)). If both source and destination are random-access, both overloads are viable (i.e. callable) and the second overload is preferred, so it's actually called. Otherwise, source is required to be at least an input iterator (maybe stronger) and destination is required to be at least an output iterator (maybe stronger) so the first overload must be viable and the second overload will be non-viable, so the first overload wins by default. However, if the destination is not marked as an output iterator or stronger, then the first overload is non-viable as well as the second, so overload resolution fails and boom. Thanks, Stephan T. Lavavej Visual C++ Libraries Developer

2 1

boost mapped_file issue
by dophine 02 Nov '11

02 Nov '11

Hi all, I try to use memory map file. However, I don't know why the readsome return 0. It is fine if I use getline. int main(int argc,char *argv[]) { boost::iostreams::mapped_file_source source(argv[1]); boost::iostreams::stream<boost::iostreams::mapped_file_source> input(source); while(!input.eof()) { char b[1]; streamsize iRet = input.readsome(b, 1); cout << iRet << endl; cout << b[iRet]; } //std::string line; //while(std::getline(input, line)) { // std::cout << "Line: " << line << std::endl; //} return 1; } -- View this message in context: http://boost.2283326.n4.nabble.com/boost-mapped-file-issue-tp3971495p397149… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[locale] Premission to merge clang bugfix changeset to release tree
by Artyom Beilis 02 Nov '11

02 Nov '11

Hello, I'd like to ask a permission to merge a changeset 75174 from trunk to release tree. It is a fix of build issue under clang-2.9 and clang-3.0. See: https://svn.boost.org/trac/boost/changeset/75174 The changeset itself: ------------------------- Index: /trunk/libs/locale/src/posix/codecvt.cpp =================================================================== --- /trunk/libs/locale/src/posix/codecvt.cpp (revision 73382) +++ /trunk/libs/locale/src/posix/codecvt.cpp (revision 75174) @@ -135,5 +135,5 @@ // maybe illegal or may be double byte - char inseq[3] = {seq0 , begin[1], 0}; + char inseq[3] = { static_cast<char>(seq0) , begin[1], 0}; char *inbuf = inseq; size_t insize = 3; ------------------------- It solves build issues as I can see at trunk tests. Thanks, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 2

[atomic] comments
by Tim Blechmann 01 Nov '11

01 Nov '11

hi helge and others, ... has been rather quiet about the boost.atomic review, so i want to raise a view issues: shared memory support: the fallback implementation relies on the spinlock pool that also used by the smart pointers. however this pool is per-process, so the fallback implementation won't work in shared memory. can this be changed/fixed? atomic::is_lock_free(): is_lock_free is set to either `true' or `false'. however in some cases, there are alignment constraints (iirc, 64bit atomics on ia32/x86_64 require a 64bit alignment). afaict there are not precautions to take care of this, are there? compile-time vs run-time dispatching: some instructions are not available on every CPU of a specific architecture. e.g. cmpxchg8b or cmpxchg16b are not available on all ia32/x86_64 cpus. i would appreciate if these instructions would not be used before performing a CPUID check, whether these instructions are really available (at least in a legacy mode) cmpxchg16b: currently cmpxchg16b doesn't seem to be supported. this instruction is required for some lock-free data structures (e.g. there is a dequeue algorithm, that requires a pair of tagged pointers). maybe this can be a starting point to discuss boost.atomic ... cheers, tim

6 38

Re: [boost] [atomic] comments
by Helge Bahmann 01 Nov '11

01 Nov '11

> > > > > e.g. i would not trust on accessing sockets from a > > > > > real-time thread. > > > > > > > > what makes you believe that message channels in real-time systems > > > > were > > > > designed so dumb as to make them unusable for real-time purposes? > > > > > > life would be so much easier for me, if the users of my software would > > > not run on off-the-shelf operating systems ;) > > > > and what makes you believe that the performance characteristics of > > sockets in off-the-shelf operating systems is unsuitable for real-time, > > while the process scheduling characteristics of process scheduling in > > off-the-shelf operating systems is suitable for real-time? > > i cannot comment on windows, but both osx and linux provide ways to > schedule a thread at a priority that it won't be preempted by any other > thread, so the process scheduler won't interfere. that answers the second part but not the first (and is getting off-topic from atomic operations) > > > > right, but the standard implementation for gcc does not use a > > > > spinlock > > > > per object (see __atomic_flag_for_address) which turns all of this > > > > moot - there is NO guarantee for std::atomic to be safe > > > > interprocess, period> > > > > > > well, i'd say this is a problem of gcc's implementation of std::atomic. > > > this doesn't justify that boost.atomic does not follow the suggestion > > > of the standard. > > > > the standard says "should" not "must" -- the gcc guys have not made this > > decision without good reasons, and I agree with these reasons > > > > note that there is also trouble lurking with run-time selection of > > whether something like atomic<uint64_t> is atomic via cmpxchg8b: do you > > really want to make this at minimum 12 bytes in size (though effectively > > occupying 16 due to alignment) just to save the room for the > > rarely-if-ever used per-object spinlock? same with atomic<128> and > > cmpxchg16b ? > > i don't really care about the size of an atomic<>. but I *do* care and believe it or not there are people writing applications that are memory-bound (doubling the overhead of the reference count in each of several millions of objects is *not* funny) > one other point for > runtime selection is compatibility. e.g. you may have two binaries, one is > compiled with support for double-width CAS, the other one without. with > compile-time dispatching the behavior would be undefined, with run-time > selection, it would be handled gracefully ... I don't quite understand the point -- quite obviously nothing good will happen if the applications do not agree on a protocol, and there is nothing that can be salvaged if they do agree on the objects being lock-free, fine if they do agree on the objects not being lock-free, well then explicit locking is faster anyways and you should use your "locked" reference implementation of the data structure that you surely wrote to run suitable regression tests of your lock-free data structure > > 2. What is wrong with implementing boost::interprocess::atomic<T> that > > specializes to boost::atomic<T> when possible and uses an interprocess > > lock otherwise? > > will you provide an implementation? people were asking for > boost::interprocess support during the boost.lockfree review. the only > missing feature is the atomic<> implementation. no problem Best regards Helge

1 0

[config] clang.hpp is not up-to-date
by Michel Morin 01 Nov '11

01 Nov '11

boost/config/compiler/clang.hpp is not up-to-date. For example, BOOST_NO_AUTO_DECLARATIONS is *always* defined (even if clang supports this feature). Is it worth fixing this on the release branch? P.S. I can make a patch, but before doing that I'd like to confirm whether __has_feature(cxx_auto_type) means that multi-declarator auto is supported or not. The following page says nothing about multi-declarator auto. http://clang.llvm.org/docs/LanguageExtensions.html Doug? Regards, Michel

3 4

Silly Boost.Locale default narrow string encoding in Windows
by Alf P. Steinbach 01 Nov '11

01 Nov '11

When I engage the compiler-in-my-mind to the example given at http://cppcms.sourceforge.net/boost_locale/html/ namely <code> #include <boost/locale.hpp> #include <boost/filesystem/path.hpp> #include <boost/filesystem/fstream.hpp> int main() { // Create and install global locale std::locale::global(boost::locale::generator().generate("")); // Make boost.filesystem use it boost::filesystem::path::imbue(std::locale()); // Now Works perfectly fine with UTF-8! boost::filesystem::ofstream hello("שלום.txt"); } </code> then it fails to work when the literal string is replaced with a `main` argument. A conversion is then necessary and must be added. It breaks the principle of least surprise. It breaks the principle of not paying for what you don't (want to) use. I understand, from discussions elsewhere, that the author(s) have chosen a narrow string encoding that requires inefficient & awkward conversions in all directions, for political/religious reasons. Maybe my understanding of that is faulty, that it's no longer politics & religion but outright war (and maybe that war is even over, with even Luke Skywalker dead or deadly wounded). However, I still ask: why FORCE INEFFICIENCY & AWKWARDNESS on Boost users -- why not just do it right, using the platforms' native encodings. Cheers, - Alf

9 43

[unordered] 1.48 beta1 fails to compile with MSVC 2010 SP 1, error C2027: use of undefined type 'boost::type'
by Johan Lindvall 01 Nov '11

01 Nov '11

After trying out beta 1, I am seeing some failures with unordered containers, see attached file. Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 The code compiles without problems under 1.47.0. Unfortunately, I cannot yet publish the source code that triggers this problem. Any hints where to start investigating this? -- /Johan.

2 5

[multi_array] typed subarray from raw memory
by Maxim Yanchenko 01 Nov '11

01 Nov '11

Hi, While using multi_array, I found I frequently need a way to view some memory which is a multi-dimensional array and I don't know the type of the element, but I know its size and I know that this element has a member of the type I need (and I know the offset). So I need to be able to write something like struct A { double x, y; }; void* p = mmap(...); size_t el_size = size_of_element_in_p; size_t offset = offset_of_A_inside_element; boost::multi_array_typed_view<A, NumDims> my_view(p, extents, el_size, offset ); and have a standard multi_array-compatible interface. Also, with existing multi_arrays of known types, this feature will give a way to create views of element's members (the closest we have now is a strided view but it only works if the element size is a multiple of the member size). I filed a Feature Request for multi_array (https://svn.boost.org/trac/boost/ticket/6073) but I wonder if there are any other possibilities around, and I'd also like to know what the community think of necessity of this feature. Thanks, Maxim

1 0