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

[Variant] Time complexity of apply_visitor
by Scott Meyers 25 May '06

25 May '06

If I invoke apply_visitor, what is the time complexity wrt the number of types that may be in the variant? The doc doesn't seem to address this. I looked at the source code, but all I can remember before my head exploded due to exposure to the MPL and the PPL was "switch" (which suggests constant time) and "unrolling" which suggests either linear or constant time, depending on what is being unrolled. Does anybody know what the time complexity of apply_visitor is? My real question is whether applying a visitor to a variant is more efficient than a cascading series of calls to get. I know that the following runs in linear time wrt the number of types in the variant, if (T1 *p = get<T1>(&myVariant)) ... else if (T2 *p = get<T2>(&myVariant)) ... else ... else if (Tn *p = get<Tn>(&myVariant)) ... but what about this? apply_visitor(myVisitor, myVariant); Thanks for any enlightenment. Scott

2 1

[multi_array] size_type
by Daniel Mitchell 24 May '06

24 May '06

It seems clear that since each dimension of a multi_array can have (I presume) extent up to numeric_limits<size_type>::max(), size_type isn't always large enough to hold the actual size of the multi_array and multi_array::size() may overflow. I have a similar problem with some of my own code, and I'd like to know how the multi_array designers approached this problem--my approach so far is to punt the problem to my users. Thanks. D.

2 1

multi_array index_gen or extent_gen store for reuse
by Levent 24 May '06

24 May '06

Is it possible to store tuples of index or range values (or generators) for later reuse? Consider the following: typedef boost::multi_array<int,3> Arr; typedef Arr::index_range Ir; typedef ??? indices; Arr a(boost::extents[3][4][5]); Arr b(a); indices somerange = Arr::index_gen[Ir()][Ir(1,5)][Ir()<2]; b[somerange] = a[somerange]; // and so on What should `???' be? thanks - Levent

2 2

[boost.multi_array] Question about iterators on multi_array_views
by bernhard.maeder＠zkb.ch 24 May '06

24 May '06

Hello everyone I'm trying to use the boost.multi_array's iterators and came across a problem: calling end() on a certain multi_array_view only yields the same iterator, if it is called on exactly the same instance of the view. When, however, the view is created twice (using the same expression, of course), end() produces an iterator that doesn't compare to the first one. In other words: m_a[indices[index_range()][1]].end() != m_a[indices[index_range()][1]].end() I'm not sure whether this is just me, trying to use something in a way it shouldn't be used, or if this is a limitation of the multi_array library. I'd appreciate your opinion! Thanks a lot! Bernhard Maeder Following is the code that produces an error due to using the multi_array in the above manner: ----------------------------------------------------------------- #include <iostream> #include <boost/multi_array.hpp> using namespace boost; typedef boost::multi_array_types::index_range index_range; using boost::indices; template<typename IteratorType> void output(IteratorType begin, IteratorType end) { for (IteratorType it = begin; it != end; ++it) { std::cout << *it << std::endl; } } template<typename ArrayType> void output(ArrayType const & ar) { std::cout << "----------" << std::endl; std::cout << (ar.end() == ar.end()) << std::endl; std::cout << "----------" << std::endl; output(ar.begin(), ar.end()); } int main() { typedef boost::multi_array<double, 2> array_type; // Create a 3x3 array: array_type m_a(boost::extents[3][3]); for (std::size_t i=0; i<9; i++) m_a.data()[i] = static_cast<double>(i); // Works: std::cout << "Use a sub_array:" << std::endl; output(m_a[1]); // Works: std::cout << "Use a multi_array_view:" << std::endl; output(m_a[indices[index_range()][1]]); // Doesn't work: std::cout << "Use subsequent versions of a multi_array_view:" << std::endl; // This returns false: std::cout << "----------" << std::endl; std::cout << ( m_a[indices[index_range()][1]].end() == m_a[indices[index_range()][1]].end() ) << std::endl; std::cout << "----------" << std::endl; output( m_a[indices[index_range()][1]].begin() , m_a[indices[index_range()][1]].end() ); return 0; } ___________________________________________________________________ Disclaimer: Diese Mitteilung ist nur fuer die Empfaengerin / den Empfaenger bestimmt. Fuer den Fall, dass sie von nichtberechtigten Personen empfangen wird, bitten wir diese hoeflich, die Mitteilung an die ZKB zurueckzusenden und anschliessend die Mitteilung mit allen Anhaengen sowie allfaellige Kopien zu vernichten bzw. zu loeschen. Der Gebrauch der Information ist verboten. This message is intended only for the named recipient and may contain confidential or privileged information. If you have received it in error, please advise the sender by return e-mail and delete this message and any attachments. Any unauthorised use or dissemination of this information is strictly prohibited.

2 1

[shared_ptr] locking issues in Multithreads and singlethreaded env.
by Kobi Cohen-Arazi 24 May '06

24 May '06

Hi As far as we know, boost::shared_ptr has a locking overhead when inc/dec is invoked. I wonder: 1. Is it using atomic op? 2. Why Alexandrescu policy based shared_ptr was rejected? 3. What can we do in order to be able to use shared_ptr without that overhead? Thanks, Kobi.

2 1

[mpl] C++ Template Metaprogramming book - Question
by Kobi Cohen-Arazi 24 May '06

24 May '06

