- Boost-users - lists.boost.org

[BGL]: Getting the space used by a graph
by Nicola Vitacolonna 20 Dec '05

20 Dec '05

Hi, how can I accurately measure the memory used by an adjacency_list (per node, per edge, per property, overall)? Best regards Nicola Vitacolonna

2 1

Re: [Boost-users] Mutually exclusive options in boost::program_options?
by james.jones＠firstinvestors.com 20 Dec '05

20 Dec '05

Marshall Clow wrote: > The other one is that program_options, by default, wants to use > double hyphens to define options: > "foo --option1 --option2" > > I'm a lot more comfortable with single hyphens: > "foo -option1 -option2" I don't know about your other problem, but using single hyphens with long options is nonstandard. In most *nix programs, -option1 means the same thing as -o ption1, i.e. a -o with the argument "ption1". Whereas --option1 means what it says. Single hyphens are reserved for single-letter options. - James Jones Administrative Data Mgmt. (v)732-510-1806 375 Raritan Center Pkwy, Suite A (f)732-510-1855 Edison, NJ 08837 Visit us on the web at http://www.firstinvestors.com/

1 0

[variant] Proposal of compile-time checked get for variant
by Zara 20 Dec '05

20 Dec '05

[Note to moderator] I am not surte if previous version of this message will really go through, beacuase I was not yet subscribed to users list. Should that be the case, please forgive me. [End of note to moderator] Dear all, I have been doing a deep redesign of an old SW project, and in the course of it I have changed a typical struct {enum;union;} to boost:variant. This design change has surfaced some problems of the original SW, as there were lots of implicit/explicit casting when accesing the above mentioned struct. To detect and correct all this problems, I have found that boost::get working on boost:variant is not enough, it will only give either a null pointer or a bad_get exception when trying to access a variant with the wrong type. Even in the cases that the wrong type is unaccessible all the time, as it is not included in the variant list of types. IMHO, this should be detected at compile-time, as it denotes a design flaw, not a runtime access error. To cover this cases, I suggest the following addition to variant library, based on get definition: namespace boost { template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer<U>::type checked_get( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U) ) { typedef boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) > Variant; BOOST_STATIC_ASSERT((!is_same< typename mpl::find<typename Variant::types,U>::type, typename mpl::end<typename Variant::types>::type>::value)); typedef typename add_pointer<U>::type U_ptr; if (!operand) return static_cast<U_ptr>(0); detail::variant::get_visitor<U> v; return operand->apply_visitor(v); } } // end of addition to namespace boost And, of course, the rest of the templates needed for const *, ref and const&.. Best regards, -- Zara

1 0

TR: [Boost.Filesystem] Missing inline keywords in I18N branch
by Marc VIALA 20 Dec '05

20 Dec '05

Hi, Ive already sent this email but Ive not seen any reply, maybe Ive missed it. In order to take advantage of the I18N/HEAD CVS merging and after Ive checked that the inline declarations are always missed; I post again my corrections in convenience.hpp for decode_system_message () declaration and fstream.hpp for narrow_path() declaration, see the attached files for diff. Could you confirm these corrections? Best regards, Marc Viala, PhD Directeur Général/Directeur Technique 122 rue de la Roche-de-Lorzier 38430 MOIRANS Tél : +33 (0)4 76 91 37 60 Fax : +33 (0)4 76 35 00 07 <http://www.acticm.com> www.acticm.com <mailto:mviala@acticm.com> mailto:mviala@acticm.com _____ De : Marc Viala Envoyé : mardi 6 décembre 2005 21:54 À : 'boost-users(a)lists.boost.org' Objet : [Boost.Filesystem] Missing inline keywords in I18N branch Hi, Im not really sure but I think there are some missing inline declarations in convenience.hpp and fstream.hpp of Boost.fileystem for the I18N branch. Ive joined the patched files Could you confirm these observations? Marc Viala <http://www.acticm.com> www.acticm.com <mailto:mviala@acticm.com> mailto:mviala@acticm.com

2 1

Re: [Boost-users] Installation Complete Steps
by Phil Endecott 20 Dec '05

20 Dec '05

>>but the very first command rpm gives a conflict message with Debian >>files since I am using Ubuntu which is based on Debian or am I wrong? Umut, you have a choice: A. Download the source tar files and compile them. B. Install from .deb files. B should be easier and quicker than A. In theory you could install from .rpms, but I can't think of a reason why you would want to do that. I'm suprised that no-one who uses Ubuntu has replied with instructions for you. I don't use Ubuntu, so I can't give you exact step-by-step instructions. I use Debian. On Debian, installting Boost involves: # apt-get update # apt-get install libboost-dev libboost-thread-dev libboost-program-option-dev ..... (Boost is split into several .deb packages, so you only need to install the parts that you will be using. For a list you could go to packages.debian.org and search for packages whose name contains "boost".) I expect that on Ubuntu you should use very similar, or possibly exactly the same, commands. Alternatively, you may have a graphical package installer program that you can use. On the other hand, if it turns out that Ubuntu doesn't have Boost packages, then you could install the Debian ones. The best way to find out how to do that would be to ask in an Ubuntu forum or list somewhere. I hope that helps. (Isn't there someone out there using Ubuntu who can help Umut with some more precise details?) --Phil.

4 3

type_info
by Kerner, Jacques 20 Dec '05

20 Dec '05

Hi, I have a type_info related problem when using boost::function on a platform that does not support rtti. boost\function\function_base.hpp(315) : error C2039: 'type_info' : is not a member of 'std' Does boost function provide something similar to the rtti policy in serialization ? How can I get around this ? Cheers, Jacques

1 0

Re: [Boost-users] Boost issues on Darwin (Mac OS X 10.4/gcc)
by Ryan McGann 19 Dec '05

19 Dec '05

(Re-posted with correct subject line) On Dec 19, 2005, at 9:00 AM, boost-users-request(a)lists.boost.org wrote: 1) The build.sh file for the boost bjam tool in the 1.33.0 and 1.33.1 release seems to have DOS line endings. I know there are prebuilt binaries of bjam up on the Web, but our build system builds it manually, and it choked on Darwin because sh didn't like the DOS line endings. I resaved the file with Unix line endings and it built fine. Did you download the tar.gz distribution? That should have Unix line endings throughout where as the .zip file has DOS line endings throughout (intensionally). Well our build system uses whichever archive is checked in. I imagine the PC folks downloaded the .zip version. I can check in a different version for the Unix folks. 2) I get errors for multiply defined symbols for the placeholder symbols declared in boost/bind/placeholders.hpp. Every file that #include <boost/bind.hpp> contains actual instances of _1, _2, etc. Changing the declarations of these in boost/bind.hpp to static (I added a __APPLE__ to the #ifdef in the middle of the file) fixes this issue, but then I get warnings for unused static symbols if I don't use the placeholder objects. This issue in particular is quite annoying. What compiler are you using? The first #if says: #if defined(__BORLANDC__) || defined(__GNUC__) isn't this the branch that gets taken? Hm in my boost/placeholders.hpp, I see #if defined(__BORLANDC__) ... #elif defined(BOOST_MSVC) || (defined(__DECCXX_VER) && __DECCXX_VER <= 60590031) || defined(__MWERKS__) ... #else ... #endif I don't have a _GCC__ anywhere in there. This is from 1.33.1 (which I just newly expanded from the .tar.gz, not the .zip). If I add a defined(__GCC__) to the first or second set of #ifdefs, it works fine. 3) The header in boost/compatibility/cpp_c_headers/cstdio does not match up with the cstdio file included with the Mac OS X dev tools. In particular it is missing a using ::snprintf, which causes problems because this cstdio file is being included BEFORE the Mac OS X version of the same file, and other C++ header files rely on std::snprtinf being declared. I fixed this at first by deleting the boost/compatibility/cpp_c_headers folder, but then ending up just deleting that single file so that OS X always used the built-in header file. Why are those headers getting included? They were intended for use only with certain broken compilers that didn't have the c-prefixed std lib headers. They're known not to work with several std conforming compilers (but shouldn't be included for these anyway). I'm not sure why they're being included. I'm guessing it's because we pass -I<path to boost> to GCC, which causes it to search inside of that directory before the standard directories get searched. I'll have to investigate that further. Thanks, Ryan

