- Boost-users - lists.boost.org

compact matrix/dense vector product
by Daniel L Elliott 13 Nov '04

13 Nov '04

Hello, I am using the CVS Head version of uBLAS from approximately one month ago with gcc. I get a ton of errors when trying to multiply a dense vector by a compact matrix. This is what my code looks like: la::compressed_matrix<int>* permutationMatrix; template<class T> void Permutation::apply(la::vector<T>& dataPoint){ dataPoint = prod(*permutationMatrix,dataPoint); } What, conceptually, am I doing wrong? If asked, I will happily provide more information. For now, I am trying to keep this email to a reasonable size. Thank you, -- dan ************************** Dan Elliott 402-210-6429 (me) or 402-210-6735 (amy) dan_elliott(a)cox.net **************************

1 0

boost::function and equality operators?
by Alo Sarv 12 Nov '04

12 Nov '04

Hi I was just transforming my event engine from another callback functors lib to boost::function, and discovered that boost::function has explicitly forbidden operator== and operator!=. My question is why is this done, and what could be possible workarounds? Thanks in advance, Alo Sarv. Example: #include <boost/function.hpp> #include <cassert> void foo() {} void bar() {} int main() { // won't compile if these are used in the below asserts // boost::function<void()> f(&foo); // boost::function<void()> g(&bar); // boost::function<void()> h(&foo); // works with raw function pointers void (*f)() = &foo; void (*g)() = &bar; void (*h)() = &foo; assert(f == h); assert(f != g); assert(g != h); }

1 0

New trouble compiling with MS VC6 SP5 and MFC/AFX
by Arno Schäfer 12 Nov '04

12 Nov '04

Hi, if I want use the boost libs in an existing MFC/AFX environment I have a lot of compiling problems, what seems to depend on the order of includes. One problem what I see, but I don't understand, is the following compile error: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. cl /MDd /W3 /GR /GX /Zi /Od /I ...bunch of includes... /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_SECDLL" /D "_AFXDLL" /D "_ MBCS" /D "_GXDLL" /D "NOMINMAX" /D "_SECNOMSG" /D "_GXNOMSG" /D "_SFLNOMSG" /Fp" D:\temp\debug\GUIClient/Plato.pch" /YX"stdafx.h" /Fo"D:\temp\debug\GUIClient/" / Fd"D:\temp\debug\GUIClient/" /FD /Zm200 /GZ /c "F:\Gui+Client\src\AboutDlg.cpp" AboutDlg.cpp Note: Using precompiled header Automatically linking with RWUXThemeSD.lib ..\..\PlatoServer\Basics\boost\inc\boost/detail/iterator.hpp(326) : error C2039: 'difference_type' : is not a member of 'Iterator' ..\..\..\libs\stingray\objective_studio\include\foundation\Patterns\Iter ator.h(77) : see declaration of 'Iterator' ..\..\PlatoServer\Basics\boost\inc\boost/detail/iterator.hpp(331) : see reference to class template instantiation 'boost::detail::standard_iterator_traits<Iterator>' being compiled ... So it looks like, that the template parameter "Iterator" in "boost::detail::standard_iterator_traits<Iterator>" conflicts with the template class "stingray::foundation::Iterator" in some header files from the GUI control stuff, what was included before the boost header. How is this possible, what has the template parameter "Iterator" in the namespace "boost::detail" to do with the template class "Iterator" in the namespace "stingray::foundation" has anybody an explaination for this? regards Arno

3 3

[boost][boost-users][random] Open bugs
by Cromwell Enage 12 Nov '04

12 Nov '04

Any chance that any of the following bug reports will be resolved before the release? <http://sourceforge.net/tracker/index.php?func=detail&aid=911758&group_id=75…> <http://sourceforge.net/tracker/index.php?func=detail&aid=715667&group_id=75…> <http://sourceforge.net/tracker/index.php?func=detail&aid=652567&group_id=75…> TIA! Cromwell Enage __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

