> > > I suggest adding another boost defect: BOOST_BROKEN_ADL (or similar)
> >
> > How about BOOST_LIBRARY_IMPL_VULNERABLE_TO_ADL? It's not that the
> > compiler's ADL implementation is broken, it's that the library
> > implementation isn't protected against ADL lookups where it needs
> > to be.
>
David Abrahams wrote:
[...]
> Oh, I'm not up on the new interface. How are we going to create a
> new thread?
"KISS": new_thread factories. Please.
regards,
alexander.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boos
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> David Abrahams said:
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>>> David Abrahams said:
>> ...and if it can't be default-constructed?
>
> That's what boost::optional<> is for ;).
Yeeeh. Once the async_call returns, y
David Abrahams said:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>> The line in the middle won't work, actually, but that's another story.
>> boost::thread() creates a "handle" to the current thread. ;-) Score
>> another one for defining concepts before using them.
>
> Oh, I'm not up on the new in
"William E. Kempf" <[EMAIL PROTECTED]> writes:
>>> except that the async_call doesn't need to know about Executors.
>>
>> ...and that you don't need a special syntax to get the result out that
>> isn't compatible with functional programming. If you want to pass a
>> function object off from the a
"Peter Dimov" <[EMAIL PROTECTED]> writes:
>>> except that the async_call doesn't need to know about Executors.
>>
>> ...and that you don't need a special syntax to get the result out that
>> isn't compatible with functional programming. If you want to pass a
>> function object off from the above,
Alexander Terekhov <[EMAIL PROTECTED]> writes:
> But I >>still insist<< ( ;-) ) on a rather simple interface
> for creating a thread object (that shall kinda-"encapsulate"
> that "async_call"-thing "representing" the thread routine
> with its optional parameter(s) and return value... and which
David Abrahams said:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>>
With the above AsyncCall:
async_call f( bind(g, 1, 2) ); // can offer syntactic sugar
here thread t(f); // or thread(f); for extra cuten
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams said:
> ...and if it can't be default-constructed?
That's what boost::optional<> is for ;).
>>>
>>> Yeeeh. Once the async_call returns, you have a value, and should be
>>> able to count on it.
On Fri, 10 Jan 2003 11:22:23 +, Vincent Finn wrote:
>>>I have added 2 parsers to my code base and the compile time (VC6) has
>>>gone from 10 mins to 30mins :-(
>>At the very least, yes, you can separate the parsers from the project.
>>How about writing some wrappers that *hides* the grammars i
< repost [with repaired link] >
Peter Dimov wrote:
[...]
> > Another alternative might allow all of the following:
> >
> > async_call f(create_thread(), bind(g,1,2));
> > int r = f();
> >
> > async_call f(thread_pool(), bind(g,1,2));
> > int r = f();
>
> Using an undefined-yet Ex
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> Using an undefined-yet Executor concept for the first argument. This
>> is not much different from
>>
>> async_call f( bind(g, 1, 2) );
>> // execute f using whatever Executor is appropriate
>> int r = f.result();
>>
>> except t
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>
>>> With the above AsyncCall:
>>>
>>> async_call f( bind(g, 1, 2) ); // can offer syntactic sugar here
>>> thread t(f); // or thread(f); for extra cuteness
>>> int r = f.result();
>>>
On Sat, 8 Feb 2003 03:06:02 -0600, Aleksey Gurtovoy
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota wrote:
>> However, if we agree that when having autonomous next/prior we will
>> only use them to access next/prior< .. >::type and that the user
>> *must* specialize them for everything else
>
>Nope, we
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> With the above AsyncCall:
>>
>> async_call f( bind(g, 1, 2) ); // can offer syntactic sugar here
>> thread t(f); // or thread(f); for extra cuteness
>> int r = f.result();
>>
>> The alternative seems to be
>>
>> async_call f( bi
Guillaume Melquiond <[EMAIL PROTECTED]> writes:
> On Fri, 7 Feb 2003, Dave Gomboc wrote:
>
>> > I suggest adding another boost defect: BOOST_BROKEN_ADL (or similar)
>>
>> How about BOOST_LIBRARY_IMPL_VULNERABLE_TO_ADL? It's not that the
>> compiler's ADL implementation is broken, it's that the li
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
>> That's the general idea. Of course we can haggle over the syntactic
>> details, but the main question is whether you can get a return value
>> from invoking a thread function or whether you have to declare some
>> "global" sta
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>
>> [...]
>>
>>> Well, I don't really feel like arguing about this much longer.
>>
>> I'd love to contribute to this discussion but there's no firm ground
>> to stand on. What _are_ the concepts being
Amélie et François Dumont wrote:
> Just a little remark about the code that has nothing to do with the
> bug that has been elucidated by Graig Henderson. When Greg Dehaas
> wrote:
[...]
>> fncSelection = boost::bind(GenAlg::RouletteWheel> unsigned long>,_1);
>
> It seems to me that it would have be
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
> [...]
>
>> Well, I don't really feel like arguing about this much longer.
>
> I'd love to contribute to this discussion but there's no firm ground to
> stand on. What _are_ the concepts being discussed? I think I see
>
> AsyncCa
David Abrahams wrote:
[...]
> Well, I don't really feel like arguing about this much longer.
I'd love to contribute to this discussion but there's no firm ground to
stand on. What _are_ the concepts being discussed? I think I see
AsyncCall
AsyncCall(function f);
void operator()();
// eff
Thank. I must have a blind spot for the "is_scalar" line as I missed it
several times, thus I wasn't able to understand how pointers got
rejected from is_class (and I kept looking for is_pointer, etc. but it
was implicit). Sorry for the noise. One reason for my blind spot may be
that I used to thin
Hi Johan,
you wrote:
[snip]
> Let's look at just assembly for now. We start by creating an 1e5 x 1e5
> sparse matrix. We then successively insert 1e5 elements in the diagonal.
> What happens is that the insertion speed is linear for the first ~5
> elements, and then grinds to a halt. The in
On Fri, 7 Feb 2003, Dave Gomboc wrote:
> > I suggest adding another boost defect: BOOST_BROKEN_ADL (or similar)
>
> How about BOOST_LIBRARY_IMPL_VULNERABLE_TO_ADL? It's not that the
> compiler's ADL implementation is broken, it's that the library
> implementation isn't protected against ADL looku
Gennaro Prota wrote:
> On Thu, 6 Feb 2003 06:05:23 -0600, Aleksey Gurtovoy
> <[EMAIL PROTECTED]> wrote:
> > It has 'next'/'prior' members because it's the easiest/most
> > efficient way to implement 'next/prior< integral_c >::type'
> > functionality on compilers that don't support partial template
25 matches
Mail list logo