1 0

[Boost.Thread] portable thread ids and library development status
by Ben L. Perkins 19 Dec '05

19 Dec '05

I'm evaluating the difficulty involved in converting some applications that currently use an in-house cross platform library to use Boost instead. One feature these applications currently make heavy use of is the availability of a portable thread identifier that can be accessed from both inside and outside the thread. The present implementation of boost::thread lacks this feature. I searched the archives of this list and found a fairly lively discussion on this topic that took place back in 2003. Unfortunately I couldn't find any indication that it was ever resolved and apparently the original maintainer of the thread library ceased working on it about this time. I'm curious about the status of the boost::thread library now. I just downloaded boost_1_33_1 and I see from the release notes that at least minor bug fixes are still being made there. Is any more ambitious work still being done on it? Has there been any progress made toward the concept of a portable thread id? Thank you for any information you can pass along. - Ben Perkins

1 0

Assertion failure usign boost::format with Visual C++ 2005
by J.S. Otis 19 Dec '05

19 Dec '05

Hello, Here is a sample that generates an assertion failure with Visual C++ 2005. A NULL ptr is passed to std::string::append() by boost::io::detail::mk_str(). //////////////////////////////////////////////////////////////////// #include <boost/format.hpp> int main(int argc, char* argv[]) { std::string str(""); // Empty string. boost::format frmt( "%s" ); std::string res = ( frmt % str ).str(); return 0; } //////////////////////////////////////////////////////////////////// This is due to all the assert statements added in the new "secure" STL that is shipped with VC2005. But still, I don't think passing NULL to string::append() is correct anyway... Regards. J.S.Otis Software Developper InnovMetric Software Inc.

1 0

Re: [Boost-users] Graph problem -- solvable using the Boost graph library ?
by Dmitry Bufistov 19 Dec '05

19 Dec '05

>If the graph is acyclic -> it is a tree -> there is 1 and only 1 path >between any two vertices (consequently, it is both shortest and longest). >So you might as well perform breadth-first search from a starting vertex to >get all paths and distances to other vertices. BFS complexity is O(|A|) where >|A| is the number of edges in the graph. So, how "zvrba(a)globalnet.hr" point out absolutly correctly the problem could be solved using BFS (in linear time with respect to edges number), with the following visitor //////////////////code//////////////////// #include <boost/graph/adjacency_list.hpp> #include <boost/graph/breadth_first_search.hpp> using namespace boost; template < typename DistanceMap > class bfs_distance_visitor : public default_bfs_visitor { typedef typename property_traits < DistanceMap >::value_type T; public: bfs_distance_visitor(DistanceMap dmap) : m_distances(dmap) { } template <typename vertex_descriptor, typename Graph> void initialize_vertex(vertex_descriptor v, Graph& g) { m_distances[v] = 0; } template < typename Edge, typename Graph > void tree_edge(Edge e, Graph& g) { put(m_distances, target(e, g), m_distances[source(e,g)] + get(edge_weight, g, e)); } DistanceMap m_distances; }; typedef adjacency_list <listS, vecS, undirectedS, no_property, property<edge_weight_t, double> > graph_t; typedef graph_traits<graph_t>::vertex_descriptor vertex_descriptor_t; struct ltvertex { bool operator()(vertex_descriptor_t v1, vertex_descriptor_t v2) const { return unsigned(v1) < unsigned(v2); } }; template <typename TValue> struct vertex_external_property_map { typedef std::map<vertex_descriptor_t, TValue, ltvertex> property_map_type; }; typedef vertex_external_property_map<double>::property_map_type distance_map_t; int _tmain(int argc, _TCHAR* argv[]) { graph_t g; typedef associative_property_map<distance_map_t> T; T dmap; bfs_distance_visitor<associative_property_map<distance_map_t> > vis(dmap); //Now it would be good to read graph breadth_first_search(g, vertex(0, g), visitor(vis)); return 0; } ///////////////////////////////////////////////////////////////////////////// If it doesn't work then I don't know who wrote it Ну привет, --Дима

1 0