- Boost - lists.boost.org

[proto] design rationale for expr<proto::function, argsN<Fun, Args...> >?
by Markus Werle 23 Mar '08

23 Mar '08

Hi! I may have overlooked something, but while thinking about proto's design I was surprised by some asymmetry. I'd like to know why this was done the way it is. Consider two objects (type A and B are proto terminals) A a; B b; The expression a + b is considered equivalent to a function call operator+(a, b). The corresponding type representation approximately is expr<tag::binary_plus // I will vote for this ;-) ,args2<expr<tag::terminal, A> ,expr<tag::terminal, B> > > This is done according to the rationale that what binary_plus really means is domain specific. Therefore the expression is simply tagged by the name of the function call, while the second argument is the typelist containing the parameters in the same order as they appear in the expression. Important: any information about what the function call means is stored *outside* the expression. Up to here I appreciate the design and IMHO this is the most appropriate way to represent an expression (I said that before, I know). Now we introduce another function call - not an operator this time, but in C++ these are equivalent. struct fun_t {}; terminal<fun_t>::type const fun = {{}}; fun(a, b); This is represented by something similar to expr< tag::function ,args3< ref_<expr<tag::terminal, args0<fun_tag> > const> ,expr<tag::terminal, args0<> > ,expr<tag::terminal, args0<> > > > This is suprising. In contrast to operator+, the function fun is treated as if it was an *operand*, not an *operator*. The expression is not tagged by _the_ function call, but by a global this-is-a-function-tag and the function is stored in the argument typelist. What fun means is context dependent, I would expect the context to take care about what fun_t might mean, so if we want symmetry first I'd expect a type representation similar to expr< tag::function<fun_t> ,args2< ,expr<tag::terminal, args0<...ommitted...> > ,expr<tag::terminal, args0<...ommitted...> > > > So I wonder whether this asymmetry was introduced due to the fact that function objects could have a state which makes them an in-between between operator and operand ... Can we save state in tag::function<T> then? expr< tag::function<expr<tag::terminal, args0<fun_t> > > ,args2< ,expr<tag::terminal, args0<...ommitted...> > ,expr<tag::terminal, args0<...ommitted...> > > > I do not like that one either ... I ask because ripping the function off the argument list via fusion magic still looks odd to me and makes me feel uncomfortable: Any compile time algorithm has to fork for function calls if it is to apply an operation to the operands. Shed some light on this, please. Markus

4 3

[Boost] Compile-time power of a run-time base
by Bruno Lalande 23 Mar '08

23 Mar '08

Hello, I have written for the need of a coworker a function template that computes the compile-time power of a base that is known only at runtime. The original need was just to avoid having to write things like "value*value*value*value*value". Before doing this, I've been searching for such a thing in the Boost documentation and mailing lists, but could only find discussions about an entierely compile-time version (compile-time exponent of compile-time base) intended for use in metaprograms. Is there any reason why the "semi-compile-time" version I describe here hasn't been discussed? Even though it can be viewed as a mere syntactic sugar, it can be very practical when it comes to write by hand a power with a big exponent. In case of interest, here is my code : template <int N> struct positive_power { template <typename T> static float result(T base) { return base*positive_power<N-1>::result(base); } }; template <> struct positive_power<0> { template <typename T> static float result(T) { return 1; } }; template <int N, bool> struct power_if_positive { template <typename T> static float result(T base) { return positive_power<N>::result(base); } }; template <int N> struct power_if_positive<N, false> { template <typename T> static float result(T base) { return 1/positive_power<-N>::result(base); } }; template <int N, typename T> float power(T base) { return power_if_positive < N, boost::mpl::greater_equal < boost::mpl::int_<N>, boost::mpl::int_<0> >::type::value >::result(base); } It supports positive, null and negative integer exponents. Some improvements can surely be done, like allowing to specify the desired return type. Examples of use : power<3>(myValue); power<0>(myValue); power<-5>(myValue); Thanks Bruno

8 37

[Feature Request :: Boost][MultiArray] Creating Boost Multi.Array in shared memory
by sankar lingam 23 Mar '08

23 Mar '08

I was working with Boost Multi Array and I find it really useful in my project.. But I would also want to create multi array in shared memory.But currently Boost Multi Array is not compatible with shared memory allocators provided by Boost Interprocess.I raised a question in the boost users list and I got to know that it is an adaptation that Boost Multi Array developers would have to do.. I would love to see an added feature in Boost Multi Array which would be compatible with Boost Interprocess allowing Boost MultiArray to be created in shared memory( just like how Boost MultiIndex in the 1.35 release would be).As I understand the MultiArray adaptation would require using allocator::pointer instead of raw pointers as member pointers. I would want to suggest this request to Boost Multi Array developers as it would be a very useful feature for a Boost user like me..Can this feature be added into the Boost 1.35 release..? Regards, Sankar

1 0

Re: [boost] [shared_ptr] gcc 3.2 build broken with current trunk
by Ralf W. Grosse-Kunstleve 23 Mar '08

