Re: [functional] adding overload

On Mon, Jan 30, 2012 at 1:34 PM, Dave Abrahams <dave <at> boostpro.com> wrote:
>
> on Tue Jan 17 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
>
>> as a user. I picked overloaded_function.
>>
>> Here's a first draft for the docs:
>>
>> https://svn.boost.org/svn/boost/sandbox/closure/libs/functional/overloaded_function/doc/html/index.html
>>
>> Comments welcome.
>
> What are the use-cases for such a beast?

Just the case that you have a bunch of functions (function pointers,
function references, and monomorphic functors) with different names
and you want to combine them into an API with a single overloaded
function name.

History: The idea was originally raised as a side discussion on the
limitation that local functions cannot be polymorphic
http://lists.boost.org/Archives/boost/2011/05/181501.php . No
Boost.Local reviewer raised concerns on adding overloaded_function and
the consensus was to potentially add it under Boost.Functional.
However, my impression was that all reviewers saw this as a "nice to
have" (so no object but not strong preference for addition either). I
since then asked Boost.Functional authors (and Boosters in general) if
there is any concern with adding this functionality but I didn't get
much of a reply :(

[local_function] ready

Hello all,

I have finished making the modifications requested by the
Boost.Local(Function) review. The code is now in the sandbox ready to
be moved into trunk.

Can I get write access to the trunk?

1) Boost.LocalFunction
New: This library allows to program functions locally, directly within
the scope where they are needed.
https://svn.boost.org/svn/boost/sandbox/local_function/libs/local_function/doc/html/index.html

2) Boost.ScopeExit
Improved APIs (variadic macros, this_, void, and C++11 closures) while
keeping full backward compatibility.
https://svn.boost.org/svn/boost/sandbox/local_function/libs/scope_exit/doc/html/index.html

3) Boost.Utility/IdentityType
New: Macro to wrap type expressions within round parenthesis so they
can be passed to macros even when they contain commas.
https://svn.boost.org/svn/boost/sandbox/local_function/libs/utility/identity_type/doc/html/index.html

4) Boost.Functional/OverloadedFunction
New: Overload different functions into a single function object.
https://svn.boost.org/svn/boost/sandbox/local_function/libs/functional/overloaded_function/doc/html/index.html

All source files:
https://svn.boost.org/svn/boost/sandbox/local_function/

Re: [hash] regular behaviour of hash function for double values

On 1/31/2012 1:55 PM, Daniel James wrote:
> The requirements for the hash function are:
>
> For two different values
> t1 and t2, the probability that h(t1) and h(t2) compare
> equal should be very small, approaching 1.0 / numeric_
> limits<size_t>::max().
>
> There's no requirement about how h(t1) and h(t2) are distributed so it
> must be the container's responsibility, since the container must work
> well with any hash function that meets these requirements. How else
> can you interpret it?
>    
As what it says.

It does not say anything about the distribution from which the two 
different values are drawn so the implication is that for /any /two 
values the probability must approach 1/max-value.  Technically, of 
course, this is impossible -- you can always choose the values from a 
distribution based on inverting the hash (that this might be extremely 
costly or even infeasible is irrelevant).  A reasonable view, however, 
is that if the values are chosen using any reasonable method that is not 
too specific to the particular hash method then the probability of a 
collision is as stated.  Any simple pattern in the input that results in 
a pattern in the output -- a restriction over the possible range of 
output values for meaningful subsets of all possible values -- will 
produce collision probabilities much higher than that.

If we do not read it that way -- if we take "two different values" to 
mean "two values uniformly selected from all possible input values" -- 

[Python] Please move patch to release

Hi,

The following issue has a well-tested patch now on 
trunk.  Can it be moved to release, please?

 	https://svn.boost.org/trac/boost/ticket/4657

Thanks,
-Steve

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

[Fusion] Fix needs to be pushed to release

Hi,

This issue is fixed on the trunk.  Can it be pushed to
release, please?

 	https://svn.boost.org/trac/boost/ticket/6338

Thanks,
-Steve

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

[MPI] Patch needs to be pushed to release

Hi,

The following issue is fixed on trunk.  Can it be moved
to release, please?

 	https://svn.boost.org/trac/boost/ticket/5538

Thanks,
-Steve

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

Re: [hash] regular behaviour of hash function for double values

