Hi again,
I am doing some helper class that will pad the space after a given type
until it reaches a machine word boundary. This word boundary would be the
maximum of (alignment_of::value - sizeof(char)) where T is any
'typename', 'typename' is one of {is_class::value == false} and U is any
t
> If you run bjam with "-d2" option, you'll see all the command lines, which
> should be enough to find out which libraries are beeing linked.
It appears that I don't really need -d2 to get a linker line. bjam prints ot
togerther with error anyway:
mwld -search -maxerrors 5 -maxwarnings 20 -expor
Hi,
I just wanted to know if shifted_ptr.zip is going to be revised for the
stable version of Boost. The sandbox looks like a big step ahead;
smart_ptr<>s are completely different ;) I am reworking offset.hpp right
now.
Thanks in advance,
Philippe A. Bouchard
"Lin Xu" <[EMAIL PROTECTED]> writes:
>>But you can't do that ;-)
>>
>>In particular, MemberFun is incompatible with, say,
>>MemberFun. You'd need something more like:
>>
>> MemberFun
>> MemberFun
>>
> Sorry, but why? The two functions have different signitures, a::print
> has a void (A::*)(),
But you can't do that ;-)
In particular, MemberFun is incompatible with, say,
MemberFun. You'd need something more like:
MemberFun
MemberFun
Sorry, but why? The two functions have different signitures, a::print has a
void (A::*)(), while setz has void (A::*)(int)..so they have different
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> I can. On the other hand, I can implement the thread primitives and
> optional, too. The point is that if, while building a high-level interface
> implementation, we discover an useful low-level primitive that offers
> greater expressive power (if less s
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> No, I was asking anyone interested in responding, and you're certainly
> not wasting your breath. I think I reached a compromise on these
> issues/questions, and would appreciate your response (it's in another
> post).
Done.
>> Allocation can be
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> From: David Abrahams <[EMAIL PROTECTED]>
>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> > It's a tool that allows high-level interfaces to be built. Whether
>> > people will want/need to build their own high-level interfaces is
>> > another stor
David B. Held wrote:
[...]
> You might have to pull some tricks with the Ownership policy, I'm not
> sure. For conversions, the pointer casts should work, unless you need
> to do some tricks.
>
> Dave
As for conversions, I think I will use counted_base, but it seems the new
version of shared_co
William E. Kempf wrote:
>
> It's not just the efficiencies that concern me with dynamic
> allocation. It's the additional points of failure that occur in this
> case as well. For instance, check out the article on embedded coding
> in the most recent CUJ (sorry, don't have the exact title handy).
William E. Kempf wrote:
>
> How about this compromise:
>
> template
> class async_call
> {
> public:
> template
> explicit async_call(const F& f)
> : m_func(f)
> {
> }
>
> void operator()()
> {
> mutex::scoped_lock lock(m_mutex);
> if (m_result)
>
Gustavo Guerra wrote:
> On the same spirit, I would like to request that boost::non_copyable
> be also moved to a separate header "boost/non_copyable.hpp" or
> "boost/utility/non_copyable", so we don't have to include the whole
> "boost/utility.hpp"
Uhmm, that's actually my fault. I proposed to s
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>>
Unspecified, but I don't think we can avoid that with the low-level
interface. High level wrappers that package creation and execution
would
> From: David Abrahams <[EMAIL PROTECTED]>
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
> >> > I lean towards simple undefined behavior. How do you feel about it?
>
> I have a feeling that I'm not being asked here, and maybe even that
> it's wasted breath because you've grown tired of my emph
> From: David Abrahams <[EMAIL PROTECTED]>
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
> > It's a tool that allows high-level interfaces to be built. Whether
> > people will want/need to build their own high-level interfaces is
> > another story.
>
> I think it's a valuable question to ask whethe
In theory we could even have writen:
fncSelection = GenAlg::RouletteWheel;
but it is the same problem with MSVC6 that with the & form. If anyone has a
little time I would be interesting in understanding why MSVC6 doesn't accept
that!
Thanks
-Original Message-
From: Greg Dehaas [mailto:
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> > Sort of... I was thinking about the refactoring where you don't hold
>> > the mutex the entire time the function is being called. But even
>> > with out the refactoring, there is some room for error:
>> >
>> > thread1: call()
>> > thread2: call(
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>
>>> Unspecified, but I don't think we can avoid that with the low-level
>>> interface. High level wrappers that package creation and execution
>>> would be immune to this problem.
>>
>
On Mon, 10 Feb 2003 17:55:56 -, "Gustavo Guerra" <[EMAIL PROTECTED]>
wrote:
>Gennaro Prota wrote:
>> Well, the title says it all :-) I would like to have a separate source
>> file for the ubiquitous BOOST_STATIC_CONSTANT. I have several files
>> that use BOOST_STATIC_CONSTANT but no real confi
Thanks again, Peter. That's about what I expected - a mutex around A::create
should do the trick.
Peter Krnjevic
Dynalink Technologies
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
000d01c2d138$2d29e7d0$1d00a8c0@pdimov2">news:000d01c2d138$2d29e7d0$1d00a8c0@pdimov2...
> dynalink wrote:
> > Wo
Alexander Terekhov wrote:
[...]
> bool acquire_strong_from_weak() {
> int status = pthread_refcount_enroll_one(&strong_count); //
[...]
> Or am I just missing and/or misunderstanding something?
You are missing the fact that nobody (even Google) has a clue as to what
pthread_refcount_enroll_o
On Mon, 10 Feb 2003 18:18:11 -, "Gustavo Guerra" <[EMAIL PROTECTED]>
wrote:
>Hi,
>I would like to propose the addition of a new config macro to Boost.Config:
>BOOST_USING_OLD_STYLE_IOSTREAMS
>
>A (possibly incomplete) implementation is:
>#if defined(__GNUC__) && (__GNUC__ < 3) && !defined(__ST
Pavel Vasiliev wrote:
>
> Alexander Terekhov wrote:
>
> [...]
> >> Pavel Vasiliev wrote:
> >> > The true locking/unlocking, not InterlockedIncrement/Decrement()
> >
>
> > Nah, pthread_refcount_t. ;-)
>
> >> > even if availabe,
I have followed this discussion with great interest.
I feel that the lack of an easy, 'library' 'standard' way of 'outputting' STL
objects is a major turnoff to their use. There is persistent re-invention of
wheels. Some users may have their own special ideas about format, but a default
would be
dynalink wrote:
> Works great! How thread safe is this?
Looks as thread safe as your version, where you could end up calling
m_X.reset(new X) simultaneosly if two threads created a B at the same time.
IOW, not much. :-)
All shared_ptr/weak_ptr operations have the same thread safety level, i.e.
mu
Gennaro Prota wrote:
> Well, the title says it all :-) I would like to have a separate source
> file for the ubiquitous BOOST_STATIC_CONSTANT. I have several files
> that use BOOST_STATIC_CONSTANT but no real config macro. For those
> ones, I currently have something like
>
> #include "boost/config
Hi,
I would like to propose the addition of a new config macro to Boost.Config:
BOOST_USING_OLD_STYLE_IOSTREAMS
A (possibly incomplete) implementation is:
#if defined(__GNUC__) && (__GNUC__ < 3) && !defined(__STL_USE_NEW_IOSTREAMS)
|| defined(_MSC_VER) && (_MSC_VER < 1300)
#define BOOST_USI
Works great! How thread safe is this?
Thanks,
Peter
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
001301c2d12c$30c1d210$1d00a8c0@pdimov2">news:001301c2d12c$30c1d210$1d00a8c0@pdimov2...
> dynalink wrote:
> > I need to create a single instance of X and have it disappear when
> > the
> > final
As I've asked in a recent post, I would like to have boost not using
non-standard features (e.g. long long), unless they are explicitly
requested by the user. The reason, besides general boost philosophy
considerations, is that, with some compilers, it is otherwise
impossible to compile code that i
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> Unspecified, but I don't think we can avoid that with the low-level
>> interface. High level wrappers that package creation and execution
>> would be immune to this problem.
>
> Is there really a need for a low-level async_call
>
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> Date: 2003/02/10 Mon PM 12:54:28 EST
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Subject: Re: Re: [boost] Re: A new boost::thread implementation?
>
> William E. Kempf wrote:
> >> From: "Peter Dimov" <[EMAIL PROTECTED]>
> // step 2: exec
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> Unspecified, but I don't think we can avoid that with the low-level
> interface. High level wrappers that package creation and execution would be
> immune to this problem.
Is there really a need for a low-level async_call interface? After
all, the exis
William E. Kempf wrote:
>> From: "Peter Dimov" <[EMAIL PROTECTED]>
// step 2: execute an async_call
call();
>>>
>>> This example, and the implementation above, are just complex
>>> synchronous calls. I assume you really meant for either the
>>> constructor or this call to also ta
dynalink wrote:
> I need to create a single instance of X and have it disappear when
> the
> final B pointer goes out of scope. The problem with this code is that
> A::m_X immediately bumps the ref count and only goes out of scope on
> termination.
>
> Here's a simple example:
>
> class X;
Toon Knapen wrote:
On Saturday 08 February 2003 00:26, Rene Rivera wrote:
If the old run is no longer relevent (as run date October 17 suggests)
who would be responsible for removing it?
I would think the person who ran the test, or Beman, or David, or any admin,
etc.
These are results from
I need to create a single instance of X and have it disappear when the
final B pointer goes out of scope. The problem with this code is that A::m_X
immediately bumps the ref count and only goes out of scope on termination.
Here's a simple example:
class X;// defined elsewhere; in my case wra
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> >> // step 2: execute an async_call
> >> call();
> >
> > This example, and the implementation above, are just complex
> > synchronous calls. I assume you really meant for either the
> > constructor or this call to also take an Executor concept?
>
Well, the title says it all :-) I would like to have a separate source
file for the ubiquitous BOOST_STATIC_CONSTANT. I have several files
that use BOOST_STATIC_CONSTANT but no real config macro. For those
ones, I currently have something like
#include "boost/config.hpp" // for BOOST_STATIC_CONSTA
Pavel Vasiliev wrote:
> May be the following code answers the challenge? :-).
Interesting...
[...]
> void weak_ref_control_block::release_strong()
> {
> if(atomic_decrement(&strong_count) == 0)
> strong_refs_lost();
> }
> bool weak_ref_control_block::acquire_strong_from_weak()
> {
>
dynalink wrote:
> Forgive me if this seems like a really basic question, but how does
> one create a shared_ptr with an initial use count of zero?
There is no way to create a shared_ptr with use_count of zero. Use_count()
returns the number of shared_ptr instances sharing ownership. Use_count() ==
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> From: David Abrahams <[EMAIL PROTECTED]> Date: 2003/02/10
>> Mon AM 11:15:31 EST To: Boost mailing list <[EMAIL PROTECTED]>
>> Subject: Re: [boost] Re: A new boost::thread implementation?
>>
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>
>
> From: David Abrahams <[EMAIL PROTECTED]>
> Date: 2003/02/10 Mon AM 11:15:31 EST
> To: Boost mailing list <[EMAIL PROTECTED]>
> Subject: Re: [boost] Re: A new boost::thread implementation?
>
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
> > Actually, there's another minor issue as well.
Vladimir Prus wrote:
> >>I'm pulling at stings, but there has to be good stuff to add if we come up
> >
> > with
> >
> >>the right aspect to develop. I have never heard of a library designed for
> >>evaluation of debug-time expressions... It would be interesting to see
> >
> > how
> >
> >>powe
William E. Kempf wrote:
>> Here's some compilable code, to put things in perspective:
>
> Thanks. This helps me, at least.
>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> template class async_call
>> {
>> public:
>>
>> template explicit async_call(F f): f_
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> Actually, there's another minor issue as well. The user can call
> operator() and then let the async_call go out of scope with out ever
> calling result(). Mayhem would ensue. The two options for dealing
> with this are to either block in the des
Forgive me if this seems like a really basic question, but how does one
create a shared_ptr with an initial use count of zero?
Thanks,
Peter
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> Date: 2003/02/10 Mon AM 09:08:08 EST
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Subject: Re: [boost] Re: A new boost::thread implementation?
>
> David Abrahams wrote:
> > "Peter Dimov" <[EMAIL PROTECTED]> writes:
> >
> >> I am not saying that t
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>
>>> We have three concepts: Runnable, Executor (executes Runnables), and
>>> HasResult (for lack of a better name.) The AsyncCall concept I had
>>> in mind is both Runnable and HasResu
Alexander Terekhov wrote:
[...]
>> Pavel Vasiliev wrote:
>> > The true locking/unlocking, not InterlockedIncrement/Decrement()
>
> Nah, pthread_refcount_t. ;-)
>> > even if availabe, is necessary to support weak references.
>>
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> We have three concepts: Runnable, Executor (executes Runnables), and
>> HasResult (for lack of a better name.) The AsyncCall concept I had
>> in mind is both Runnable and HasResult, so it can't use operator()
>> for both. x.resu
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>
>>> I am not saying that this is never useful, but syntax should target
>>> the typical scenario, not corner cases.
>>
>> Agreed. I suppose that you'll say it doesn't target the typic
Terje Slettebø wrote:
From: "Jason House" <[EMAIL PROTECTED]>
Terje Slettebø wrote:
Regarding this project. I've got doubts about the viability of it.
Well, I'm glad you've given it a greater level of thought. I really like
the idea
of the composite_format, and probably should try to
On Sunday 09 February 2003 08:46 pm, Davlet Panech wrote:
> Hello,
>
> I just compiled build 1.29 with MS Visual C++ 6, and one of the libraries,
> boost_signals.dll does not export any symbols (and, as a consequence, no
> corresponding .LIB file is generated). Is that normal? A library with no
> s
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> I am not saying that this is never useful, but syntax should target
>> the typical scenario, not corner cases.
>
> Agreed. I suppose that you'll say it doesn't target the typical
> scenario because of its confusability. I woul
On Saturday 08 February 2003 00:26, Rene Rivera wrote:
> >If the old run is no longer relevent (as run date October 17 suggests)
> >who would be responsible for removing it?
>
> I would think the person who ran the test, or Beman, or David, or any admin,
> etc.
These are results from compilations
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>>> David Abrahams said:
No, my fault. Syntactically, I should've written this:
async_call f(create_thread(), bind(g,1,2));
int r = f();
>>>
>>> Do yo
David Abrahams wrote:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams said:
>>> No, my fault. Syntactically, I should've written this:
>>>
>>> async_call f(create_thread(), bind(g,1,2));
>>> int r = f();
>>
>> Do you want it to be "int r = f();" or just "int r = f;" or
ehab samir aziz <[EMAIL PROTECTED]> writes:
> I am running C++ ver 3 . How can I know exactly the
> libraries linked ?
You can examine the command lines generated by bjam when it builds
your project.
> Is a bjam -d2 command that when I issue I discover
> libraries linked ?
Yes, bjam -d2 will ca
I am running C++ ver 3 . How can I know exactly the
libraries linked ?
Is a bjam -d2 command that when I issue I discover
libraries linked ?
--- Vladimir Prus <[EMAIL PROTECTED]> wrote:
> Gennadiy Rozental wrote:
> >>It looks to me like the C library is not getting
> linked into the
> >>executable
Gennadiy Rozental wrote:
It looks to me like the C library is not getting linked into the
executable. There are several possible versions of the C library which
might meet the need (some of them listed in the error messages).
Can you list the libraries that are being linked in? From that I c
60 matches
Mail list logo
