Групы Малюнкі Пераклад Каталёг Сеціва
Недавно посещенные группы | Справка | Вход
Главная страница Google Groups
Сообщение из обсуждения upcoming Switch library review Jan 5th - Jan 9th
Сообщение будет отправлено в группу Usenet. Когда Вы отправляете сообщения в такие группы, Ваш адрес электронной почты публикуется в Интернете.
Ваш ответ не был отправлен.
Сообщение отправлено успешно.
 
Автор:
Кому:
Копия:
В ответ на:
Добавить копию | Добавить заголовок "В ответ на" | Изменить тему
Тема:
Утверждение:
Для подтверждения введите символы, изображенные на картинке ниже, или цифры, которые вы услышите, нажав на значок упрощенного доступа. Слушайте и вводите услышанные числа
 
Tobias Schwinger  
Просмотреть профиль   Перевести на Переведено (просмотреть оригинал)
 Дополнительные параметры 6 янв 2008, 02:26
Автор: Tobias Schwinger <tschwin...@isonews2.com>
Дата: Sun, 06 Jan 2008 01:26:07 +0100
Местное время: Вс. 6 янв 2008 02:26
Тема: Re: [Boost-users] upcoming Switch library review Jan 5th - Jan 9th

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-us...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users


    Переслать  
Чтобы отправлять сообщения, сначала необходимо Войти.
Чтобы отправлять сообщения, сначала необходимо присоединиться к группе.
Перед отправкой сообщения обновите свой псевдоним на странице Настройки подписки.
У вас нет разрешения на отправку сообщений.

Создать группу - Группы Google - Главная страница Google - Условия предоставления услуг - Политика конфиденциальности
©2010 Google