5 6

Some trouble with "regex_replace()"
by Arno Schäfer 12 Nov '04

12 Nov '04

Hi all, Using "regex_replace(string, pattern, replace_string, flags)" I got some unwished results. I can't find out what flag set I have to use, that the replacement string was taken, as it is. I think this short example should make my problem clear: Replace in a string all occurences of PATH through the actual windows directory: "Actual path: 'PATH'" with Path "D:\temp\rest" leads to the string: "Actual Path: 'D: emp est'" This show, that "\t" and "\r" was interpreted. For me that is an unexspected behaviour, because the replacement is just some string, not more. I understand that the pattern will be interpreted and controlled over the flags, but why the replacement string? Can somebody explain that behaviour and show me a way out? regards Arno

3 9

Re: [ANN] Format Lite
by Jonathan D. Turkanis 12 Nov '04

12 Nov '04

"Pavel Vozenilek" <pavel_vozenilek(a)hotmail.com> wrote in message news:cn0l08$cul$1@sea.gmane.org... > > "Jonathan Turkanis" wrote: > > > > // specialization for debug formatting > > > template<> > > > void serialize<formatted_text_oarchive>(....) { > > > > I believe this specialization is illegal. You could write > > > > void serialize(formatted_text_oarchive&ar, const unsigned) > > > > but I can't say whether this will work (I seem to remember Robert saying > > somewhere in the documentation that he was relying on the fact that > > non-templates are better matches than templates.) > > > Yes, this (nontemplated overloaded function) will work. > I just wrote down an idea in haste. > > > > I have two separate ideas for formatting libraries: > > > > - one lightweight, which I posted, for input and output of ranges and > > tuples-like objects > > - one for output only, which allows much more customization; I see this as > > an inverse of Spirit > > > > Your suggestion looks similar to the second (except that you want to > > support input), so let me sketch my idea (which has improved since I > > sketched it here last time), and then ask some questions about yours. > > > Formatted input would be optional (and maybe not practical). > > I do not understand what are avantages of the "lightweight" > approach (except compile time). The aim of Format Lite was to present a facility which would be a candidate for standardization, filling a need that was expressed at the most recent library working group meeting. Towards this end, 1. I tried to keep the implementation as small as possible 2. I introduced just one new function template -- punctuate() -- in the public interface 3. I used the same syntax currently recommended for formatting user-defined types (overloading iostreams operators >> and <<) 4. I introduced no new class templates in the public interface 5. I introduced no new concepts. (Strictly speaking, I use Single Pass Range and Extensible Range, but these could be replaced by the standard library container concepts.) If people like the interface (and so far there's not much evidence), I think Format Lite would stand a reasonable chance of making it into TR2. To get Serialization standardized would require a much bigger push, IMO, although I'd like to see it happen -- perhaps with additional language support. > Is switch between lightweight and heavyweight solution easy? Yes, since formatting with Format Lite would still be the default when a Style provides no specific formatting options for a given range or tuple-like type. In the following vector< string > v = list_of( ... ); ostream out; styled_ostream<cajun_style> cajun_out(out); cajun_out << v; If none of the Styles or Formatters associated with cajun_style knows how to format a vector, cajun_out will delegate formatting to the underlying ostream out, which will use the operator<< from Format Lite. > [snip] > > The advantages of this approach are: > > > > - an arbitrary amount of contextual information, such as indentation > > and numbering, can be stored in the styled_stream and accessed directly > > by formatters > > - arbitrary user-defined types can be formatted non-intrusively > > - flexible formatting is built-in for sequences and tuple-like types (and > > user-defined types can choose to present themselves as sequences or > > tuple-like types to take advantage of this feature.) > > > I feel having formatting descendant of boost::archive stream > could be made with the same features. Good. > > > The advantages I see: > > > - the whole infrastructure of Boost.Serialization is available and > > > ready and it handles all situations like cycles. format_lite could > concentrate on just formatting. > > > > This is a big plus, obviously. (However, I remember Robert saying her > > prefered to keep formatting and serialization separate.) > > > Formatting, as I see it would just use Serialization as > infrastructure. There would be no inpact on Serialization > from Formatting. You mean no changes to the library code -- we would just define additional archive concepts and types? > > > - formatting directives can be "inherited" from > > > "higher level of data" to "lower levels". Newly added data would > > > not need formatting of its own by default. Change on higher level > > > would propagate itself "down". > > > > Can you explain how this works? > > > I mean trick with RAII (its not really Serialization feature): > > void serialize(formatting_archive& ar, const unsigned) > { > // change currently used formatting style > formatting_setter raii(ar, "... formattng directives...") > ar & data; <<== new formatting style will be used > // destructor of raii object will revert formatting back > } I see. I think this is a characteristic of all schemes where stylistic info is stored in the stream or stream-like object. > > > - indentation for pretty printing could be handled (semi)automatically > > > by formatting archive. > > > > Would this involve modifying the archive interface? I'd like a formatter > > for a given type (or an overloaded serialize function) to be able to access > > these properties directly. > > > Yes, formatting archive could have any additional interface. I see. But no changes to existing archive types. > > > - multiple formatting styles could be provided for any class. > > > > It would be one formatting style for each archive type for which serialize > > has been specialized, correct? Would this allow styles for various types to be > > mixed freely? > > > Yes, serialize() function would be specialized. What I meant to ask can be illustrated by an example. Suppose you have two classes, Duck and Goose. Duck and Goose each have two associated formatting styles. The choice of styles should be independent, so we would need four archive types to handle the various combinations. Now my question is: would Duck need four specializations of serialize, or just two? In my system, formatting options for Duck and Goose could be added to a Style independently; I want to know if overloading serialize can handle this. > I see three ways to customize output: > > 1. Formatting archive has its own configuration how > to output data. This keeps overall style coherent > and should be enough for most uses. > > 2. Specialization of serialize() could change > formatting style. This may be used to fine > tune the output here or there. > > 3. Specializations of serialize() may generate > different outputs altogether. > > E.g. if you have archives: > class high_level_formatting_archive {...} > class all_details_formatting_archive { ... } > > you can omit details in > > void serialize(high_level_formatting_archive& ar, const unsigned); > > and use them all in > > void serialize(all_details_formatting_archive& ar, const unsigned); > > I think this (option 3) is not possible now with format_lite. In fact, it only supports 1. That's part of what makes it 'lite'. If a class already provides standard library inserters and extractors (corresponding to 2, above), those provided by Format Lite will not be called. I have a couple of questions: 1. Is your idea flexible enough to allow pairs (a,b) to be formatted with the elements in reverse order? 2. If a type defines a member function serialize, can it be bypassed altogether in favor of an end-user supplied formatting style? > > My inclination is to > > keep formatting separate from serialization, though, because they have different > > aims. If you believe they can be integrated, without making serialization harder > > to learn or sacrifying flexibility of formatting options, it should definitely be > > considered. > I see Serialization as just vehicle, ready and handy and almost > invisible to Formatting users. > Simple data structures are very easy with Serialization and should > be as easy as with format_lite now. > If user tries to format tricky structures (e.g. pImpl) he would need > to dig into Serialization docs but at least there will be chance to > make the whole thing work. The Serialization goes to great lengths > to work under any situation and configuration. This sounds quite reasonable, provided it is sufficiently flexible. I wonder how much of the Serialization infrastructure is really needed, though. Detecting cycles is defintely not something I want to reimplement; OTOH, I'm not sure it's needed for pretty-printing. I haven't looked at the Serialization implementation, but I did read the Java serialization specification several years ago. IIRC, when an object was encountered for the second time, some sort of placeholder would be inserted in the stream referencing the already serialized data. I assume the Serialization library does something like this. Would this really be desirable for human-readable output? Perhaps the formatting library should concern itself only with cycle-free data structures. > /Pavel Jonathan

