Would this not break all code currently using the templated allocator version of boost::function? I would call that not at all appropriate for a dot release, and should be avoided outright if possible. On 11/1/07, Eric Niebler <eric@boost-consulting.com> wrote:

Emil Dotchevski wrote:

...

Any chance of incorporating

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2308.html

into boost::function for the 1.35.1 release? Here is a link to my implementation, including a SVN patch file:

http://www.revergestudios.com/boost-function/

I've tested with MSVC 8 and 9, and with gcc 3.4.4.

Funny, we haven't even released 1.35 yet, and you're already assuming we'll need a point release. ;-) It's too late to add new features for 1.35, and a point release is for bug fixes only, so I'd imagine the earliest somthing like this can go in would be 1.36.

-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Thu, 01 Nov 2007 22:38:00 +0100, Emil Dotchevski <emil@revergestudios.com> wrote:

...

Would this not break all code currently using the templated allocator version of boost::function? I would call that not at all appropriate for a dot release, and should be avoided outright if possible.

I apologize I meant 1.35 but now I see that it was naive to think it could happen that soon. My understanding is that Doug himself wanted the new allocator semantics for boost::function merged into Boost, but perhaps we should have a discussion first.

About breaking user code -- yes, it's a breaking change but I think that most people will not be affected, because using allocators with boost::function is not very practical with the legacy allocator semantics, and switching to the new allocator semantics is trivial.

It is also possible to introduce a macro that switches the legacy allocator semantics on (the allocator change affects only 2 hpp files.)

This sounds as a good news! So it will be possible for boost overload to pass a (shared) user-defined allocator to the embedded boost function objects. At present the only solution, to allow to specify an allocator type as template argument, would be to wrap all the supported signatures inside a tuple. This new semantic remove such a need, providing a transparent solution to the problem. :-) Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Douglas Gregor wrote:

On Thu, 2007-11-01 at 13:18 -0700, Eric Niebler wrote:

...

Emil Dotchevski wrote:

...

Any chance of incorporating

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2308.html

into boost::function for the 1.35.1 release? Here is a link to my implementation, including a SVN patch file:

http://www.revergestudios.com/boost-function/

I've tested with MSVC 8 and 9, and with gcc 3.4.4.

Funny, we haven't even released 1.35 yet, and you're already assuming we'll need a point release. ;-) It's too late to add new features for 1.35, and a point release is for bug fixes only, so I'd imagine the earliest somthing like this can go in would be 1.36.

Yes, especially since Function is depended upon by several other libraries. For 1.35, we'll put in a warning noting that the next version will have a source-incompatible change (the removal of the Allocator parameter) to bring it into line with C++0x semantics. We'll make the change in 1.36.

Good. Making source-incompatible changes for 1.35.0 isn't acceptable. --Beman