upcoming Switch library review Jan 5th - Jan 9th

The review of the Switch library by Steven Watanabe will begin this
Saturday, Jan 5th.

Description:

The built in C/C++ switch statement is very efficient. Unfortunately,
unlike a chained if/else construct there is no easy way to use it when
the number of cases depends on a template parameter. The Switch
library addresses this issue.


You can download the library from the Boost Vault:
http://tinyurl.com/23qn7w

For convenience, the docs have been uploaded here:
http://tinyurl.com/2h6ut9

... and the source file here:
http://tinyurl.com/2cbfyk

If you are interested, please consider submitting a review of this
library.  I will send more detailed instructions on what to include in
the review on the 5th.

Regards,

Stjepan
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Stjepan Rajko wrote:
> If you are interested, please consider submitting a review of this
> library.  I will send more detailed instructions on what to include in
> the review on the 5th.

Can I jump the gun with with a few questions please?

Why is the fall through behaviour to throw an exception? This is not consistent with standard switch, possibly a motivation section is needed in the docs to explain this type of decision?

I'm not too clear with the documentation what the parameter 'n' can be? It is of type 'Int' which is described as being an Integer in the parameters section of the documentation. What does this mean, any built in integral type, can I switch on a std::string? What are the limitations? I got a bit lost here in the docs here, after admittedly only a quick read. Maybe just some clarification is required?

The parameter section does not specify the arities of the 2 function object parameters, I had to deduce them from the example. Why do these have to be function objects, and not just any callable type, including ordinary functions (using the Boost.ResultOf mechanism to sort out the return type)? I'm not sure how useful that would be for 'f', but for 'default_' a full blow function object seems a bit much typing, can't I just use a function.

Also, why is 'default_' unary, the default in a standard switch statement does not access the switch parameter, and the example does not exploit this feature either. Why not just a nullary function? Again some motivation might be nice.

And finally, as the introduction mentions the efficiency of the standard switch statement, could the docs show some performance stats for the library code for comparison?

Cheers

Dan




      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

dan marsden wrote:
> Why is the fall through behaviour to throw an exception?

I too tripped over this one, yesterday.

I think it shouldn't throw. If we want it to, we can use an approporiate
  function object.

The 'throw' statement (even if unreachable) can influence other
optimizations. Further, without throwing the semantics remain the same
if exceptions are disabled.

>
> I'm not too clear with the documentation what the parameter 'n' can be?

"MPL sequence of integer constants" and "equal to" are sorta fuzzy in
this context, too.

Maybe stating that the "[...] the public static member constants 'value'
[...] are used for the 'case' conditions" and that "'n' is used as the
argument to the 'switch' statement" (or so) works to improve the
specification.

> The parameter section does not specify the arities of the 2 function
> object parameters, I had to deduce them from the example. Why do these
> have to be function objects, and not just any callable type, including
> ordinary functions (using the Boost.ResultOf mechanism to sort out the
> return type)? I'm not sure how useful that would be for 'f', but for
> 'default_' a full blow function object seems a bit much typing, can't
> I just use a function.

I think "function object" is still the correct term even if you /can/
use a function pointer for the default: A pointer is an object and a
function pointer is a function object. A pointer to member function is
also Callable -- and we probably wouldn't want to support this case...

Of course there are no pointers to templates, so using a function
pointer for anything but the default is pretty pointless. So is trying
to handle varying result types -- maybe the result type should be passed
in with another template parameter?

> Also, why is 'default_' unary, the default in a standard switch
> statement does not access the switch parameter, and the example does
> not exploit this feature either. Why not just a nullary function?

I really like this feature a lot:

If you can't react to some case at compile time doesn't mean you can't
at runtime...

> Again some motivation might be nice.
>
> And finally, as the introduction mentions the efficiency of the
> standard switch statement, could the docs show some performance
> stats for the library code for comparison?
>

Yes, please!

Couldn't resist to throw some more Euro cents into the pot...


Regards,
Tobias

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

On Jan 2, 2008 2:36 PM, dan marsden <danmarsden@...> wrote:
> Stjepan Rajko wrote:
> > If you are interested, please consider submitting a review of this
> > library.  I will send more detailed instructions on what to include in
> > the review on the 5th.
>
> Can I jump the gun with with a few questions please?

Of course - thanks for opening up the discussion!  I'm just not sure
whether Steven will be able to respond until the review officially
starts.

Stjepan
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

AMDG

Tobias Schwinger <tschwinger <at> isonews2.com> writes:

> dan marsden wrote:
> > Why is the fall through behaviour to throw an exception?
>
> I too tripped over this one, yesterday.
>
> <snip>

