- Boost-users - lists.boost.org

Const Graph Property Maps
by dmatt001 23 Mar '03

23 Mar '03

Hi Guys, I have three interesting questions in regard to graph properties. Please assume Boost 1_29_0. I'm a little slow in upgrading ... ;-) 1. If I define: MyGraph_t const myGraph; Why cannot I get a property map to access my property: typedef boost::property_map<MyGraph_t, MyPropTag_t>::type MyPropMap_t; MyPropMap_t myPropMap = get(MyPropTag_t(), myGraph); Instead I need to use for each access: get(MyPropTag_t(), myGraph, *i) I have noticed that gcc 3.2 complains in regard to conversion to a non-scalar type being similar to that of myGraph without const-ness of the nested property type. What can I do to get normal map access? 2. Why not use a copy constructor if it exists when copying graph elements? Is the existence of a copy constructor a hard-yard to verfiy with MPL? 3. I noticed that remove_edge(...) complains in regard to a missing default constructor of a property object. Don't get me wrong; this happened during an editing mishap and I know that we need regular types here. Why is this required if you are removing an element? Thanks for the pointers/opinions! :-) Matt

2 1

Suggest: tuple base class
by Bryan Silverthorn 23 Mar '03

23 Mar '03

Hi, I haven't found any discussion of this issue; it's possible I've just missed it. Anyway, the short form is that I'm trying to partially specialize a class for tuple types. I specialize for cons<H, T>, but specialization requires an exact type match, so tuple<...> will fail to match cons<...> and instead fall to the base template<class T> case--which has the wrong behavior. If I assume that the passed type is a tuple, I can use inheritance trickery and inherit from the tuple<...>::inherited case to match the correct case. Of course, this assumes that the template type is a tuple, when I can't make that assumption--I'm using specialization precisely because the type isn't known. I could specialize on tuple<T0...T9>, but that sets another arbitrary max tuple size; it would be nice to be able to match all tuples allowed by the boost::tuple implementation. So: I need a way to determine if a particular type is a tuple type, which would allow me to do the following: template<bool B, class T> class FooIf {}; template<class T> class Foo : public FooIf<is_tuple_type<T>, T> {}; template<class T> class FooIf<true, T> { /* tuple implementation */ }; template<class T> class FooIf<false, T> { /* non-tuple implementation */ }; AFAICT, there's no way to do so at present. I'd like to suggest a way to add this functionality: have cons<> (or tuple<>) inherit from a blank "tuple_base" class. This would let us use boost::is_base_and_derived to provide the is_tuple_type functionality for the code block above. Of course, it's possible I'm just missing a simple way to partially specialize for tuple types, or that such functionality is bad and unecessary. Thoughts? ---- Bryan Silverthorn :: bcs26(a)cornell.edu

2 1

Boost 1.30.0: Problems with lexical_cast together with unsigned short and MSVC7
by p.klotz＠icoserve.com 23 Mar '03

23 Mar '03

The code fragment below does not compile. The problem seems to be related to wide character support. MSVC6 works without problems. #include <boost/lexical_cast.hpp> int main(void) { boost::lexical_cast<std::string,unsigned short>(4); return 0; } Here are the resulting error messages: C:\devel\BOOST\1.30.0\win32-msvc7\include\boost\lexical_cast.hpp(162) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'std::basic_stringstream<_Elem,_Traits,_Alloc>::_Mystr' (or there is no acceptable conversion) with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Alloc=std::allocator<wchar_t> ] C:\devel\BOOST\1.30.0 \win32-msvc7\include\boost\lexical_cast.hpp(158) : while compiling class-template member function 'bool boost::detail::lexical_stream<Target,Source>::operator >>(std::string &)' with [ Target=std::string, Source=unsigned short ] C:\devel\BOOST\1.30.0 \win32-msvc7\include\boost\lexical_cast.hpp(190) : see reference to class template instantiation 'boost::detail::lexical_stream<Target,Source>' being compiled with [ Target=std::string, Source=unsigned short ] C:\devel\ICOSOFT\PROJECTS\Applications\H\HelloWorld\main.cpp(5) : see reference to function template instantiation 'Target boost::lexical_cast?$@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@G(Source)' being compiled with [ Target=std::string, Source=unsigned short ] Best regards, Peter.

2 1

[MPL] Comments for a newbie
by cj2048 23 Mar '03

23 Mar '03

