I've sent (and then received) the following posting on the new Boost list.

Since boost@... seems to be working, I'll shut off new messages
at the YahooGroups host.

--Beman

  >When you get this message, it means the Boost mailing list is now active
at
  >a new host (courtesy of the Open Systems Lab at Indiana University).
  >
  >New email address for posting: boost@...
  >
  >The web page for users is:
  >
  >  http://lists.boost.org/mailman/listinfo.cgi/boost
  >
  >All current Boost members have been subscribed to the new list.  If you
  >received digests from YahooGroups, you should still get posting that
way.
  >Everyone else has been set up to receive individule postings by email.
These
  >were the only two options open to us for bulk subscriptions, but other
  >subscription options are available via the above link.  At the bottom of
  >that page, enter your email address, then click on "Edit Options".
  >
  >It looks like the bulk subscription process created a password for each
  >subscriber. One of the choices on the web page you reach via "Edit
Options"
  >is a button "Email my password to me".  It has the obvious effect.
  >
  >The list archives should be available at
  >http://lists.boost.org/MailArchives/boost/ (That doesn't seem to be
working
  >at this precise instant, but it has been working OK, so hopefully the
  >problem will clear soon.)
  >
  >There are still a lot of loose ends, but we are definitely making
progress.
  >Thanks to Brian Barrett and Carl Daniel for all their efforts!

I have recently been working on a magazine article about a smart weak
pointer implementation, without being aware of the work being done by Peter
Dimov for the boost weak_ptr. Now there's not much to be gained trying to
publish the article, so I guess I'll put my implementation up for discussion
here.

The main difference in my weak_ptr is that it relies on support from the
referant class instead of from a related strong pointer (i.e. weak_ptr<T>
requires specific support from class T, instead of from shared_ptr<T>). How
it works is the referant (or target) object must allocate a boolean "true"
flag on the heap, and must clear it to "false" in its destructor. The flag
has a reference count that gets shared by any weak pointers that refer to
the target object. In this way, the flag can outlive the target object's
destruction. The weak pointers can simply check the value of the flag to see
whether their target object still exists or not.

So compared to the boost strong pointer/weak pointer combination, I see two
benefits:

1. The target objects can be allocated and managed in any way (static,
automatic, heap, etc...) because its destructor always does the right thing.

2. It does not impact code which uses shared_ptr but not weak_ptr

As I understand it, the new boost:weak_ptr requires all boost::shared_ptr
objects to maintain two reference counts, even if the user code does not use
the weak pointer facilities. In fact, I had already found an implementation
along these lines from Dejan Jelovic's home page (http://www.jelovic.com/).
This approach seems a bit unfair, seeing as weak pointers are (IMHO) pretty
rarely used compared to strong pointers.

The disadvantage I see with my approach is that the target class has to have
explicit support, and (of course) can't be a built-in type. So that's not so
good in a generic library, but I think that weak pointers are something of
an usual case. The typical usage pattern for weak pointers (in data
structures which contain cycles) means that the objects in question are
usually not built-in types, and also not from third party code. If one of
these situations were actually to arise, then the target object would have
to be stored in some kind of wrapper I guess, but I can't think of a
situation where this would happen.

The easiest way to support weak_ptr in a target class is to add inheritance
from the simple weak_ptr_target base class which does all the necessary
stuff for you. I guess I shouldn't post the code directly to this list, but
if anyone is interested in seeing it (or can suggest where to post it) drop
me an email. Any comments welcomed.

Regards,
Raoul Gough.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

--- In boost@y..., Aleksey Gurtovoy <alexy@m...> wrote:
>
> The formal review of Lambda Library by Jaakko Järvi and Gary
Powell
starts
> today, March 8th and runs through Wednesday, March 20th.
>
> The library is available at
>
http://groups.yahoo.com/group/boost/files/lambda/lambda_2002_02_22.zip

>
http://groups.yahoo.com/group/boost/files/lambda/Lambda_2002_02_22.tar
.gz

I am currently evaluating this library and in principle, as a long-
time support of the addition of Lambda functions to C++ I am very
interested in such a library as this being added to Boost.  However,
I have to appologize for my late entry in the discussion as I have
only just learned about boost a few days ago and have to review the
Bind library and any other library that is mentioned in these
discussions and although I still have 2 days to make my comments I
hope pass or fail you won't mind me posting my review a day or two
late if I can't do so in a timely fashion.

From what I have read of the BLL so far I am very pleased with it and
if I don't get a chance to post my review before the time limit,
please consider this a tentitive endorsement.

Thanks all and great work Jaakko and Gery!!

Devo Andare,

Jeffrey.

I think we can only find if the overflow problem is a serious practical
problem
but letting people try it - they HAVE been warned!

Paul

PS Nobody has responded to my query if the compiler can be
persuaded to insert checks (see CSR?) and do something on overflow.
All hardware can do something, if believe, but somehowC++ code (at least
portable code)
never uses this.  Is this something Boost can help with?

