Re: Updated version of futures library

On Saturday 31 May 2008 17:14, Hartmut Kaiser wrote:
> > On Saturday 31 May 2008 14:30, Hartmut Kaiser wrote:
> > > > I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>&
> > > > rhs) would return a new future which is equal to true, iff
> > > > lhs.get()==true and rhs.get()==true. If either one returned false
> >
> > it
> >
> > > > would be false and otherwise the composed future would not be
> > > > ready yet.
> > >
> > > Doing it the way you're proposing implies shortcutting operator&&(),
> > > which can't be implemented.
> >
> > left-to right evaluation can't be short-circuited, but he's talking
>
> Right, that's exactly my point.
>
> > about short circuiting in time, as either the lhs or rhs futures
> > complete.
>
> Didn't we talk about operator&&()? No 'either/or' here, only both
> futures. Additionally, the same comments apply as outlined below.

I'm pretty sure he's not talking about your "wait_for_all" operator&&() at 
all, he's talking about one with semantics closer to the "real" operator&& 
defined by the language.

> My main point was that such operator overloads apply to the result types
> and not the futures themselves, which adds unnecessary semantics and

Re: Property Tree Library status?

Jonathan Biggar <jon <at> biggar.org> writes:
> 
> Is this finally going to make it into a release?  1.36?
> 

I had the same question a couple months back.  The reply I received
pointed me to the following interesting message from Marcin:

http://article.gmane.org/gmane.comp.lib.boost.devel/171825

Basically, it appears that there is some work that still is 
required for this library, especially on moving the documentation
to Boost.Book.  

My reply (and more information on the delay) is here:

http://article.gmane.org/gmane.comp.lib.boost.devel/173006/

As you can see I mentioned that I might be able to help out
with the documentation if I could find some time to learn
about the doc chain.  

Fortunately, I was finally able to find some time recently to 
do this.  Currently I have converted Marcin's original docs 
to QuickBook format.  I also ran into issues with the 
reference section looking horrible.  I am currently working 
around bugs(?) in doxygen's xml generation and trying to 
improve this.  It's starting to near an acceptable state and
I hope to have a couple patches to upload in a few days.  The
documentation would still require further work as the old

Re: Updated version of futures library

Frank Mori Hess wrote:

> > > > > would be false and otherwise the composed future would not be
> > > > > ready yet.
> > > >
> > > > Doing it the way you're proposing implies shortcutting
> > > > operator&&(), which can't be implemented.
> > >
> > > left-to right evaluation can't be short-circuited, but he's talking
> >
> > Right, that's exactly my point.
> >
> > > about short circuiting in time, as either the lhs or rhs futures
> > > complete.
> >
> > Didn't we talk about operator&&()? No 'either/or' here, only both
> > futures. Additionally, the same comments apply as outlined below.
> 
> I'm pretty sure he's not talking about your "wait_for_all" operator&&()
> at all, he's talking about one with semantics closer to the "real"
> operator&& defined by the language.

Sure, I understand. But the issue is that these are very similar to the
proposed math operators in the sense that they add semantics in terms of the
future results not the futures themselves.

> > My main point was that such operator overloads apply to the result
> > types and not the futures themselves, which adds unnecessary
> semantics
> > and defeats separation of concerns. And, BTW, this is very much like

thread_primitives.hpp conflicts with the platform sdk

The following logic from thread_primitives.hpp needs to allow for a
separately installed platform SDK:

#if defined(BOOST_MSVC) || defined(BOOST_INTEL_WIN)
#if _MSC_VER>=1400
#if _MSC_VER==1400
extern "C" unsigned char _interlockedbittestandset(long *a,long b);
extern "C" unsigned char _interlockedbittestandreset(long *a,long b);
#else
extern "C" unsigned char _interlockedbittestandset(volatile long *a,long b);
extern "C" unsigned char _interlockedbittestandreset(volatile long *a,long b);
#endif

Right?

--

-- 
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Updated version of futures library

On Saturday 31 May 2008 21:19, Hartmut Kaiser wrote:
> I'm perfectly aware of this. And actually I expressed exactly the same
> by pointing out the main difference between the two sets of operators:
> the logical operators I proposed are for the futures themselves while
> the others are related to the future results.
>
> But you're diligently ignoring my point: overloading the operators for
> the future results is conceptually equivalent to having a default
> conversion operator to the result type for the future itself! And for
> that reason I would not like to see something like that in the future
> library.

Ah, I think I'm understanding you better now.  You are appalled by the idea 
of treating a future<T> like it was a T, is that correct?  You want a 
future<T> to only be treated like an abstract handle to a value, not the 
value itself?  I wasn't ignoring your point, it's just that your view is 
extremely foreign to how I view futures, so your words were almost 
meaningless to me.  I view being able to view a future<T> as a placeholder 
for a T object as a large part of what makes futures useful.  I 
implemented the future class in libpoet to support that, with implicit 
conversions from future<T> to future<U>, from T to future<T>, etc.  And 
being able to treat a future<T> as a placeholder for a T is essential to 
implementing things like poet::active_function.  

