October 2008 - Boost - lists.preview.boost.org

Autolinking not working in Windows x64 cross-compile environment
by Dave Barnett 09 Oct '08

09 Oct '08

All: I have taken the Boost 1.33.1 distribution [we have to stay with this for consistency with our Linux build...], along with the extra information here ( http://en.allexperts.com/q/C-1040/Building-boost-libraries-64.htm ) and been able to generate the Boost libraries using the X64 compiler on a machine running Windows XP Pro 64. I have taken the compiled libraries and copied them to our 32-bit XP Pro build machine for use in an X64 cross-compile environment. [We working on setting up a native X64 build machine, but it is a work in progress....] When I try to link, I get the list of unresolved symbols below. We use a command-line tool to do our builds, which calls "cl", "lib", "mt", and "link" directly. If I modify the link file passed to "link" such that it adds "s:\....\libboost_thread-vc80-mt-1_33_1.lib [which is the one dumpbin shows our object wants....], our DLL (omega_runtime) will link successfully. So, to my untrained eye [I'm new to building on Windows....] it looks like there is something wrong with the autolink magic. During the compilation, we do have "/DBOOST_ALL_DYN_LINK" set. Adding "/DBOOST_THREAD_USE_DLL" doesn't change anything. Does anyone have any suggestions for me on why this might be the case, or how to track it down? I have added the lib directory to both LIB and LIBPATH but that doesn't appear to change the situation. Thanks in advance. Cheers, Dave Creating library com\westerngeco\omega\runtime\omega_runtime.lib and object com\westerngeco\omega\runtime\omega_runtime.exp Thread.obj : error LNK2019: unresolved external symbol "public: __cdecl boost::mutex::mutex(void)" (??0mutex@boost@@QEAA@XZ) referenced in f unction "void __cdecl com::westerngeco::omega::runtime::`anonymous namespace'::classInit(void)" (?classInit@?A0xe5577335@runtime@omega@weste rngeco@com@@YAXXZ) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: __cdecl boost::mutex::mutex(void)" (??0mutex@boost@@QEAA@XZ) Thread.obj : error LNK2019: unresolved external symbol "void __cdecl boost::call_once(void (__cdecl*)(void),long &)" (?call_once@boost@@YAXP 6AXXZAEAJ@Z) referenced in function "public: static int __cdecl com::westerngeco::omega::runtime::Thread::currentGroup(void)" (?currentGroup @Thread@runtime@omega@westerngeco@com@@SAHXZ) Thread.obj : error LNK2019: unresolved external symbol "public: void * __cdecl boost::detail::tss::get(void)const " (?get@tss@detail@boost@@ QEBAPEAXXZ) referenced in function "public: class com::westerngeco::omega::runtime::ThreadHandle * __cdecl boost::thread_specific_ptr<class com::westerngeco::omega::runtime::ThreadHandle>::get(void)const " (?get@?$thread_specific_ptr@VThreadHandle@runtime@omega@westerngeco@com@@@ boost@@QEBAPEAVThreadHandle@runtime@omega@westerngeco@com@@XZ) Thread.obj : error LNK2019: unresolved external symbol "public: void __cdecl boost::detail::tss::cleanup(void *)" (?cleanup@tss@detail@boost @@QEAAXPEAX@Z) referenced in function "public: void __cdecl boost::thread_specific_ptr<class com::westerngeco::omega::runtime::ThreadHandle> ::reset(class com::westerngeco::omega::runtime::ThreadHandle *)" (?reset@?$thread_specific_ptr@VThreadHandle@runtime@omega@westerngeco@com@@ @boost@@QEAAXPEAVThreadHandle@runtime@omega@westerngeco@com@@@Z) Thread.obj : error LNK2019: unresolved external symbol "public: void __cdecl boost::detail::tss::set(void *)" (?set@tss@detail@boost@@QEAAXP EAX@Z) referenced in function "public: void __cdecl boost::thread_specific_ptr<class com::westerngeco::omega::runtime::ThreadHandle>::reset( class com::westerngeco::omega::runtime::ThreadHandle *)" (?reset@?$thread_specific_ptr@VThreadHandle@runtime@omega@westerngeco@com@@@boost@@ QEAAXPEAVThreadHandle@runtime@omega@westerngeco@com@@@Z) Thread.obj : error LNK2019: unresolved external symbol "public: __cdecl boost::lock_error::lock_error(void)" (??0lock_error@boost@@QEAA@XZ) referenced in function "public: void __cdecl boost::detail::thread::scoped_lock<class boost::mutex>::lock(void)" (?lock@?$scoped_lock@Vmutex @boost@@@thread@detail@boost@@QEAAXXZ) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: __cdecl boost::lock_error::lock_error(void)" (??0lock_error@boost@@QE AA@XZ) Thread.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl boost::lock_error::~lock_error(void)" (??1lock_error@boost@@ UEAA@XZ) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl boost::lock_error::~lock_error(void)" (??1lock_error@ boost@@UEAA@XZ) Thread.obj : error LNK2019: unresolved external symbol "public: virtual __cdecl boost::thread_exception::~thread_exception(void)" (??1thread _exception@boost@@UEAA@XZ) referenced in function "public: virtual void * __cdecl boost::thread_exception::`scalar deleting destructor'(unsi gned int)" (??_Gthread_exception@boost@@UEAAPEAXI@Z) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl boost::thread_exception::~thread_exception(void)" (?? 1thread_exception@boost@@UEAA@XZ) Thread.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl boost::lock_error::what(void)const " (?what@loc k_error@boost@@UEBAPEBDXZ) ResourceUsage.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl boost::lock_error::what(void)const " (?w hat@lock_error@boost@@UEBAPEBDXZ) Thread.obj : error LNK2019: unresolved external symbol "private: void __cdecl boost::mutex::do_lock(void)" (?do_lock@mutex@boost@@AEAAXXZ) r eferenced in function "public: static void __cdecl boost::detail::thread::lock_ops<class boost::mutex>::lock(class boost::mutex &)" (?lock@? $lock_ops@Vmutex@boost@@@thread@detail@boost@@SAXAEAVmutex@4@@Z) ResourceUsage.obj : error LNK2001: unresolved external symbol "private: void __cdecl boost::mutex::do_lock(void)" (?do_lock@mutex@boost@@AEA AXXZ) Thread.obj : error LNK2019: unresolved external symbol "private: void __cdecl boost::mutex::do_unlock(void)" (?do_unlock@mutex@boost@@AEAAXX Z) referenced in function "public: static void __cdecl boost::detail::thread::lock_ops<class boost::mutex>::unlock(class boost::mutex &)" (? unlock@?$lock_ops@Vmutex@boost@@@thread@detail@boost@@SAXAEAVmutex@4@@Z) ResourceUsage.obj : error LNK2001: unresolved external symbol "private: void __cdecl boost::mutex::do_unlock(void)" (?do_unlock@mutex@boost@ @AEAAXXZ) Thread.obj : error LNK2019: unresolved external symbol "private: void __cdecl boost::detail::tss::init(class boost::function1<void,void *,cl ass std::allocator<class boost::function_base> > *)" (?init@tss@detail@boost@@AEAAXPEAV?$function1@XPEAXV?$allocator@Vfunction_base@boost@@@ std@@@3@@Z) referenced in function "public: __cdecl boost::detail::tss::tss(class boost::function1<void,void *,class std::allocator<class bo ost::function_base> > *)" (??0tss@detail@boost@@QEAA@PEAV?$function1@XPEAXV?$allocator@Vfunction_base@boost@@@std@@@2@@Z) Thread.obj : error LNK2019: unresolved external symbol "public: __cdecl boost::thread_resource_error::thread_resource_error(void)" (??0threa d_resource_error@boost@@QEAA@XZ) referenced in function "public: __cdecl boost::detail::tss::tss(class boost::function1<void,void *,class st d::allocator<class boost::function_base> > *)" (??0tss@detail@boost@@QEAA@PEAV?$function1@XPEAXV?$allocator@Vfunction_base@boost@@@std@@@2@@ Z) Thread.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl boost::thread_resource_error::~thread_resource_error(void)" (??1thread_resource_error@boost@@UEAA@XZ) Thread.obj : error LNK2001: unresolved external symbol "public: virtual char const * __cdecl boost::thread_resource_error::what(void)const " (?what@thread_resource_error@boost@@UEBAPEBDXZ) lib\omega_runtime.dll : fatal error LNK1120: 15 unresolved externals Error status returned = 1120

2 1

[1.37.0] Release schedule added to Development page
by Beman Dawes 09 Oct '08

09 Oct '08

The calendar with the release schedule appears on the web site's Community page, but that isn't the first place a developer is likely to look. So I've added a copy on the Development page. See http://www.boost.org/development/index.html. The "Month" or "Agenda" tabs provide useful views. The time zone shown is US Central Time. I guess that's because its Rene's time zone, and he created the calendar. It might be better if it were UTC, but I'll leave that up to Rene. --Beman

2 1

1.37: Boost.Pool fixes to be merged to release?
by Chris Newbold 08 Oct '08

08 Oct '08

I've fixed a couple of minor issues in Boost.Pool over the course of the last week and submitted to trunk. Can/should I go ahead and merge these to release? -Chris

2 1

Known 1.36 bugs
by Johan Torp 08 Oct '08

08 Oct '08

Is there a list of known 1.36 bugs? Or can someone please point me to the most serious ones? Best Regards, Johan Torp www.johantorp.com -- View this message in context: http://www.nabble.com/Known-1.36-bugs-tp19878713p19878713.html Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

[multi_array] Finding array bounds.
by Robert Jones 08 Oct '08

08 Oct '08

I'm trying to write this piece of code struct Cell { .... }; typedef boost :: multi_array< Cell, 2 > Grid; void f( Grid & grid ) { for ( Grid::index i=grid.?????(); i!=grid.????(); ++i ) { ..... } } where the intention is to iterate over the first subscript of the multi_array. I can see that index_range has start() and finish() methods, but I can't see how to extract the first index_range from the multi_array. Thanks - Rob.

1 0

[phoenix] Phoenix & 1.37
by Robert Jones 08 Oct '08

08 Oct '08

I see the 1.37 release is gathering momentum. We will see any development of Phoenix in 1.37, following on from all the input of the recent review? - Rob.

2 1

config.hpp
by Joel Falcou 08 Oct '08

08 Oct '08

I'm digging up a previous topic of mine : http://article.gmane.org/gmane.comp.lib.boost.user/39236/match=config Basically, is it possible to consolidate the boost/config headers so they provide a macro usable in #ifdef and such so we can use Boost comprehensive platform/compiler tests in library ? I know some are already usable (like testing for BOOST_MSVC and such) but it lacks in some area like platform. My proposal is the following : For platform, stdlib and compiler config flag, add a macro called respectively : BOOST_ACTIVE_PLATFORM_CONFIG BOOST_ACTIVE_STDLIB_CONFIG BOOST_ACTIVE_COMPILER_CONFIG That contains a numeric value that identify the current chosen configuration. For each type of configuration, files called boost/config/platform_list.hpp,boost/config/stdlib_list.hpp and boost/config/compiler_list.hpp are provided. Those files contains the global list of possible active configuration and give them proper usable symbol. eg : platform_list.hpp #ifndef __BOOST_CONFIG_PLATFORM_LIST_HPP__INCLUDED__ #define __BOOST_CONFIG_PLATFORM_LIST_HPP__INCLUDED__ #define BOOST_AIX_PLATFORM_CONFIG 100 #define BOOST_AMIGAOS_PLATFORM_CONFIG 101 /// and so on ... #define BOOST_WIN32_PLATFORM_CONFIG 111 #define BOOST_UNKNOWN_PLATFORM_CONFIG 999 #endif Then in win32.hpp, the following definition is provided : #define BOOST_ACTIVE_PLATFORM_CONFIG BOOST_WIN32_PLATFORM_CONFIG In user code, it can be checked like this : #if (BOOST_ACTIVE_PLATFORM_CONFIG == BOOST_WIN32_PLATFORM_CONFIG) // Some Win32 code #else // some other code for non-win32 #endif Does this sound useful or am I overlooking some already existing boost system that may already do this ?

1 0

[serialization] disabling msvc warnings
by Jürgen Hunold 08 Oct '08

08 Oct '08

Hi ! Please find a patch attached which disables MS "secure" STL and C-Runtime warnings when build Boost.Serialization with msvc-8.0 and above. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[serialization] extended_type_info_typeid doesn't work with objects with non public destructors
by Rodolfo Lima 07 Oct '08

07 Oct '08

Hi, it seems that in boost::serialization-1.36 the extended_type_info_typeid and extended_type_info_no_rtti doesn't use boost::serialization::access to delete the object, hence there are compile failures when it's used with an object whose destructor isn't public. Is there any chances that this will be fixed in boost-1.37? Regards, Rodolfo Lima

2 2

[property_tree] Conversion constructor missing?
by Boris 07 Oct '08

07 Oct '08

Imagine you have this XML structure (copied from the documentation and shortened): <debug> <modules> <module>Finance</module> <module>Admin</module> <module>HR</module> </modules> </debug> Now imagine you have this function which you want to call three times to pass the <module>...</module> nodes to: void foo(boost::property_tree::ptree pt); You can use get_child("debug.modules") to retrieve a property tree containing all module nodes. However if you iterate over the property tree the iterator refers to std::pair<const key_type, basic_ptree<Tr>> - and there is no simple way to convert this pair to a new property tree. You must create an empty property tree followed by a call to push_back() to insert the pair. Either there is a conversion constructor missing or I miss something and there is a simpler way of what I'm trying to do? Boris

1 0

type_with_alignment.hpp / alignment_of.hpp too heavy
by Emil Dotchevski 07 Oct '08

07 Oct '08

I need to allocate an object of type T, but I also need to bundle it in a single memory allocation with an object of class U. Something like "new std::pair<T,U>" would work, except that U is a rather heavy type and I want to pimpl it away into a cpp. This means that the cpp needs to deal with the alignment of T and U when allocating the memory. For that purpose, I could use type_traits/type_with_alignment.hpp in my header, but when I looked at it, I was blown away by how much crap it includes (remember, I want my header to be very very light.) Then I thought that I could probably build my system by just using type_traits/alignment_of.hpp. It sure would be very light, right? Wrong, it also includes mpl and whatnot. I hope someone shares my frustration. Shouldn't at least alignment_of.hpp be much, much lighter? I'd think that all it should contain is whatever compiler-specific hacks are needed and that's it. What is the justification for including stuff like <boost/mpl/aux_/lambda_support.hpp> in alignment_of.hpp? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

8 9

status on Coroutine library?
by Tim Michals 07 Oct '08

07 Oct '08

What is the status of the coroutine library? _________________________________________________________________ Get more out of the Web. Learn 10 hidden secrets of Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!5…

1 0

[config] Any reason not to enable long long support in for Sun's compiler?
by John Maddock 07 Oct '08

07 Oct '08

Title says it all really, any reason why I should define BOOST_HAS_LONG_LONG for sun's compiler? Seems to all work OK... John.

2 2

[lambda] Serialising Lmanda functions
by Robert Jones 07 Oct '08

07 Oct '08

Is there a 'standard' solution to this problem? #include <list> #include <iostream> #include "boost/lambda/lambda.hpp" typedef std::list<unsigned> List; std::ostream & operator<<( std::ostream & s, const List & ); int main( ) { using namespace boost::lambda; List my_list; ( std::cout << _1 << "\n" )( my_list ); } The compiler cannot find a match for operator<<() because the operator and the type are defined in different namespaces, but it's really a nuisance! - Rob.

2 1

Difficulties checking into release ready branch
by Robert Ramey 07 Oct '08

07 Oct '08

In following instructions to commit to the releae ready branch I get the following message: Modified: BoostRelease\boost\archive\impl\basic_binary_iprimitive.ipp Error: Commit failed (details follow): Error: Your file or directory 'impl\basic_binary_iprimitive.ipp' is probably out-of-date Error: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit). This was after a bunch of files got commit successfully. In the past when problems like this occured (as they often seem to), repeating the operation (with maybe an intervening clean up) seemed to plow through the situation. But this time it seems something is permantly stuck. Any help would be appreciated. Robert Ramey

