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

Re: [BGL] forced client complexity
by Christopher D. Russell 31 Mar '04

31 Mar '04

A well written critique. I had to go look up the word "prolix" (i.e. verbose). In defense of BGL: I am no BGL expert despite having read the book several times and writing a complex client application that uses dozens of different graph types. I admit, it was some hard work getting going with BGL. However, this is because I didn't know C++ templates nearly as well as I thought I did. Certainly there's nothing in the library that would preclude anyone from writing simpler BGL-derived classes that offer solutions that are packaged to solve specific problems. Post specific problems and people will help. > It is difficult for me to assess whether the > simplicity I yearn for isn't present for stylistic > reasons or whether it would rather necessitate a > sacrifice of flexibility, functionality or > implementation clarity. Having become baseline proficient with BGL, I would disagree that it's overly complex. To me BGL is an elegant solution to a class of very complex problems that strikes a reasonable balance between complexity and flexibility. In my opinion, if you frequently use graphs BGL is well worth the investment required to learn how to use it. - Chris "Provisional Dissonance" <prosonance(a)yahoo.com> wrote in message news:20040331094800.93338.qmail@web60105.mail.yahoo.com... > If one accepts the axiom that "a picture is worth a > thousand words," then it naturally follows that > discussion of graphs is always overly prolix. Sadly, > the same reasoning is also applicable to the code of > graph libraries. Boost.Graph seems to expose and > require an unnecessarily large amount of complexity, > though. Whereas libraries like Spirit go to great > lengths to make hard things easy, BGL seems to try > only to make hard things possible. The amount of > scaffolding required to use BGL for even the simplest > of projects often dwarfs the code size of a naive, yet > functional, special-purpose implementation. > > While I understand that the BGL is deeply entrenched > in boost culture, certain academic circles, and even > publications, I nonetheless suggest that BGL lacks the > ease of use necessary for widespread adoption. Even > knowing that ease-of-use is not a criterion for > acceptance into boost, looking at what is required of > the client to use the BGL always leaves me feeling > perplexed. Is there any particular reason that a > simplified interface is not made available? Perhaps a > container adapter could be packaged with the library > allowing a compromise of functionality and flexibility > for simplicity? If a graphing problem is trivial, > shouldn't BGL provide a trivial solution? Why are the > simplest useful examples several hundred lines of > code? > > I apologize for all of my vague criticisms - my > intention is not to flame but rather to test the > waters. It is difficult for me to assess whether the > simplicity I yearn for isn't present for stylistic > reasons or whether it would rather necessitate a > sacrifice of flexibility, functionality or > implementation clarity. Nor is it clear to me to what > extent these criteria can be compromised to promote > clarity of client code. For what it is worth, the > kind of ease-of-use I'm imagining might look like: > > #include <less_than_10_graph_headers> > ... > digraph<some_node_type,some_edge_context_type> g; > g << "vertex" << make_pair("vertex", > "implicit_vertex"); > g.add_edge("brother", "sister", "sibling"); > if(g.find(make_pair("brother", "sister"))) > related = true; > > Could someone please elucidate on why it is > impossible/impractical/unnecessary/whatever for a > graph library to have such an interface? Should I > accept that the BGL is not the magic bullet graph > library and move on, or can this kind of simplicity be > somehow found within? > > Thanks in advance, > prs > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance Tax Center - File online. File on time. > http://taxes.yahoo.com/filing.html > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: boost::variant's and > 10 supported types
by Aleksey Gurtovoy 31 Mar '04

31 Mar '04

Eric Friedman writes: > Preston A. Elder wrote: > > How do I support > 10 types in a variant without having support for > > make_variant_over (since I wish to still support Borland and MSVC 6/.NET > > (aka. 7, not 7.1), as well as gcc). > > To solve your problem under the current implementation, you need a > greater value for BOOST_MPL_LIMIT_LIST_SIZE. I'm unfortunately not > attuned enough to the MPL implementation to know what is involved in > attaining this; I've CCed this to Aleksey Gurtovoy (the MPL maintainer), > who may be able to help you. Just #define-ing BOOST_MPL_LIMIT_LIST_SIZE to something that is a multiple of 10 (e.g. 20) before including Boost headers should work. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Lambda question
by Anders Sundman 31 Mar '04

31 Mar '04

Hi all! I'm using the lambda library to compute the sum of squared differences, but I have encountered a puzzling problem. I would really appreciate if someone could explain it to me. This doesn't compile: std::inner_product(i1, i1+x, i2, 0.0, (_1 + _2), (_1*_1)(_1 - _2)); however, this does: std::inner_product(i1, i1+x, i2, 0.0, std::plus<double>(), (_1*_1)(_1 - _2)); The compiler message is very voluminous and hard to read. But I think this part might be of importance, the (double&, double) looks strange: /usr/include/c++/3.3/bits/stl_numeric.h:119: error: no match for call to `( boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambd a::arithmetic_action<boost::lambda::plus_action>, boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder <1> >, boost::lambda::lambda_functor<boost::lambda::placeholder<2> >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >) (double&, double)' /usr/include/boost/lambda/detail/lambda_functors.hpp:142: error: candidates are: typename T::sig<boost::tuples::null_type>::type boost::lambda::lambda_functor<Base>::operator()() const [with T = boost::lambda::lambda_functor_base<boost::lambda::arithmetic_action<boost::la mbda::plus_action>, Many thanks in advance Anders Sundman

2 3

Error building Boost_1_30_0
by Albert Gome 31 Mar '04

31 Mar '04

Hi, I am build Boost_1_30_0 on HPUX11.11 using gcc 3.3.3. I m getting these errors. skipping Boost.Python library build due to missing or incorrect configuration couldn't find Python.h in "/usr/local/include/python2.2" . . . . . ...patience... ...found 2254 targets... ...updating 295 targets... gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/c_regex_traits.o libs/regex/src/c_regex_traits.cpp: In static member function `static void boost::c_regex_traits<char>::update()': libs/regex/src/c_regex_traits.cpp:655: call of overloaded `getlocale(int)' is ambiguous /usr/include/locale.h:114: candidates are: locale_data* getlocale(int) libs/regex/src/c_regex_traits.cpp:62: const char* <unnamed>::getlocale(int) libs/regex/src/c_regex_traits.cpp:658: call of overloaded `getlocale(int)' is ambiguous /usr/include/locale.h:114: candidates are: locale_data* getlocale(int) libs/regex/src/c_regex_traits.cpp:62: const char* <unnamed>::getlocale(int) libs/regex/src/c_regex_traits.cpp:660: call of overloaded `getlocale(int)' is ambiguous /usr/include/locale.h:114: candidates are: locale_data* getlocale(int) libs/regex/src/c_regex_traits.cpp:62: const char* <unnamed>::getlocale(int) libs/regex/src/c_regex_traits.cpp:663: call of overloaded `getlocale(int)' is ambiguous /usr/include/locale.h:114: candidates are: locale_data* getlocale(int) libs/regex/src/c_regex_traits.cpp:62: const char* <unnamed>::getlocale(int) g++ -c -Wall -ftemplate-depth-100 -DBOOST_REGEX_NO_LIB=1 -DBOOST_REGEX_STATIC_LINK=1 -g -O0 -fno-inline -I"libs/regex/build" -I "/mnt/r7/apal3/lib/boost_1_30_0" -o "libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/c_regex_traits.o" "libs/regex/build/../src/c_regex_traits.cpp" ...failed gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/c_regex_traits.o... gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/c_regex_traits_common.o gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/cpp_regex_traits.o gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/cregex.o gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/fileiter.o gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/posix_api.o gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/regex.o gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/regex_debug.o gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/regex_synch.o gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/debug/runtime-link-dynamic/w32_regex_traits.o . . . . . ...skipped <libs!regex!build/libboost_regex.a/gcc/debug/runtime-link-dynamic>libboost_regex_debug.a for lack of <libs!regex!build/libboost_regex.a/gcc/debug/runtime-link-dynamic>libboost_regex_debug.a(c_regex_traits.o)... ...skipped <!libs!regex!build!bin-stage>libboost_regex_debug.a for lack of <libs!regex!build/libboost_regex.a/gcc/debug/runtime-link-dynamic>libboost_regex_debug.a... gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/release/runtime-link-dynamic/c_regex_traits.o libs/regex/src/c_regex_traits.cpp: In static member function `static void boost::c_regex_traits<char>::update()': libs/regex/src/c_regex_traits.cpp:655: call of overloaded `getlocale(int)' is ambiguous /usr/include/locale.h:114: candidates are: locale_data* getlocale(int) libs/regex/src/c_regex_traits.cpp:62: const char* <unnamed>::getlocale(int) libs/regex/src/c_regex_traits.cpp:658: call of overloaded `getlocale(int)' is ambiguous /usr/include/locale.h:114: candidates are: locale_data* getlocale(int) libs/regex/src/c_regex_traits.cpp:62: const char* <unnamed>::getlocale(int) libs/regex/src/c_regex_traits.cpp:660: call of overloaded `getlocale(int)' is ambiguous /usr/include/locale.h:114: candidates are: locale_data* getlocale(int) libs/regex/src/c_regex_traits.cpp:62: const char* <unnamed>::getlocale(int) libs/regex/src/c_regex_traits.cpp:663: call of overloaded `getlocale(int)' is ambiguous /usr/include/locale.h:114: candidates are: locale_data* getlocale(int) libs/regex/src/c_regex_traits.cpp:62: const char* <unnamed>::getlocale(int) g++ -c -Wall -ftemplate-depth-100 -DNDEBUG -DBOOST_REGEX_NO_LIB=1 -DBOOST_REGEX_STATIC_LINK=1 -O3 -finline-functions -Wno-inline -I"libs/regex/build" -I "/mnt/r7/apal3/lib/boost_1_30_0" -o "libs/regex/build/bin/libboost_regex.a/gcc/release/runtime-link-dynamic/c_regex_traits.o" "libs/regex/build/../src/c_regex_traits.cpp" ...failed gcc-C++-action libs/regex/build/bin/libboost_regex.a/gcc/release/runtime-link-dynamic/c_regex_traits.o... Does anybody know how to reolve this? Thnks Albert --------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.