> -----Original Message-----
> From: Steve M. Robbins [mailto:steven.robbins@...]
> Sent: Friday, March 15, 2002 2:12 PM
> To: boost@yahoogroups.com
> Subject: Re: [boost] Rational precision issues
>
>
> On Thu, Mar 14, 2002 at 09:49:14AM -0000, Paul A. Bristow wrote:
> > I believe a templated rational WILL be useful and will be used
> with 32 or 64
> > bit integers, (or unlimited precision integers when available).
> >
> > Isn't the key advantage of rational is that results remain EXACT (no
> > rounding etc)?
>
> Yes, but that is only true if you use an arbitrary-precision integer
> package.  And only if you stick to using the four basic arithmetic ops
> -- no sqrt(), no trig.
>
> > And perhaps rationals are quick too?
>
> Not if you use arbitrary-precision integers :-)
>
>
> -S
>
> --
> by Rocket to the Moon,
> by Airplane to the Rocket,
> by Taxi to the Airport,
> by Frontdoor to the Taxi,
> by throwing back the blanket and laying down the legs ...
> - They Might Be Giants
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
> <mailto:boost-unsubscribe@yahoogroups.com>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>

--- In boost@y..., Beman Dawes <bdawes@a...> wrote:
>
<snip>

> The convenience functions, besides providing recursion, regular
expression
> and other filtering, and similar commonly needed features, will
also treat
> errors in the context of typical use.  Thus remove() resulting in
ENOENT
> wouldn't throw an exception, for example.
>
From what I've seen on this thread, of all the different scenarios in
which various remove failures can be safely ignored, none stand out
as so common as needing their own "convenience" function.  As it is,
it's 4-5 lines of code to write your own wrapper around what boost
provides.  Just for the record, most of the times I have used remove,
I've literally not cared at all whether there was an error, no matter
what it was.  The "file in use" error in particular is one that I
know I can safely ignore (sometimes I might retry a couple of times).
But to start picking and choosing arbitrarily which errors should
throw exceptions seems a questionable task at this stage anyway.  The
first cut of the library can get by fine with just a 'remove' that
throws exceptions on all possible errors - if there really is a
strong demand for one that avoid some exceptions, then we can look at
it then.  And it may not be just remove - it's conceivable that other
filesystem operations need similar treatment.

As for the temporary file case, there's actually a good argument for
a RAII-style "temporary file" and "temporary directory" class (I've
used them quite a bit myself).  As it is I don't think there has been
a proprosal to support things like tmpnam etc.

Dylan

----- Original Message -----
From: "rameysb" <ramey@...>
To: <boost@yahoogroups.com>
Sent: Monday, March 18, 2002 12:46 PM
Subject: [boost] Serialization Draft Submission # 2


> Fellow programmers
>
> I have just uploaded draft # 2 of my proposal for a boost library to
> address saving and restoring of C++ objects. Serialization.zip

<snip>

> Aside from the issues noted above, the library has no KNOWN bugs.
> I would ask those who have shown an interest in this library to
> attempt to install it on their own platforms and try to use in one
of
> there own applications.  Feedback from these efforts would be
> invaluable to me.

I looked through it but haven't tried to compile or test it.  Some
comments:

   - Strings are not serialized reliably in text archives unless
(ironically) the underlying stream is opened in binary mode.  In
particular, the characters '\n' and '\r' may not be read back
correctly.

   - Strings that start with a numeric character are not handled
correctly in text archives.

   - The Boost smart pointers should be supported directly.  On the
other hand, supporting raw pointers is highly dangerous (although
probably unavoidable).  Maybe a special syntax should be used for the
serialization of raw pointers.

   - Placing names in the global namespace is never safe.  Consider:

#include "boost/serialization.hpp"
bool serialization; // Oops: name collision.

   - The 'typedef's in namespace 'boost' do not belong there, and are
in part too restrictive anyway.  Only 255 versions?

   - 'using' directives are not appropriate for header files.

   - Some lines are over 80 characters long (contrary to Boost
guidelines).


--
Rainer Deyke | root@... | http://rainerdeyke.com

>> it's only that this epic scope could prevent lambda
  >> from
  >> > being added to the standard library.
  >
  >Agreed, BLL exception handling etc. are probably not features I'd
  >suggest to be added to the standard library. For standard library,
  >some branches would obviously get chopped away - for boost, I think
  >it's ok to have a richer set of features.

That's true, but even on Boost a somewhat bloated library will turn off
some users.  (That's just a general comment, not a specific opinion that
you should remove anything from the lambda library.)

-------------------------------------------------
True enough, but we got here because after using LL for a bit, we started
wanting more. You know how this goes, first you say, ah hah! We've got
ll::for_each, then we realize what we want is a nested "count_if" and pretty
soon all of the STL algorithms are cloned into lambda. (not the algorithm,
just a wrapper to forward it to std::STL).

   Then we added exceptions, and we realized we needed to be able to
