Dean Michael Berris wrote:

To the moderators on the list:

I'll take that...

I'm not sure how the subversion access works, but will it be alright if this library continues to get developed in the sandbox? Is there a specific process for that?

Yes, this is the point of the sandbox. More details at http://svn.boost.org/trac/boost/wiki/BoostSubversion Basically you need to send the moderators and email and we will send you an invite for sandbox svn access.

And would this be a candidate for a mini-review once the appropriate documentation and "boostification" process gets done? Or would this merit a full review just like the other libraries that try to become part of the Boost C++ Library?

Not sure yet on that -- it has to be a fairly small utility to be a mini-review. In it's an existing library extension the current library author may just accept it as an extension and add it to the library. Not sure how this really fits yet... Jeff

Dean Michael Berris wrote:

Right now I'm thinking maybe this should be a separate library (or a small utility class) that builds upon or depends on Boost.Function.

That's cool too. A thorough review will be a nice exercise and a good experience for those how haven't undergone the spine-chilling adventure yet ;-) It's better than a bungee jumping, promise! :-P

However, if Doug (or Joel, and everybody else) thinks otherwise, and that this should be merged into Boost.Function as an overload extension, that would be acceptable as well.

Doug's the boss here. Ultimately, he'll decide on that route.

Either way, we still need to write documentation and more tests, so in the meantime I'd love to get this (and the documentation) into the sandbox so that others can play around with it as well.

Thanks, Dean, Marco and Marco and all else for your work on this! Amazing folks! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

On 10/10/07, Joel de Guzman <joel@boost-consulting.com> wrote:

Dean Michael Berris wrote:

...

Right now I'm thinking maybe this should be a separate library (or a small utility class) that builds upon or depends on Boost.Function.

That's cool too. A thorough review will be a nice exercise and a good experience for those how haven't undergone the spine-chilling adventure yet ;-) It's better than a bungee jumping, promise! :-P

I'll take your word for it. ;-) This I think will be very welcome experience indeed. :-)

...

However, if Doug (or Joel, and everybody else) thinks otherwise, and that this should be merged into Boost.Function as an overload extension, that would be acceptable as well.

Doug's the boss here. Ultimately, he'll decide on that route.

I'd definitely love to hear what Doug thinks about these proceedings. :-)

...

Either way, we still need to write documentation and more tests, so in the meantime I'd love to get this (and the documentation) into the sandbox so that others can play around with it as well.

Thanks, Dean, Marco and Marco and all else for your work on this! Amazing folks!

You're welcome. The pleasure is mine. It just so happens that I also really need this functionality, so it makes sense for me to pitch in some time to get this into Boost one way or another. :) Thanks for the initial code and the idea, it's certainly a good thing to be able to start with something like what you've posted. :-) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]

On Wed, 10 Oct 2007 18:32:54 +0200, Dean Michael Berris <mikhailberis@gmail.com> wrote:

Just a quick update:

Those interested in checking out the documentation as it takes shape (or just read through the document in whatever form it currently is) can click on http://tinyurl.com/3xtbyl to get to the published Google Document.

I haven't gotten to uploading the files into the sandbox just yet -- I'm still currently focused on writing the document and making sure that the information being conveyed is consistent with the original intent of the library. If you think there are things that need fixing (in terms of documentation) please let me know ASAP so that I can clear them up as I go along.

For now though, I'm referring to Marco Ceccheti's implementation using Boost.PP and with a pretty well fleshed out interface for the Boost.Overload object/concept. I think this is already available in the Boost.Vault.

Any documentation suggestions would be most appreciated. Please keep in mind though that the Google Document is meant to get this thing documented quickly -- it will eventually be moved either to the Wiki and/or into a quickbook file which should be made part of the "boostified" distribution (again to be uploaded to the sandbox soon). If you find questionable or unclear content, I'd like to hear from you your thoughts and suggestions to improving them -- please don't mind the aesthetics yet, I'm not a very aesthetically gifted writer. ;-)

Have fun and I certainly hope to hear from you guys soon!

On 10/11/07, Dean Michael Berris <mikhailberis@gmail.com> wrote:

...

On 10/10/07, Joel de Guzman <joel@boost-consulting.com> wrote: [...]

Thanks for your efforts Dean ! I'm tidying up the code. I'll make a new post as soon as I'm ready. Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Wed, 10 Oct 2007 18:38:15 +0200, Marco Costalba <mcostalba@gmail.com> wrote:

On 10/10/07, Dean Michael Berris <mikhailberis@gmail.com> wrote:

...

...

Thanks, Dean, Marco and Marco and all else for your work on this! Amazing folks!