2 2

Speedier test results.
by Rene Rivera 07 Oct '08

07 Oct '08

First, many thanks to Noel and Sandia Labs for the resources to make this possible. Especially since there aren't many places where quad core machines are near the bottom of the speed spectrum :-) So if you didn't notice the testing hiccups during the weekend you missed the fun of watching a new test report generation server being put online. The new server is a magnitude faster than my server. Which means test results are now available approximately on an hourly basis. Note, there are still the usual double delays to account for the time testers take to run the tests. Have fun with the new timely data! -- -- 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

4 3

[scope_exit] Status?
by Andrey Semashev 06 Oct '08

06 Oct '08

Hi, I've been wondering what's the status of the Boost.ScopeExit library? It's been accepted more than a year ago, though it didn't make it to neither 1.35 nor 1.36. And I don't see it in trunk either. Is it still alive and expected in 1.37?

2 3

[spirit1] including type_traits.hpp
by Richard Webb 06 Oct '08

06 Oct '08

When looking at <http://thread.gmane.org/gmane.comp.lib.boost.devel/180769>, i noticed that <boost\spirit\home\classic\core\parser.hpp> includes <boost/type_traits.hpp>, when only part of it (remove_reference.hpp?) actually seems to be required. Not really a problem, but including the full type_traits.hpp does add quite a bit of weight to my precompiled header.