23 Mar '08

Hi Frank, Your solution works perfectly on all our platforms, in addition to being nicer than the type holder trick. Thanks for the quick fix! Ralf ----- Original Message ---- From: Frank Mori Hess <fmhess(a)speakeasy.net> To: boost(a)lists.boost.org Sent: Friday, March 21, 2008 5:11:52 PM Subject: Re: [boost] [shared_ptr] gcc 3.2 build broken with current trunk On Friday 21 March 2008 18:53, Ralf W. Grosse-Kunstleve wrote: > Hi Frank, > > Your patch resolves the error I posted before, but there are still > other, similar errors while compiling other Boost.Python sources. I > think this is the problem: > > shared_ptr.hpp: > if(del_wrapper) del = del_wrapper->get_deleter<D>(); > ^^^ > ^^^ > I think gcc 3.2 doesn't support this syntax. In the old days this was a > common problem. The usual workaround is to use a type holder. See the > patch below, which resolves all my compilation errors. I put a different workaround in svn a little while ago (fully qualified the get_deleter call) which allowed get_deleter to compile with gcc 2.95. Is the type holder solution more effective? -- Frank

1 0

Executable files, and SVN.
by Rene Rivera 22 Mar '08

22 Mar '08

As mentioned in the Boost RC thread there was a problem with the archives stemming from the svn::execute property being set in many files that make no sense as executables. To fix it at the source I went through, with initial help from Jens S., and removed the svn:execute property as needed. I made the changes to "branches/release" and to "trunk". It would very neighborly if other went through and fixed their own code in branches as needed. WARNING: This means the next update for Unix users might be rather large as SVN resets permissions on files. Additionally incremental testers will likely see a long cycle. I used a combination of the "find" utility and the "svn" command: find . \ -type f \ -not -regex ".*[/][.]svn[/].*" \ -not -regex ".*\([.]bat\|[.]cmd\|[.]com\|[.]csh\|[.]m4\|[.]pl\|[.]py\|[.]sh\|configure\|rst2latex\)" \ -exec svn propdel "svn:executable" "{}" ";" Then doing a commit with whatever SVN tool you use normally. For Windows users you can still use the above command but you will need to either run something like the Cygwin shell, or MSYS shell. Or you can download a the standalone GnuWin32 port of find <http://gnuwin32.sourceforge.net/packages/findutils.htm> and the standard Windows SVN install. Lastly, please be careful about adding files that may be executable. And make sure the SVN properties are set correctly. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

cpp-netlib & pion-net
by Michael Dickey 22 Mar '08

22 Mar '08

I started writing the Pion Network Library (first called "libpion") almost a year ago to start learning Boost and to help fill a need I've repeatedly encountered over the past decade. There are several good third-party networking libraries available for C++, but none that took advantage of Boost and the new ASIO library that will be included in version 1.35. I have a lot of experience working with HTTP, and needed to develop (for the third time in my career) a lightweight HTTP server interface. Although I planned to release libpion as open source, I never gave much thought to submitting it for review to be included in Boost. Over time, and with support and encouragement from the community, my desire to do this grew. I've also been keeping up with the cpp-netlib project on SourceForge, which shares the same goal. For several months we've been kicking around the idea of merging our efforts. Today, I've decided to commit to winding down the Pion Network Library as an independent project, and merging all the code (about 15,000 lines) into the cpp-netlib project. This is going to be a gradual conversion and refactoring of code, adopting it into the framework and styles that have been established by the cpp-netlib folks. My goals will be to enhance cpp-netlib so that it is functionally equivalent to the current Pion Network Library (with asynchronous and synchronous HTTP 1.0 and 1.1 client and server-side support), and to help prepare cpp-netlib for inclusion in the next major Boost release. I expect that the transition will take at least 3 to 6 months. Because there are several entities actively using the Pion Network Library (including my own company, Atomic Labs), I plan to continue developing and enhancing it as an independent project at least until the transition has been fully completed. Dean, Glyn and I are excited about merging the two projects and developer communities, and I am happy to be part of what is now the definitive candidate for a Boost networking protocol library. Take care, -Mike

2 1

Release 1_35_0_RC2: Boost Python hello tutorial
by Johannes Brunen 22 Mar '08

22 Mar '08