"construct" objects to throw them. So that got added, then.... and well you
can see the result. (or rather the "trim" version.)

   Originally we split it into several libraries, and the idea again was mix
and match, but that doesn't really work. You can't take boost::bind and
lambda::bind and expect them to work together without some fudging. (ok a
lot) So as it stands now the big stuff is all each in their own include
files which you can use or not.

   As far as the language standard changes go, I'd really rather see
"anonymous functions" as part of the language than this. But given that this
does work as a "library" it becomes harder to justify a change to the core
language. (aka "inherit") Also I didn't really hear any support for such a
big change from the committee in Redmond.

    -Gary-

PS
  A real good "typeof" could trim a lot of the code.

At 11:31 AM 3/18/2002, Stewart, Robert wrote:

  >> Is this analysis correct?
  >
  >Let me address your question by enumerating the errors that are possible
  >when trying to remove a file and indicate whether an exception is
  >warranted.
  >I took these errors, which may not be sufficient to cover all platforms
and
  >filesystems, from a Solaris unlink(2) manpage.
  >
  >Error                                   Exception Warranted?
  >--------------------------------------- --------------------
  >Can't get to file or read only (EACCES) Yes
  >Mount point in use (EBUSY)              Yes
  >Signal occurred (EINTR)                 Yes
  >Too many symbolic links (ELOOP)         Probably
  >Name too long (ENAMETOOLONG)            Yes
  >No such file (ENOENT)                   No
  >Can't get to file's host (ENOLINK)      Yes
  >Bad pathname component (ENOTDIR)        Yes
  >Filesystem is read only (EROFS)         Yes
  >Dynamic library code in use (ETXTBSY)   Yes
  >
  >My judgement as to whether an exception is warranted is that when the
error
  >is likely fatal, then an exception is warranted.  The only common
failure,
  >which indicates that there is no such file, doesn't warrant an exception.
  >The only question, in my mind is what to do if there is a (apparent)
cycle
  >in symbolic links.  If the cycle is genuine, there's nothing the
immediate
  >caller is likely to be able to do.  If the cycle is not genuine, but
merely
  >a consequence of some unusual filesystem arrangement, few callers would
be
  >prepared to rectify the situation.  Given the rarity of this condition,
I'd
  >be inclined to think that an exception is warranted.
  >
  >To make a long story short, then, I agree that we need some means by
which
  >to indicate that ENOENT is acceptable.

OK.  Thanks for the extended analysis.

  >  The question is whether that
  >condition should ever throw an exception.

I've seen a lot of errors that first manifested themselves as removal of a
file failing because the file did not exist.

The general approach I'm working on is a set of basic functions, and then
an additional set of convenience functions.  The convenience functions
could be implemented in terms of the basic functions, although for
efficiency an implementation might not choose to do that.

The basic functions are indivisible, non-recursive, very specific, (and
thus efficient), and are extremely picky about errors.

The convenience functions, besides providing recursion, regular expression
and other filtering, and similar commonly needed features, will also treat
errors in the context of typical use.  Thus remove() resulting in ENOENT
wouldn't throw an exception, for example.

By the way, in working various usage examples, it has become obvious that a
fair number of uses of directory iterators need to recurse into
sub-directories.  Sometimes depth first, sometimes breadth first.  Whether
that need is common enough to justify either adapter iterators, or a
directory iterator option, I don't know yet.

--Beman

At 01:50 PM 3/18/2002, dmoore99atwork wrote:
  >Is the relatively low message volume still a "Yahoo Groups"
  >maintenance hangover from the weekend, or has some (most?) of the
  >traffic migrated to the new Mailman based list?

No migration yet.  Key people still out of town.

--Beman

At 11:55 AM 3/18/2002, Jaakko Jarvi wrote:

  >> it's only that this epic scope could prevent lambda
  >> from
  >> > being added to the standard library.
  >
  >Agreed, BLL exception handling etc. are probably not features I'd
  >suggest to be added to the standard library. For standard library,
  >some branches would obviously get chopped away - for boost, I think
  >it's ok to have a richer set of features.

That's true, but even on Boost a somewhat bloated library will turn off
some users.  (That's just a general comment, not a specific opinion that
you should remove anything from the lambda library.)

--Beman

hello everyone,
just a quick and (hopefully) easy question:
  how do I use BGL Dijkstra algorithm to compute shortest path from a
given vertex and all vertexes in a subset of graph's vertexes??
i have got really big graphs (from streets network), some milion of
edges and vertexes, and onlòy need to compute shortest path between
subsets of vertexes
  sorry for my bad english(i'm italian..)

Fellow programmers

I have just uploaded draft # 2 of my proposal for a boost library to
address saving and restoring of C++ objects. Serialization.zip

In addition to the original list of requirements (see below), and in
reponse to comments from boost members, I have implemented the
following enhancements:

1) Archives are derived from a base class with virtual functions.
This allows applications to implement custom archive formats.  The
library contains support for archives in character text, native
binary data, and wide character text.

