- Boost - lists.boost.org

typeless trampoline
by Bronek Kozicki 07 Sep '04

07 Sep '04

Hi I factored out trampoline class from my ext_auto_ptr_090 . I'd like to know how it works on modern compilers. I was able to test it on few compilers I use for regression tests: msvc71 (passed with FAULTY set) como 4.3.3 with backend msvc71 mingw 3.3.1 mingw 3.4.1RC I will be happy to know how it works with other compilers. Maybe boosters could test this code with some compilers? I'm especially interested in recent Intel and CW versions. I think that it might be useful utility in boost, provided I can make it enough functional (passing arguments to function is first thing to be added). B. #include <cassert> #include <cstdio> #include <utility> // Copyright Bronislaw Kozicki 2003-2004. Use, modification and // distribution is subject to the Boost Software License, Version // 1.0. (See http://www.boost.org/LICENSE_1_0.txt ) #ifndef __COMO__ # if defined(_MSC_VER) && (_MSC_VER <= 1310) # define FAULTY # endif // _MSC_VER #endif // __COMO__ template <bool> struct static_assert; template <> struct static_assert<true> {}; class trampoline { private: typedef void(*_pf_t)(void *); template <typename Functor> struct _lever_t; template <typename Functor> struct _lever_t<Functor *> { static_assert<sizeof(Functor*) == sizeof(void *)> size; union convert { Functor* f; void* p; }; static void exec(void * p) { convert c; c.p = p; (*c.f)(); } static std::pair<_pf_t, void *> init(Functor* f) { convert c; c.f = f; return std::pair<_pf_t, void *>(&exec, c.p); } }; // the one and the only data std::pair<_pf_t, void *> _pf; public: template <typename Functor> trampoline(Functor f) : _pf(_lever_t<Functor>::init(f)) {} trampoline(const trampoline& rh) : _pf(rh._pf) {} trampoline& operator=(const trampoline& rh) { _pf = rh._pf; return *this; } void operator()() { _pf.first(_pf.second); } }; static int tmp = 0; static const int tmp_f = 2; void f() { printf("f()\n"); tmp = tmp_f; } static const int tmp_g = 5; static const int tmp_g_f = 6; #ifdef FAULTY int g() { int i = tmp_g_f; printf("faulty "); #else int g(int i = tmp_g) { #endif tmp = i; printf("g(%d)\n", i); return tmp; } static const int tmp_A = 10; struct A { void operator()() const { printf("A::operator()()\n"); tmp = tmp_A; } }; trampoline f1() { return trampoline(&f); } trampoline g1() { return trampoline(&g); } trampoline A1() { static A a; return trampoline(&a); } int main() { trampoline l = f1(); l(); assert(tmp == tmp_f); l = g1(); l(); assert(tmp == tmp_g || tmp == tmp_g_f); l = A1(); l(); assert(tmp == tmp_A); }

5 13

[mpl] mpl::if_ workaround for digital mars
by Daniel James 07 Sep '04

07 Sep '04

Aleksey, I've just been trying the new version of mpl on Digital Mars. The attached patch fixes the bug that sometimes causes mpl::if_ to fail. The problem is that the class template gets redeclared with different parameter names by bind.hpp, and this confuses the compiler. When it instantiates the class, it uses the wrong names. The fix is just to make sure bind.hpp is included before mpl::if_ is defined. thanks, Daniel

3 5

Thread-safe containers
by Tony Juricic 07 Sep '04

07 Sep '04

Browsing through the older posts I could not find any relevant discussion. What is the opinon on implementing thread-safe containers? Java library has them, for example, and, since extending existing containers to be thread safe using locks is a work each client would have to repeat, it looks like a good candidate for standardized library implementation. As for more efficient lock-free impleentations (using CAS) Microsoft has (relatively recently) added singly linked lock-free list to Win32 API. There are examples of lock-free implementations of doubly linked STL list using older Valois algorithm. I would argue that most of multi-threaded programs need thread-safe containers. Tony

6 12

[mpl][vacpp] recurrent problems with name confusions
by Joaquín Mª López Muñoz 07 Sep '04

07 Sep '04

Visual Age 6.0 for AIX complains about the way list iterator is defined "/home/tk/boost_regression/boost/boost/mpl/list/aux_/iterator.hpp", line 30.47: 1540-0416 (S) "next" cannot be declared because its name has already been used. The offending line is typedef l_iter<typename next<Node>::type> next; I guess it'd suffice with rewriting it as: typedef l_iter<typename boost::mpl::next<Node>::type> next; This error (and similar ones in range_c, transform_view, joint_view, pair_view,filter_view) seem to share the same pattern: the compiler complains whenever it finds a structure like this: struct foo { ... name ... typedef ... name; }; a possible workaround (though I cannot test it) is to rewrite this as: struct foo { ... boost::mpl::name ... typedef ... name; }; I don't know if vacpp is meant to be supported by MPL. In case it is, maybe this can be of some help. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

