- Boost-users - lists.preview.boost.org

Troubling building Boost for Borland C++ Builder 6
by Edward Diener 25 Jul '05

25 Jul '05

When building Boost for C++ Builder 6 and Boost 1.32, the serialization libray fails to build. The reason for this is that it attempts to use the latest Spirit header files and this does not support C++ Builder 6. What makes this doubly annoying is that the only reason that serialization needs to use Spirit is to support XML serialization. So even if I will never be using serialization for XML serialization, but will use it for the more mainstream binary serialization, I can not use this library with C++ Builder 6. Clearly this is a case for a built library to be split up into sub-libraries, so that there would be a built serialization library supporting binary serialization, which would not be dependent on Spirit, and a built serialization library supporting XML serialization, which would be dependent on Spirit. In this case I would be able to build the library that did not depend on Spirit for C++ Builder and I would not care, if I never used XML serialization, whether or not the library that was built to support XML serialization could be built for C++ Builder 6. In the serialization documentation it says that one can build serialization so that it can be used with C++ Builder 6 by downloading the standalone version of Spirit 1.6, installing that, and setting the SPIRIT_ROOT environment variable to the directory where Spirit 1.6 is installed. Despite having done this, any attempt to build serialization for C++ Builder 6 ends with error messages showing that header files for Spirit in the main Boost directory, rather in the Spirit 1.6 directory, are being used in the process to build the serialization library. The error message comes from spirit/core/config.hpp in my Boost 1.32 directory tree that C++ Builder 6 is not supported. In the Spirit 1.6 distribution there is no spirit/core/config.h. While I understand that a particular library may not want to support a particular compiler/version because that compiler is deficient in the C++ standard requirments to support that library, I feel that if a library is marked as supporting a compiler/version it should do so. In the case of serialization in Boost 1.32 it is marked as supporting C++ Builder 6 when clearly it does not according to my efforts.

4 12

minimal spanning trees & Visual C++ 7.1
by Amit K. Jain 24 Jul '05

24 Jul '05

Hello, I've got the latest version of Boost set up w/ Visual C++ 7.1. When I try to compile kruskal-example.cpp or prim-example.cpp, I get an internal compiler error on properties.hpp:216. I'm reasonably sure that I have Boost set up properly because I can use the strongly connected components stuff w/ adjacency lists just fine. Has this happened to anyone else and, if so, does anyone know how to work around it? Thanks in advance -Amit

1 0

help with integral type conversion trait
by Slawomir Lisznianski 24 Jul '05

24 Jul '05

Hello, I'm looking for a way to convert an integral type into its unsigned equivalent. For example, assume a trait called to_unsigned_integral such that: to_unsigned_integral<int>::type ---> yields unsigned int to_unsigned_integral<short>::type ---> yields unsigned short to_unsigned_integral<unsigned char>::type ---> yields unsigned char ... Regards, Slawomir

2 2

Missing functions in date_time library
by Sean Rohead 23 Jul '05

23 Jul '05

I am using the boost date_time library and noticed that there is a from_ftime() function to convert a FILETIME into a ptime, but I could not find the reverse operation to_ftime(). Am I missing it somewhere? Likewise, I am using the c_local_adjustor::utc_to_local() function and cannot find the corresponding local_to_utc() function in c_local_adjustor. Thanks, Sean

2 1

Re: [Boost-users] Can't create time_duration with milliseconds onVS.NET 2003
by Sean Rohead 23 Jul '05

23 Jul '05

Thank you! I also discovered that this works: time_duration t(8, 45, 0, milliseconds(100).fractional_seconds()); Sean -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: Thursday, July 21, 2005 9:37 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Can't create time_duration with milliseconds onVS.NET 2003 On Thu, 21 Jul 2005 18:37:32 -0600, Sean Rohead wrote > I am using VS.NET 2003 and attempting to create a time_duration > using hours, minutes, seconds, and milliseconds. > > However, I get an error message regarding the 4th parameter > (milliseconds). > > Here is my code and the error message: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > // main.cpp > > #include "boost/date_time/posix_time/posix_time.hpp" > > using namespace boost::posix_time; > > void main() > { > time_duration t(8, 45, 00, milliseconds(100)); > } The error is valid. Milliseconds is-a time-duration so you don't pass it as the fourth parameter. Add it instead. Something like: Try this instead: time_duration t(8, 45,0); t += milliseconds(100); or even clearer: time_duration t = hours(8) + minutes(45) + milliseconds(100); Jeff _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Trouble building Boost for Comeau
by Edward Diener 23 Jul '05

23 Jul '05

When I attempt to build the Boost libraries for the Comeau compiler using vc71 as my backend, each build line fails with: "Command-line error #595: too many arguments on command line" Is there a workaround to this problem ? I am surprised to see that for compilers which support the use of a file to hold command line parameters the build process does not use this technique, which leads to such an error.

2 3

boost cvs acces?
by Serge Skorokhodov 23 Jul '05

23 Jul '05