2) More checking has been implemented to detect erroneas library usage

3) Archives no longer need to store class names.  This makes them
smaller and portable across platforms.

4) Archives have a header to detect cases of erroneas usage.

5) Objects serialized through pointers no longer require a default
constructor. Any constructor can be supported.  This implies that
const values and references can be saved and restored for objects
serialized through pointers.

6) System should function on platorms that fail to properly implement
partial ordering for function templates (e.g MSVC 6)

7) library, test and demo build and function properly on MINGW as
well as MSVC 7.0

8) More complete documentation.

Pending issues

1) wide character support for text archives still has problems.

2) needs testing on other platforms. In particular MSVC 6.  I can't
test the partial ordering hack on the platforms available to me.

3) test needs enhance to test cases such as recurrsive, self
referencial and cyclicly self referntial pointers

4) consider whether it necessary and/or meaningful to try to include
serialization of iterators.

Aside from the issues noted above, the library has no KNOWN bugs.
I would ask those who have shown an interest in this library to
attempt to install it on their own platforms and try to use in one of
there own applications.  Feedback from these efforts would be
invaluable to me.

Robert Ramey

note:

My original list of requirements was:

1) Code portability - depend only on ANSI C++ facilities.

2) Code economy - exploit features of C++ such as RTTI, templates,
and multiple inheritence, etc where appropriate to make code shorter
and simpler to use.

3) Independent versioning for each class definition. That is, when a
class definition changed, older files can still be imported to the
new version of the class.

4) Pointer persistence. Pointers and the objects they point to are
restored to a state equivalent to the original state when the objects
were stored. This includes proper restoration of multiple pointers
to the same object.

5) Persistence of STL containers

6) Archive portability - should be portable from one platform to
another.

7) Orthogonal specification of file stream output to permit seamless
filtering (e.g. encryption, compression, etc).

8) Non-intrusive. permit serializaton to be applied to unaltered
classes. That don't require that classes to be serialized be derived
from a specific base class or implement specified member functions.
This is necessary to easily permit serialization to be applied to
classes from class libraries that we don't want to have to alter.

9) Absolute minimal coding required to add serialization to ones
program

Robert Ramey

----- Original Message -----
From: "Stewart, Robert" <stewart@...>
To: <boost@yahoogroups.com>
Sent: Monday, March 18, 2002 9:31 AM
Subject: RE: [boost] Filesystem library: remove


> Let me address your question by enumerating the errors that are
possible
> when trying to remove a file and indicate whether an exception is
warranted.
> I took these errors, which may not be sufficient to cover all
platforms and
> filesystems, from a Solaris unlink(2) manpage.
>
> Error                                   Exception Warranted?
> --------------------------------------- --------------------

<reorganize>

> Name too long (ENAMETOOLONG)            Yes
> No such file (ENOENT)                   No
> Bad pathname component (ENOTDIR)        Yes

These all imply that the file doesn't exist, right?  Why throw an
exception in some cases but not in others?

> Can't get to file or read only (EACCES) Yes
> Filesystem is read only (EROFS)         Yes
> Mount point in use (EBUSY)              Yes
> Dynamic library code in use (ETXTBSY)   Yes

These imply that the file exists but can't be deleted (for now):
genuine failure.

> Signal occurred (EINTR)                 Yes
> Too many symbolic links (ELOOP)         Probably
> Can't get to file's host (ENOLINK)      Yes

I'm not exactly sure what these mean, so no comment.

> My judgement as to whether an exception is warranted is that when
the error
> is likely fatal, then an exception is warranted.

Whether or not an error is fatal depends entirely on the context.
Here's a list of some possible reasons why one might want to delete a
file:

Direct user request: If the operation fails, this should be reported
to the user (along with the specific type of failure).  It is not
fatal in the larger sense.

Removal of temporary files: Failure is generally not critical; it just
leaves some garbage on the user's disk.  Should probably be
logged/reported and then ignored.

Uninstalling something from the system: Failure should be reported to
the user, who may then be given the option of correcting the error,
ignoring it, and/or aborting the entire program.

Removing a file that is used as an inter-process mutex: Failure (of
any kind) is probably fatal.


--
Rainer Deyke | root@... | http://rainerdeyke.com

Is the relatively low message volume still a "Yahoo Groups"
maintenance hangover from the weekend, or has some (most?) of the
traffic migrated to the new Mailman based list?

Thanks,
Dave

Dear Boosters,
I am currently working on "Beyond The C++ Standard Library - An Introduction to Boost", which is a tutorial-style book about several of the Boost libraries. Where would one seek knowledgeable reviewers? Of course, it is here, and that's the reason for this note.