Hello everyone, I've only recently taken my first small steps into the world of metaprogramming, and now I've hit a snag. I'm trying to create a metafunction that returns the smallest unsigned integral type with at least the specified number of bits and, if no such type exists, reports an error. For example, ceil_uint<24> (named so for lack of a better name) returns the first member of the list consisting of unsigned char short unsigned int unsigned int long unsigned int whose number of bits is greater than or equal to 24. Now, ceil_uint<N> seems to work fine for 0 <= N <= 32, but with N outside this range, g++ (3.2) gives me a compilation error: [cej@kirk aux]$ g++ -I/usr/include/boost test.cpp -o test test.cpp: In function `int main()': test.cpp:48: conversion from `int' to non-scalar type `boost::mpl::void_' requested test.cpp:49: no match for `-- boost::mpl::void_&' operator test.cpp:50: no match for `boost::mpl::void_& == unsigned char' operator test.cpp:52: no match for `boost::mpl::void_& == short unsigned int' operator test.cpp:54: no match for `boost::mpl::void_& == unsigned int' operator I guess that a compilation error is desirable in these cases, but is there some MPL-blessed way to make the error message(s) more informative (i.e., tell the user that N is outside the valid range)? I'd greatly appreciate any and all suggestions for improving the metafunction. I'd also like to know the generally recommended way to separate the "invocation" of the metafunction from its definition. I intend to invoke the metafunction in a header file like this: namespace X { /* a definition of ceil_uint here would clutter the interface of class Y */ template<int N> class Y { /* ... */ typename ceil_uint<N>::type data; // invocation }; } Having the definition and the invocation in the same header file seems to clutter the interface of the class. /* test program */ #include "boost/mpl/vector.hpp" #include "boost/mpl/find_if.hpp" #include "boost/mpl/transform.hpp" #include "boost/mpl/multiplies.hpp" #include "boost/mpl/sizeof.hpp" #include "boost/mpl/greater_equal.hpp" #include "boost/mpl/int.hpp" #include "boost/mpl/at.hpp" #include "boost/mpl/distance.hpp" #include <limits> #include <iostream> namespace mpl = boost::mpl; using namespace mpl::placeholders; template<int N> struct ceil_uint { typedef mpl::vector< unsigned char, short unsigned int, unsigned int, long unsigned int > types; typedef typename mpl::transform< types, mpl::multiplies< mpl::sizeof_<_>, mpl::int_<std::numeric_limits<unsigned char>::digits> > >::type result; typedef typename mpl::find_if< result, mpl::greater_equal< _1, mpl::int_<N> > >::type iter; typedef typename mpl::at< types, typename mpl::distance< typename mpl::begin<result>::type, iter >::type >::type type; }; int main() { ceil_uint<24>::type i = 0; --i; if (i == std::numeric_limits<unsigned char>::max()) std::cout << "\"i\" is an unsigned char." << '\n'; else if (i == std::numeric_limits<short unsigned int>::max()) std::cout << "\"i\" is a short unsigned int." << '\n'; else if (i == std::numeric_limits<unsigned int>::max()) std::cout << "\"i\" is an unsigned int." << '\n'; else std::cout << "\"i\" is a long unsigned int." << '\n'; } TIA, Christian

2 1

RE: [Boost-Users] Regex++ newbie problems
by Bruce Adams [TSP Sunbury] 22 Mar '03

22 Mar '03

>-----Original Message----- >From: John Maddock [mailto:john_maddock@compuserve.com] >Sent: 20 March 2003 12:48 >To: Boost-Users(a)yahoogroups.com >Subject: Re: [Boost-Users] Regex++ newbie problems > > >> I've just started using Regex++ (from boost 1.29.0) >> and I'm experiencing some strangeness that don't seem to be >mentioned >> in >the >> faq. [snip] >Word_expression("([:punct::space:]*)([-:upper::lower:^[:punct:: >space:]]+)([: >> punct::space:]*)"); >> >> Is it right that 'bad' expressions should coredump? > >boost::regex will through an exception if you pass it an >invalid expression - you need to catch it or else yes your >program will core dump. > Hi, Thanks. I knew it was a newbie error. I guess I was working too late and reading only every other line in the manual. I tell from my bad grammar. I'll try and save face by attempting to make a useful contribution. :-) Is there a debug variant or third party program that can be used to generate a useful syntax error? Note: I haven't looked at the exception generated yet but I would assume (incorrectly?) that it does not give much detail about the error. Though if you write and use expressions cleanly it should be trivial to find them by inspection. >It's an invalid expression because: > >[:punct::space:]* should be [[:punct:][:space:]]* > >and > >[-:upper::lower:^[:punct::space:]] you can't nest character >classes like that (in any regular expression language that I know of). > Bah. Newbie error. I only tried it "straw clutching mode" because of my earlier error. > >> (as an aside maybe we could catch bad ones better by replacing regex >strings >> with >> overloaded operators the way streams have superceded printf) >> Apologies for being slightly off topic for the users group. Has there been any work in this direction? We want to compile the expression for efficiency reasons. Building them up using operator<< might sacrifice this without an additional "reduction" phase to compile down to the most efficient automata. I guess this would be the regexp equivalent to endl. Still I like the idea as a debugging tool and I don't think the efficiency lost would be prohibitive. Regular expressions being more like trees rather than streams the << syntax might get a bit ugly with all the brackets required. E.g. char_class Punct = regex::PUNCTUATION + regex::SPACE reg_exp WordExpression = Kleene_closure(Punct) + Positive_closure(char_class("-") + regex::ALPHA) + Kleene_closure(Punct); I guess that is pretty ugly compared to the conventional syntax, despite the improved checkability. I meant to write something like that years ago but never found the time and did have working regexp library around. How about the equivalent using some hidden template metaprogramming (for use when the expression is fixed at compile time) I have a feeling that the complexity added relative to the minor inconvenience of setting up the expression on start-up outweigh the benefits. Still I would be interested to read about research in this area (i.e. tree syntax & compile time compilation of regular expressions in C++ or other languages). With even the most elegant design there's usually a way it can be improved if you look hard enough. (perhaps that improved should be in quotes :-) I feel quite sincere about both interpretations) >> >> I found I still get rogue matches on punctuation and spaces >when I use >> the manually expanded form below: > >You are using the member first of boost::match_results as a >null terminated string - it is *Not* a copy of the string >matched or a null terminated string it is an iterator into >your text - either use the sequence (first-second), or call >match_results::str() to get a std::string object. > >John. > Bah, I even remember reading that (and doing it the first time). Sorry for time wasting and thanks again. Regards, Bruce A. ============================================================================ Any opinions expressed in this e-mail are those of the individual and not necessarily those of Tyco Safety Products. Any prices for the supply of goods or services are only valid if supported by a formal written quotation. This e-mail and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from Tyco Saftey Products are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this e-mail in error and that any use is strictly prohibited. In this event, please notify us via e-mail at 'helpdesk.tepg(a)tycoint.com' or telephone on 0121 255 6499 and then delete the e-mail and any copies of it. ============================================================================

2 1

Re: How to build boost on Darwin/MacOSX
by Reed Hedges 21 Mar '03

21 Mar '03

Aha. I was using "bjam -sTOOLS=gcc", when I *should* have used bjam -sTOOLS=darwin reed I wrote: > Hello. I'm new to Boost, and am trying to build the boost_thread > library on Darwin (Mac OSX 10.2.4). I have tried 1.30.0 and the CVS > version, but get a bunch of linker errors (copied below), as well as a > warning about Python (which I assume is safe to ignore if I don't want > Python stuff). > > What is the correct way to build boost on Darwin/OSX? > > I have tried the following: > bjam boost_thread > bjam -sTOOLS=gcc boost_thread > bjam -sBUILD="framework bundle-loader" boost_thread > bjam > bjam -sTOOLS=gcc > ... > And I tried hacking tools/build/gcc-tools.jam to add "-lstdc++" to the > linker command line. > > All have the same problem. > > here is my GCC version: > $ gcc --version > 2.95.2 > > (3.2, which is also available for OSX, and I think might be the > defauld, has bugs [so does 2.95 though...], so I can't use it for my > own c++ code) > > Here is the bjam output (I used "bjam -q boost_thread" on the CVS > checkout): > > > > [...Python warning...] > > ...found 322 targets... > ...updating 6 targets... > gcc-Link-action > libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- > dynamic/shared-linkable-true/libboost_thread.dylib > /usr/bin/ld: Undefined symbols: > _main > __._9exception > ___builtin_delete > ___cp_push_exception > ___eh_alloc ...

1 0

1.30.0 - problem with filesystem lib
by Russ Wood 21 Mar '03

21 Mar '03

Hi, When using the filesystem lib in the 1.30.0 release, I experience hangs when incrementing the directory iterator. The compiler I've been using is MinGW, an example that exhibits the behaviour on my machine is included below. The hang only occurs when -mthreads is used. The hang occurs on the increment when there are no more files in the directory. Russ // -------------------------------------------------------- cut #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp> #include <iostream> namespace fs = boost::filesystem; int main ( void ) { fs::path cwd ( fs::initial_path() ); fs::directory_iterator entry ( cwd ); fs::directory_iterator end; while ( entry != end ) { fs::path const dirent ( *entry ); std::cout << dirent.native_file_string() << std::endl; ++ entry; std::cout << "next iteration" << std::endl; } } ---- Russell Wood - Dept. of Computing, Imperial College, London.

3 4

Re: Boost version 1.30.0 released
by Kirill Lapshin 21 Mar '03

21 Mar '03

Another attempt to attach file. Few log fragmets (just in case if attach will not come through again): cpp_main.obj : error LNK2001: unresolved external symbol "int __cdecl cpp_main(int,char * * const)" (?cpp_main@@YAHHQAPAD@Z) libs\test\build\bin\boost_prg_exec_monitor.dll\msvc\debug\runtime-link-static\threading-single\boost_prg_exec_monitor.dll : fatal error LNK1120: 1 unresolved externals unit_test_main.obj : error LNK2001: unresolved external symbol "class boost::unit_test_framework::test_suite * __cdecl init_unit_test_suite(int,char * * const)" (?unit_unit_test_suite@@YAPAVtest_suite@unit_test_framework@boost@@HQAPAD@Z) libs\test\build\bin\boost_unit_test_framework.dll\msvc\debug\runtime-link-static \threading-single\boost_unit_test_framework.dll : fatal error LNK1120: 1 unresolved externals __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com [Non-text portions of this message have been removed]

2 1

warnings in Thread library in 1.30.0 release when compiled by VC
by huangsean 21 Mar '03

21 Mar '03

Subject: numerous warnings in Thread library in 1.30.0 release when compiled by VC7.1 (or other vc versions) with warning level 3 or above We're in the process of migrating our project from V1.29.0 to 1.30.0. We are getting a lot of warnings with thread library such as the following: c:\Program Files\Boost\boost\thread\condition.hpp(38) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll- interface class 'boost::detail::condition_impl' I know very little about bjam but it looks like it doesn't even use /Wn switch (correct me if I am wrong and the default is /W2. IMHO, it seems to me that it is always a good practice to set the warning level to at least 3. Also, we would really really like to have the static library option back. :-) Best regards, Sean

3 2

How to build boost on Darwin/MacOSX
by Reed Hedges 20 Mar '03

20 Mar '03

Hello. I'm new to Boost, and am trying to build the boost_thread library on Darwin (Mac OSX 10.2.4). I have tried 1.30.0 and the CVS version, but get a bunch of linker errors (copied below), as well as a warning about Python (which I assume is safe to ignore if I don't want Python stuff). What is the correct way to build boost on Darwin/OSX? I have tried the following: bjam boost_thread bjam -sTOOLS=gcc boost_thread bjam -sBUILD="framework bundle-loader" boost_thread bjam bjam -sTOOLS=gcc ... And I tried hacking tools/build/gcc-tools.jam to add "-lstdc++" to the linker command line. All have the same problem. here is my GCC version: $ gcc --version 2.95.2 (3.2, which is also available for OSX, and I think might be the defauld, has bugs [so does 2.95 though...], so I can't use it for my own c++ code) Here is the bjam output (I used "bjam -q boost_thread" on the CVS checkout): [...Python warning...] ...found 322 targets... ...updating 6 targets... gcc-Link-action libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/libboost_thread.dylib /usr/bin/ld: Undefined symbols: _main __._9exception ___builtin_delete ___cp_push_exception ___eh_alloc ___eprintf ___rtti_si ___throw ___vt_9exception _terminate__Fv ___builtin_new ___cp_pop_exception ___nw__FUlPv ___start_cp_handler ___tf9exception ___ti9exception export DYLD_LIBRARY_PATH c++ -g -fPIC -shared -o "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/libboost_thread.dylib" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/condition.o" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/mutex.o" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/recursive_mutex.o" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/thread.o" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/tss.o" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/xtime.o" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/once.o" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/exceptions.o" "libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/threadmon.o" ...failed gcc-Link-action libs/thread/build/bin/libboost_thread.dylib/gcc/debug/runtime-link- dynamic/shared-linkable-true/libboost_thread.dylib... ...failed updating 1 target... Thanks for any info anyone can give. reed -- Reed Hedges VOS/Interreality Project reed(a)interreality.org http://interreality.org

1 0