serialization - build shared libs
by Neal Becker 07 Sep '04

07 Sep '04

I'm using current boost cvs. Building with bjam -sTOOLS=gcc stage, builds only archive (.a) versions of serialization libs. I need shared (.so). What needs to be done?

3 3

Problems building --v2 (x86_64)
by Neal Becker 07 Sep '04

07 Sep '04

PYTHON_ROOT=/usr PYTHON_VERSION=2.3 PYTHON_LIB_PATH=/usr/lib64/python2.3 bjam --v2 ...patience... ...found 986 targets... ...updating 113 targets... MkDir1 bin.v2 MkDir1 bin.v2/libs MkDir1 bin.v2/libs/test MkDir1 bin.v2/libs/test/build MkDir1 bin.v2/libs/test/build/gcc MkDir1 bin.v2/libs/test/build/gcc/debug gcc.compile.c++ bin.v2/libs/test/build/gcc/debug/execution_monitor.o gcc.compile.c++ bin.v2/libs/test/build/gcc/debug/cpp_main.o gcc.link.dll bin.v2/libs/test/build/gcc/debug/boost_prg_exec_monitor.so /usr/bin/ld: bin.v2/libs/test/build/gcc/debug/execution_monitor.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC bin.v2/libs/test/build/gcc/debug/execution_monitor.o: could not read symbols: Bad value collect2: ld returned 1 exit status

2 1

Interest in custom numeric formatting?
by Stefan Slapeta 07 Sep '04

07 Sep '04

Hi all, I've recently developed a small lib for custom numeric formatting, which is part of many programming languages. You pass any number and a format string which controls the formatting. Some examples (using the US locale): num_format ( 3332123.3332, "$#,0.00" ) -> "$3,332,123.33" num_format ( 123, "#.00" ) -> "123.00" num_format ( 12, "000" ) -> "012" num_format ( 12.9, "000" ) -> "013" (rounded!) num_format ( -123.1, "#.#;-#.00" ) -> "-123.10" num_format ( -123, "$#;- $0.00;0" ) -> "- $123.00" num_format ( 0, "0.00;-0.00;<Zero>" ) -> "<Zero>" num_format ( 1000000, "#,#,.00" ) -> "1,000.00" Short explanation for the format string: . marks the decimal separator , has two functions: - if the format string contains any "," before, but not immediately before the decimal separator, there will be thousand separators in the output. - if the format string contains any "," immediately before the decimal separator, the number will be divided by the number of "," characters multiplied by 1000. 0 If there is no digit in this position, there will be a 0 in the output string # If there is a digit in this position, it is copied to the output string (except non-significant zeros) ; Section separator: if there is one section in the format string, it applies to all values. If there are two sections, the first applies to positive values and to zeros and the second applies to negative values. If there are three sections, the first applies to positive values, the second to negative values and the third to zeros, except if the second section is empty, in which case the first section applies to all non-negative values. Everything in enclosed by ' or " in the format string will be copied to the output as is. I've been looking for a (C++) solution for this for a long time and as I didn't find anything appropriate, I developed it myself finally. If anybody is interested, I could post source somewhere. Stefan

6 8

iostream problems
by Neal Becker 07 Sep '04

07 Sep '04

cd /home/nbecker/shannon2/wrap/ g++34 -o Test Test.cc -g -I /usr/local/src/iostream/ In file included from /usr/local/src/iostream/boost/io/detail/streambufs/direct_streambuf.hpp:18, from /usr/local/src/iostream/boost/io/streambuf_facade.hpp:15, from /usr/local/src/iostream/boost/io/stream_facade.hpp:20, from Test.cc:1: /usr/local/src/iostream/boost/io/detail/streambufs/linked_streambuf.hpp:54: error: variable or field `close' declared void /usr/local/src/iostream/boost/io/detail/streambufs/linked_streambuf.hpp:54: error: `close' declared as a `virtual' field /usr/local/src/iostream/boost/io/detail/streambufs/linked_streambuf.hpp:54: error: expected `;' before '(' token In file included from /usr/local/src/iostream/boost/io/detail/adapters/filter_wrapper.hpp:16, from /usr/local/src/iostream/boost/io/detail/streambufs/indirect_streambuf.hpp:23, from /usr/local/src/iostream/boost/io/streambuf_facade.hpp:16, from /usr/local/src/iostream/boost/io/stream_facade.hpp:20, from Test.cc:1: /usr/local/src/iostream/boost/io/operations.hpp: In static member function `static void boost::io::detail::read_impl<boost::io::input>::putback(T&, typename boost::io::char_type<T>::type)': /usr/local/src/iostream/boost/io/operations.hpp:106: error: invalid application of `sizeof' to an incomplete type In file included from /usr/local/src/iostream/boost/io/detail/push.hpp:16, from /usr/local/src/iostream/boost/io/detail/streambufs/indirect_streambuf.hpp:28, from /usr/local/src/iostream/boost/io/streambuf_facade.hpp:16, from /usr/local/src/iostream/boost/io/stream_facade.hpp:20, from Test.cc:1: /usr/local/src/iostream/boost/io/detail/resolve.hpp: At global scope: /usr/local/src/iostream/boost/io/detail/resolve.hpp:38: error: non-template `result_type' used as template /usr/local/src/iostream/boost/io/detail/resolve.hpp:38: error: (use `U::template result_type' to indicate that it is a template) /usr/local/src/iostream/boost/io/detail/resolve.hpp:38: error: expected `{' before ';' token Adding #include <iostream> fixes this problem.