The other option is an assertion.  Is that any better?
Or should a void return type be a special case?

> >
> > I'm not too clear with the documentation what the parameter 'n' can be?
>
> "MPL sequence of integer constants" and "equal to" are sorta fuzzy in
> this context, too.
>
> <snip>

OK.  I'll tighten this up.

> > The parameter section does not specify the arities of the 2 function
> > object parameters, I had to deduce them from the example.

I'll be more precise.

> > Why do these
> > have to be function objects, and not just any callable type, including
> > ordinary functions
> > <snip>

You can use a plain function for default_.

> I think "function object" is still the correct term even if you /can/
> use a function pointer for the default: A pointer is an object and a
> function pointer is a function object. A pointer to member function is
> also Callable -- and we probably wouldn't want to support this case...

Even if it's specified as Callable, it's ok
because void int::*() e.g. is illegal anyway.

> Of course there are no pointers to templates, so using a function
> pointer for anything but the default is pretty pointless. So is trying
> to handle varying result types -- maybe the result type should be passed
> in with another template parameter?

I'd rather leave it as result_of<F()>::type.

> > Also, why is 'default_' unary, the default in a standard switch
> > statement does not access the switch parameter, and the example does
> > not exploit this feature either. Why not just a nullary function?
>
> I really like this feature a lot:
>
> If you can't react to some case at compile time doesn't mean you can't
> at runtime...

Exactly.

> > And finally, as the introduction mentions the efficiency of the
> > standard switch statement, could the docs show some performance
> > stats for the library code for comparison?
> >
>
> Yes, please!

Will do.

In Christ,
Steven Watanabe


_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Steven Watanabe wrote:
> AMDG
>
> Tobias Schwinger <tschwinger <at> isonews2.com> writes:
>
>> dan marsden wrote:
>>> Why is the fall through behaviour to throw an exception?
>> I too tripped over this one, yesterday.
>>
>> <snip>

> The other option is an assertion.  Is that any better?

I think the "default default behavior" should be to use the default
constructor. This approach works nice with Any, Variant and Optional.

> Or should a void return type be a special case?

If 'Default's result type is 'void' although something else is expected,
we should assert it never actually returns at runtime (note that it is
possible to detect the result type with an overloaded comma operator and
without requiring 'Default' to work with 'result_of' -- might also be
faster). If assertions are disabled the behavior should be unspecified
in that case.

<snip>

>> Of course there are no pointers to templates, so using a function
>> pointer for anything but the default is pretty pointless. So is trying
>> to handle varying result types -- maybe the result type should be passed
>> in with another template parameter?
>
> I'd rather leave it as result_of<F()>::type.

Actually 'result_of<F()>::type' determines the result of the nullary
call to F. I don't think I like this sort of "result_of abuse"... The
correct usage would be 'result_of<F(MPLConstant)>::type' but it's
pointless since 'MPLConstant' varies and so may the whole type expression.

So, if you insist on deducing the result type from the function object
(instead of having it specified explicitly) my vote is 'F::result_type',
however, I still find another template parameter more appropriate for
the following good reasons:

o The function object can work fine with result_of in a non-'switch_'
   context. The cases can return different things as long as they are
   convertible to the result of 'switch_', and

o there is no way to determine this type with 'result_of.


Regards,
Tobias

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

On Jan 6, 2008 7:34 AM, Tobias Schwinger <tschwinger@...> wrote:
The current implementation seems to use result_type - is it planned to
change to use result_of?

I agree that result_of<F()>::type is slightly abusive, since that's
not what actually gets called.  Would using
result_of<F(boost::mpl::front<Cases>::type)> be an option for a
non-empty case sequence?  As long as the order of the cases doesn't
matter (btw, does it?), the user could put the desired type in the
front of the Cases sequence if the return type differs for different
MPLConstant types.

Stjepan
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Stjepan Rajko wrote:
Actually, the latter is more severe...

>
> The current implementation seems to use result_type - is it planned to
> change to use result_of?
>
> I agree that result_of<F()>::type is slightly abusive, since that's
> not what actually gets called.  

> Would using
> result_of<F(boost::mpl::front<Cases>::type)> be an option for a
> non-empty case sequence?  

I think it's too complicated: We can't use 'result_of' to determine the
result of 'switch_', so it should be as simple to determine as possible
(ideally without deduction at all).

> As long as the order of the cases doesn't
> matter (btw, does it?), the user could put the desired type in the
> front of the Cases sequence if the return type differs for different
> MPLConstant types.

Further, we still need a special-engineered function object; one of the
cases will have a special role. It might work, but it feels inelegant to
me: The function object's result type should be convertible to whatever
'switch_' wants to return.

So what will deducing that type from the function object buy us?

The only answer I can currently see is "nothing but trouble" :-). Please
tell me if I'm missing something.


Regards,
Tobias


_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

On Jan 6, 2008 12:20 PM, Tobias Schwinger <tschwinger@...> wrote:
> Stjepan Rajko wrote:
> > Would using
> > result_of<F(boost::mpl::front<Cases>::type)> be an option for a
> > non-empty case sequence?
>
> I think it's too complicated: We can't use 'result_of' to determine the
> result of 'switch_', so it should be as simple to determine as possible
> (ideally without deduction at all).
>

Sure - although the library could offer something along the lines of
result_of::switch.

I agree that being able to specify the return type explicitly would be
very useful, precisely because you could use function objects that are
not result_of/result_type compatible, or override the return type even
if one is specified by the function object. I can see overriding it to
boost::any or some other "common denominator" as a frequent use case.

> So what will deducing that type from the function object buy us?
>
> The only answer I can currently see is "nothing but trouble" :-). Please
> tell me if I'm missing something.
>

>From what I can see, it buys simplicity when the use case is not
complicated (the return type is available through result_type or
result_of and does not change), or when you really want to leave it to
the function object to specify what the return type should be.
Granted, all of the proposed solutions for return type deduction seem
slightly imperfect / inelegant, but as long as the behavior is clearly
explained in the documentation they could be useful.

Regards,

Stjepan
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Tobias Schwinger wrote:
> Stjepan Rajko wrote:

I haven't been following the review (yet, though I'll be in the next
few days) and I haven't read the docs yet. But from intuition, having
implemented at least 2 switch implementations (spirit and phoenix),
I'm guessing that there are N functions with N return types, right?
If so, it follows (to my mind) that the result should be a boost::variant
of all the possible return types given the arguments (through
application of result_of to all the functions).

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Joel de Guzman wrote:
What are we going to do with that Variant? Switch again and go back
where we're coming from? It might but isn't necessarily what we want.

Now in order to get our Variant we have to
o  check result_of<Fn(arg)>::type for every function,
o  figure out unique types, and
o  make a variant from them, possibly handling special cases like using
Boost.Optional or the bare type where more appropriate.

It's surely useful for certain use cases but takes a lot of template
instantiations, so I think it should be an extra metafunction.


Regards,
Tobias

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Tobias Schwinger wrote:
Use the variant visitor. That may amount to the same thing, but
in this case, we have a value, not a function that returns a value.

> It might but isn't necessarily what we want.

Why not?

> Now in order to get our Variant we have to
> o  check result_of<Fn(arg)>::type for every function,
> o  figure out unique types, and
> o  make a variant from them, possibly handling special cases like using
> Boost.Optional or the bare type where more appropriate.
>
> It's surely useful for certain use cases but takes a lot of template
> instantiations, so I think it should be an extra metafunction.

Sorry, perhaps I missed the "extra metafunction" solution.
What is it again?

Anyway, you have good points. Yes, an explicitly specified return
type would be ok too. In the standpoint of optimization, yes, a
variant return is suboptimal at both compile time and at runtime.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Joel de Guzman wrote:
Because we're just coming from inside the switch and if we wanted to do
something conditionally we could have done it there. Variant, Any,
Optional or some non-union type can all make sense, depending on what
we're up to.

Ooops -- the English word "extra" might not work quite the way I
expected (see below for clarification).

>
> Anyway, you have good points. Yes, an explicitly specified return
> type would be ok too. In the standpoint of optimization, yes, a
> variant return is suboptimal at both compile time and at runtime.

Exactly. The mechanism you propose could still be useful and provided by
the library as a utilty metafunction (which is what I was trying to say
with "should be an extra metafunction" :-)).


Regards,
Tobias

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Tobias Schwinger wrote:
> Joel de Guzman wrote:

>> Anyway, you have good points. Yes, an explicitly specified return
>> type would be ok too. In the standpoint of optimization, yes, a
>> variant return is suboptimal at both compile time and at runtime.
>
> Exactly. The mechanism you propose could still be useful and provided by
> the library as a utilty metafunction (which is what I was trying to say
> with "should be an extra metafunction" :-)).

Agreed 100%

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Tobias Schwinger wrote:
> Joel de Guzman wrote:

This is not always the case. Many times, you don't supply
the functions or have control over them. That's specially true
if you are a library writer, you know that ;-)

Anyway, I agree with you, not in the standpoint of what is
a better API, but in the standpoint of practicality. Many
languages do switch the /variant/ way. But in our case, the
variant will indeed be a burden that might not be needed. So,
I am for "you pay only for what you need".

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users