Thanks to you and Dean for the big help to let me start with boost libraries, and a special thank to Marco Cecchetti for the ideas and the implementations from which I have learned a lot of tricks.

Oh I learnt from your code, too. (For instance the SFINAE compiler workaround )

Just to end up this very nice experience I have posted in Vault my library with added support for functors, so now I would say all that was planned has been implemented.

http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=overload_slim.tar.bz2&directory=&

I had very little time this week, even no time to check Marco's implementation!!

I have checked only this afternoon and it helped finishing my implementation.

I'm glad to hear that you found it useful.

After looking at Marco's work I have decided to call mine "slim" overload, because it's less then half then the former. Of course is also much less feature packed, there is only the bare minimum to work as advertised: overloading of functions or functors with hidden handling of indices and hidden container, tuples in this case.

Indeed, your implementation can be a simple fitting solution in several contexts. :-)

I have tried to stick to Marco's API to easy the review and comparing for interested people, in particular the use of set() and other little things.

You can look, as usual, at test program for getting a quick idea.

Thanks again to everybody Marco

BTW it seems to pass a good buch of tests...

Thanks to you Marco, I hope that you find the time to propose your hints and suggestions, they will be very appreciated. Kind Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Thu, 11 Oct 2007 19:18:17 +0200, Marco Costalba <mcostalba@gmail.com> wrote:

On 10/11/07, Marco <mrcekets@gmail.com> wrote:

...

Thanks to you Marco, I hope that you find the time to propose your hints and suggestions, they will be very appreciated.

Just a question.

Why do you foreseen

f.set<5>(f6); f.set<sig5_t>(f5);

instead of just

f.set(f6); f.set(f5);

Normally you should have a good reason to allow redundancy in the API, in other words if the above just works the by-index and by-sig features would seem to me more error prone and I fail to see the advantages.

Thanks Marco

P.S: for "redundancy" I don't mean that does exist more way to do the same thing but that the API

f.set<5>(f6);

specify two times where to store f6, one directly with <5> and one indirect through signature of f6

The set<signature_type>(f) and set<index>(f) are needed to manage overloaded and polymorfic function objects. That is if the functor is compatible with more than one signature the signature_type and the index are no more redundant but necessary. In my next release I'll follow the policy to use the functor as target for all the compatible signatures included in the overload but even so there will be always the need for set<signature_type>(f) or/and set<index>(f) in order to be able to use the functor as target for only one specific signature. Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On 10/12/07, Marco Costalba <mcostalba@gmail.com> wrote:

So I would say a _possible_ policy is to not allow to register say

set(f6);

if is already registered a function with a "compatible" signature.

This is wrong. I would have said: " a _possible_ policy is that a call like f.set(f6); overwrites any exsisting function with the same signature *or with a compatible signature*"

Hi Michael, On 10/13/07, Michael Fawcett <michael.fawcett@gmail.com> wrote:

On 10/12/07, Marco Costalba <mcostalba@gmail.com> wrote:

...

On 10/12/07, Marco Costalba <mcostalba@gmail.com> wrote:

...

So I would say a _possible_ policy is to not allow to register say

set(f6);

if is already registered a function with a "compatible" signature.

This is wrong.

I would have said:

" a _possible_ policy is that a call like

f.set(f6);

overwrites any exsisting function with the same signature *or with a compatible signature*"

Why is that better than your original wording? Your latter description breaks from precedence set by std::set and map.

I don't think we have to follow the precendent by std::set and std::map because of two very important reasons: 1.) The Boost.Overload implementaion does not follow the Contianer concept -- not by a long shot. If at best, it's closer to an std::pair<> than an std::map<> or std::set<>. This is because Boost.Overload is not a container -- it never was, and it never will be. 2.) The concepts and the use cases for Boost.Overload are not meant for run-time consumption: therefore throwing exceptions and runtime dispatch is out of the question. This means doing a set(&foo1) is better than saying insert(&foo1) because 'set' conveys better the concept which Boost.Overload is making as compared to 'insert'. See #1 as to why this is the case. Again, if you're looking for a container for runtime function objects, see Boost.Signals and the (other) library I'm working on, the Runtime Dynamic Dispatch Library. At best, you might want to consider an std::map<> of Boost.Function objects instead. I hope this makes things clearer. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]

On Fri, 12 Oct 2007 08:56:50 +0200, Marco Costalba <mcostalba@gmail.com> wrote:

On 10/12/07, Marco Costalba <mcostalba@gmail.com> wrote:

...

So I would say a _possible_ policy is to not allow to register say

set(f6);