2 3

Preliminary:building with VC++ 8.0 Express beta
by Tony Juricic 06 Sep '04

06 Sep '04

I downloaded and installed MS VC++ 8.0 Express beta. The advantage of Express over full Visual Studio 2005 is in a smaller disk footprint and you need 'only' MS Passport (not MSDN subscription) to download it. Note that Express does not come with Windows headers and libraries so you need to download Platform SDK or use existing, older installation. For example, before invoking bjam, you may say: set INCLUDE="C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include";%INCLUDE% set LIB="C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\lib";%LIB% Here are the problems encountered when building boost: 1) flags for DLL and single-threaded static library have changed. You would need the following flags in msvc-tools.jam: # VC8.0 flags msvc CFLAGS <runtime-build>release/<runtime-link>dynamic : /LD ; flags msvc CFLAGS <runtime-build>debug/<runtime-link>dynamic : /LDd ; flags msvc CFLAGS <runtime-build>release/<runtime-link>static/<threading>single : /MD ; flags msvc CFLAGS <runtime-build>debug/<runtime-link>static/<threading>single : /MDd 2) Og and Gs compiler flags will be deprecated and cause warning. 3) many string functions ( sprintf, strcat, wsccpy, etc. ) cause deprecated warning. 4) compilation errors, all involving wchar_t like: C:\Program Files\Microsoft Visual Studio 8\VC\include\xutility(207) : error C2664: 'bool boost::spirit::utility::impl::range_char_compare<CharT>::operator ()(const boost::spirit::utility::impl::range<CharT> &,const CharT) const' : cannot convert parameter 1 from 'wchar_t' to 'const boost::spirit::utility::impl::range<CharT> &' with [ CharT=wchar_t ] Reason: cannot convert from 'wchar_t' to 'const boost::spirit::utility::impl::range<CharT>' with [ CharT=wchar_t ] No constructor could take the source type, or constructor overload resolution was ambiguous Problem #1 can be solved by commenting out older flags and substituting them with the new ones in msvc-tools.jam. I am sure this is not the most elegant solution, ignorant of bjam as I am. Re. problem #2, I could not find an explicit suggestion on what new options should be used. However, the sheer number of problems with /Og option listed in MS Knowledge Base make me believe that it would be best to remove it. Whidbey (but not Express) is to offer more advanced profile-based optimizations. As for /Gs I would assume that /GS (also /RTC1) should substitute it, following the article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha… As for #3, even barring security concerns, I tend to agree that using string functions with source and destination buffer size parameters is desirable. However, I wouldn't know which portable changes would avoid these warnings; presumably MS-specific extensions would be required. Still unfamilar with boost++ modules that caused errors under #4, I haven't looked into it. While more detailed info about these issues may be possible to find on MSDN, searching for any phrase, unfortunately, results in a huge number of .NET related articles. Tony

1 1

shared_ptrget_deleter
by David Pierre 06 Sep '04

06 Sep '04

I have got a shared_ptr use case where I use the Deleter to hold some extra data which I access through get_deleter. But now I would like to have custom deletion too, by subclassing from the common part. Then to access my data, I need get_deleter to work with superclass(es) of the actual deleter, not only with the exact type. Here is a simple suggestion to make it possible : in boost/detail/shared_count.cpp, introduce : template <class D> struct deleter_caster { void * operator()(std::type_info const & ti, D * del) const { return ti == typeid(D) : del : 0; } }; and make get_deleter implementation in sp_counted_base_impl as virtual void * get_deleter(std::type_info const & ti) { return deleter_caster<D>(ti, del); } Then I can specialize deleter_caster to my linking. D. Pierre

1 0