Сообщение Re[5]: [trick] C++14 return unnamed structure от 13.10.2015 10:03
Изменено 13.10.2015 10:06 _hum_
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, _hum_, Вы писали:
BFE>>>Не знаю как вам, а мне часто хочется написать функцию возвращающую код ошибки осмысленным текстом:
BFE>>>
__>>А чем все-таки вас не устраивает первое решение?
BFE>Тем, что приходится объявлять enum или структуру с каким-то именем и это имя засоряет пространство имён. Как правило тип возвращаемого значения создаётся ровно для одной функции, тогда логично в качестве имени взять имя функции и добавить в конце слово Result, как в примере выше. Получается слишком длинно, но это ещё можно пережить. А представьте, что у вас в классе 5 методов возвращающих результат. Получается, что в классе объявляется пять enum'ов только для того, чтобы написать пять функций. Код начинает приобретать монструозный вид, особенно для inline методов в две-три строчки. У программиста читающего такой код начинают возникать вопросы к автору относительно его, автора, психического здоровья. Тогда предпринимаются объединить похожие типы результатов в один тип, что привносит в код путаницу на ровном месте. Например, вскоре оказывается, что хотя функция и возвращает в качестве результата некий enum, но, тем не менее, не все значения этого enum'а могут быть возвращены этой функцией, что в вызывающем коде порождает ещё большую путаницу — либо писать обработчик для значения, которое никогда не будет получено, либо заложится на знание устройства функции, что чревато проблемами при изменении функции...
То есть, речь о том, чтобы уметь делать что-то наподобие:
?
Если да (хотя автор изначально как-то не совсем то излагал), то согласен, полезная штука.
BFE>Здравствуйте, _hum_, Вы писали:
BFE>>>Не знаю как вам, а мне часто хочется написать функцию возвращающую код ошибки осмысленным текстом:
BFE>>>
BFE>>>enum class FunResult
BFE>>>{
BFE>>> Ok,
BFE>>> WrongFormat,
BFE>>> DeviceError
BFE>>>};
BFE>>>FunResult fun()
BFE>>>{
BFE>>> return FunResult::Ok;
BFE>>>}
BFE>>>__>>А чем все-таки вас не устраивает первое решение?
BFE>Тем, что приходится объявлять enum или структуру с каким-то именем и это имя засоряет пространство имён. Как правило тип возвращаемого значения создаётся ровно для одной функции, тогда логично в качестве имени взять имя функции и добавить в конце слово Result, как в примере выше. Получается слишком длинно, но это ещё можно пережить. А представьте, что у вас в классе 5 методов возвращающих результат. Получается, что в классе объявляется пять enum'ов только для того, чтобы написать пять функций. Код начинает приобретать монструозный вид, особенно для inline методов в две-три строчки. У программиста читающего такой код начинают возникать вопросы к автору относительно его, автора, психического здоровья. Тогда предпринимаются объединить похожие типы результатов в один тип, что привносит в код путаницу на ровном месте. Например, вскоре оказывается, что хотя функция и возвращает в качестве результата некий enum, но, тем не менее, не все значения этого enum'а могут быть возвращены этой функцией, что в вызывающем коде порождает ещё большую путаницу — либо писать обработчик для значения, которое никогда не будет получено, либо заложится на знание устройства функции, что чревато проблемами при изменении функции...
То есть, речь о том, чтобы уметь делать что-то наподобие:
auto fun()
{
enum class ResStatus
{
Ok,
WrongFormat,
DeviceError
};
//<...>
return ResStatus::Ok;
}
void main(void)
{
const fun::ResStatus res = f();
if(fun::ResStatus::ok == res)
{
//<...>
}
else
{
//<...>
};
}?
Если да (хотя автор изначально как-то не совсем то излагал), то согласен, полезная штука.
Re[5]: [trick] C++14 return unnamed structure
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, _hum_, Вы писали:
BFE>>>Не знаю как вам, а мне часто хочется написать функцию возвращающую код ошибки осмысленным текстом:
BFE>>>
__>>А чем все-таки вас не устраивает первое решение?
BFE>Тем, что приходится объявлять enum или структуру с каким-то именем и это имя засоряет пространство имён. Как правило тип возвращаемого значения создаётся ровно для одной функции, тогда логично в качестве имени взять имя функции и добавить в конце слово Result, как в примере выше. Получается слишком длинно, но это ещё можно пережить. А представьте, что у вас в классе 5 методов возвращающих результат. Получается, что в классе объявляется пять enum'ов только для того, чтобы написать пять функций. Код начинает приобретать монструозный вид, особенно для inline методов в две-три строчки. У программиста читающего такой код начинают возникать вопросы к автору относительно его, автора, психического здоровья. Тогда предпринимаются объединить похожие типы результатов в один тип, что привносит в код путаницу на ровном месте. Например, вскоре оказывается, что хотя функция и возвращает в качестве результата некий enum, но, тем не менее, не все значения этого enum'а могут быть возвращены этой функцией, что в вызывающем коде порождает ещё большую путаницу — либо писать обработчик для значения, которое никогда не будет получено, либо заложится на знание устройства функции, что чревато проблемами при изменении функции...
То есть, речь о том, чтобы уметь делать что-то наподобие:
?
Если да (хотя автор изначально как-то не совсем то излагал), то согласен, полезная штука.
p.s. а что в таких случаях будет с перегружаемыми функциями, наподобие auto f(); auto f(int i); ?
BFE>Здравствуйте, _hum_, Вы писали:
BFE>>>Не знаю как вам, а мне часто хочется написать функцию возвращающую код ошибки осмысленным текстом:
BFE>>>
BFE>>>enum class FunResult
BFE>>>{
BFE>>> Ok,
BFE>>> WrongFormat,
BFE>>> DeviceError
BFE>>>};
BFE>>>FunResult fun()
BFE>>>{
BFE>>> return FunResult::Ok;
BFE>>>}
BFE>>>__>>А чем все-таки вас не устраивает первое решение?
BFE>Тем, что приходится объявлять enum или структуру с каким-то именем и это имя засоряет пространство имён. Как правило тип возвращаемого значения создаётся ровно для одной функции, тогда логично в качестве имени взять имя функции и добавить в конце слово Result, как в примере выше. Получается слишком длинно, но это ещё можно пережить. А представьте, что у вас в классе 5 методов возвращающих результат. Получается, что в классе объявляется пять enum'ов только для того, чтобы написать пять функций. Код начинает приобретать монструозный вид, особенно для inline методов в две-три строчки. У программиста читающего такой код начинают возникать вопросы к автору относительно его, автора, психического здоровья. Тогда предпринимаются объединить похожие типы результатов в один тип, что привносит в код путаницу на ровном месте. Например, вскоре оказывается, что хотя функция и возвращает в качестве результата некий enum, но, тем не менее, не все значения этого enum'а могут быть возвращены этой функцией, что в вызывающем коде порождает ещё большую путаницу — либо писать обработчик для значения, которое никогда не будет получено, либо заложится на знание устройства функции, что чревато проблемами при изменении функции...
То есть, речь о том, чтобы уметь делать что-то наподобие:
auto fun()
{
enum class ResStatus
{
Ok,
WrongFormat,
DeviceError
};
//<...>
return ResStatus::Ok;
}
void main(void)
{
const fun::ResStatus res = f();
if(fun::ResStatus::ok == res)
{
//<...>
}
else
{
//<...>
};
}?
Если да (хотя автор изначально как-то не совсем то излагал), то согласен, полезная штука.
p.s. а что в таких случаях будет с перегружаемыми функциями, наподобие auto f(); auto f(int i); ?