1 0

Re: Re: boost graph library bugs
by qyang＠cs.ucr.edu 11 Nov '04

11 Nov '04

>> >Below is a list of bugs (at least I think so) in boost graph library: >> > >> >... >> > >> >I found the above problems when I tried to create subgraphs for each >> >component in the graph when the number of components was large. > > > >> It always helps to identify the compiler and it's version number, the >> operating system, and to indicate the version of the Boost code (or CVS, >> if that was the source.) > > > Hi, > > The compiler is: > g++ (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > The OS is: > Linux version 2.6.7-1.494.2.2 > (Fedora Core release 2 (Tettnang)) > > The boost code (I think) is: > boost_1_31_0 > (I will update this one once I have the reply from system administrator) > Hi, The boost code version is: boost-1.31.0-7 boost-devel-1.31.0-7 Qiaofeng

1 0

lambda lib (1.31) and MSDEV 6.0
by Martin Lemieux 11 Nov '04

11 Nov '04

When compiling a sample file, the compiler crashed at line: #include <boost\lambda\lambda.hpp> The message is as follow: test.cpp c:\boost\include\boost-1_31\boost\lambda\detail\lambda_fwd.hpp(31): fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Error executing cl.exe. Although I did build the complete boost library with the same compiler, I was surprised not to be able to use the lambda lib in a simple application. Did this happen to any of you? Did you find any solution or alternative? Thank you.