Before saying more, I would like to ask that responses be sent directly to me rather than to the list. The moderators have allowed this note, but this is not intended to become a discussion. Should I receive notes of public interest, I'll post those to the list. Also, for those that are subscribing to both Boost (developers) and Boost-Users, my apologies for cross-posting.

Onwards! The book will cover the following libraries (minor modifications to this list may occur):

* Any
* Array
* Bind
* Call_traits
* Compose
* Concept check
* Conversion
* Functional
* Operators
* Random
* Rational
* Regex
* Smart_ptr
* Static_assert
* Tokenizer
* Tuple
* Type_traits
* Utility

I am looking for people interested in reviewing one or more chapter(s) (libraries). If you are volunteering, please add information that states the library, or libraries, that you'd be willing to review. Where one reviewer will have a deep knowledge about the libraries, another may only have a strong interest. Both are very welcome!

What's in it for you? Not money I'm afraid, but something that is hopefully more valuable: A chance to make the book better, to share some of your knowledge, and maybe to learn something new. Your name in the preface :-).

To volunteer, send a comment or ask a question, please contact me directly at bjorn.karlsson@.... Thanks!

Before I end this post:
Boost is becoming more and more important for the C++ community, and I would like to thank all participating Boosters for the libraries, the ideas, the research, the discussions and the enthusiasm that sums up to what we call Boost. All of this not only makes the world a better place, it also (which I personally think is more important) makes the world more interesting!

Thanks,

Bjorn Karlsson

Yet another example of complexity being useful (ie. control fns.)

I have a class which for reasons has to be this way, with a "type" id. I
want a clone of it. (Sorry no virtual fns allowed in the original objects.)

(Warning more uncompiled code)

using boost::lambda;

   transform(a.begin(), a.end(),
             back_inserter(b.begin()),
               switch_statement(_1->*getType()),
               case_statement<FIRST_TYPE>( new_ptr<Clone1stType>(*_1) ),
               case_statement<SECOND_TYPE>( new_ptr<Clone2ndType>(*_1) ),
             ....
               ));

That's not too bad to read and maintain. (Yes I know about the pitfalls of
adding a new type, but see the above comment about virtual.)

What I find, is that the utility that allows me to write an entire program
as one function and one file, doesn't prevent me from structuring my
programs into multiple subroutines and files. Same for Lambda functions. If
you find that the complexity is getting high. Make a subroutine!