2 1

boost::variant's and > 10 supported types
by Preston A. Elder 31 Mar '04

31 Mar '04

Hi, How do I support > 10 types in a variant without having support for make_variant_over (since I wish to still support Borland and MSVC 6/.NET (aka. 7, not 7.1), as well as gcc). To be precise, I need 18 types to be supported. -- PreZ Founder The Neuromancy Society http://www.neuromancy.net

5 4

boost::filesystem::exists() & GetfileAttributesA
by Sebastian Orfino 31 Mar '04

31 Mar '04

Hi, I am experiencig a problem with exists() and its Windows implementation with GetFileAttributes API. I am using exists() prior to the scan of a directory to see if it exists; the fact is that on W2K (just tested it on that OS) after a day or two GetFileAttributesA() returns INVALID_FILE_ATTRIBUTES but the path does exists (it is a UNC-style path). After a restart of the app, all works fine. So, should I use exists() this way ? I don't know why not. Or just use directory_iterator and scan the hot-folder right away catching any exceptions ?. I don't want to iterate over a direcotry that doesn't exists if I could knew that in advance; besides, I don't know if that will work anyway. Does anyone know somthing about this GetFileAttributesA/boost::exists() behavior ? Thanks in advance, Sebastian.

4 6

vc7.1-stlport
by GoochRules! 31 Mar '04

31 Mar '04

Greetings, I am attempting to build boost using "-sTools=vc7.1-stlport". I have copied the STLport libaries to C:\src\lib. The STLport headers are in c:\src\include\stlport. I extracted the STLport archive to c:\src\STLport-4.6.1. I have tried STLPORT_PATH=c:\src, c:\src\lib, c:\src\include, and c:\src\include\stlport with STLPORT_VERSION unset, and set to 4.6.1, as well as both unset. Boost succeeds in building, yet does not link against the STLport libraries (as reported by depends.exe), but rather to MSVCP71.DLL and MSVCP71.DLL (the C++ and C runtime libraries provided by vc7.1 I presume). I have ensured that c:\src\lib is first in %LIB% and c:\src\include\stlport;c:\src\include; is first in %INCLUDE% Any suggestions for what my STLport setup should look like are appreciated, as well as pointers on getting boost to link against the STLport libraries. --Matthew Peltzer

3 3

Boost Python on Mac OS X
by James Mastro 31 Mar '04

31 Mar '04

Hello all, I'm trying to use Boost Python on Mac OS X 10.3. I'm following along with what is at http://www.boost.org/libs/python/doc/tutorial/doc/ building_hello_world.html. After using bjam like this: bjam -sTOOLS=darwin the following are built: libboost_python.dylib hello.so This seems to be correct. I'm not totally sure where they are supposed to go, so I put them in next to Python in the Python framework so Python could find them to import. It found them, but an "import hello" in Python resulted in: ImportError: Failure linking new module: ../../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/ debug/shared-linkable-true/libboost_python.dylib: dyld: /Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE can't open library: ../../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/ debug/shared-linkable-true/libboost_python.dylib (No such file or directory, errno = 2) Before putting the 2 libs in, "import hello" found nothing. So I assume Python is finding the hello module now, but not liking it. Can anyone show me where I've gone wrong? Many thanks. -jim

2 1

Installing pyste
by Yannick Patois 31 Mar '04

31 Mar '04

Hi, When running "bjam install" from top-level directory, even with PYTHON_ROOT set correctly, it only creates shared libs but doesnt build and install pyste. What should be done to install it properly ? I finally went to libs/python/pyste/install and executed: python setup.py install I would expect this to be wrapped in some top-level command. Did I miss something in the doc ? Thanks, Yannick

2 1

Compilation problems on Linux
by mayankg＠iiitb.ac.in 31 Mar '04

31 Mar '04

Hi, We are trying to use the libboost_python.so library in Linux with our project. When we try to compile the C++ file of our project having all the boost interfaces, we get the following compilation error only on Linux. Although on Windows it works fine. We are using the Python 2.2.3 and Boost 1.30.2 versions. /usr/include/boost/python/converter/as_to_python_function.hpp:28: sorry, unimplemented: ` method_call_expr' not supported by dump_expr /usr/include/boost/python/converter/as_to_python_function.hpp:28: sorry, unimplemented: ` method_call_expr' not supported by dump_expr /usr/include/boost/python/converter/as_to_python_function.hpp:28: sorry, unimplemented: ` method_call_expr' not supported by dump_expr /usr/include/boost/python/converter/as_to_python_function.hpp:28: sorry, unimplemented: ` method_call_expr' not supported by dump_expr Please help, Regards, Mayank

2 1