- Boost - lists.preview.boost.org

Re: [boost] discussion of garbage collection in C++
by Kasra 27 Apr '09

27 Apr '09

Edward Diener wrote: >Also, for people looking for a runtime envrironment for C++, they can look >at Ch. Or CERN.ROOT.CINT project. Either way we are looking at GC in C++ from the wrong direction. I like to know and be able to determine where the memory allocation deallocation occurs. When the constructor and destructor is called using RAII, however, this doesn't mean I shouldn't use GC. GC is supposed to release unused memory, not to call the destructors of objects; although it does on most implementations. [example bool g(int); for(int i=0; i<10000; i++) { // allocate a memory of size = sizeof(Foo) // then construct an instance of Foo on that memory gc_ptr<Foo> f(new (gc) Foo()); // if g(i) == true, delete the memory if( g(i) ) operator delete(f, gc); } // delete all of the objects. GC::collect(); example] The distinction is between construction/destruction of objects and allocation/deallocation of memory. We let GC to perform allocation/deallocation of memory, while we allow ourselves optionaly to take control of construction/destruction of the objects allocated on that memory. This distinction is so important while everyone ignores :D -- Kasra

3 2

[ASIO] Host not found (authoritative)
by Alexander Dong Back Kim 27 Apr '09

27 Apr '09

Dear members, This is a very beginner's question on ASIO. I followed the tutorial example "daytime" in the ASIO document. Server one seems running well because nestat shows the port has been opened and listening. However, when I run the client one, the application prints out "Host not found (authoritative)" message only. I'm using port 21165. $ ./client localhost:21165 Is my command wrong? cheers, Alex Kim

1 0

[1.39] Merge to release
by Daniel James 27 Apr '09

27 Apr '09

Is it okay to merge this? https://svn.boost.org/trac/boost/changeset/52598 It's just a trivial CSS bug fix. thanks, Daniel

4 3

[gc] new implementation in boost vault that solves the issue of finalization order
by Achilleas Margaritis 26 Apr '09

26 Apr '09

Hi. I have posted a new gc implementation in the boost vault here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=gc1.zi… The code included in the file is a garbage collector with the following differences from the previous one: 1) finalization order that respects destructor semantics, except when there are cycles. In the previous collector, the order of finalization was random. In the new collector, an unreachable object A that is pointed to by another unreachable object B will be finalized after B is finalized. This allows the use of gc ptrs within destructors. 2) O(1) detection of member ptrs: pointers registers themselves to the appropriate ptr list as they are created. In the previous collector, pointers where discovered in the collection phase by look-up on the sorted blocks. The code is not completed or polished, but it is published for discussing possible implementation ideas. The main bottleneck right now is how to locate blocks from pointers. The current solution is to sort the blocks by address at collection time, then use std::upper_bound to locate the blocks. This has O(log2(N)) complexity, where N is the number of blocks.

1 0

[ANN] Spirit V2.1 (beta) committed to the Boost SVN
by Hartmut Kaiser 26 Apr '09

26 Apr '09

Hi all, The Spirit team proudly announces that we committed Spirit V2.1 (beta) to the Boost SVN (trunk). We will continue the development there, so please don't use the Spirit SVN anymore as it will quickly go out of sync. Spirit V2.1 is a complete rewrite of V2.0, while maintaining most of the V2 interface. We will add a comprehensive document explaining what's changed soon. Here are some of the highlights: - More homogeneous interface (multi-attribute API similar to printf/scanf, but using Qi/Karma format descriptions) - More balanced set of primitives and directives (Qi and Karma now better complement each other) - Reduced compile times! Compilation is up to 50% faster if compared to equivalent code from V2. - Optimized execution times. Spirit is now faster than ever before. - Simplified usage of grammars and token definitions - Fixed a whole bunch of bugs and inconsistencies - etc. Please report any experience you might gain (good and bad)! As a side note: Joel and I will give a talk about Spirit V2.1 at BoostCon in Aspen slightly more than a week from now. You still can register (www.boostcon.com) if you haven't done yet. On behalf of the Spirit team Regards Hartmut PS: We would like to thank all who participated and contributed to this. It really was a major team work!