Hi, today I have tried the boost python tutorial with the 1_35 release candidate 2. Unfortunately it didn't worked as expected. Especially, I'm missing the hello.pyd file after building the jamroot file. Below I describe what I have done in detail. I'm working on the windows platform with the msvc-7.1 compiler. First I build the bjam.exe from the tools/jam folder with the build_dist.bat script. Next I used this one to build all the boost libraries by running bjam --toolset=msvc-7.1 release debug stage from the command line. I then swichted to the libs/python/example/tutorial directory and called bjam --toolset=msvc-7.1 release debug from the command line. This failed with this output F:/Development/Libraries/boost_1_35_0_RC2/tools/build/v2/build\project.j am:307: in load-jamfile F:/Development/Libraries/boost_1_35_0_RC2/tools/build/v2/build\project.j am:63: in load F:/Development/Libraries/boost_1_35_0_RC2/tools/build/v2/build\project.j am:167: in project.find F:/Development/Libraries/boost_1_35_0_RC2/tools/build/v2\build-system.ja m:516: in load F:\Development\Libraries\boost_1_35_0_RC2\libs\python\example\..\..\..\t ools\build\v2/kernel\modules.jam:267: in import F:\Development\Libraries\boost_1_35_0_RC2\libs\python\example\..\..\..\t ools\build\v2/kernel/bootstrap.jam:132: in boost-build F:\Development\Libraries\boost_1_35_0_RC2\libs\python\example\boost-buil d.jam:7: in module scope I then added the following line at the beginning of the jamroot file: import python ; After running the bjam again I found the following files in the bin/msvc-7.1/release/threading-multi subdirectory. hello.obj hello.obj.rsp hello_ext.exp hello_ext.lib hello_ext.pyd.rsp As you can see. The hello.pyd (or hello_ext.pyd) file is missing. In order to confirm that I didn't fool myself, I tried exactly the same procedure with the current boost release 1_34_1. Here I found these files in the threading-multi subdirectory. hello.exp hello.lib hello.obj hello.obj.rsp hello.pyd hello.pyd.rsp With the hello.pyd file I was able to run the import from within the python interpreter. Is this a known problem? Is my procedure correct? Any tips what I can do? Johannes Brunen DataSolid GmbH

2 1

[inspect][1.35] Link check fixes
by Daniel James 22 Mar '08

22 Mar '08

Hi, Some of the link errors in the inspect report are incorrect. I checked some fixes into trunk: http://svn.boost.org/trac/boost/changeset/43750 http://svn.boost.org/trac/boost/changeset/43752 The first one causes it to check links in single quotes - this fixes a couple of incorrect unlinked file reports in iostream (although 'libs/iostreams/doc/concepts/multi-character.html' is unlinked). The second changeset decodes urls with percent encoded characters and encoded ampersands - this fixes about 200 incorrect link errors in the doc directory (but there are a few left). There's no real need to add these changes to release at this late stage, just note that some of the link errors are incorrect. Daniel

2 3

Re: [boost] [shared_ptr] gcc 3.2 build broken with current trunk
by Ralf W. Grosse-Kunstleve 22 Mar '08

22 Mar '08

Hi Frank, Your patch resolves the error I posted before, but there are still other, similar errors while compiling other Boost.Python sources. I think this is the problem: shared_ptr.hpp: if(del_wrapper) del = del_wrapper->get_deleter<D>(); ^^^ ^^^ I think gcc 3.2 doesn't support this syntax. In the old days this was a common problem. The usual workaround is to use a type holder. See the patch below, which resolves all my compilation errors. Ralf P.S.: I bet there must be a central type holder in boost somewhere, but I couldn't find it. Index: shared_ptr.hpp =================================================================== --- shared_ptr.hpp (revision 43744) +++ shared_ptr.hpp (working copy) @@ -633,6 +633,8 @@ #endif +template <class T> struct sp_dw_type_holder { typedef T type; }; + class sp_deleter_wrapper { shared_ptr<const void> _deleter; @@ -649,7 +651,7 @@ _deleter.reset(); } template<typename D> - D* get_deleter() const + D* get_deleter(sp_dw_type_holder<D> const&) const { return boost::detail::basic_get_deleter<D>(_deleter); } @@ -663,7 +665,7 @@ if(del == 0) { detail::sp_deleter_wrapper *del_wrapper = detail::basic_get_deleter<detail::sp_deleter_wrapper>(p); - if(del_wrapper) del = del_wrapper->get_deleter<D>(); + if(del_wrapper) del = del_wrapper->get_deleter(detail::sp_dw_type_holder<D>()); } return del; }

2 1

Re: [boost] [python] set iteration
by Ralf W. Grosse-Kunstleve 21 Mar '08

21 Mar '08

In C++? I don't know the most elegant solution, but one that should work easily is to convert the set to a boost::python::list, maybe (untested): void foo(boost::python::object s) { boost::python::list l(s); long n = boost::python::len(l); for(long i=0;i<n;i++) { boost::python::extract<int> proxy(l[i]); int v = proxy(); } } Probably, a more efficient solution is to use PyObject_GetIter() and PyIter_Next(), but to make this safe you have to mess with boost::python::handle<> and PyErr_Clear(). Look here for a related example: http://phenix-online.org/cctbx_sources/scitbx/include/scitbx/boost_python/c… Ralf ----- Original Message ---- From: Gennadiy Rozental <rogeeff(a)gmail.com> To: boost(a)lists.boost.org Sent: Friday, March 21, 2008 11:45:18 AM Subject: [boost] [python] set iteration How do I iterate over object that correspond to python set? Gennadiy _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0