2 2

[RFC] Protocol for operator. (dot) overloading
by Corrado Zoccolo 06 Oct '08

06 Oct '08

Hi boosters, I think that Adobe poly approach on "operator . overloading" could be extracted as orthogonal to the polymorphic object container concept, and easily generalized to serve all kinds of wrappers. My proposal (see code in the vault: *http://tinyurl.com/5xo9or*) is to have a class template (interface<T,W,B>) that describes the interface of type T, forwarding any operation to the implementation type, got directly from the wrapper (W). B is used when vertical inheritance is needed, either to benefit of EBO or to insert a base class on top of the hierarchy (see type_erasure_wrapper). There is actually a fourth boolean parameter, that will be explained later. interface<T,W,B> can be partially specialized for user types (and libraries can provide the specializations for theirs), leaving the wrapper as free parameter, so that the same specialization can be used for any wrapper we can subsequently write, thus decoupling the interface description step from the interface usage by a wrapper. The interface is separated in 3 parts: * const interface (interface<const T, W, B>) * mutable interface (interface<T, W, B, false>) for const propagating wrappers (inherits from the const interface) * mutable interface (interface<T, W, B, true>) for non const propagating wrappers (simply a copy of the previous one, but with all members/member functions declared const) *Example, for std::string* // sample (*const*) interface for std::string template<typename W, typename B> struct interface<const std::string, W, B> : B { typedef const std::string type; std::size_t size() const { return get_()->size(); } const char * c_str() const { return get_()->c_str(); } // free operators as friend template<typename W1, typename B1> friend std::string operator+ (const interface<const std::string,W,B>& lhs, const interface<const std::string,W1,B1>& rhs) { return *lhs.get_()+*rhs.get_(); } // snip other overloads of operator+ private: typename interface_hook_type<type, W>::type get_() const { return static_cast<W const*>(this)->get_(); } }; // sample (*mutable*) interface for std::string template<typename W, typename B> struct interface<std::string, W, B, false> : interface<const std::string, W, B> { typedef std::string type; void swap(std::string& other) { get_()->swap(other); } std::string& operator=(std::string other) { get_()->swap(other); return *get_(); } std::string& append ( const std::string& str ) { return get_()->append(str); } //snip other overloads of append private: typename interface_hook_type<type, W>::type get_() { return static_cast<W*>(this)->get_(); } }; // mutable, version for non-const propagating wrappers template<typename W, typename B> struct interface<std::string, W, B, true> : interface<const std::string, W, B> { typedef std::string type; void swap(std::string& other) const { get_()->swap(other); } std::string& operator=(std::string other) const { get_()->swap(other); return *get_(); } std::string& append ( const std::string& str ) const { return get_()->append(str); } //snip other overloads of append private: typename interface_hook_type<type, W>::type get_() const { return static_cast<W const*>(this)->get_(); } }; In the archive, you can find: * interface.hpp = definition of interface class template * string_interface.hpp = partial specialization of interface class template for std::string * pair_interface.hpp = partial specialization of interface class template for std::pair (interesting for the way to handle first and second) * wrappers.hpp = some example wrappers. We distinguish between wrappers that propagate their constness to their wrapped type (value semantics, like containers) and wrappers that do not propagate constness (ptr semantics, like reference_wrapper, smart pointers), and provite examples for both. A wrapper (computation_wrapper) is provided in both flavors. * lockable.hpp = a more complex example wrapper. lockable<T> (locking proxy) automatically locks when accessing a method of T through the wrapper. * test{1,2,3,4,5,6}.cc instantiate the wrappers on various types, showing which expressions are well formed and which are't. ** test1: lockable<T> ** test2: string interface (methods & operators), reference vs. value wrappers ** test3: type_erasure_wrapper<I,T> ** test4: const-propagating vs. non-const propagating wrappers, in various scenarios (const wrapper<T>, wrapper<const T>, const wrapper<const T>) ** test5: computation_wrapper<T>, and fundamental types ** test6: pair interface Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo@gmail.com PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

2 2

Win64 and abi_prefix.hpp/abi_suffix.hpp warnings
by Chris Newbold 06 Oct '08

06 Oct '08

I know there have been previous discussions about the warnings emitted from abi_prefix.hpp and abi_suffix.hpp on Win64. Was there ever any resolution? To recap, for every header which uses the ABI bookends, the compiler emits four warnings: abi_prefix.hpp(19) : warning C4103: 'abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) exceptions.hpp(22) : warning C4103: 'exceptions.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) abi_suffix.hpp(20) : warning C4103: 'abi_suffix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) exceptions.hpp(108) : warning C4103: 'exceptions.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) I'm unclear on the rationale for forcing 8-byte alignment in config/abi/msvc_(pre|suf)fix.hpp: 8-byte alignment is the compiler default. Is there concern over Boost headers being included in a context where the alignment has been otherwise artificially altered? Assuming that's the case, I would like to propose adding a warning suppression to config/warning_disable.hpp to silence this particular warning. Here's a diff of what I'm proposing: @@ -43,5 +43,14 @@ // std library function is encountered. # pragma warning(disable:1786) #endif +#if defined(_MSC_VER) && defined(_M_X64) + // warning: 'file': alignment changed after including header, may + // be due to missing #pragma pack(pop) + // + // Caused by MSVC-specific abi_prefix and abi_suffix bookends which + // twiddle the default structure alignment via #pragma pack(); this + // results in a warning only on x86_64 targets. +# pragma warning(disable:4103) +#endif #endif // BOOST_CONFIG_WARNING_DISABLE_HPP I'd like to get something in for Boost 1.37 as this warning is responsible for a significant amount of spam in our build logs. Comments? -Chris

4 10

link error "can not open file "libboost_regex-vc80-mt-gd-1_36.lib"
by ipangth 06 Oct '08

06 Oct '08

I built boost_1.36_0 with vs2005, used command "bjam.exe --build-dir="D:\src\boost_1_36_0" --toolset=msvc --build-type=complete stage". Then i built a project using regex, and link error "can not open file "libboost_regex-vc80-mt-gd-1_36.lib" ". I check the stage diretory, found regex libs: libboost_regex-vc80-mt-s-1_36.lib libboost_regex-vc80-mt-s.lib libboost_regex-vc80-mt-sgd-1_36.lib libboost_regex-vc80-mt-sgd.lib libboost_regex-vc80-s-1_36.lib libboost_regex-vc80-s.lib libboost_regex-vc80-sgd-1_36.lib libboost_regex-vc80-sgd.lib There are no "libboost_regex-vc80-mt-gd-1_36.lib" here. How can i get the "libboost_regex-vc80-mt-gd-1_36.lib" ? PS. I have a machine which has vs2005 and vs2008 install, when i built boost on it, it always uses vs2008 to compile. How can i just use vs2005 buiding it? -- Best regards, PangYongQiang

2 4

[asio] ip::tcp::iostream usage
by Gregory Dai 05 Oct '08

05 Oct '08

The classic example: int main() { boost::asio::ip::tcp::iostream s("www.boost.org", "http"); s << "GET / HTTP/1.0\r\n"; s << "Host: www.boost.org\r\n"; s << "\r\n" << std::flush; std::cout << s.rdbuf(); return 0; } It works. But with a server on port 8080, it does not seem to work anymore. The host line was changed to s << "Host: www.boost.org:8080\r\n"; of course.

2 2

[tr1][spirit][hash] Boost trunk +VC9 - autolinking libboost_math
by Richard Webb 05 Oct '08

05 Oct '08

When test building some code with VC9 + the current Boost trunk i had a link failure due to a missing libboost_math_c99-vc90-mt-1_37.lib, which i hadnt built because i'm not using the math lib. On investigation, this seems to be down to using Spirit/Hash(via multi_index) when the "boost/tr1/tr1" dir is in the include path. More specifically, the files: spirit\home\classic\core\primitives\impl\numerics.ipp functional\detail\float_functions.hpp do an include <cmath>, which in this case includes <boost\tr1\cmath.hpp>, which then includes <boost/math/tr1.hpp>, autolinking and all. I can work around the problem by building the math lib or turning off auto linking for it but it seems wrong that i have to do that. Is there a better official solution for this, such as using <config/no_tr1/cmath.hpp> instead of <cmath> ? Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-tr1--spirit--hash--Boost-trunk-%2BVC9---autolinking-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[xpressive] recursive calls for matching repetitions.
by Raindog 05 Oct '08

05 Oct '08

Eric, I was recently hit by a stack overflow due to the way xpressive makes recursive calls when dealing with patterns like *_, etc and was wondering if there is an alternative, more efficient way of matching these types of patterns. p.s I know about keep() but that can get cumbersome to use everywhere.

2 1

[variant] unreferenced formal parameter warning from VC9
by Richard Webb 05 Oct '08

05 Oct '08

(i think i might have mentioned this before, but it still happens with the current code, so...) Using Variant on VC9 with warning level 4 can result in an unreferenced parameter warning: boost/variant/variant.hpp(289) : warning C4100: 'operand' : unreferenced formal parameter This can be silenced by extending the existing Borland workaround to apply to VC as well. For example, change the existing: #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x0551)) operand; // suppresses warnings to #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x0551)) || BOOST_WORKAROUND(BOOST_MSVC, >= 1400) operand; // suppresses warnings Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-variant--unreferenced-formal-parameter-warning-from-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

generative geometry algorithms library idea
by Brandon Kohn 05 Oct '08

05 Oct '08

Hi all, I've been doing some work for the past few weeks on a generative/generic 2D geometry library (leaving open the possibility for 3D in the future). The idea is for all the algorithms to be generative taking coordinate, point, segment, polyline/gon types as template parameters (or deducing where presented as nested typedefs) and specialized traits types for accessing type traits and methods ( things like access_traits<point_type>::get_x( point ) .). So far the library has allowed me to work with the same algorithms in native floating type and exact types like gmp's mpq_class. It's just a first rough draft of ideas, and I would really like some input from the community to see if I'm on the right track for something that boost would be interested in having. I'll post a copy of the lib in the vault. It's header only (with a small testbed with trivial testing and a visual studio 2008 solution/project). I hope there should not be too many issues compiling these tests/headers under other platforms. I'll put it in the vault as generative_geometry_algorithms.zip link: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=genera… Thanks for any constructive input. With regards, Brandon Kohn

