Maxim Egorushkin wrote:
> I think it would be great to make boost::any's memory allocation
> strategy for value holder customizable. It would allow to use not only
> global new operator, but any other special fast allocators like, for
> example, Loki::SmallObject.
I can add it to dynamic_any. All
Hi Maxim,
> I think it would be great to make boost::any's memory allocation
> strategy for value holder customizable. It would allow to use not only
> global new operator, but any other special fast allocators like, for
> example, Loki::SmallObject.
>
> The changes are minor and would not break ex
Firstly my thanks to everyone who worked so hard on boost 1_30_0.
Particularly all the that regression testing that went on.
On to the next release... One quick fix for the documentation for
"Variant descriptions" used in the build system
The syntax for defining parents (see features.jam) is mi
Does anybody know if regex++ has support for lookbehind assertions, or if
there is a way of achieving the same result with other expressions.
Example lookbehind assertion:
(?http://lists.boost.org/mailman/listinfo.cgi/boost
> > Since you advocate elsewhere that exception classes be derived
> > from std::exception, the answer is because otherwise LSP would
> > be violated.
>
> You can't access the derived class' assignment operator through a
> pointer/reference to a polymorphic base, so that point is moot.
Well, you'
[The attachment got messed up in the last post. Hopefully, it will be OK
this time]
This is my final repost of my Lock Classes. If I do not get any
constructive feedback this time I am going to give up.
These classes have the following features:
1) The ability to acquire a lock and release
This is my final repost of my Lock Classes. If I do not get any
constructive feedback this time I am going to give up.
These classes have the following features:
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implementing the "Monitor" conce
I'm very interested in having tree container concepts in Boost.
The tree_node_map class provides an implementation to a basic tree node
of variable branching size. The implementation here uses the std::map to
implement the children, but this could equally be a std::list,
std::vector or any sui
David Abrahams <[EMAIL PROTECTED]> writes:
> And set equality can be tested in O(N) by iterating the first sequence
> of nodes and asking whether each one's ::type is a member of the
> other one.
Of course, that only tests for a subset relation. You need to do
that twice to test a <= b and b <=
"Lapshin, Kirill" <[EMAIL PROTECTED]> writes:
> Hi All,
>
>
>
> I posted this question on boost.users list but did not get any response.
>
> My first attempt to switch my project from boost 1.29 to 1.30 failed
> miserably due to compilation errors in random library.
>
>
>
> Simple
>
>
>
> #i
David Abrahams <[EMAIL PROTECTED]> writes:
> signifies that the tag acts differently, but rc1, rc2 et al are part
> of the version number. The only reason to use the underscores at all
> is that version numbers will eventually become ambiguous otherwise.
I'm even inclined to do as other projects
"Jaap Suter" <[EMAIL PROTECTED]> writes:
> One could implement a set that does not 'duplicate' values, but the
> following is harder because insertion order matters:
>
> typedef mpl::set< float, int, bool > set_0;
> typedef mpl::set< bool, int, float, > set_1;
>
> mpl::is_equal< set_0,
>> I've done it somewhat differently in the new code.
>
> Eh, whoops; your template invokes num_bits_set_impl, which isn't
> defined. Also, next is spelled "netxt". I also think you may have a
> problem with eager evaluation or one too many ::type s. I think you
> should test these.
Woops. I ju
> A. int_c et al are now int_ et al.
>From previous post:
"The quality of the Effective MPL (especially after the new MPL changes) is
not very good anyway. I would like to make a major overhaul, testing all
code examples, changing the code layout (moving it to docbook perhaps), and
making it 1.30
Daniel Frey <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> Daniel Frey <[EMAIL PROTECTED]> writes:
>>
>>>Sounds reasonable. Which makes me wonder if we shouldn't change the
>>>naming of branches a bit:
>>>
>>>We should have a branch for the development of new versions (1.30.x),
>>>let's c
David Abrahams wrote:
Daniel Frey <[EMAIL PROTECTED]> writes:
Sounds reasonable. Which makes me wonder if we shouldn't change the
naming of branches a bit:
We should have a branch for the development of new versions (1.30.x),
let's call it DEVELOP_1_30_x. On this branch, we can now add several
tag
Daniel Frey <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
>> I can do that. Should we start a new branch for things that would go
>> into a hypothetical 1.30.1? My feeling is that we should just keep
>> using the RC_1_30_0 branch, since it's already been tagged where the
>> release was m
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Sun, 23 Mar 2003 17:17:03 +0100, Gennaro Prota
> <[EMAIL PROTECTED]> wrote:
>
>>the standard defines 'stack unwinding' as (15.2/3)
>>
>> The process of calling destructors for automatic objects
>> constructed on the path from a try block to a thro
"Thorsten Ottosen" <[EMAIL PROTECTED]> writes:
>> > random and intels compiler v7 does not work together. Does anyone know
> what
>> > it would take
>> > to make it work?
>>
>> An active maintainer for the Boost.Random library ;-)
>
> I was more thinking about what compiler features that are
> pro
A. int_c et al are now int_ et al.
B. In item 5.3 you should probably suggest:
template< class N >
struct square
: integral_c< typename N::value_type, N::value * N::value >
{};
and later,
template
struct square_c : square > {};
Not only is it sim
"Jaap Suter" <[EMAIL PROTECTED]> writes:
>> Jaap, I was just looking over the EMPL Wiki page (which continues to
>> be a great thing), and noticed that item 5.2 is not really a good
>> example of MPL style.
>
> The original intention was to focus on the default-template-parameter
> technique, and
> Jaap, I was just looking over the EMPL Wiki page (which continues to
> be a great thing), and noticed that item 5.2 is not really a good
> example of MPL style.
The original intention was to focus on the default-template-parameter
technique, and keep the rest simple. The 'operate-on-types-only'
Title: Сообщение
I think it would be great to make boost::any's
memory allocation strategy for value holder customizable. It would allow to use
not only global new operator, but any other special fast allocators like, for
example, Loki::SmallObject.
The changes are minor and would not break
> > random and intels compiler v7 does not work together. Does anyone know
what
> > it would take
> > to make it work?
>
> An active maintainer for the Boost.Random library ;-)
I was more thinking about what compiler features that are prohibiting the
intel compiler from working with the
library. S
On Sun, 23 Mar 2003 17:17:03 +0100, Gennaro Prota
<[EMAIL PROTECTED]> wrote:
>the standard defines 'stack unwinding' as (15.2/3)
>
> The process of calling destructors for automatic objects
> constructed on the path from a try block to a throw-expression
>
>Does this include the 'argument' of
"Thorsten Ottosen" <[EMAIL PROTECTED]> writes:
> Hi,
>
> random and intels compiler v7 does not work together. Does anyone know what
> it would take
> to make it work?
An active maintainer for the Boost.Random library ;-)
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_
On Sun, 23 Mar 2003 08:11:02 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes:
>> - "Don't embed a std::string object or any other data member or base
>> class whose copy constructor could throw an exception. That could lead
>> to termination during stack
Hi,
random and intels compiler v7 does not work together. Does anyone know what
it would take
to make it work?
regards
-Thorsten
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I don't know if anyone else noticed, but the performance, UI, and
reliability of the ASPN archives seems to have undergone a radical
improvement recently. It still mis-threads some messages, but
otherwise it feels entirely usable. Gracious thanks to everyone at
ActiveState for this overhaul!
I
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Sat, 22 Mar 2003 09:38:49 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>David Abrahams <[EMAIL PROTECTED]> writes:
>>
>>> Damn, maybe I need to update more/error_handling.html
>>
>>Done.
>
> Just some notes:
>
> - "Don't embed a std::string
Dave Gomboc <[EMAIL PROTECTED]> writes:
Yes. Since type_info objects can't be copied, one might instead store
pointers or references to them.
>>>
>>> Pointers would be better because, for better or for worse (mostly for
>>> worse), standard exceptions support assignment as part of their
>
"Jaap Suter" <[EMAIL PROTECTED]> writes:
>> It could be an instantiation depth issue. Maybe the OP's code needs
>> more of our loop unrolling technique to avoid deep instantiations. I
>> think that can be controlled by #defining BOOST_MPL_UNROLLING_LIMIT
>> to some number greater than 4 before m
On Sat, 22 Mar 2003 09:38:49 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>David Abrahams <[EMAIL PROTECTED]> writes:
>
>> Damn, maybe I need to update more/error_handling.html
>
>Done.
Just some notes:
- "Don't embed a std::string object or any other data member or base
class whose copy co
On Sat, 22 Mar 2003 20:11:23 +, Kevlin Henney
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Terje Slettebø
><[EMAIL PROTECTED]> writes
>>
>>Regarding the other MSVC 6 warning given in the original report, Gennaro
>>Prota has suggested using an explicit "!=", rather than relying o
>>>Yes. Since type_info objects can't be copied, one might instead store
>>>pointers or references to them.
>>
>> Pointers would be better because, for better or for worse (mostly for
>> worse), standard exceptions support assignment as part of their
>> interface.
>
>Why should boost exception cla
> It could be an instantiation depth issue. Maybe the OP's code needs
> more of our loop unrolling technique to avoid deep instantiations. I
> think that can be controlled by #defining BOOST_MPL_UNROLLING_LIMIT
> to some number greater than 4 before mpl files are #included.
Thanks, I already man
36 matches
Mail list logo