1 0

[boost-users][BGL] prim_minimum_spanning_tree
by Cromwell Enage 11 Nov '04

11 Nov '04

According to the source, all variants of the function template take in a const reference to Graph, but the docs state that the non-named-parameter variant takes in a regular Graph reference. There is also no mention of the two-parameter variant that takes in only a const Graph& and an output PredecessorMap. Is this a documentation bug? Cromwell Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

newbie: graph library support vertex with x, y coordinates
by TC MA 11 Nov '04

11 Nov '04

This is a newbie question. Do boost graph library support an vertex with x, y coordinates? i.e. typedef std::pair<int, int> Vertex; I modify the dijkstra-example.cpp sample program in the libs/graph/example directory but it fails to compile. // new dijkstra-example.cpp int main(int, char *[]) { typedef adjacency_list < listS, vecS, directedS, no_property, property < edge_weight_t, int > > graph_t; typedef graph_traits < graph_t >::vertex_descriptor vertex_descriptor; typedef graph_traits < graph_t >::edge_descriptor edge_descriptor; typedef std::pair<int, int> Vertex; typedef std::pair<Vertex, Vertex> Edge; const int num_nodes = 5; enum nodes { A, B, C, D, E }; char name[] = "ABCDE"; Vertex a = Vertex(0, 0); Vertex b = Vertex(1, 2); Vertex c = Vertex(2, 2); Edge edge_array[] = { Edge(a, b), Edge(a, c) }; int weights[] = { 1, 200 }; int num_arcs = sizeof(edge_array) / sizeof(Edge); graph_t g(edge_array, edge_array + num_arcs, weights, num_nodes); property_map<graph_t, edge_weight_t>::type weightmap = get(edge_weight, g); std::vector<vertex_descriptor> p(num_vertices(g)); std::vector<int> d(num_vertices(g)); vertex_descriptor s = vertex(A, g); dijkstra_shortest_paths(g, s, predecessor_map(&p[0]).distance_map(&d[0])); std::cout << "distances and parents:" << std::endl; graph_traits < graph_t >::vertex_iterator vi, vend; for (tie(vi, vend) = vertices(g); vi != vend; ++vi) { std::cout << "distance(" << name[*vi] << ") = " << d[*vi] << ", "; std::cout << "parent(" << name[*vi] << ") = " << name[p[*vi]] << std:: endl; } std::cout << std::endl; return EXIT_SUCCESS; } // compile output is: bjam ...found 518 targets... ...updating 4 targets... gcc-C++-action /home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on/dijkstra-example.o /home/tcma/cpp/boost_1_31_0/boost/graph/detail/adjacency_list.hpp: In constructor `boost::vec_adj_list_impl<Graph, Config, Base>::vec_adj_list_impl(typename Config::vertices_size_type, EdgeIterator, EdgeIterator, EdgePropertyIterator) [with EdgeIterator = main(int, char**)::Edge*, EdgePropertyIterator = int*, Graph = boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>, Config = boost::detail::adj_list_gen<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>, boost::vecS, boost::listS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>::config, Base = boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>, boost::vecS, boost::listS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>::config>]': /home/tcma/cpp/boost_1_31_0/boost/graph/adjacency_list.hpp:363: instantiated from `boost::adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>::adjacency_list(EdgeIterator, EdgeIterator, EdgePropertyIterator, typename boost::detail::adj_list_gen<boost::adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, VertexListS, OutEdgeListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>::type::vertices_size_type, typename boost::detail::adj_list_gen<boost::adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, VertexListS, OutEdgeListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>::type::edges_size_type, const GraphProperty&) [with EdgeIterator = main(int, char**)::Edge*, EdgePropertyIterator = int*, OutEdgeListS = boost::listS, VertexListS = boost::vecS, DirectedS = boost::directedS, VertexProperty = boost::no_property, EdgeProperty = boost::property<boost::edge_weight_t, int, boost::no_property>, GraphProperty = boost::no_property, EdgeListS = boost::listS]' /home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.cpp:146: instantiated from here /home/tcma/cpp/boost_1_31_0/boost/graph/detail/adjacency_list.hpp:1904: error: no matching function for call to `add_edge(main(int, char**)::Vertex&, main(int, char**)::Vertex&, int&, boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>&)' /home/tcma/cpp/boost_1_31_0/boost/graph/detail/adjacency_list.hpp:599: note: candidates are: std::pair<typename boost::directed_graph_helper<Config>::edge_descriptor, bool> boost::add_edge(typename Config::vertex_descriptor, typename Config::vertex_descriptor, const typename Config::edge_property_type&, boost::directed_graph_helper<Config>&) [with Config = boost::detail::adj_list_gen<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>, boost::vecS, boost::listS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>::config] /home/tcma/cpp/boost_1_31_0/boost/graph/detail/adjacency_list.hpp:1987: note: std::pair<typename Config::edge_descriptor, bool> boost::add_edge(typename Config::vertex_descriptor, typename Config::vertex_descriptor, const typename Config::edge_property_type&, boost::vec_adj_list_impl<G, C, B>&) [with Graph = boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>, Config = boost::detail::adj_list_gen<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>, boost::vecS, boost::listS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>::config, Base = boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>, boost::vecS, boost::listS, boost::directedS, boost::no_property, boost::property<boost::edge_weight_t, int, boost::no_property>, boost::no_property, boost::listS>::config>] set -e g++ -c -Wall -ftemplate-depth-100 -g -O0 -Wno-inline -I"../../../bin/boost/libs/random/test" -I "/home/tcma/cpp/boost_1_31_0" -o "/home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on/dijkstra-example.o" "/home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.cpp" /usr/bin/objcopy --set-section-flags .debug_str=contents,debug "/home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on/dijkstra-example.o" ...failed gcc-C++-action /home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on/dijkstra-example.o... ...removing /home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on/dijkstra-example.o ...skipped </home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on>/home/tcma/cpp/boosttcma/libs/graph/dijkstra-example for lack of </home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on>dijkstra-example.o... ...skipped </home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on>/home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.run for lack of </home/tcma/cpp/boosttcma/libs/graph/dijkstra-example.test/gcc/debug/inlining-on>/home/tcma/cpp/boosttcma/libs/graph/dijkstra-example... ...failed updating 1 target... ...skipped 3 targets... ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

2 1