1 0

Boost 1.39.0 beta 1 is available for download
by Beman Dawes 26 Apr '09

26 Apr '09

Boost 1.39.0 beta 1 is available for download from SourceForge. See http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&… New Libraries: Signals2. Updated Libraries: Asio, Flyweight, Foreach, Hash, Interprocess, Intrusive, Program.Options, Proto, PtrContainer, Range, Unordered, Xpressive. Updated Tools: Boostbook, Quickbook. Plus the usual bug fixes to numerous libraries. Please report any problems to the Boost users or developers mailing list. Thanks, --Beman Dawes, Daniel James, and all the other Boosters who help get releases out

1 0

[quick-book] suggestion about library compatibility
by Thorsten Ottosen 26 Apr '09

26 Apr '09

Hi, quickbook already has Admonitions like [note a note] which generates a nice box with an icon. I think it would be useful to have addition admonitions to indicate the following - the library can be serialized with Boost.Serialization - the library can be compiled without exceptions (BOOST_NO_EXCEPTION) - the library can be used with Boost.Interprocess so these can be stated in a consistent manner up front in the documentation. Perhaps it is better that these are written up front like [library Boost.AutoBuffer [quickbook 1.4] [copyright 2009 Thorsten Ottosen] [compatibility noexceptions serialization interprocess] ] ? Any comments? -Thorsten

2 1

[mpl] mpl::string, help needed (vacpp, sun, borland)
by Eric Niebler 25 Apr '09

25 Apr '09

A few days ago, I added mpl::string (a compile-time string class template) to trunk. I expected horrific portability problems with my use of multi-character literals, but it's not as bad as all that judging from the test results. There are only a few failures on compilers I don't have access to: vacpp, sun and borland. I invite anybody with access to these compilers to "bjam string" in the libs/mpl/test directory, try their hand at fixing the problems and submitting a patch. Thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 10

Proposed templated integer_sort
by Steven Ross 25 Apr '09

25 Apr '09

Would there be interest in an integer_sort call that is faster than std::sort? Spreadsort is an in-place hybrid radix-based and comparison-based algorithm with better worst-case and average-case (roughly 20-50%) performance than introsort on random integer data. The worst-case advantage is algorithmic, with Spreadsort taking the better of O(n(square_root(bit_sizeof(data) - log(n)))) and O(nlog(n)) time. For 32-bit integers, that's O(n(square_root(32 - log(n)))), so for a log(n) of 16 (65536 items), it's 4n (plus a small constant times n), vs 16n for introsort. For larger n, the advantage vs. pure comparison-based algorithms increases. In effect, Spreadsort smoothly transitions from pure MSB Radix sort to std::sort with its data cut up by a couple iterations of MSB Radix sort (reducing the size of the log(n) factor), depending upon the distribution and size of the data. I could write a templated version of Spreadsort for the Boost library if there is interest. It would work for anything that supports the << and - operators. It could also handle standard floats sorted as integers. Functors supporting << and - could make it more general. Multi-dimensional sorting is also sped up by Spreadsort. I could also write a similar string_sort, that should also be significantly faster than std::sort. This would look much like postal sort, just using introsort after a certain number of iterations. Is this of interest? http://sourceforge.net/projects/spreadsort

15 118

BoostCon 2009 Registrar's Report
by Kim Scheibel 24 Apr '09

24 Apr '09

I'm very happy to report that, despite the current economic climate, we currently have a very solid number of confirmed registrations for BoostCon 2009. 84 registrations to be precise, of which 6 were registered in the last two days alone. You still have time to register at the discounted price of USD599 at http://www.boostcon.com/registration, on or before Apr. 26th. After that, the fee is USD699. Best regards, Kim Scheibel BoostCon 2009 Registrar

1 0