Meantime for boost a rich set of utilities can make writing/reading code
much easier. (Note: I didn't say debugging and compiling)

    Yours,
   -Gary-

> > I haven't look at any of the technical issues, but from a purely
> > esthetic view I prefer the familiar, explicit "lambda(x, y, x + y)".

Also I might add, that with _1 being a typedef, you can have "x", "y", "z"
instead if you prefer. Then writing a fn "lambda" to look like the above is
pretty trivial.

(This is not to say that FACT and LL are equivalent, but that the simpler
things in FACT can be simulated in LL, and probably vise versa.)

(Warning untested code!)

namespace LL_FACT {

typedef boost::lambda::placeholder1_type& x = free1;
typedef boost::lambda::placeholder1_type& y = free2;

template<class BinderArgs>
boost::lambda::lambda_functor<BinderArgs> &
lambda(boost::lambda::placeholder1_type&,
        boost::lambda::placeholder1_type&,
        boost::lambda<BinderArgs> &lfn)
{ return lfn; }

}
   using LL::FACT x,y;
   for_each(a.begin(), a.end(), LL_FACT::lambda(x,y, x+y)(1) );


(Note: The above does not check the order of the placeholder arguments, the
way FACT does, nor does if verify that the lambda function even uses the
same set of place holder arguments that are stated in args 1, & 2.) This
could be done but not in an email message code.

   ie.
    for_each(a.begin(), a.end(), LL_FACT::(lambda(_1,y)(x+_2) );

would compile. (IMO it shouldn't)

   Anyway Jaakko and I have looked at FACT! and J.Striegnitz has looked at
Lambda, and while we differ on some of the syntax issues we agree that C++
needs a functional languge.

   Future work could include a real "lambda" function specifier if there is a
need.

   We've also looked at integration with PETE. (Whose development appears to
be on hold.) But so far haven't done anything more than play around with it.

   Yours,
   -Gary-

> I'm getting warnings about boost::lambda::action, return_type,
> return_type_1, return_type_2 having inconsistent declarations using both
> 'class' and 'struct', and unreferenced parameter warnings in selector<FIRST>
> and selector<SECOND>.

Some of these have already been fixed (there's a separate branch,
lambda_development_during_review, where I currently make any fixes to
prevent changing the code during review).

Jaakko

Agreed, the try/catch stuff, complicate loops etc. may be a bit too much
as lambda expressions. The simple control structures (if_then,
if_then_else), on the other hand, are quite convenient.
Just some silly example:

for_each(a.begin(), a.end(), if_then(_1 < 0, _1 = 0));


Having if statements, loops are quite natural addition.

And being able to throw an exception can be handy:

for_each(a.begin(), a.end(),
   if_then_else(_1 < 0,
               throw_exception(bind(constructor<std::exception>(), "negative")),
               do_something));

And being able to throw, wht not catch?

I noticed Gary posted some rationale too. So the complex stuff in the
library is partially there as a 'proof of concept'.

> > I don't see for loops and try/catch blocks as necessary parts
> > of a lambda library; of course this is only my personal opinion,
> and I am
> > free to not use the features I don't find appropriate, so this is
> not a
> > major problem;

control structures and exceptions are in separate include files,
so one does not pay what one does not use.

> it's only that this epic scope could prevent lambda
> from
> > being added to the standard library.

Agreed, BLL exception handling etc. are probably not features I'd
suggest to be added to the standard library. For standard library,
some branches would obviously get chopped away - for boost, I think
it's ok to have a richer set of features.

  ( Another feature I don't see
> a need of
> > is currying support. It seems added just because it's possible, not
> because
> > it solves a practical problem.

This is funny. Adding currying was initiated by Jeremy Siek's suggestion:
"Jaakko, you know what would be cool. If you could write something like
..."
So, you're absolutely right, there was no urgent practical problem that
needed currying. I'm not sure there's a need to remove it though.

Jaakko

From: Beman Dawes [mailto:bdawes@...]
>
> We talked about two flavors of remove():
>
>    remove( foobar );  // throws if foobar doesn't exist,
>                       // or otherwise can't be deleted.
>
>    remove( foobar, nothrow); // doesn't throw ever?
>
> The problem with the second form is that it makes it look
> like it will
> never throw.  If fact, if foobar exists, but can't be deleted
> (perhaps
> because it is read-only, in use, wrong permissions, or any
> other reason)
> then we still want to throw, AFAIK.
>
> I'm thinking what we are really looking for is more like this:
>
>    void remove_if_exists( const string & path )
>     { if ( exists( path ) remove( path ); }
>
> Is this analysis correct?

Let me address your question by enumerating the errors that are possible
when trying to remove a file and indicate whether an exception is warranted.
I took these errors, which may not be sufficient to cover all platforms and
filesystems, from a Solaris unlink(2) manpage.

Error                                   Exception Warranted?
--------------------------------------- --------------------
Can't get to file or read only (EACCES) Yes
Mount point in use (EBUSY)              Yes
Signal occurred (EINTR)                 Yes
Too many symbolic links (ELOOP)         Probably
Name too long (ENAMETOOLONG)            Yes
No such file (ENOENT)                   No
Can't get to file's host (ENOLINK)      Yes
Bad pathname component (ENOTDIR)        Yes
Filesystem is read only (EROFS)         Yes
Dynamic library code in use (ETXTBSY)   Yes

My judgement as to whether an exception is warranted is that when the error
is likely fatal, then an exception is warranted.  The only common failure,
which indicates that there is no such file, doesn't warrant an exception.
The only question, in my mind is what to do if there is a (apparent) cycle
in symbolic links.  If the cycle is genuine, there's nothing the immediate
caller is likely to be able to do.  If the cycle is not genuine, but merely
a consequence of some unusual filesystem arrangement, few callers would be
prepared to rectify the situation.  Given the rarity of this condition, I'd
be inclined to think that an exception is warranted.

To make a long story short, then, I agree that we need some means by which
to indicate that ENOENT is acceptable.  The question is whether that
condition should ever throw an exception.  The postcondition of remove() is
that the file in question no longer exists.  If the file didn't exist on
entry, the postcondition is still satisfied.  Therefore, I think that
remove() should always return a Boolean to indicate whether the file was
actually removed from the filesystem; false would indicate that the file
didn't exist when remove() tried to remove it.

Thus,

     template <typename String>
     bool
     remove(String const & pathname_i);


Rob
Susquehanna International Group, LLP
http://www.sig.com

> Bind issues aside, I my overall impression is that the library is
> overdesigned.
> I don't see for loops and try/catch blocks as necessary parts
> of a lambda library; of course this is only my personal opinion,
and I am
> free to not use the features I don't find appropriate, so this is
not a
> major problem; it's only that this epic scope could prevent lambda
from
> being added to the standard library. ( Another feature I don't see
a need of
> is currying support. It seems added just because it's possible, not
because
> it solves a practical problem. I liked the original lean-and-mean
lambda
> from several years ago. :-) )

Second this. I can hardly imagine using of very complex function with
switch end exception handling expreseed as one expression in a
production code. What if I need to step into it in the debugger?
Though this is just my feeling, that need real usage to justify it.

[...]

----------------------------------------------
Part of the reason to extend the Lambda library is to show that anonymous
functions should be added to the language. In order to allow anyone to even
simulate this idea we attempted to add as much of C++ to the lambda syntax
as is possible. I too hate the current error messages, and the debugging,
although with inline'ing off its not too bad.

In an earlier version we implemented _ALL_ of the STL algorithms into LL.
The reason being was that it should be possible to do iterate across a
matrix using for_each et.al.  We can of course finish this work but are
waiting to see how this level is received. Our main complaint with the STL
algorithms was that as soon as things got in the slightest way complex
things start to get really hard. Lambda is one way to make it easier.

On the other hand we tried to keep each new layer of complexity to its own
include file so like everything else in C++, you only pay for what you use.

   Yours,
   -gary-

At 09:07 AM 3/8/2002, Moore, Paul wrote:

  >(Actually, a general point regarding all review announcements)

I've added a request for compiler guidance to the review managers
instructions in the review procedures.

  >It would be helpful to state in the announcement which compilers are
  >supported. Specifically, for me in this case, does it work with MSVC++
6.0?
  >If not, I won't bother downloading & trying it.

--Beman

> > I haven't look at any of the technical issues, but from a purely
> > esthetic view I prefer the familiar, explicit "lambda(x, y, x + y)".
>
> Sometimes the choice is not so clear-cut.
>
> std::for_each(v.begin(), v.end(), std::cout << _1 << '\n');
>
> vs
>
> std::for_each(v.begin(), v.end(), lambda(x, std::cout << x << '\n'));
>
> In general, I find that every non-pure-functional use looks better with the
> _N syntax; lambda() implies a pure function as far as I'm concerned.
>

The difference is really just syntactical.
Even with lambda(x, y, ...) the variables x and y are still predefined
placeholder names, defined by the FACT library, not real formal parameter
names.

Jaakko

From: "rogeeff" <rogeeff@...>
> --- In boost@y..., "Peter Dimov" <pdimov@m...> wrote:
> >
> >  std::vector< boost::shared_ptr<X> > v;
> >  std::for_each( v.begin(), v.end(), boost::bind(&X::f, _1) );
>
> How will it look like with LL?

Actually now that I think about it, this is probably a non-issue since LL
will just use bind(&X::f, *_1). This covers most of the cases. Thanks.

> How will it look like with LL? I.e. how to define binary function
> like this:
>     f(x,y) = g(x,x)?

(_2, bind(g, _1, _1))

--- In boost@y..., "Peter Dimov" <pdimov@m...> wrote:
> I think that the Lambda library should be accepted.
>
> * Semantics
>
> The two primary differences between the lambda bind and boost::bind
are:
>
> 1. boost::bind uses mem_fn to support smart pointers:
>
>  std::vector< boost::shared_ptr<X> > v;
>  std::for_each( v.begin(), v.end(), boost::bind(&X::f, _1) );

How will it look like with LL?

>
> The above unfortunately doesn't work with lambda; the bind in
lambda is not
> a drop-in replacement for boost::bind (as I'd have liked.)
>
> 2. Function object arity issues.
>
> A boost::bind expression has the same arity regardless of context,
i.e.
> bind(&X::f, _1) always has arity [1, +inf). In lambda, the same
expression
> has a fixed arity that is context dependent; i.e. the expression by
itself
> has arity of 1, but in the context _2 + bind(&X::f, _1) that same
expression
> has arity of 2.

How will it look like with LL? I.e. how to define binary function
like this:
     f(x,y) = g(x,x)?

> Bind issues aside, I my overall impression is that the library is
> overdesigned.
> I don't see for loops and try/catch blocks as necessary parts
> of a lambda library; of course this is only my personal opinion,
and I am
> free to not use the features I don't find appropriate, so this is
not a
> major problem; it's only that this epic scope could prevent lambda
from
> being added to the standard library. ( Another feature I don't see
a need of
> is currying support. It seems added just because it's possible, not
because
> it solves a practical problem. I liked the original lean-and-mean
lambda
> from several years ago. :-) )

Second this. I can hardly imagine using of very complex function with
switch end exception handling expreseed as one expression in a
production code. What if I need to step into it in the debugger?
Though this is just my feeling, that need real usage to justify it.

[...]

> --
> Peter Dimov
> Multi Media Ltd.

Regards,

Gennadiy Rozental.

I think that the Lambda library should be accepted.

* Semantics

The two primary differences between the lambda bind and boost::bind are:

1. boost::bind uses mem_fn to support smart pointers:

  std::vector< boost::shared_ptr<X> > v;
  std::for_each( v.begin(), v.end(), boost::bind(&X::f, _1) );

The above unfortunately doesn't work with lambda; the bind in lambda is not
a drop-in replacement for boost::bind (as I'd have liked.)

2. Function object arity issues.

A boost::bind expression has the same arity regardless of context, i.e.
bind(&X::f, _1) always has arity [1, +inf). In lambda, the same expression
has a fixed arity that is context dependent; i.e. the expression by itself
has arity of 1, but in the context _2 + bind(&X::f, _1) that same expression
has arity of 2.

My experience with bind so far is that the flexible arity does not decrease
safety in significant ways, it simplifies the specification and the
implementation, and has proven useful in a number of cases where the user
intends to ignore the extra arguments. Having select1st always spelled '_1'
regardless of arity often makes code clearer.

Bind issues aside, I my overall impression is that the library is
overdesigned. I don't see for loops and try/catch blocks as necessary parts
of a lambda library; of course this is only my personal opinion, and I am
free to not use the features I don't find appropriate, so this is not a
major problem; it's only that this epic scope could prevent lambda from
being added to the standard library. ( Another feature I don't see a need of
is currying support. It seems added just because it's possible, not because
it solves a practical problem. I liked the original lean-and-mean lambda
from several years ago. :-) )

* Implementation

I'm getting warnings about boost::lambda::action, return_type,
return_type_1, return_type_2 having inconsistent declarations using both
'class' and 'struct', and unreferenced parameter warnings in selector<FIRST>
and selector<SECOND>.

The implementation doesn't scale well to more than three placeholders
AFAICS. This is not a major defect since code rarely needs _4 (I've
encountered it only once so far.)

_E is a reserved name.

I was unable to compile

  std::for_each( v.begin(), v.end(), (_1->*&X::f)() );

with both MSVC 7.01a and g++ 2.95.3.

* Documentation

The documentation doesn't have a reference section; it'll probably need one
in order for lambda to be considered for inclusion in the standard library.
:-)

--
Peter Dimov
Multi Media Ltd.

Dear Boosters,
I am currently working on "Beyond The C++ Standard Library - An Introduction to Boost", which is a tutorial-style book about several of the Boost libraries. Where would one seek knowledgeable reviewers? Of course, it is here, and that's the reason for this note.

Before saying more, I would like to ask that responses be sent directly to me rather than to the list. The moderators have allowed this note, but this is not intended to become a discussion. Should I receive notes of public interest, I'll post those to the list. Also, for those that are subscribing to both Boost (developers) and Boost-Users, my apologies for cross-posting.

Onwards! The book will cover the following libraries (minor modifications to this list may occur):

* Any
* Array
* Bind
* Call_traits
* Compose
* Concept check
* Conversion
* Functional
* Operators
* Random
* Rational
* Regex
* Smart_ptr
* Static_assert
* Tokenizer
* Tuple
* Type_traits
* Utility

I am looking for people interested in reviewing one or more chapter(s) (libraries). If you are volunteering, please add information that states the library, or libraries, that you'd be willing to review. Where one reviewer will have a deep knowledge about the libraries, another may only have a strong interest. Both are very welcome!

What's in it for you? Not money I'm afraid, but something that is hopefully more valuable: A chance to make the book better, to share some of your knowledge, and maybe to learn something new. Your name in the preface :-).

To volunteer, send a comment or ask a question, please contact me directly at bjorn.karlsson@.... Thanks!

Before I end this post:
Boost is becoming more and more important for the C++ community, and I would like to thank all participating Boosters for the libraries, the ideas, the research, the discussions and the enthusiasm that sums up to what we call Boost. All of this not only makes the world a better place, it also (which I personally think is more important) makes the world more interesting!

Thanks,

Bjorn Karlsson

I've uploaded a new version of a barrier synchonization primitive to
http://groups.yahoo.com/group/boost/files/thread_barrier_v2.zip

Changes/Issues:

1.  HTML documentation included.
2.  "generational_barrier" variant renamed to barrier.  This will be
the primary barrier in the package.
3.  "barrier" variant renamed to one_shot_barrier.  This may be
dropped from the package as it is a limited version of #2 w/o much
compensating efficiency/functionality.
4.  Both barrier variants now return a "BOOST_SERIAL_THREAD" value to
exactly one thread upon return from wait().
5.  Behavior is still undefined if the barrier is destroyed while
some threads are still in wait().  Once Boost.Threads cancellation
mechanics are solidified, I think that barrier should cooperate
gracefully with cancellation and that this will address many of the
same needs that an exception throw from wait() would accomplish.


Comments welcome.

Thanks,
Dave

From: <nbecker@...>
> I haven't look at any of the technical issues, but from a purely
> esthetic view I prefer the familiar, explicit "lambda(x, y, x + y)".

Sometimes the choice is not so clear-cut.

std::for_each(v.begin(), v.end(), std::cout << _1 << '\n');

vs

std::for_each(v.begin(), v.end(), lambda(x, std::cout << x << '\n'));

In general, I find that every non-pure-functional use looks better with the
_N syntax; lambda() implies a pure function as far as I'm concerned.

This post

http://groups.google.com/groups?selm=000001c1cc83%24e154d5e0%247772e50c%40c1
61550a

contains a clever is_class<> implementation based on the fact that void T::*
is only valid when T is a class.

The thread contains another gem, has_key_type<T>::value which is true only
when T has a nested type named key_type.

--
Peter Dimov
Multi Media Ltd.