- Boost - lists.preview.boost.org

[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