Re: [boost] request for interest in a garbage collection library
by Kasra 24 Apr '09

24 Apr '09

>One of the advertised advantages was that is was written purely in >standard C++, which isn't the case of Boehm which isn't portable. I am sure Boehm supports so many platforms and many compilers. Even so, an interpretation from C to ISO C++ is enough for that problem. >> auto_ptr<char*> traced_buffer(new (gc_traced) char[1024]); > This raises undefined behaviour, I believe. gc allocated memory slab is always zero, so there would be no live pointers on the traced_buffer memory slab. I think we the concept of the GC should encapsulate two things separately. memory allocation/deallocation object construction/destruction [example class foo; { auto_ptr< foo > foo_bar(new (gc) foo()); } // call foo_bar->~foo(); example] the RAII call the destructor but the memory that was occupied is not necessarily free. the gc::collect(), collects the memory as well as calling the destructor for non-destructed objects. -- Kasra

7 11

Re: [boost] [soc2009] Proposal for serialization library
by uwe.arzt 24 Apr '09

24 Apr '09

Hartmut Kaiser wrote: > > >> implementation has not responded to my email. You can check out the >> code >> here: >> http://code.google.com/p/google-summer-of-code-2008- >> boost/downloads/list > > In this case you might want to contact the mentor of last year's YAML > project: Joel de Guzman (joel at boostpro dot com). > > Do you know if the merge to boost is planned in the (near) future? Who should be contacted about that? Is help needed? Thanks :q! Uwe -- View this message in context: http://www.nabble.com/-soc2009--Proposal-for-serialization-library-tp226009… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] Boost.Process article: Tutorial and request for comments
by Boris Schaeling 24 Apr '09

24 Apr '09

On Tue, 21 Apr 2009 16:05:04 +0200, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > [...]I assume the name of the executable should be in the locale > character set. > So std::string, or even const char*, appear suitable. > > Now, if you want to perform automatic translation from unicode to locale > character set, why not, but that's another layer on top of that. An > unicode string type should be convertible to the locale character set > easily enough so that you don't need to that in your library, however. > > You could eventually add support for wide characters, though. While wide > characters are Unicode on Windows, they are as far as C++ is concerned > just another locale character set, and I think considering them as > nothing more than that is best. > > As far as I know, POSIX systems simply don't have APIs for wide > characters, however. Another problem on Windows might be that new projects in VC++ 2008 automatically assume Unicode is used. Thus all Windows API functions expect wide character strings which again means for executable names std::wstring would need to be used. And I don't know if developers really think about it and not simply assume that they can use std::string in all cases. I think Ion faced a similar problem when he developed Boost.Interprocess which only accepts const char* strings (and according to http://www.boost.org/doc/libs/1_38_0/doc/html/interprocess/acknowledgements… waits for string conversion utilities which would be the additional layer you mentioned). >> * 'handle' is the underlying native file handle of a stream (file >> descriptor on POSIX systems, handle on Windows). The concept is based >> on a >> class in the detail namespace of Boost.Process. There is just one class >> and it's not meant to be used by users of the library either. Thus I'm >> not >> sure what's the benefit of having an explicit 'handle' concept at all. > > Isn't it in case Boost.Process doesn't implement the features I need, so > that I may use them directly with the native functions? Before I had added a handle() function to the stream classes there was no way to access a handle. Indeed I had added handle() because I wanted to use the file descriptor/Windows HANDLE for asynchronous I/O. I think I agree with you that it should be possible to access native handles. However I'm not sure if a concept has to be defined. Maybe I understand concept wrong but if I hear concept I think about extensibility and different types. In that sense a concept for an executable name makes sense to me (if it wasn't so difficult to support it). But I'm not sure how it fits to a handle? Boris > [...]

1 0

Boost Serialization problem
by Suhail 24 Apr '09

24 Apr '09

Hallo I have currently installl the Boost boost_1.38 . Start new program in VC2003 add following lib in my project boost_serialization-vc71-mt-1_38.lib boost_serialization-vc71-mt-gd-1_38.dll example code: #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <iostream> #include <fstream> #include <stdio.h> using namespace std; void save() { std::ofstream file("archiv.txt"); boost::archive::text_oarchive oa(file); int i = 7; oa << i; } void load() { std::ifstream file("archiv.txt"); boost::archive::text_iarchive ia(file); int i = 0; ia >> i; std::cout << i << std::endl; } //========================================================== /// Main function //========================================================== void main(int argc, char* argv[]) { save(); load(); } After executing this example "archiv.txt" only stores 22 serialization::archive 5 instead of 22 serialization::archive 5 1 Could someone help me where i am making mistake??

1 0

Interest in atomic library?
by Seth LaForge 23 Apr '09

23 Apr '09

In this day and age, running our C++ programs off fossil fuels makes a dangerous contribution to global warming and requires purchase of carbon offsets for ethical programming. Thus I think it's time for a Boost atomic power library. Oops, sorrry, wrong meaning of atomic. What would people think of an atomic integer library, along the lines of Linux's asm/atomic.h? I'd propose a class atomic<T> implementing operations like atomic read (implicit conversion to T), atomic set (assignment from T), and compare-and-exchange. For integral types it would support atomic add and return result (operator+=), atomic subtract and return result (operator-=), atomic increment and return result (prefix operator++), and atomic decrement and return result (prefix operator--). For arbitrary architectures or unhandled types of T, there would be a naive implementation using a mutex. On supported architectures there would be specializations for integral T types, using assembly to implement more efficient atomic operations. This assembly could pretty much just be borrowed from the Linux asm/atomic.h headers. What do people think? I see pros: + Cross-platform efficient atomic operations for efficient threaded apps. I see cons: - Hard to predict whether your atomic ops will be efficient (no specialization for your architecture/T). - Some architectures may implement different atomic ops, making the above ops not the most efficient. I think the pros outweight the cons. I'd personally much rather use a Boost.atomic library than asm/atomic.h. Seth

6 7

Re: [boost] request for interest in a garbage collection library
by Kasra 23 Apr '09

23 Apr '09

>This library is not better than Boehm's gc (certainly slower than Boehm's), >but it is portable C++. I have looked at the library more thoroughly now. If you are interested in improving performance I have a method that could improve the performance big time. Just drop me a personal email. -- Kasra

1 0

Re: [boost] request for interest in a garbage collection library
by Kasra 23 Apr '09

23 Apr '09

I have interest in garbage collection. However, I have few questions about this library. * How is it going to be better than The Boehm GC? * Why isn't it a wrapper for Bohem? This header is what is used within our organisation for GC memory management. [C++ =============================================== C++] #ifndef __GC__ #define __GC__ #define GC_NOT_DLL #include <bohem/gc.h> #include <bohem/gc_allocator.h> #undef GC_NOT_DLL #ifdef BOOST_MSVC # pragma comment(lib, "gc.lib") #endif namespace { using gc_allocator; using gc_traceable; extern const struct gc_memory_t { } gc; extern const struct gc_traceable_t { } gc_traced; inline void* operator new(size_t size, const gc_memory_t&) throw(bad_alloc); inline void* operator new[](size_t size, const gc_memory_t&) throw(bad_alloc); inline void operator delete(void* memory, const gc_memory_t&) throw(bad_alloc); inline void operator delete[](void* memory, const gc_memory_t&) throw(bad_alloc); inline void* operator new(size_t size, const nothrow_t&, const gc_memory_t&) throw(); inline void* operator new[](size_t size, const nothrow_t&, const gc_memory_t&) throw(); inline void operator delete(void* memory, const nothrow_t&, const gc_memory_t&) throw(); inline void operator delete[](void* memory, const nothrow_t&, const gc_memory_t&) throw(); inline void* operator new(size_t size, const gc_traceable_t&) throw(bad_alloc); inline void* operator new[](size_t size, const gc_traceable_t&) throw(bad_alloc); inline void operator delete(void* memory, const gc_traceable_t&) throw(bad_alloc); inline void operator delete[](void* memory, const gc_traceable_t&) throw(bad_alloc); inline void* operator new(size_t size, const nothrow_t&, const gc_traceable_t&) throw(); inline void* operator new[](size_t size, const nothrow_t&, const gc_traceable_t&) throw(); inline void operator delete(void* memory, const nothrow_t&, const gc_traceable_t&) throw(); inline void operator delete[](void* memory, const nothrow_t&, const gc_traceable_t&) throw(); } #endif /* __GC__ */ [C++ =============================================== C++] [example auto_ptr<char*> gc_buffer(new (gc) char[1024]); auto_ptr<char*> traced_buffer(new (gc_traced) char[1024]); example] -- Kasra

3 2

[1.39.0] [Lambda] [Iterator] Warnings with gcc 4.3?
by Beman Dawes 22 Apr '09

22 Apr '09

In an email about something else, someone asked: ... we will be eager to use your upcoming version 1.39. One point we would be interested is to remove the following warnings on gcc 4.3. Would you know if those were fixed? <warning value="boost-1_38/boost/lambda/detail/lambda_functors.hpp:137: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:55: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:60: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:65: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/iterator/iterator_facade.hpp:652: warning: type qualifiers ignored on function return type" /> Does anyone know the status of these? --Beman

2 2

[Boost-announce] Review Conclusion - Futures Library
by Tom Brinkman 21 Apr '09

21 Apr '09

Review Conclusion - Futures Library Braddock Gaskill http://braddock.com/~braddock/future Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp The lack of examples and documentation made them difficult to review. Nevertheless, Anthony Williams futures library did receive almost unanimous and enthusiastic support. Unfortunately, the depth of the support was very shallow. I just finished my first read of Anthony's book "C++ Concurrency in Action and acknowledge his expertise in the areas of multi threaded and parallel programming. (http://www.manning.com/williams/) Anthony is the maintainer of boost::threads. Anthony's Future library has been approved for the next major release of c++ standard. Conclusion Braddock Gaskill - Rejected Anthony Williams - Approved Anthony's Futures library is approved for inclusion into boost::threads. As he is the maintainer of that library, he should be given maximum latitude about how that is to be done. In the future, if Anthony wants to re-publish the library as a top-level boost library, then he needs to resubmit it again with samples and test cases, which are lacking. Requirements As per the usual boost library requirements, examples and test cases are needed. Anthony should also improve the documentation, which should not be a problem as he is a prolific author in the area of multi threaded programming. Review Manager Tom Brinkman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

3 2

[mpi] Automatically Cascading/Nested Reduce?
by Dean Michael Berris 21 Apr '09

21 Apr '09

Hi Guys, I'm writing quite a number of parallel-distributed applications in the day job, and I'm missing a facility which allows for "automagically" nesting my reductions. The reduction strategy I'm looking for is one of a networked approach where (if you can imagine a tree): 0 |-1 | |-2 | |-3 | |-4 |-5 |-6 Nodes 2 and 3 send their data to node 1, node 5 and 6 send their data to node 4, and eventually node 1 and 4 send their (reduced) data to node 0. My idea is that it should be simple to implement this without having to go through too much trouble with communicators -- or that it could be automagically done by hiding the communicator splits in the special reduce implementation. Would something like this be best implemented within Boost.MPI? Or is there a way of implementing this by composing the functionality already available in Boost.MPI? The reason I ask is that sometimes the reduction step dominates the amount of time the application spends especially when you have quite a number of nodes (around 90ish). Being able to parallelize (or nest) the reduction would definitely help, but the cost of supporting that routine over a number of applications seems to warrant a special implementation of the Boost.MPI reduce. TIA -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

2 3

Problem with write_graphviz
by Josep TORRAS FLAQUER 21 Apr '09

21 Apr '09

Hello, I'm working with boost graph library. I'm creating a graph and i'd like to write its description into a file or to display it on the screen. The properties of Edges and Vertex are bundled, and i'm not able to write them. I have read the doc once and again and i don't get to find a solution. I have looked for examples but i haven't found anything actually useful for me. Could anyone please help me or propose a possible solution? Here is my code: #include <boost/graph/iteration_macros.hpp> #include <string> #include <boost/tuple/tuple.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/visitors.hpp> #include <boost/graph/breadth_first_search.hpp> #include <map> #include <boost/graph/adj_list_serialize.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/multi_array.hpp> #include <cassert> #include <boost/graph/graphviz.hpp> //using namespace boost; struct VertexProperties{ std::string gate_type; int gate_level; int gate_index; int num_input; float prob_err; }; struct edge_properties { std::string name; }; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, VertexProperties , edge_properties> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; int main() { int i=0; //const char* name = "123"; Graph g; Vertex u1; u1=add_vertex(g); g[u1].gate_type = "Input"; g[u1].gate_level=1; g[u1].gate_index=i; g[u1].num_input=0; g[u1].prob_err=0; i++; Vertex u2; u2=add_vertex(g); g[u2].gate_type = "Input"; g[u2].gate_level=1; g[u2].gate_index=i; g[u2].num_input=0; g[u2].prob_err=0; i++; Vertex u3; u3=add_vertex(g); g[u3].gate_type = "Input"; g[u3].gate_level=1; g[u3].gate_index=i; g[u3].num_input=0; g[u3].prob_err=0; i++; Vertex u4; u4=add_vertex(g); g[u4].gate_type = "XOR"; g[u4].gate_level=2; g[u4].gate_index=i; g[u4].num_input=0; g[u4].prob_err=0.001; i++; Vertex u5; u5=add_vertex(g); g[u5].gate_type = "AND"; g[u5].gate_level=1; g[u5].gate_index=i; g[u5].num_input=0; g[u5].prob_err=0.001; i++; Vertex u6; u6=add_vertex(g); g[u6].gate_type = "XOR"; g[u6].gate_level=1; g[u6].gate_index=i; g[u6].num_input=0; g[u6].prob_err=0.001; i++; Vertex u7; u7=add_vertex(g); g[u7].gate_type = "AND"; g[u7].gate_level=1; g[u7].gate_index=i; g[u7].num_input=0; g[u7].prob_err=0.001; i++; Vertex u8; u8=add_vertex(g); g[u8].gate_type = "OR"; g[u8].gate_level=1; g[u8].gate_index=i; g[u8].num_input=0; g[u8].prob_err=0.001; i++; Edge e1; e1=(add_edge(u1,u4,g)).first; Edge e2; e2=(add_edge(u1,u5,g)).first; Edge e3; e3=(add_edge(u2,u4,g)).first; Edge e4; e4=(add_edge(u2,u5,g)).first; Edge e5; e5=(add_edge(u3,u6,g)).first; Edge e6; e6=(add_edge(u3,u7,g)).first; Edge e7; e7=(add_edge(u4,u6,g)).first; Edge e8; e8=(add_edge(u4,u7,g)).first; Edge e9; e9=(add_edge(u5,u8,g)).first; Edge e10; e10=(add_edge(u7,u8,g)).first; const char* name[] = { "Input 1", "Input 2", "Input 3","XOR","AND","XOR","AND","OR"}; int index[] = {g[u1].gate_index,g[u2].gate_index,g[u3].gate_index,g[u4].gate_index,g[u5].gate_index,g[u6].gate_index,g[u7].gate_index,g[u8].gate_index}; write_graphviz(std::cout, g, boost::make_label_writer(name)); } I am able to write a label, but i can't write all the properties, and that's what i want. Thank you. Josep

2 2

[Math] Making math compile on C99 archs with no long double
by Seth LaForge 21 Apr '09

21 Apr '09

In trying to compile Boost 1.38.0 for arm/gcc-4.1.2, which has no long double support, I ran into the following compile error: ./boost/math/special_functions/expm1.hpp: In function ‘long double boost::math::expm1(long double, const boost::math::policies::policy<boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy>&)’: ./boost/math/special_functions/expm1.hpp:270: error: ‘::expm1l’ has not been declared The fix is simple - the expm1.hpp is trying to use a long double C99 function despite BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS being defined. The following patch (also attached in case gmail mangles it) fixes the problem: diff -r -u boost_1_38_0.orig/boost/math/special_functions/expm1.hpp boost_1_38_0/boost/math/special_functions/expm1.hpp --- boost_1_38_0.orig/boost/math/special_functions/expm1.hpp 2009-01-07 08:37:59.000000000 -0800 +++ boost_1_38_0/boost/math/special_functions/expm1.hpp 2009-04-20 18:24:33.312485307 -0700 @@ -267,10 +267,12 @@ #if defined(BOOST_HAS_EXPM1) && !(defined(__osf__) && defined(__DECCXX_VER)) # ifdef BOOST_MATH_USE_C99 inline float expm1(float x, const policies::policy<>&){ return ::expm1f(x); } +# ifndef BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS inline long double expm1(long double x, const policies::policy<>&){ return ::expm1l(x); } -#else +# endif +# else inline float expm1(float x, const policies::policy<>&){ return ::expm1(x); } -#endif +# endif inline double expm1(double x, const policies::policy<>&){ return ::expm1(x); } #endif

2 1

BoostCon lodging
by Sebastian Redl 20 Apr '09

20 Apr '09

Hi list, Two things. First, a comment at the BoostCon lodging page[1] gave me the impression that lodging for two isn't actually cheaper than for one. Is this correct? Second, is anyone interested in sharing a room at a place where this actually is cheaper? (And do you have recommendations for such a place?) I have to pay for lodging myself and would like to reduce the costs. Regards, Sebastian [1] http://www.boostcon.com/location/lodging#reservations

3 3

[smart_ptr] post 1.34 regression
by Gennadiy Rozental 20 Apr '09

20 Apr '09

Hi, Following snippet compiles fine with 1.34.1 -------------------------- #include "boost/shared_ptr.hpp" class Base { public: virtual ~Base() {} }; class Derived; boost::shared_ptr<Base> foo() { return boost::shared_ptr<Derived>(); } class Derived : public Base {}; -------------------------- It fails though with boost 1.36: a.cpp: In function `boost::shared_ptr<Base> foo()': a.cpp:13: error: conversion from `boost::shared_ptr<Derived>' to non-scalar type `boost::shared_ptr<Base>' requested Looks like it caused by additional argument in template constructor sp_enable_if_convertible. Is it intentional? Can we still support old use case? Gennadiy

2 1

[SCOPE_EXIT] compiler errors for structure members
by Sid Sacek 20 Apr '09

20 Apr '09

struct { int one; } test ; test.one = 55; BOOST_SCOPE_EXIT( ( test.one ) ) { } BOOST_SCOPE_EXIT_END The above code gives me lots of compiler errors. Is there a special syntax I have to provide to be able to use structure members? Thanks, -Sid Sacek The errors I get using MSVC 2008 are: error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2144: syntax error : 'int' should be preceded by ')' error C2059: syntax error : ')' error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2143: syntax error : missing ')' before 'constant' error C2039: 'type' : is not a member of '`global namespace'' error C2653: 'boost_se_wrapped_t_0_12' : is not a class or namespace name error C2143: syntax error : missing ';' before '{' error C2065: 'boost_se_param_t_0_12' : undeclared identifier error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2143: syntax error : missing ',' before 'constant' C2143: syntax error : missing ',' before ')' error C2653: 'boost_se_params_t_12' : is not a class or namespace name error C2143: syntax error : missing ';' before '{' error C2143: syntax error : missing ';' before '}' error C2143: syntax error : missing ';' before '}' error C2143: syntax error : missing ',' before ')'

2 6