I don't particularly like the implicit conversion from T to future<T>, but 
that has absolutely nothing to do with not wanting to treat a future<T> as 
a placeholder.  It's simply because the conversion can block, and thus 
produce unexpected behavior (an object appearing on the right hand side of 
an assignment stalling your program).  The explicit future::get() at least 
gives a hint that something more than a quick conversion might be 

Re: Updated version of futures library

On Saturday 31 May 2008 23:21, Frank Mori Hess wrote:
> I don't particularly like the implicit conversion from T to future<T>,

Err, I meant future<T> to T.

> but that has absolutely nothing to do with not wanting to treat a
> future<T> as a placeholder.  It's simply because the conversion can
> block, and thus produce unexpected behavior (an object appearing on the
> right hand side of an assignment stalling your program).  The explicit
> future::get() at least gives a hint that something more than a quick
> conversion might be happening.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Polymorphic function (was: Multi signature boost::function v1.0)

On Sat, May 31, 2008 at 8:23 AM, Marco Costalba <mcostalba <at> gmail.com> wrote:
>
>> Sorry for the delay. I just put it on vault.
>
> I'm just back after a week off-line due to my job. This is a great
> news, I'm going to download right now.
>
> More to come...
>

Hi Daniel,

  I have downloaded and tested Function
Objects/polymorphic_function.zip from boost vault.

Very nice stuff! really! a lot of new tricks to learn 

I have immediately replaced boost::function with
boost::functional::polymorphic_function in msf-1.2 (also under vault,
but in base directory) and gave it a spin.

Unfortunately I was not able to make it work.

Some boost::function API, necessary for msf-1.2, are not supported:
operator==(), empty(), clear(), contains()

I said, ok not a biggie, I can just use polymorphic_function::target()
and build something similar myself.

But what stopped me is that target() does not seem to work.

Re: Updated version of futures library

On Sun, Jun 1, 2008 at 12:21 AM, Frank Mori Hess <fmhess <at> speakeasy.net> wrote:
> On Saturday 31 May 2008 21:19, Hartmut Kaiser wrote:

[snip]

>> > Personally, I don't particularly want to see a future
>> > library overload any logical operators at all, or at least have the
>> > overloads sequestered in separate headers that aren't included by any
>> > of the other future library headers.
>>
>> That's a matter of taste, for sure. But would you mind telling us why
>> you don't want to have these? Your opinion sounds to be quite strong, so
>> you must have good reasons!
>
> It's the obvious reason.  I don't think taking a function with a 2 letter
> name, which is already overloaded, and adding a new set of overloads to it
> which have semantics completely unrelated to the existing overloads is a
> desirable or aesthetically pleasing interface.  No one would even consider
> doing such a thing if the function wasn't an operator.  I guess I just
> don't find operator syntax as compelling a feature as others.

I tend to agree with Frank's view of overloading && and || for futures.
I'm surely not a never-overload-operators-guy. I, for instance, love spirit.
But in spirit && and || has a specific meaning inside EBNF domain.
In futures, we're just inventing that meaning.
Couldn't lambda's help us more than overloading here?

--

-- 
Felipe Magno de Almeida
_______________________________________________

Re: Updated version of futures library

On Sunday 01 June 2008 06:34, Felipe Magno de Almeida wrote:
> >> That's a matter of taste, for sure. But would you mind telling us why
> >> you don't want to have these? Your opinion sounds to be quite strong,
> >> so you must have good reasons!
> >
> > It's the obvious reason.  I don't think taking a function with a 2
> > letter name, which is already overloaded, and adding a new set of
> > overloads to it which have semantics completely unrelated to the
> > existing overloads is a desirable or aesthetically pleasing interface.
> >  No one would even consider doing such a thing if the function wasn't
> > an operator.  I guess I just don't find operator syntax as compelling
> > a feature as others.
>
> I tend to agree with Frank's view of overloading && and || for futures.
> I'm surely not a never-overload-operators-guy. I, for instance, love
> spirit. But in spirit && and || has a specific meaning inside EBNF
> domain. In futures, we're just inventing that meaning.
> Couldn't lambda's help us more than overloading here?

Oh, I came up with another reason.  A future can be empty (default 
constructed, or a moved unique_future).  Such classes often support 
converson to bool (or conversion to "unspecified boolean type" when they 
want to be safer) to test if they have been initialized.  So seeing a 
future in a logical operator, one might mistakenly assume the operator is 
is a test to see if either or both futures have been initialized.

Although, to nit-pick myself, I don't think the statement I made about the 
logical operators already being overloaded was technically correct.  I 
suppose its really the conversion-to-bool operator that is overloaded and 
there is just the bool prototype for the logical operators.

Re: [Graph] compile error while inheriting boost graph

>
> class DerivedGraph: public boostd::Graph{
>     public:
>         class Node: public boostd::Vertex{                      // 
> error on
> this line
>         };
> };
>
> The compiler complains
>  error: expected class-name before '{' token

That's because vertex descriptors for listS vector storage have type  
void* - which you can't list as a base class.

Andrew Sutton
asutton <at> cs.kent.edu

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost