Re: [sigc] libsigc++-2.0 functor and adaptor names
- From: martin-ml hippogriff de
- To: jcf tpg com au
- Cc: libsigc-list gnome org, gtkmm-list gnome org
- Subject: Re: [sigc] libsigc++-2.0 functor and adaptor names
- Date: Wed, 29 Oct 2003 17:30:22 +0100
Am 29.10.2003 um 13:13 Uhr schrieb Jeff Franks <jcf tpg com au>:
> Martin Schulze wrote:
>
> > Hi again!
> >
> > With the release of libsigc++-2.0 the names of our
> > functors and adaptors are settled for the near future.
> > So there should be consensus about these names.
> >
> > Currently, in libsigc++-1.9.11 the functions called
> > to create functors (replacing SigC::slot()) are named
> > as following:
> >
> > sigc::ptr_fun() (stores a function pointer)
> > sigc::mem_fun() (stores a member function pointer; optionally
> > together with a reference or pointer to an object instance)
> >
> > The functors returned (no equivalent in libsigc++-1.2) are called:
> >
> > sigc::pointer_functor#<>
> > sigc::[bound_][const_][volatile_]mem_functor#<>
> >
> > The generic container for arbitrary functors (equivalent but much
more
> > powerful than SigC::Slot#) is called:
> >
> > sigc::slot<>
> >
> >
> > The functions returning adaptors are named as following:
> >
> > sigc::bind<#>() (# being the position of the bound argument)
> > sigc::bind_return()
> > sigc::hide<#>() (# being the position of the argument to hide)
> > sigc::retype_return<T>() (T being the desired return type)
> > sigc::hide_return()
> > sigc::compose()
> > sigc::exception_catch()
> > sigc::group()
> >
> > The adaptors returned are called respectively:
> >
> > sigc::bind_functor<>
> > sigc::bind_return_functor<>
> > sigc::hide_functor<>
> > sigc::retype_return_functor<>
> > sigc::compose#_functor<> (# being the number of "getter"
functions)
> > sigc::exception_catch_functor<>
> > sigc::lambda_group#<> (# being the number of arguments passed
on)
> >
> >
> > The base types for functors / adaptors are called
> >
> > sigc::functor_base
> > sigc::adaptor_base
> >
> >
> > Return type deduction for user-defined functors can be influenced
> > by specializing a template named:
> >
> > sigc::deduce_result_type<>
> >
> >
> > Lambda selectors (placeholders for arguments) are called
> >
> > sigc::_# (# being the number of the argument)
> >
> >
> > Lambda actions are named (omitting the sigc:: prefix)
> > (The names are important in case of compiler errors and when
> > return type deduction must be influenced):
> >
> > arithmetic<{plus,minus,mutliply,devide,remainder}> (for
+,-,*,/,%)
> > bitwise<{leftshift,rightshift,and_,or_,xor_}> (for <<,>>,&,|,^)
> > logical<{and_,or_}> (for &&,||)
> >
> >
relational<{less,greater,lessorequal,greaterorequal,equal,notequal}>
> > (for <,>,<=,>=,==,!=)
> > arithmetic_assign<{plus,minus,multiply,divide,remainder}> (for
+=,-
> > =,*=,/=,%=)
> > bitwise_assign<{leftshift,rightshift,and_,or_,xor_}> (for
<<=,>>=,
> > &=,|=,^=)
> > other<{subscript,assign}> (for [],=)
> > unary_arithmetic<{preincrement,predecrement}> (for ++,--)
> > unary_bitwise<not_> (for ~)
> > unary_logical<not_> (for !)
> > unary_other<{address,dereference,}> (for &,*)
> > cast_<{reinterpret_,static_,dynamic_}> (for
reinterpret_cast<>(),
> > static_cast<>(), dynamic_cast<>())
> >
> >
> > The templates that needs to be specialized to influence return type
> > deduction for lambda actions are called:
> >
> > sigc::lambda_action_deduce_result_type<>
> > sigc::lambda_action_unary_deduce_result_type<>
> > sigc::lambda_action_convert_deduce_result_type<>
> >
> >
> > Has anybody read until here and got an opinion about one or more
names?
> >
> Looks OK to me, except for the long names:
>
> do_some_functor_names_have_to _be_so_long();
:-)
Well, what would you suggest? I think the nomenclature [creator
function name]_functor is the right way to do it. pointer_functor could
be named ptr_functor. But how do we shorten
bound_const_volatile_mem_functor so that it stays clear what it's meant
to be?
Note that the point where the functor names themselves become important
is the compiler errors the use might experience on wrong usage of the
API...
We won't use these names directly.
Regards,
Martin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]