On 1 February 2012 00:44, Topher Cooper <topher <at> topherc.net> wrote:
>
> values that differ by the table size end
> up in the same bin

Is that likely though? And any more likely than other causes of collisions?

> and values that differ by a small amount end up in
> nearby bins -- which can cause excess collisions for data with some
> corelational structure.

The STL hash containers are pretty much required to be implemented
using a chained hash table.

> Lets turn one of the arguments made on its head.  Why should someone who
> finds it convenient to use a reasonable quality hash on their data type pay
> the overhead of using a container that compensates for the possibility of a
> poor one?  Is it a more reasonable expectation that someone who wishes a
> different balance of quality vs performance then the default should rewrite
> the standard hash or rewrite the standard unordered_map?

There are very good alternative open source implementations out there.
You shouldn't need to rewrite anything.

> Sorry for the length -- I had a lot to say, I guess.

Why do you think I said I didn't want to get into this debate? I do
realise that there's a lot to say, and I don't have any enthusiasm for
saying it. I wrote the thing 7 years ago.

Re: [hash] regular behaviour of hash function for double values

On Wed, Feb 1, 2012 at 12:59 PM, Daniel James <dnljms <at> gmail.com> wrote:
> On 1 February 2012 00:44, Topher Cooper <topher <at> topherc.net> wrote:
>
> IMO a more appropriate forum would be one of the C++ newsgroups, as
> this is more about how the standard should be implemented, rather than
> my particular implementation which should really become obsolete over
> the coming years.

I think, this list is appropriate for the discussion, as it is about
Boost.Hash (and Boost.Unordered, as long as it is intended to be used
with Boost.Hash). At least, it's how it started.

> Boost.Hash's advantages over standard
> implementations are its portability and its customisation abilities.
> The former will hopefully become less relevant, the latter doesn't
> seem to have been that popular.

I don't think Boost.Hash and Boost.Unordered have to die out
eventually. One possible direction of further development of these
libraries could be an attempt to fix flaws in the STL implementations
by providing superior tools.

> In other respects the standard
> implementations should be better. I'm not going to compete with them.

A few posts back you cited std::hash implementation from libc++. I
doubt it can be worse than that.

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

Re: [interprocess] utf8 file names in memory mapped files

Den 31-01-2012 20:51, Ion Gaztañaga skrev:
> El 31/01/2012 11:05, Thorsten Ottosen escribió:
>
>> I don't see any particular reason for supporting wide strings, neither
>> in Boost.Filesystem or Interprocess. If everything was in "utf8-mode",
>> we can just use std:::string. Of course, both libraries needs to do
>> custom stuff under the hood (e.g. converting to utf16 on windows before
>> calling the windows api).
>
> I'm really ignorant on encoding and unicode issues, but I guess windows
> users don't expect "char *" or std::string to be utf-8 encoded.
>

Well, its just a matter of stating the contract of your code. If you 
state that the string or const char* argument is assumed to be utf8, 
then your're done.

This is a better contract than "I assume nothing, and guarantee nothing".

Alternatively, you can accept a boost::filesystem::path object, if you 
can live with that dependency. Then you have pushed the problem to the 
caller.

-Thorsten

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

Re: [filesystem] windows/posix inconsistencies.

Den 31-01-2012 21:37, Ion Gaztañaga skrev:
> El 31/01/2012 14:47, Stephan T. Lavavej escribió:
>> [Thorsten Ottosen]

> Although returning vectors by value might be a good idea for factories,
> and such things, it's always more efficient to pass a reference to a
> vector, and clear() + fill or assign, or even better, reusing already
> constructed values (which can be vectors of vectors). Using
> filesystem::path in a loop might trigger a lot of allocations that could
> be avoided if the string could be passed as an argument, reusing already
> allocated memory for each path.
>

In my case "glob" performance is not important; STLSofts version is 
probabily much faster.

Remark 1: with the &/&& syntax of C++11, at least the temporary strings 
are more efficient, as we can move the value.

Remark 2: The fact that functions like  extension() returns a temporary 
path object seems overkill (I know its only a cheap string copy, but still).
I fail to see how ".foo" can be a path.

I feel that the problem is that there is no
uniform handling of strings in the interface/internally. If the path 
objects stored/acccepted utf8 strings, we would have a very nice, clean 
interface.

Taking extension() as an example, we have the following options: