Ross Smith <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Neal D. Becker" <[EMAIL PROTECTED]> writes:
>>>
>>> You mean I can't just run bjam with no options and get the libs
>>> built with thread support? I need to add a command-line option?
>> The libraries that require thread support w
Peter Dimov wrote:
[snip]
>> I see your point but what is the alternative? Forcing people to
>> replace global new/delete?
>
> In a word, yes. Although replacing global new/delete is forced by the
> system allocator being not up to the task and not by us.
>
> I understand that for some applications
David Abrahams wrote:
"Neal D. Becker" <[EMAIL PROTECTED]> writes:
You mean I can't just run bjam with no options and get the libs built with
thread support? I need to add a command-line option?
The libraries that require thread support will be built with thread
support. The others will not, unl
> From: David Abrahams [mailto:[EMAIL PROTECTED]
> Subject: [boost] Re: [uBlas] Any Performance Resulst Data with uBlas?
>
>
> "Patrick Kowalzick" <[EMAIL PROTECTED]> writes:
>
> > Hi Matthew,
> >
> > I like these statistics. Nice graphs.
> >
> > Did you test the block_prod compared to normal
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
> E. Gladyshev wrote:
> > --- Peter Dimov <[EMAIL PROTECTED]> wrote:
> >
> >> unless there are very solid reasons for the allocator parameter. ;-)
> >
> > I agree, but the problme is that I don't know whether I have a solid
> reason or not.
> > I have to
E. Gladyshev wrote:
> --- Peter Dimov <[EMAIL PROTECTED]> wrote:
>
>> unless there are very solid reasons for the allocator parameter. ;-)
>
> I agree, but the problme is that I don't know whether I have a solid
reason or not.
> I have to ship my class to someone else. She might have a solid reason
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 10:08 PM 8/25/2003, David Abrahams wrote:
> >David Abrahams <[EMAIL PROTECTED]> writes:
> >
> >> > What about:
> >> >
> >> > assert( p.branch_path().empty() );
> >> >
> >> > Isn't that closer to what you are trying to express?
> >>
> >> I
Jan,
That was my problem - thank you.
Chris.
- Original Message -
From: "Jan Langer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 26, 2003 11:29 AM
Subject: [boost] Re: Spirit question...
> Chris Cooney wrote:
> > I've been utilizing some of the other boost projec
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
[...]
> template struct X
> {
> typedef typename A::value_type T;
>
> static T * create(A & a)
> {
> T * p = a.allocate(1);
>
> try
> {
> new(p) T;
> }
> catch(...)
> {
>
Thomas Witt <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
>> Thomas Witt <[EMAIL PROTECTED]> writes:
>>>
>>>- - A full boost-conformant implementation is available in the sandbox
>> Or in Boost CVS, I hope... since if it's already in use it may
>> already be there.
>
> I assume that in gen
"Edward Diener" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
...
> But even for a POD type such as this, copying would lead to
> errors if the char * data were dynamically allocated since a double delete
> would probably be done.
>
Containers aware of memcpy_moveable can detect this
At 10:08 PM 8/25/2003, David Abrahams wrote:
>David Abrahams <[EMAIL PROTECTED]> writes:
>
>> > What about:
>> >
>> > assert( p.branch_path().empty() );
>> >
>> > Isn't that closer to what you are trying to express?
>>
>> I guess so. I didn't see branch_path().
>
>BTW, it would feel much more
At 09:48 PM 8/25/2003, David Abrahams wrote:
>"Rainer Deyke" <[EMAIL PROTECTED]> writes:
>
>> It is my understanding that paths are implemented as
>> std::vector or something similar, where the individual
>> strings can contain slashes if the underlying filesystem allows it.
>> It would be a shame
"Edward Diener" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
...
> But even for a POD type such as this, copying would lead to
> errors if the char * data were dynamically allocated since a double delete
> would probably be done.
>
Containers aware of memcpy_moveable can detect this
Peter Dimov wrote:
> Andreas Huber wrote:
>> Peter Dimov wrote:
>>> The usual approach is to borrow an entry from the 2*N heap and split
>>> it in two when the N heap is empty. [snip]
>>
>> Which brings back non-determinism, as the 2*N heap could be full also
>> and thus be borrowing from 4*N alrea
Andreas Huber wrote:
> [snip]
>>> However, for a certain class of systems one almost never can avoid
>>> customization, no matter how ingenious the platform is.
>>
>> This may well be true, but I'm not convinced that platform-specific
>> customizations (an implementation detail) absolutely need to
Chris Cooney wrote:
I've been utilizing some of the other boost projects for awhile now but
am new to the spirit framework and may ask some dumb questions...so,
sorry in advance.
i tried it today for the first time. and i think its really nice.
I'm wondering why the var_delm rule won't work when p
"John Maddock" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> He needs to take a look at the has_trivial_* traits:
>
> has_trivial_assign is roughly equivalent to memcpy_copyable
>
> I guess there is no equivalent to memcpy_moveable: but it looks rather
> dangerous,
>
It looks dange
Hello,
I've been utilizing some of the other boost
projects for awhile now but
am new to the spirit framework and may ask some
dumb questions...so,
sorry in advance.
I'm wondering why the var_delm rule won't work
when parsed:
rule<> var_delm = +anychar_p;
rule<> var_type = str_p("some_l
Douglas Gregor wrote:
>
> There's no reason shared_ptr couldn't support a constructor that
> takes an allocator as an argument.
"Minimal but complete". You can already achieve this functionality with the
current interface.
___
Unsubscribe & other change
Andreas Huber wrote:
> Peter Dimov wrote:
>> The usual approach is to borrow an entry from the 2*N heap and split
>> it in two when the N heap is empty. [snip]
>
> Which brings back non-determinism, as the 2*N heap could be full also
> and thus be borrowing from 4*N already. You can of course guara
[snip]
>> However, for a certain class of systems one almost never can avoid
>> customization, no matter how ingenious the platform is.
>
> This may well be true, but I'm not convinced that platform-specific
> customizations (an implementation detail) absolutely need to be
> supported by a portable
E. Gladyshev wrote:
> I am using STL and trying to use boost in my daily
> development. What can I do to implement consistent classes in terms
> of memory management. For example, if I need to implement a class A
> that has a container and pointer to a data type. I have two options:
>
> template<
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> E. Gladyshev wrote:
>> --- Gregory Colvin <[EMAIL PROTECTED]> wrote:
>>> For shared_ptr the count is allocated by the following line in the
>>> shared_count
>>> constructor:
>>>
>>> new sp_counted_base_impl(p, d);
>>>
>>> So it might be possible to m
Peter Dimov wrote:
> Andreas Huber wrote:
>> [snip]
>>> So far my experience indicates that people only bother with
>>> allocators when std::allocator is inadequate, i.e. slow.
>>
>> ... or non-deterministic. Using such an allocator in a hard real-time
>> system is simply not an option.
>> AFAIK, a
On Tuesday, Aug 26, 2003, at 10:41 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
For shared_ptr the count is allocated by the following line in the
shared_count
constructor:
new sp_counted_base_impl(p, d);
So it might be possible to make the allocation custo
David Abrahams wrote:
Thomas Witt <[EMAIL PROTECTED]> writes:
- - A full boost-conformant implementation is available in the sandbox
Or in Boost CVS, I hope... since if it's already in use it may
already be there.
I assume that in general the new component would have a new place and
add some tw
On Tuesday 26 August 2003 01:23 pm, Peter Dimov wrote:
> Leaving aside the issue of whether specializing std::allocator is
> a good idea:
>
> shared_ptr< MyClass, MyAllocator > s;
>
> note that you now wouldn't be able to pass s to a function that expects
> shared_ptr since the type is not the same
E. Gladyshev wrote:
> --- Gregory Colvin <[EMAIL PROTECTED]> wrote:
>> For shared_ptr the count is allocated by the following line in the
>> shared_count
>> constructor:
>>
>> new sp_counted_base_impl(p, d);
>>
>> So it might be possible to make the allocation customizable by
>> specializing
>>
Thomas Witt <[EMAIL PROTECTED]> writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Jaako,
>
> Jaakko Jarvi wrote:
>
> | Hi Boosters,
> |
> | We submitted enable_if for formal review in July. The library does not
> | seem to be on the review queue,
>
> It is in fact in the queue, only
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>>> I guess there is no equivalent to memcpy_moveable: but it looks
>>> rather dangerous, what state is the original object left in
>>> afterwards etc?
>>
>> None. There is no original object after the move, only raw storage.
>
> .
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
> For shared_ptr the count is allocated by the following line in the
> shared_count
> constructor:
>
> new sp_counted_base_impl(p, d);
>
> So it might be possible to make the allocation customizable by
> specializing
> sp_counted_base_impl.
I t
"Patrick Kowalzick" <[EMAIL PROTECTED]> writes:
> Hi Matthew,
>
> I like these statistics. Nice graphs.
>
> Did you test the block_prod compared to normal prod as well ? This would be
> interessting compared to ATLAS as well.
It's very hard to read, IMO. It's not clear what the lines are
referri
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
> E. Gladyshev wrote:
> >
> > I guess my question is that, is boost redefining the
> > memory management concepts that have been established by STL?
>
> Yes and no. The STL uses allocators for containers. Most non-containers do
> not have an allocator pa
"Neal D. Becker" <[EMAIL PROTECTED]> writes:
> On Saturday 23 August 2003 07:18 am, John Maddock wrote:
>> > One more thing: what exactly can go wrong with 1.30.0 if
>> > -pthread isn't used? Is it boost specific or a general thing
>> > (e.g. issues w/ respect to libstdc++)?
>>
>> A general thing
"Peter Dimov" <[EMAIL PROTECTED]> writes:
>> I guess there is no equivalent to memcpy_moveable: but it looks rather
>> dangerous, what state is the original object left in afterwards etc?
>
> None. There is no original object after the move, only raw storage.
...which is a different meaning from
For shared_ptr the count is allocated by the following line in the
shared_count
constructor:
new sp_counted_base_impl(p, d);
So it might be possible to make the allocation customizable by
specializing
sp_counted_base_impl.
___
Unsubscribe & other
Mat Marcus wrote:
It is not uncommon to use boost::function to hold on to the result of
boost::bind. Will that work for you?
Wrote it, compiled it and it worked immediately. Thanks very much! :)
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-St
On Mon, 25 Aug 2003 14:31:07 +1000, Chris Trengove
<[EMAIL PROTECTED]> wrote:
At the moment, Boost.Regex has an incompatibility with the VCL headers
when
compiling with Borland C++ 5.5. Simply having
#include
#include
generates a large number of errors of the type.
[C++ Error] cregex.hpp(91)
It is not uncommon to use boost::function to hold on to the result of
boost::bind. Will that work for you?
- Mat
--On Tuesday, August 26, 2003 4:17 PM +0200 Daniel Frey
<[EMAIL PROTECTED]> wrote:
In my current project, there are a lot of code fragments that read
like this:
result->insert( "pos
Hi Matthew,
I like these statistics. Nice graphs.
Did you test the block_prod compared to normal prod as well ? This would be
interessting compared to ATLAS as well.
Regards,
Patrick
"Hurd, Matthew" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > From: Firingme [mailto:[EMAIL PR
In my current project, there are a lot of code fragments that read like
this:
result->insert( "positions",
positions_.begin(),
positions_.end(),
bind( &Position::serialize,
_1,
boost::cref( locale ) ) );
T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jaako,
Jaakko Jarvi wrote:
| Hi Boosters,
|
| We submitted enable_if for formal review in July. The library does not
| seem to be on the review queue,
It is in fact in the queue, only that the queue is only current in CVS.
| and maybe it is not worth
On Sat, 23 Aug 2003, John Maddock wrote:
>
> > One more thing: what exactly can go wrong with 1.30.0 if
> > -pthread isn't used? Is it boost specific or a general thing
> > (e.g. issues w/ respect to libstdc++)?
>
> A general thing - without this then:
>
> Your std lib is not thread safe.
> Your
Andreas Huber wrote:
>
> I know, I just mentioned this because Peter seems to suggest that the
> need for memory management customization is rare if the compiler
> folks did their job right.
But it is. Compiler folks not doing their job is the primary motivation for
custom memory management. The C
We do a regular merge of branch changes into HEAD in our
source at work.
So far I've had a sum-total of 1 conflict...
Things to remember when merging:
* where possible ignore whitespace
* suppress keyword expansion
* keep your sync tags well documented
I based our process at work on the fo
Dear all,
attached is a patch to integer_traits.hpp, enabling it to be compiled under
NetBSD.
Kind regards,
Angus
Index: boost/integer_traits.hpp
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/boost/integer_traits.hpp,v
retrie
On Saturday 23 August 2003 07:18 am, John Maddock wrote:
> > One more thing: what exactly can go wrong with 1.30.0 if
> > -pthread isn't used? Is it boost specific or a general thing
> > (e.g. issues w/ respect to libstdc++)?
>
> A general thing - without this then:
>
> Your std lib is not thread
Andreas Huber wrote:
> [snip]
>> So far my experience indicates that people only bother with
>> allocators when std::allocator is inadequate, i.e. slow.
>
> ... or non-deterministic. Using such an allocator in a hard real-time
> system is simply not an option.
> AFAIK, a deterministic allocator mus
E. Gladyshev wrote:
>
> I guess my question is that, is boost redefining the
> memory management concepts that have been established by STL?
Yes and no. The STL uses allocators for containers. Most non-containers do
not have an allocator parameter, although many standard classes do allocate
memory
John Maddock wrote:
>>> Thats my point - you may flag some types as safely moveable and then
>>> use
>>> this knowledge in algorithms. User has the responsibility to do the
>>> decision.
>>
>> Extremely dangerous and error prone. I can't even imagine a non-POD
>> type where flagging it for memcpy_
Pavel Vozenilek wrote:
> "Edward Diener" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Extremely dangerous and error prone. I can't even imagine a non-POD
>> type where flagging it for memcpy_copyable and memcpy_moveable can
>> be right.
> Can
>> you give an example ?
>>
> It is
> At the moment, Boost.Regex has an incompatibility with the VCL headers
when
> compiling with Borland C++ 5.5. Simply having
>
> #include
> #include
>
> generates a large number of errors of the type.
>
> [C++ Error] cregex.hpp(91): E2015 Ambiguity between '_fastcall operator
> |(int,const Varia
> Compilation of Boost.Regex using Borland C++ 5.5 currently gives a bunch
of
> "previous options and warnings not restored" messages. The culprit is
> boost/regex/config/cstring.hpp where the lines
Fixes are in cvs now.
Thanks for reporting this.
John.
> see boost::is_POD.
And has_trivial_copy has_trivial_assign has_trivial_destruct etc
John.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>>
> > Thats my point - you may flag some types as safely moveable and then
> > use
> > this knowledge in algorithms. User has the responsibility to do the
> > decision.
>
> Extremely dangerous and error prone. I can't even imagine a non-POD type
> where flagging it for memcpy_copyable and memcpy_m
> From: Firingme [mailto:[EMAIL PROTECTED]
> I'm a newbie to uBlas , but have used MTL for a long time.
> Before I learned MTL, I've founded MTL's performance result
> graph data on the following URL:
>
> http://www.osl.iu.edu/research/mtl/performance.php3
>
> Now, is there any performance re
"Edward Diener" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Extremely dangerous and error prone. I can't even imagine a non-POD type
> where flagging it for memcpy_copyable and memcpy_moveable can be right.
Can
> you give an example ?
>
It is error prone but many other constructs
I'm a newbie to uBlas , but have used MTL for a long time.
Before I learned MTL, I've founded MTL's performance result graph data
on the following URL:
http://www.osl.iu.edu/research/mtl/performance.php3
Now, is there any performance result data about uBlas ?
__
David Abrahams <[EMAIL PROTECTED]> writes:
> > What about:
> >
> > assert( p.branch_path().empty() );
> >
> > Isn't that closer to what you are trying to express?
>
> I guess so. I didn't see branch_path().
BTW, it would feel much more natural to me if it were
path root() const;
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 03:55 PM 8/21/2003, David Abrahams wrote:
>
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> At 08:31 PM 8/19/2003, David Abrahams wrote:
> >> >
> >> >It surprised me a bit that leaf returns a string instead of a path.
> >>
> >> The rule isn
"Rainer Deyke" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Rainer Deyke" <[EMAIL PROTECTED]> writes:
>>
>>> David Abrahams wrote:
A single component of a path is still a path, and it
shouldn't devolve into a string.
>>>
>>> I disagree. While a path with just one component ca
Pavel Vozenilek wrote:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> ...
>>
>> I don't believe you can use memcpy to move any non-POD types
>> portably,
>> i.e. without special knowledge of the compiler.
>>
> Thats my point - you may flag some types as safely mo
At 03:55 PM 8/21/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> At 08:31 PM 8/19/2003, David Abrahams wrote:
>> >
>> >It surprised me a bit that leaf returns a string instead of a path.
>>
>> The rule isn't entirely obvious. If a decomposition function can
>> possibly
64 matches
Mail list logo