6 10

[asio] using a resolver::query to perform a "gethostbyaddr"
by Carlo Medas 05 Oct '08

05 Oct '08

Dear all, it's kind of direct and easy to perform a gethostbyname-like operation with an asio::ip::tcp::resolver::query. But is there a way to perform the opposite operation? I mean to perform a gethostbyaddr-like operation where the input is an IP address, and output is the associated DNS name. Thanks in advance. Best regards, \Carlo Medas

1 0

phoenix::bind
by Peter Dimov 04 Oct '08

04 Oct '08

This is not a review, sorry. Is it a goal of phoenix::bind to one day replace lambda::bind and boost::bind, being a superset of both, as well of std::bind? I have hoped for boost::lambda::bind to supercede boost::bind. It is a common claim that the only advantage of boost::bind is that it works on more compilers. But this isn't true. It supports constructs which lambda::bind does not; using smart pointers with member functions, member functions of abstract classes, proper const propagation, is_placeholder, _4.._9, and so on. There were other differences (lack of result_type support...) for which I was able to contribute patches to Lambda. But some of the differences are systemic and can only be addressed by a maintainer. Having two components named "bind" has always been a problem for our users. Having three will not help. Ideally, all "bind"s ought to resolve (on a supported compiler circa '08) to the same component. When I heard that the next Phoenix (at the time this meant V2) was intended to be the successor to both Phoenix 1 and Lambda, I thought that we were about to finally have a single bind that "just works". But - and sorry if this is not the case - I do not get the impression that this is a high priority goal for V2. It'd be nice if I were mistaken; it would be nicer still if phoenix::bind passed all boost::bind tests so that we can just replace boost/bind.hpp with a single using declaration. :-) To avoid any misunderstandings: this is not a review, and the above is not a condition for acceptance.

8 74

[simple_segregated_storage] segfault
by Phil Bouchard 04 Oct '08

04 Oct '08

I haven't tried this yet on Linux but so far on Gcc for Wndows my test application segfaults on an allocation routine. Here is the backtrace: #0 0x00415ace in boost::simple_segregated_storage<unsigned int>::try_malloc_n (start=@0x22fc00, n=16, partition_size=4) at simple_segregated_storage.hpp:234 #1 0x00415bc7 in boost::simple_segregated_storage<unsigned int>::malloc_n (this=0x463010, n=17, partition_size=4) at simple_segregated_storage.hpp:256 #2 0x0041c7f2 in boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc (this=0x463010, n=68) at pool.hpp:511 #3 0x0041fb25 in boost::detail::sh::pool::allocate (this=0x463010, s=68) at sh_owned_base_nt.hpp:103 #4 0x00426669 in boost::detail::sh::shifted<std::_List_node<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > > >::operator new (s=68) at sh_owned_base_nt.hpp:213 #5 0x0041f420 in boost::detail::sh::shifted_allocator<std::_List_node<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > > >::allocate (this=0x3e5094, s=1) at shifted_allocator.hpp:83 #6 0x0044aa5d in std::_List_base<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >::_M_get_node (this=0x3e5094) at stl_list.h:333 #7 0x00453ff2 in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >::_M_create_node (this=0x3e5094, __x=@0x22ff50) at stl_list.h:457 #8 0x0045414c in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >::_M_insert (this=0x3e5094, __position={_M_node = 0x3e50c8}, __x=@0x22ff50) at stl_list.h:1185 #9 0x0045418d in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >::push_back (this=0x3e5094, __x=@0x22ff50) at stl_list.h:807 #10 0x00401708 in main () at shifted_ptr_test2.cpp:102 -Phil

2 14

[Review] Phoenix review results
by Hartmut Kaiser 04 Oct '08

04 Oct '08

Hi all, the Phoenix review is over and I counted 15 votes, 11 of which vote for acceptance and 4 vote for conditional acceptance. Let me explain. All reviewers stated that the outstanding quality of the library and its documentation fully merit immediate acceptance. There is no direct concern with regard to the library itself. Phoenix V2 is already in the Boost distribution as a Spirit sub-library and has matured for a long time, proving its stability and usability. On the other hand, Phoenix provides functionality already covered by Boost.Bind and Boost.Lambda. It is the general intention to use Phoenix as the development ground for a new unified Boost library in this area. The review discussions revealed quite some details and certain problems which have to be resolved for this merger to happen. Joel has a full list of these details and promised to address all of them before adding Phoenix to the Boost SVN. The library authors made clear from the beginning that the review of the current Version 2 of the library is just a stepping stone towards this goal. At the same time Eric Niebler presented a first version of a Proto based Phoenix rewrite (referenced as Phoenix V3). It is the general consensus to use Phoenix V3 as the basis for further development. At the same time Phoenix V3 exposes the same interface as Phoenix V2 and passes all related tests. This review formally was about Phoenix V2, but largely turned out to be a discussion of the future of Bind/Lambda and how Boost should go forward in this direction. Again, the general consensus here is that a) we need a unified approach to bind, lambda, et.al., and b) Boost users need interface stability and minimal disruption. So here is the review result: The quality of Phoenix warrants immediate acceptance into Boost. OTOH, adding Phoenix to Boost as is introduces yet another library dealing with functional idioms. This possibly increases the confusion around the fact which of the libraries to use, etc. The goal should be to have a clear integration of, and migration path from the existing Boost.Bind and Boost.Lambda libraries before final addition of Phoenix to Boost. We will have a mini review before Phoenix gets merged to SVN to make sure whether the feedback from the v2 review was accommodated. Additionally this review will have to discuss: - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times In general, the review was valuable for what it accomplished. It moved us closer towards a unified Boost library in the domain of functional programming idioms. Thanks to Joel and Dan for the high quality submission and to all participating the discussion for their valuable insights! Regards Hartmut Review Manager

1 0

[phoenix] local_reference problems
by Steven Watanabe 04 Oct '08

04 Oct '08

AMDG The following code does not compile because phoenix tries to call the % operator with the types: boost::phoenix::detail::local_reference<boost::format> % int What is the rationale for local_reference? #include <boost/spirit/home/phoenix/operator.hpp> #include <boost/spirit/home/phoenix/core.hpp> #include <boost/spirit/home/phoenix/scope.hpp> #include <boost/format.hpp> #include <algorithm> #include <vector> using namespace boost::phoenix::arg_names; using namespace boost::phoenix::local_names; using namespace boost::phoenix; int main() { std::vector<int> values(10); std::for_each(values.begin(), values.end(), let(_f = boost::format("value is %d = %d\n")) [ std::cout << _f % _1 % _1 ] ); } C:\boost\trunk\boost/spirit/home/phoenix/operator/arithmetic.hpp(78) : error C2676: binary '%' : 'const boost::phoenix::detail::local_reference<T>' does not define this operator or a conversion to a type acceptable to the predefined operator with [ T=boost::basic_format<char> ] In Christ, Steven Watanabe