Hi, I've started reading Abrahams' and Gurtovoy's book, since I'm very interested in boost.mpl. Seems like a great book. I have a question regarding the 3rd chapter (3.1.4 section). Eventually, it says that operator* multiplies the runtime values (resulting in 6.0f) and the code uses transform to sum the meta-seq. template <class T, class D1, class D2> quantity<T, typename mpl::transform<D1,D2, plus_f>::type> operator*(quantity<T,D1> x, quantity<T,D2> y) { typedef mpl::transform<D1,D2, plus_f>::type dim; return quantity<T,dim>(x.value() * y.value()); } 1. Why passing x and y by value? why not const& 2. How did we got 6f ? 3. How and when the mpl::transform is getting into action here? I cannot spot it. Thanks -- - Kobi

2 1

Re: [Boost-users] Exposing Class with Private ctor and dtor
by Anand, Kumar 24 May '06

24 May '06

Well marking the copy constructor as private is not required since dtor is already marked as private. You will not be able to copy construct by saying something like A *a = new A(); A a' = A(*a) //This will fail because dtor of A is private. However making the python wrapper class as boost::noncopyable works. It seems, if you do not mark the wrapper class as "noncopyable", boost python internally generates some code which requires public dtor. Kumar -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Dale McCoy Sent: Wednesday, May 17, 2006 6:24 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Exposing Class with Private ctor and dtor > A class has static method to create and a static method to destroy. And the > constructors and destructor of the class is marked as private. How do I > expose such a class in Python? > <snip code> In the code you posted, the default constructor is indeed private, but the copy constructor is not. Was that intentional? If so, then it's still possible to write A otherA(A::create()); which requires public access to ~A() in order to destroy otherA. If it was not intentional, does explicitly privitizing the copy-constructor work? (Or make it clear where Boost::Python wants to copy-construct an A?) Dale _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

[regex] Static linking woes with gcc 4.0x on Fedora Core
by David Yon 24 May '06

24 May '06

I've been having great success with the regex library on Win32 and Linux, up until the time I decided to flip over to using all static linking. What used to be working code suddenly goes belly-up during static constructor initialization, but only when I statically link. When I use dynamic-linking, all appears to be well. I've tried the following permutations, each of which crashes, but each in a slightly different place: - Stock Fedora Core 4 install, with gcc 4.0.0 and boost 1.32 - Upgrade the above to gcc 4.0.2 - Upgrade boost to boost-1.33.1-6.i386.rpm (+boost-devel) - Build boost 1.33 from sources using gcc 4.0.2 When I started, it was dying when running static initializers inside the regex lib. I don't have the exact stack trace right now, but it looked like c_regex_traits<char>::init() was calling a null function pointer somewhere (similar to the top frame shown below). But now that I've come to the last step, it's dying during exit(), with the following backtrace---which isn't terribly helpful, I know: (gdb) backtrace Core was generated by `trquery'. Program terminated with signal 11, Segmentation fault. #0 0x00000000 in ?? () #1 0x08096f63 in __tcf_0 () #2 0x080fa5ee in exit () #3 0x08048d80 in DoQueryAll (ctl=@0xbfaf2a84, ttyname=0x0) at siquery.cpp:472 #4 0x08049826 in main (argc=1, argv=0xbfaf2ec4) at siquery.cpp:320 My DoQueryAll() is calling exit() directly, although I doubt that should make a difference. And again, this All Just Works(tm) when I dynamically link. Dynamic linking is not an option for us---if it came to that, then I'd be seriously looking at refactoring to replace boost.regex with either custom parsing or another regex lib. Besides, bjam *does* build a libboost_regex-XXX.a, presumably it's supposed to work. :-) Now I know that based on the above backtrace, this could be anything. I'm suspecting boost because of the first symptom where the backtrace is in c_regex_traits<char>::init(). So given the dearth of discussion on this category of problem, I'm guessing that perhaps this is a problem with gcc 4.x? Are there any known issues with boost.regex on gcc 4.0.x? Are they fixed in 4.1? Should I just fall back to Fedora Core 3 to get gcc 3.x? Thanks much! David Yon Tactical Software

2 6

[Wave] error (2) compared to 'cpp': ill-formed directive
by Andreas Sæbjørnsen 24 May '06

24 May '06

This is a different error from the one previously reported. Using the 'samples/cpp_tokens' example preprocessor with the input file: #define __glibcpp_function_requires(...) give the following error message test.C(1): error: ill formed #define directive: __glibcpp_function_requires This error was found when preprocessing the file: #include <algorithm> where the implementation of algorithm is from gcc. The error from the custom preprocessor is: PATH_TO_GCC_STL_IMPLEMENTATION/bits/concept_check.h(52): error: ill formed #define directive: __glibcpp_function_requires It is important for us to be able to preprocess this header file since we aim for gcc compatibility. Is this standard preprocessor syntax? Could Wave support this syntax? Regards Andreas

2 2

[BGL] graph & reverse_graph type conversion
by Jean-Charles Campagne 24 May '06

24 May '06

Given a type of graph G such as : typedef adjacency_list < listS, listS, bidirectionalS > G; and its reverse graph type : typedef reverse_graph<G> RG How can I convert a graph RG to a graph G simply ? For instance, I would like to apply a function like : void foo(G x); to graphs of type G as well as type RG. I looked in the documentation, unsuccesfully. I tried to change the type of the function to : void foo(RG x); It worked for some functions, but not for others like : void bar(RG x) { // ... add_vertex(x); //... } The compiler complains about : 'Config::vertex_descriptor boost::add_vertex( const Config::vertex_property_type &, boost::adj_list_impl<Derived,Config,Base> &)' : expects 2 arguments - 1 provided Apparently there seems to be no default type conversion ... ? PS : I am currently using VC++ 7.1.

2 2