Hi, Something real bad happend with access to :pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost:( 'unrecognized auth responce from cvs.sourceforge.net' I've found no clues on boost site and on sourceforge site. Any help? TIA -- Serge

2 1

nontemplate iterators
by Mike Gibson 23 Jul '05

23 Jul '05

Does such a thing exist? So you could the following (with some_iterator begin the 'thing'): template <typename Value> class some_iterator { ...magic... }; void f(some_iterator<int> begin, some_iterator<int> end) { ...do something cool with begin and end... } int double_int(int i) { return i * 2; } int main() { std::vector<int> vec_int; ...fill vec_int... f( make_some_iterator(vec_int.begin()), make_some_iterator(vec_int.end())); f( make_some_iterator( make_transform_iterator(vec_int.begin(), double_int)), make_some_iterator( make_transform_iterator(vec_int.end(), double_int))); std::deque<int> deq_int; ...fill deq_int... f( make_some_iterator(deq_int.begin()), make_some_iterator(deq_int.end())); }

2 1

[Filesystem] path refuses "foo\bar" on win32/mingw
by Alo Sarv 23 Jul '05

23 Jul '05

When passing "foo\bar" to boost::filesystem::path constructor, it is accepted when compiled with MSVC, but is refused when compiled with mingw-gcc (v3.4.2). "foo/bar" argument is accepted with both compilers. Test-case: #include <boost/filesystem/path.hpp> #include <iostream> using namespace boost::filesystem; using namespace std; int main(int argc, char *argv[]) { path::default_name_check(native); try { path p1("foo/bar"); cerr << "ok - constructed from 'foo/bar'" << endl; } catch (std::exception &e) { cerr << e.what() << endl; } try { path p1("foo\\bar"); cerr << "ok - constructed from 'foo\\bar'" << endl; } catch (std::exception &e) { cerr << e.what() << endl; } return 0; } Compiled with: g++ -I c:\boostcvs\include\boost-1_33 -L c:\boostcvs\lib test-path.cpp -o test-path -lboost_filesystem-mgw-d Tested against: Boost 1.32 release, CVS HEAD Is it a bug in FS library, or I'm doing something wrong? One would expect native paths be accepted by path with native namechecker, and I can't see any mingw/msvc-specific code in FS library, which could explain why it works with one compiler, but not with other compiler... Alo

2 2

performance issue with graph edge removal
by Feldman, Yulik 22 Jul '05

22 Jul '05

Hi, Our project has recently run into severe performance issue with remove_edge() function of Boost graph. In our particular case, we use adjacency list specialized as: typedef adjacency_list< listS, vecS, bidirectionalS, CdfgNodeProperty, CdfgEdgeProperty> CdfgType; At some point in the flow, we need to remove great amount of edges from the graph, an amount comparable to the total number of edges in the graph. Unfortunately, since the complexity of removal of each edge is about O(E/V) the complexity of removal of all edges is about O(E * E/V). This appears to be too much, when the number of edges is big. What is actually interesting about this situation, is that I see no way to remove all edges (let's say we need to remove all edges) with any Boost function and with any adjacency list specialization in O(E) complexity, not necessarily the one we're currently using. The O(E/V) complexity of the remove_edge() comes from the fact that there is a need to remove the edge from in/out edge lists of the vertices connected by the edge. Even though I know I will not need any of these lists after all edges are removed, remove_edge() doesn't know that, so it is doing the "extra" work of updating the lists one-by-one. Moreover, in case of edge lists such as vector/list/multiset, i.e. containers that allow parallel edges in the graph, the search is linear in the size of containers (resulting in O(E/V) complexity of the operation). The question is what can be done, in any way, to do this "simple" operation of removing all edges of the graph in "more reasonable" complexity O(E) instead of O(E * E/V)? It doesn't help to try to remove many edges at once, such as using clear_in_edges() function to remove all in-edges of the given node, or clear_vertex() to remove all edges of the given node, because these functions still have to remove all the edges being removed from the edge list of the connected nodes. This results in the same complexity of the operation, as with using repetitive remove_edge() calls. It also doesn't help using other containers for storing in/out edge lists, such as list or multiset, instead of vector. Although the removal operation is faster in these containers, the search operation that looks for the edge to be removed is still in the order of the size of the container. For containers such as set or hash set, the search operation is faster, but such containers do not allow parallel edges, since the edges are indexed by the node identifier on the other side of the edge. The search operation that looks for the edge to be removed is in the order of the size of the container because it is necessary to find all the parallel edges. Therefore, for implementations allowing parallel edges, the implementation goes over all edges stored in the container and checks whether the edge connects to the node whose edges are being removed (in case of clear_in_edges()/clear_vertex()). If it is, the edge is removed from the in/out edge list. In our graph implementation, we need to support parallel edges. Even without parallel edges, the total complexity of removal of all edges still can't be brought down to O(E) (only to O(E * log(E/V))). If I would be free to change Boost's graph implementation, one possible solution could be to store in each edge two iterators pointing to the position of this edge in the corresponding in/out edge lists. This would allow removal of the edge from "list" container in O(1). However, it doesn't seem to be possible to do with current Boost implementation. Still, even if it would be possible, the memory consumption would increase due to the storage of the two iterators (at least two additional extra pointers per edge). Another approach could be to index the edges in in/out edge lists by edge identifier (which is not a part of Boost graph infrastructure), instead of indexing them by node identifier. This would allow using "multiset" container to find the edges to remove faster (in logarithmic time). But this still doesn't seem to be possible to do with current Boost implementation and it will also incur a memory overhead (due to usage of complex container as multiset). And still the complexity will be more than O(E). Is there a way to remove all edges in O(E) complexity? Do I miss something, or there is an inherent performance issue in current Boost graph implementation with regard to the edge removal? Even if the current situation is by design due to memory consumption trade offs, I wish the graph implementation would be flexible enough to let the user control performance/memory balance, instead of requiring the performance hit. Or, at least, to provide an atomic function for removal of all edges of the graph, which can be easily implemented to work fast and without incurring any memory overhead with all underlying in/out edge container implementations (just clear all edge-related containers). Any thoughts are welcome. Thanks, Yulik.

3 2