2 1

Like to submit timeseries related functions
by S. Mamun Raihan 04 Oct '08

04 Oct '08

Hi, As part of Graduate program I have developed following useful functions that I like to submit to boost as a seperate library or part of math library - notable functions in my lists are, 1. ARBurg - Auto regressive coefficients using Burg's algorithm 2. ARCeps - Cepstrum coefficeint from Auto-regressive coefficients 3. 1-D filter function 4. 1-D convolution function 5. Moving - Average filter 6. Polynomial Fitting 7. Polynomial Value from Polynomial Coefficients Regards Syed Mamun Raihan 647.278.9083

1 0

Re: [boost] [Phoenix] Review ended September 30th
by Joel de Guzman 03 Oct '08

03 Oct '08

Jaakko Järvi wrote: > Hi All, > > Unfortunately I cannot find the time at this point for > reviewing the Phoenix library. I am familiar with the library, however, > based on careful inspection some time ago. > Phoenix "modernizes", extends, and improves over > Lambda (and FC++), and there's no question about the quality of code or documentation. > > So as much as my opinion counts without conducting a proper review, > I hope it is all right to express my support for Joel's and Dan's work, > and that I wish to see Phoenix accepted to Boost. Thank you, Jaakko for your support. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

1 0

[shared_ptr] Where is the bug?
by vicente.botet 03 Oct '08

03 Oct '08

Hi, I have the following program with the following output #include <iostream> #include <boost/shared_ptr.hpp> using namespace boost; struct B { ~B() { std::cout << "~B" << std::endl; }; }; struct X : B { ~X() { std::cout << "~X" << std::endl; }; int i; }; int main () { shared_ptr<B>* ptr=0; { shared_ptr<X> ptrX1(new X()); ptr = new shared_ptr<B>(ptrX1); } std::cout << "BEFORE" << std::endl; delete ptr; std::cout << "AFTER" << std::endl; B* b = new X(); std::cout << "BEFORE" << std::endl; delete b; std::cout << "AFTER" << std::endl; return 0; } BEFORE ~X ~B AFTER BEFORE ~B AFTER EXIT STATUS: 0 Where is the bug? Vicente P.S. I'm using g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

4 7

[thread_safe_signals] making the connection accesible from slot
by Frank Mori Hess 03 Oct '08

03 Oct '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm curious if anyone has a good idea on how to make a slot's connection easily accesible to it when it is running. A common case is a slot blocks it's own connection to avoid infinite recursion when it is about to do something that will cause its signal to be invoked again. The problem is, for a slot to block its own connection, it needs access to a connection object. But it is a pain in a multi-threaded situation to pass the connection to the slot, since the connection is not available until after the slot has already been connected to the signal. In a single-threaded program, you can do something like: namespace bs2 = boost::signals2 bs2::signal<void (void)> sig; void myslot(boost::shared_ptr<bs2::connection> conn); boost::shared_ptr<bs2::connection> conn(new bs2::connection); *conn = sig.connect(boost::bind(&myslot, conn)); void myslot(boost::shared_ptr<bs2::connection> conn) { //... { bs2::shared_connection_block blocker(*conn); //... } } However, even in thread_safe_signals, assignment of a connection object is not thread-safe. So if the signal can be invoked concurrently, you would need to protect the connect with a mutex, and also protect any use of the connection inside the slot with the mutex, which starts to get a bit tedious. Maybe an additional connect overload for signals, which takes a slot that has an additional parameter added to its signature (a reference to its connection)? For example, for a signal<void (int)> The slot_type is usually slot<void (int), function<void (int)> > I could add an extended_slot_type typedef as a slot<void (int, const connection&), function<void (int, const connection&)> > Then I would add overloads to signalN::connect which accept the new extended_slot_type. That would also mean an additional template parameter for signals, like ExtendedSlotFunction. Or, the SlotFunction template could be dropped entirely and the signal class hard-coded to use boost::function. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI5oxM5vihyNWuA4URAhKkAJwImDkQjMXbBD+81a925QXS5vKvNACgkBr9 dGC3G/2YLGVRu/CJl1zUzSY= =3oKu -----END PGP SIGNATURE-----

1 0

RFC: Integrating Boost.Process and Boost.Asio
by Boris 03 Oct '08

03 Oct '08

I'm looking for ideas how to integrate Boost.Process and Boost.Asio. As of today it is possible to use asynchronous I/O with Boost.Process. However you have to pass around low-level file descriptors/HANDLEs like this: bp::child c = start_child(); bp::pistream &is = c.get_stdout(); #if defined(BOOST_POSIX_API) ba::posix::stream_descriptor in(io_service); #elif defined(BOOST_WINDOWS_API) ba::windows::stream_handle in(io_service); #endif in.assign(is.handle().release()); is.async_read_some(...); It would be nice if you could write: bp::child c = start_child(); bp::pistream &is = c.get_stdout(); is.async_read_some(...); The first question is then where to pass the io_service instance to Boost.Process? In Boost.Asio I/O objects are typically initialized with io_service. As both child and pistream are created in the library io_service would need to be passed to Boost.Process when the child is spawned. However developers who don't want to use asynchronous I/O really shouldn't create an io_service instance first. If io_service is not passed to the constructor I wonder where to pass it then? As far as I see there are no recommendations or guidelines in the Boost.Asio documentation (probably because all I/O objects so far are always initialized with io_service). Another idea is of course adding a new class to Boost.Process (pistream would then only be used for synchronous I/O)? Right now I'd probably go this way? Boris

2 5

Subject: Re: [shared_ptr] Where is the bug?
by Kasra Nassiri(Math & ComSci) 03 Oct '08

03 Oct '08

Hi, Well the bug is in the fact the when you allocated: B* b = new X(); You have allocated an int extra, thus when you call: delete b; You are only destructing what was allocated by B, which cause a sizeof(int) bytes memory leak each time you do this. Just use a virtual destructor on virtual ~B() ... and that would take care of it all. With best regards Kasra Nassiri

4 4

Re: [boost] [shared_ptr] Where is the bug?
by Kasra Nassiri(Math & ComSci) 03 Oct '08

03 Oct '08

> No. > You are invoking undefined behaviour. Well, by definition you could not be more right, however, in practice my point applies. It is like the x86 sh(l/r) instructions, although for some values larger than the bitfield of the operand the instruction is undefined it behaves in a certain way :D. However, you are right and I am wrong! With best regards Kasra Nassiri

1 0

[threadalert] alternative design for thread_member_ptr and thread preamble
by vicente.botet 03 Oct '08

03 Oct '08