if is already registered a function with a "compatible" signature.

This is wrong.

I would have said:

" a _possible_ policy is that a call like

f.set(f6);

overwrites any exsisting function with the same signature *or with a compatible signature*"

Not sure to have understood your question. Anyway this is the assignment policy followed by the latest version of my implementation: http://archives.free.net.ph/message/20071011.214216.2c194f99.en.html Let be "ov" an instantiation of the overload template class for a given set of signatures "ss" used as template arguments: - if the passed functor "f" is a free function or a member function then: - if "f" is not overloaded and its signature is included in "ss" then the new target (i.e. "f") overwrites the target related to the matching signature; - if the signature of "f" is not included in "ss" a compile time error is produced; - if "f" is overloaded an "unresolved overloaded function type" compile time error is produced; (we can't rely on the Mesonides' trick, or equivalent for free functions, because they require to know the function name in advance); this is the same behaviour followed by boost.function; note: when I say that a function member signature is included in "ss" I actually mean that the signature of it's `equivalent` free function is included in "ss"; - if the passed functor "f" is a function object (possibly overloaded or polymorfic) then: - let be "rs" the set of signatures that are defined by its overload resolution set (or it would be better to say "by the overload resolution set of f::operator()" ); note that for a polymorfic object function "rs" is an infinite set; - if the intersection between "rs" and "ss" is empty the assignment fails and a compile time error is produced; - if the intersection between "rs" and "ss" is not empty then the new target (i.e. "f") overwrites all the targets related to the signatures included in the intersection. I hope to have answered to your question. Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Sat, 13 Oct 2007 08:20:32 +0200, Marco Costalba <mcostalba@gmail.com> wrote:

On 10/12/07, Marco <mrcekets@gmail.com> wrote:

...

- if the intersection between "rs" and "ss" is not empty then the new target (i.e. "f") overwrites all the targets related to the signatures included in the intersection.

I hope to have answered to your question.

Yes thanks. I would have read the previous posted policy better.

My concern has more to do with a language corner than with overload 'per se'.

The whole point is that the 'comparison' used when adding a function to the overload set is different from the 'comparison' used when choosing among the function given a set of arguments, i.e. at call time.

In particular at registering time we (but also C++ compiler) uses perfect signature match to test a function signature against the others.

As example

class A { void foo(char); void foo(long); };

compiles because void(char) and void(long) are different function types. Also

void foo1(char); void foo2(long);

boost::overload<void(char), void(long)> ov;

ov.set(&foo1); ov.set(&foo2);

compiles the same.

But at call time matching between passed in arguments and function to call is done (in C++) not with "perfect type match" comparison but with "type match + implicit conversions" comparison.

That's the reason that instruction;

A a; a.foo(7); // compile error!

fails with message "ambiguous call, 2 candidates...", not with message 'I don't find a suitable foo()'

This ambiguity is, of course, intrinsically present also in 'overload' because registering is done on perfect signature matching, while at runtime class member overloading is used (i.e. implicit conversions are taken in account).

Please note that this is good! is what C++ does, the only difference is that with

a.foo(7);

a compile error is produced and user is warned about this ambiguity that he must resolve explicitly in some way.

I didn't know what, in the above case

ov(7);

should produce.

You catched exactly the point. :-) At call time boost::overload rules are the same followed by normal (member) function calls. There is no surprise for the user. What's better ? I want only to point out that there is nothing odd in the fact that C++ allows to define both:

void foo(char); void foo(long); because the compiler doesn't know if the call will be ambiguos or not, that is:

foo(7); // is ambiguos, but long l = 7; foo(l); // there is no ambiguity Problably you had already argued all that, but just to be sure :-)

Thanks Marco

You're welcome, good weekend, Marco

P.S: In case you are wondering "why didn't he tried?" is that I had some compiler error (probably SFINAE related) and didn't had the time to dig it more.

That sounds odd to me I used only partial template specialization and just one enable_if in all my code. What compiler are you using ? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Sat, 13 Oct 2007 16:38:36 +0200, Marco Costalba <mcostalba@gmail.com> wrote:

On 10/13/07, Marco <mrcekets@gmail.com> wrote:

...

...

P.S: In case you are wondering "why didn't he tried?" is that I had some compiler error (probably SFINAE related) and didn't had the time to dig it more.

That sounds odd to me I used only partial template specialization and just one enable_if in all my code. What compiler are you using ?

This is the compiler (under Windows):

gcc (GCC) 3.4.2 (mingw-special)

And this is the error log:

In file included from boost/overload/detail/overload_base.hpp:14, from boost/overload/overload_impl.hpp:12, from boost/overload/overload.hpp:18, from test.cpp:10: boost/overload/detail/final_overload_base.hpp:23: warning: converting of negative value `-0x000000001' to `unsigned int' In file included from test.cpp:21: boost/overload/overload_impl.hpp: In instantiation of `boost::overloads::overload<void ()(std::string, std::string, std::string), int ()(bar1*, char), double ()(const bar2*, int, char), char ()(std::string), int ()(char), double ()(int, char), boost::overloads::detail::no_signature, boost::overloads::detail::no_signature, boost::overloads::detail::no_signature, boost::overloads::detail::no_signature>': boost/overload/detail/trait_by_index.hpp:23: instantiated from `boost::overloads::detail::extent<test01::overload_type>' test/test_trait_by_index.hpp:11: instantiated from here boost/overload/overload_impl.hpp:47: error: incomplete type `boost::overloads::detail::extent<test01::overload_type>' used in nested name specifier In file included from test.cpp:23: boost/overload/detail/functor_has_signature.hpp: In instantiation of `boost::overloads::detail::func_obj_has_signature<f6_t, double ()(float, float), boost::overloads::detail::member_func_const_tag>': boost/overload/detail/functor_has_signature.hpp:107: instantiated from `boost::overloads::detail::functor_has_signature<f6_t, double ()(float, float), boost::detail::function::function_obj_tag>' test/test_trait_by_functor.hpp:12: instantiated from here boost/overload/detail/functor_has_signature.hpp:52: error: incomplete type `boost::overloads::detail::func_obj_has_signature_impl<double (foo6::*)(float, float) const>' used in nested name specifier boost/overload/detail/functor_has_signature.hpp: In instantiation of `boost::overloads::detail::func_obj_has_signature<f6_t, double ()(float, float), void>': boost/overload/detail/functor_has_signature.hpp:107: instantiated from `boost::overloads::detail::functor_has_signature<f6_t, double ()(float, float), boost::detail::function::function_obj_tag>' test/test_trait_by_functor.hpp:12: instantiated from here boost/overload/detail/functor_has_signature.hpp:42: error: incomplete type `boost::overloads::detail::func_obj_has_signature_impl<double (foo6::*)(float, float)>' used in nested name specifier

I didn't succeed in guessing what's wrong, I'll try to get the specific compiler and to perform a pool of tests.

It compiles and works flawlessy with gcc 4.2.2 under Linux.

Interesting enough the obviously "warnable" line in final_overload_base.hpp

static const unsigned int index = -1;

is warned only with gcc 3.4, not with the newer gcc 4.2 also if -pedantic is given.

Marco

Truly a strange behaviour. Anyway I changed -1 to UINT_MAX . Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Tue, 09 Oct 2007 16:45:29 +0200, Dean Michael Berris <mikhailberis@gmail.com> wrote:

...

Thanks for the advice. I registered to boost vault and uploaded my implementation to it. I thought that the boost vault was reserved to boost developers.

This is the link:

http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=overload-mrcec-20071009.zip&directory=&

Great! This should make it available to more people. :)

...

And thanks a lot for the documentation that you're writing. :-)

You're welcome. :)

(I'm also thinking of writing a bit more tests just to make sure it's covered pretty well, and if I get the time write some in-line documentation and perhaps split up the file into appropriate header files. There's also a recommended Boost library directory structure, and I'll try coming up with that as well.)

To the moderators on the list: I'm not sure how the subversion access works, but will it be alright if this library continues to get developed in the sandbox? Is there a specific process for that? And would this be a candidate for a mini-review once the appropriate documentation and "boostification" process gets done? Or would this merit a full review just like the other libraries that try to become part of the Boost C++ Library?

Well obviously the proposed and uploaded implementation needs still a lot of testing. About directory and namespace organization, this my point of view: in namespace boost::overloads::detail should be put all the helper functions and metafunctions in namespace boost::overloads the overload class and all the type information helper utilities ( has_signature<Sig, overload_type>, signature<N, overload_type>, extent<overload_type>, ...) then only the overload class is made available in the boost namespace through a using overloads::overload; directories/files: (1) boost/overload/overload.hpp with the source code belonging to namespace boost::overloads but not to namespace boost::overloads::detail (2) boost/overload/detail/overload.hpp with the source code belonging to namespace boost::overloads::detail only. These are just my speculations, I don't know if they fit with the boostification process, moreover we should take into account the possibility to include the new code straight into boost.function. But, IMO, this kind of decisions are up to boost moderators and the authors of boost.function. Regards, Marco Cecchetti -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/