Hello, I have do some refactoring on the thdmbrptr.hpp and thdmbrptr.cpp files. * The design is now more decoupled, separating the thread preamble initialization and the thread_member_ptr type. * The thread_member_ptr constructor supports now a cleanup functions parameter. * I have added the release function * We don't need any more a new class thread (boostex::thread) that inherits from boost::thread, to store the common context for the thread to manage the detaching of the pointer from the map (this is done using the thread_specific_ptr cleanup). * I have renamed boostex::thread::init by boost::thread_preamble, and these preamble functions will be called on the threads initialized using the thread_preamble::proxy. You can find the code and example in the attached files. Just to recall the goals: * thread_preamble allows to define some preample functions which will be called by each thread initialized using the thread_preamble::proxy * thread_member_ptr: The intent of this class is to allow two threads to establish a shared memory space, without requiring the user code to pass any information. This basically does work like a thread local storage from inside the thread: boost::thread_member_ptr<myclass> pmyclass; All functions known from thread_specific_ptr are available, and so is semantics from inside the thread. Besides this another thread can get access to the data by: pmyclass[th->get_id()]->foo(); where "th" is a boost::thread* and "foo()" is a function of "myclass". The lifetime of the myclass instance is managed by a shared_ptr. One reference is held by the thread (by means of a tss), a second is held by the boost::thread object that created the thread, and additional references might be held by other threads that obtained it by "*pmyclass[th]". Please let me know what do you think of this new design. I'll use these classes for some libraries: * a software transaction library: transactional thread specific context which can also be accesible from other threads during consistency checking * a thread keep alive: the keep_alive_manager will check the registered threads by looking on the associated keep_alive thread_member_ptr. Do you think that these two classes might be a candidate to a separated Boost library or that it will be better to integrate them on the thread library? Best, Vicente

2 1

[mp_math_v02] Bug in assignment operator
by Mikko Vainio 03 Oct '08

03 Oct '08

Hi, Referring to the mp_math_v02 library in the Vault, the assignment operator of class mp_int<> does not quite behave the way it should. The following program #include <iostream> #include <boost/mp_math/mp_int.hpp> using namespace std; int main( int argc, char* argv[] ) { boost::mp_math::mp_int<> a, b(-1); a = -1; cout << a << " == " << b << endl; return 0; } produces the output -4294967295 == -1 It seems that the constructor code behaves as expected. I'm using gcc 4.3.0 on x86 Fedora 9. Cheers, Mikko

2 1

[shared_ptr] towards a static_cast applied to smart_ptr
by vicente.botet 03 Oct '08

03 Oct '08

Hello Peter, the following simplified example do not compile when DONT_NOT_COMPILE is defined. #include <boost/shared_ptr.hpp> using namespace boost; struct X { int i; }; int main () { shared_ptr<X> ptrX1(new X()); shared_ptr<void> ptr_void(ptrX1); #if DONT_NOT_COMPILE shared_ptr<X> ptrX2(ptr_void); #endif return 0; } test_thread_shared_ptr.cpp: In function `int main()': test_thread_shared_ptr.cpp:37: error: no matching function for call to `boost::s hared_ptr<X>::shared_ptr(boost::shared_ptr<void>&)' ../../../boost/shared_ptr.hpp:154: note: candidates are: boost::shared_ptr<X>::s hared_ptr(const boost::shared_ptr<X>&) ../../../boost/shared_ptr.hpp:241: note: boost::shared_ptr< <template-parameter -1-1> >::shared_ptr(const boost::detail::shared_count&, T*) [with T = X] ../../../boost/shared_ptr.hpp:167: note: boost::shared_ptr< <template-parameter -1-1> >::shared_ptr() [with T = X] This is normal as void* is not convertibel to X*. But in my program I can ensure that the pointeed object by ptr_void is a X pointer. So it would be safe to do a kind of static_cast on shared_ptr. At the end smart pointers should behave like pointers. My real use case is a map of void* to shared_ptr<void>. I insert pairs of T* and shared_ptr<T> and I want be able to static_cast the resulting shared_ptr<void> of find function to shared_ptr<T>. Can I achieve this already? I was thinking is something like something like shared_ptr<X> ptrX2(boost::static_cast<shared_ptr<X> >(ptr_void)); If we can not achieve this now, I think that it should be not too dificult to implement inside your library. Do you think that this is an interesting feature to be included in the Boost.SmartPtr library? Best, Vicente Botet

2 2

sandbox:spatialIndex example compilation fails on gcc-4.2
by Sandeep Gupta 02 Oct '08

02 Oct '08

Hi, Not sure if this known problem but example.cpp of spatial_index library fails to compile out of the box (this is latest version check out from svn repository). A brief look at the code shows that all avatar of spatial_index take two template-arguments but example calls it with one argument. Please find the error message pasted below. Thanks sandeep example.cpp:14: error: wrong number of template arguments (1, should be 3) ../../../boost/spatial_index/spatial_index.hpp:29: error: provided for 'template<class Point, class Value, class Index> class boost::spatial_index::spatial_index' example.cpp:14: error: invalid type in declaration before ';' token example.cpp:17: error: request for member 'get_nothing_count' in 'object', which is of non-class type 'int' example.cpp:18: error: request for member 'nothing' in 'object', which is of non-class type 'int' example.cpp:19: error: request for member 'get_nothing_count' in 'object', which is of non-class type 'int' example.cpp:21: error: request for member 'get_call_count' in 'object', which is of non-class type 'int' example.cpp:22: error: request for member 'nothing' in 'object', which is of non-class type 'int' example.cpp:23: error: request for member 'get_call_count' in 'object', which is of non-class type 'int' example.cpp:24: error: request for member 'get_nothing_count' in 'object', which is of non-class type 'int'

1 0

[Phoenix] review
by Giovanni Piero Deretta 02 Oct '08

02 Oct '08

- Please always state in your review, whether you think the library should be accepted as a Boost library! Having to review a library that is already expected to change is hard, OTOH functional programming in c++ need to go beyond boost.lambda (which has been basically in maintenance mode for a long time), and I think that Phoenix is the way to the future. Thus I think that Phoenix should be accepted. I support having an extra mini review after the implementation has been updated, but my vote is not under this condition. I think that the review plan proposed by Eric is great. - What is your evaluation of the documentation? I think that documentation of Phoenix is probably the most important part of the library and I consider it of high quality: I've been an happy lambda user for a couple of years. I went beyond its documented interface and started to play with its internal. I've been able to add lazy functions to lambda and other nice additions. But I would never even have attempted that if I hadn't been exposed to the Phoenix documentation. I've never really used the phoenix library, but I've read its documentation many times (starting maybe 4 years ago, I think it was the old V1 documentation). I remember that the first time I read it I understood basically nothing. But it got me interested in functional programming. Every time I read it I learned a bit more until something clicked. After that everything seemed so obvious. Thanks Joel, you exposed me to a new world. - What is your evaluation of the design? Very good. I'm a big fan of lazy functions (I try to make all my polymorphic functions object lazy, and leave bind only for good old function pointers), and I hope that Joel will make them 'optionally lazy'. But even if he didn't, thanks to phoenix extensibility, it wouldn't be hard to add it on top of the current design. Again, I vote for always requiring lambda[] around every lambda expression, as this could really help to solve many problems, like assignability and operator& problems. It will also open up the road for further improvements, like overriding capture defaults or selecting perfect forwarding. About perfect forwarding: it would be great if phoenix allowed it by default at least on compilers that support rvalue references. IMHO result_of support is necessary for a library released today :). I cannot really comment on the details of extension interface as it seems that it is bound to change, but I think it is, together with lazy functions, the bigger improvement to boost.lambda. - What is your evaluation of the implementation? I did only take a quick glance at the implementation, but the code looks surprisingly clean (even if comments are a bit spotty), with few compiler workarounds. This is most likely due to the clean separations of the various parts of the library. Even the use of the preprocessor seems limited to the strict neces. I did notice that stl function object instances are declared, as const, in an header file. This could cause ODR violations. - What is your evaluation of the potential usefulness of the library? Great, at least if one is interested in a more functional approach to C++. - Did you try to use the library? With what compiler? Did you have any problems? I tried some examples with gcc 4.2. Didn't have any problem after I figured out that the header placement inside spirit changed from boost 1.35 to 1.36. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in depth study of the documentation and a quick reading of the source. - Are you knowledgeable about the problem domain? A bit. I've never implemented a full lambda library, but played a lot with boost.lambda. [ I would have liked to make a more in-depth review, but I'm in the middle of a deadline, sorry] -- gpd

3 6

[Review] Phoenix review starts today, September 21st
by Hartmut Kaiser 02 Oct '08

02 Oct '08

Hi all, The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: The Phoenix library enables FP techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to FP principles. History: Phoenix is a mature library from years of use as a sub-project under Spirit where it serves its purpose for semantic action handling. Phoenix predates Lambda's acceptance into Boost, but not Lambda itself. When Lambda was reviewed, it was concluded that both libraries were to be merged, and work on it began, culminating in Phoenix V2, what you are seeing now (an interesting offshoot of this effort is Boost.Fusion. We needed a powerful tuple facility with algorithms to get the design right). Recently, Eric Niebler did a (fully compatible) port to proto making use of boost.typeof for result type deduction. Eric's port, while significant, will not be the subject of the review, but can be regarded as the future of Phoenix (Phoenix V3). Phoenix V2 is currently a utility library included with Spirit V2 and therefore is already available from the latest Boost distributions (headers: $BOOST_ROOT/boost/spirit/home/phoenix, docs: $BOOST_ROOT/libs/spirit/phoenix, or http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/index.html) Phoenix V2 is a very important infrastructure library, IHMO. It has been used for several other library writing efforts already, most notably, Spirit V2. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

12 37

error during compliation of documentation for SpatialIndexes
by Sandeep Gupta 01 Oct '08

01 Oct '08

Hi, I am getting following error while compiling the docs for spacial_indexing: ...patience... ...found 1299 targets... ...updating 2 targets... xslt-xsltproc ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.docbook ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.xml:82: parser error : Opening and ending tag mismatch: section line 44 and library </library> ^ ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.xml:83: parser error : Premature end of data in tag library line 3 ^ unable to parse ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.xml XML_CATALOG_FILES=/home/sandeep/develop/libraries/boost-trunk/bin.v2/boostbook_catalog.xml export XML_CATALOG_FILES "/usr/bin/X11/xsltproc" --stringparam annotation.support "1" --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "3" --stringparam generate.section.toc.level "3" --stringparam toc.max.depth "3" --stringparam toc.section.depth "3" --xinclude -o "../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.docbook" "/home/sandeep/develop/libraries/boost-trunk/tools/boostbook/xsl/docbook.xsl" "../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.xml" ...failed xslt-xsltproc ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.docbook... ...skipped <phtml>standalone_HTML.manifest for lack of <p../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug>spatial_index_xml.docbook... ...failed updating 1 target... ...skipped 1 target... Thanks sandeep

1 0

Re: [boost] [switch] Is there any interest in library switch extention?
by Kasra Nassiri(Math & ComSci) 01 Oct '08

01 Oct '08

>I hardly see how this could work for a O(1) lookup (the point of the >switch statement). I have found a compile time solution! However, we need C++0x :( A hash functions with output type of <int> so we could embed the statement in a normal switch statement on C++0x. #define BOOST_SWITCH( object ) switch ( const_hash_function(object) ) #define BOOST_CASE( case_object ) case const_hash_function(case_object) #define BOOST_DEFAULT default So we could write code like: BOOST_SWITCH( "Hello World" ) { BOOST_CASE("wrong value"): BOOST_CASE("another wrong value"): cout << "Reached wrong statements" << endl; BOOST_BREAK; BOOST_DEFAULT: cout << "Hello World" << endl; }; What I like to add is a reference to the value of the BOOST_SWITCH(...), in this example "Hello World".

2 1

[integer] Promotion of endian library code from vault
by Neil Mayhew 01 Oct '08

01 Oct '08

On 2006-07-22 12:21:01, Beman Dawes wrote: > [boost] [integer] endian-0.6 posted w/ names changed > endian-0.6.zip has been posted in the integer directory of the file > vault at http://boost-consulting.com/vault/ This code is still in the vault, but I'd like to see it in the main part of boost. What needs to be done to make this happen? The endian library is exactly what I've been looking for, and I would really like to use it in my work, but I can't justify that to my colleagues if it's not an official part of boost. I would hate to become yet another person that reinvents this particular wheel. However, I notice there was a lot of discussion <http://lists.boost.org/Archives/boost/2006/07/108125.php> about PODs vs constructors, because of unions, so maybe not enough consensus was reached? There were some interesting proposals but no agreed-upon solution. In which case, I suspect that people will need to copy the code and each hack it to suit their own purposes, which is not what boost is all about. I have two use cases from my own work: TrueType fonts, and Mac HFS+ file systems. Both of these are big-endian file formats that need to be read into memory and processed, so (FWIW) I would support the POD approach. Currently, I can't use the code as-is because of the need to use the types in unions. References: http://lists.boost.org/Archives/boost/2000/03/2495.php http://lists.boost.org/Archives/boost/2006/05/105621.php http://lists.boost.org/Archives/boost/2006/06/105695.php http://lists.boost.org/Archives/boost/2006/06/105779.php http://lists.boost.org/Archives/boost/2006/06/105968.php http://lists.boost.org/Archives/boost/2006/06/106655.php http://lists.boost.org/Archives/boost/2006/07/108125.php http://lists.boost.org/Archives/boost/2006/07/108202.php --Neil

9 37

[Phoenix] Review ended September 30th
by Hartmut Kaiser 01 Oct '08

01 Oct '08

Hi all, just a (last) reminder for all of you still wanting to submit a review. The official review period is over, but since I'm going prepare the review summary this weekend only anyway - you still have a day or two. Regards Hartmut Review Manager

1 0

Phoenix and perfect forwarding
by Mathias Gaunard 01 Oct '08

01 Oct '08

Compilers are starting to support rvalue references. Wouldn't it be pertinent to use that to implement perfect forwarding, if available? Phoenix could surely benefit from that.

3 2