Re[13]: [trick] C++14 return unnamed structure - C/C++

Здравствуйте, Went, Вы писали:

EP>>Не пойму, то есть ты за то чтобы в этом случае auto вообще не использовать? Тогда это ортогонально struct vs tuple.
W>...
W>Если же это какое-то значимое данное, состав которого неочевидным образом определяется на момент компиляции тела функции, то без статической рефлексии или замены на туплы, мы просто не будем знать что с ней делать дальше.

Такая возможность появляется когда мы используем вывод типов в любом виде, не только при возврате значения, но и обычное auto или шаблоны функций.
Либо взять те же языки с динамической типизацией — там возвращаемый тип не виден если не лезть в документацию или в рефлексию, но ведь их используют без проблем.

Да даже без вывода типов такая ситуация возможна — сделали статическую трансформацию одной структуры данных в другую, например через Boost.Fusion. Например преобразовали массив структур в структуру массивов — без документации или кода нельзя определить какие поля/методы доступны.

В целом же согласен, не нужно прятать структуру во внутрь функции при каждом подернувшимся случае. Где-то это оправданно, а где-то нет.

Здравствуйте, Erop, Вы писали:

EP>>А такая функция и будет в header, так как результирующий тип выводится.
E>Ну так надо будет ботать код функции, что бы понять чего от ней ждать...

Или в документацию, так же как и в случае с кортежем, также как и в случае с динамически типизированными языками.

E>В чём профит?

Например это как минимум лучше выглядит на стороне пользователя чем при возвращении безликого кортежа.
Почему вообще возвращают кортежи (не считая TemplateMP, и случаев где действительно имеет место набор безликих значений) — другой вопрос.

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, _hum_, Вы писали:

__>>Однако, как в дальнейшем выяснилось, мой вариант невозможен, ибо идентификация области видимости функции по ее имени не уникальна. А изначальный вариант (и ваш его повторяющий) плох тем, что за пределами функции приходится работать с анонимным типом. Соответственно, например, нельзя просто заранее организовать контейнеры для хранения результатов вычислений функции, не говоря уже о том, что читабельность такого варианта плохая.

_NN>Ну так на то и анонимные типы.
_NN>Нужно больше, нужно создавать именованный тип.

_NN>Очень редкая ситуация когда один тип ограничен одной функцией.

да вот и речь о том, что этот редкий случай очень часто встречается — тип кода возврата функции в общем случае специфичный для каждой конкретной функции, и не имеет смысла его использовать отдельно от нее

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:

__>>То есть, речь о том, чтобы уметь делать что-то наподобие:
__>>

__>>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); ?

E>А что мешает делать как-то так:

E>struct fun {
E>    enum ResultStatus { 
E>        Ok,
E>        WrongFormat,
E>        DeviceError };

E>        static ResultStatuc Call();


E>};

1) вызов будет fun::Call(); // а не классический fun();
2) с релизацией такого подхода для метода класса возникнут трудности
3) громоздко

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, Erop, Вы писали:

E>>В чём профит?

EP>Например это как минимум лучше выглядит на стороне пользователя чем при возвращении безликого кортежа.
EP>Почему вообще возвращают кортежи (не считая TemplateMP, и случаев где действительно имеет место набор безликих значений) — другой вопрос.
речь же вроде шла о выборе между "засовыванием определения типа в функцию" (и, соответственно, необходимости в этом коде рыться) и "классикой" — использовать независмое определение типа вне тела функции, а не между specific-именоваными и неименоваными компонентами возвращаемых функцией значений.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, Went, Вы писали:

EP>>>Не пойму, то есть ты за то чтобы в этом случае auto вообще не использовать? Тогда это ортогонально struct vs tuple.
W>>...
W>>Если же это какое-то значимое данное, состав которого неочевидным образом определяется на момент компиляции тела функции, то без статической рефлексии или замены на туплы, мы просто не будем знать что с ней делать дальше.

EP>Такая возможность появляется когда мы используем вывод типов в любом виде, не только при возврате значения, но и обычное auto или шаблоны функций.
EP>Либо взять те же языки с динамической типизацией — там возвращаемый тип не виден если не лезть в документацию или в рефлексию, но ведь их используют без проблем.

точно без проблем?

ведь известно же: динамические vs статические языки = гибкость vs надежность/безопасность

Здравствуйте, _hum_, Вы писали:

__>1) вызов будет fun::Call(); // а не классический fun();
Ну, зато можно несколько функций сделать при нужде, перегрузками управлять опять же.
Можно, кстати, не struct, а namespace, тогда не надо будет static писать...

__>2) с релизацией такого подхода для метода класса возникнут трудности
Зачем это методам я совсем не понимаю.

__>3) громоздко
что конкретно? То, что надо fun::call писать?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:

__>>1) вызов будет fun::Call(); // а не классический fun();
E>Ну, зато можно несколько функций сделать при нужде, перегрузками управлять опять же.
E>Можно, кстати, не struct, а namespace, тогда не надо будет static писать...

да уж лучше тогда

__>

__>struct f
__>{  
__>    enum class Res{ok, failed}; 

__>    Res operator()(){return Res::ok;}
__>};
__>

__>для которого можно
__>

__>void main()
__>{
__>    list<f::Res> ResLog;

__>    for(int i = 0; i < 100; ++i)
__>    {
__>         f::Res res = f()();// а хотелось бы f()

__>         ResLog.push_back(res);
__>    };    
__>}
__>

__>>2) с релизацией такого подхода для метода класса возникнут трудности
E>Зачем это методам я совсем не понимаю.

а чем методы хуже? им что не надо возвращать коды ошибок?

__>>3) громоздко
E>что конкретно? То, что надо fun::call писать?

нет, писать struct-ы обертки, чтобы реализовать нужный функционал

Здравствуйте, _hum_, Вы писали:

EP>>Либо взять те же языки с динамической типизацией — там возвращаемый тип не виден если не лезть в документацию или в рефлексию, но ведь их используют без проблем.
__>точно без проблем?

ведь известно же: динамические vs статические языки = гибкость vs надежность/безопасность

Это ортогонально дискуссии — в нашем случае есть статические проверки.

Здравствуйте, _hum_, Вы писали:

E>>>В чём профит?

EP>>Например это как минимум лучше выглядит на стороне пользователя чем при возвращении безликого кортежа.
EP>>Почему вообще возвращают кортежи (не считая TemplateMP, и случаев где действительно имеет место набор безликих значений) — другой вопрос.
__>речь же вроде шла о выборе между "засовыванием определения типа в функцию" (и, соответственно, необходимости в этом коде рыться) и "классикой" — использовать независмое определение типа вне тела функции, а не между specific-именоваными и неименоваными компонентами возвращаемых функцией значений.

Я к тому что кортежи используют в том числе в случаях, когда по какой-то причине не хотят выходить за пределы области функции и объявлять что-то вне её. Сейчас в этом же ключе могут использовать локальные структуры.

Здравствуйте, Erop, Вы писали:

E>А что мешает делать как-то так:

E>struct fun {
E>    enum ResultStatus { 
E>        Ok,
E>        WrongFormat,
E>        DeviceError };

E>        static ResultStatuc Call();
E>};

У незнакомых с паттерном, такая конструкция вызывает желание дописать, например, функцию Call с параметром:

struct fun
{
    enum ResultStatus { 
        Ok,
        WrongFormat,
        DeviceError };

        static ResultStatuc Call();
        static ResultStatuc Call(int count);
};

В результате имеем необоснованное ре-использование ResultStatus.

Здравствуйте, _hum_, Вы писали:

__>да уж лучше тогда

__>>

__>>struct f
__>>{  
__>>    enum class Res{ok, failed}; 

__>>    Res operator()(){return Res::ok;}
__>>};
__>>

Если таки это больше нравится, то можно и так. Мне это меньше нравится. Например нельзя взять указатель на функцию...
Я бы вообще namespace использовал, а struct тока если в шаблон какой-то передать надо...

E>>Зачем это методам я совсем не понимаю.

__>а чем методы хуже? им что не надо возвращать коды ошибок?

Ну можно же и так писать

enum FunResult { ... };
FunResult fun(...

Для функйий не очень, так как пространство имён забивается, но в нормальных классах таки обычно не так уж много имён...

__>>>3) громоздко
E>>что конкретно? То, что надо fun::call писать?

__>нет, писать struct-ы обертки, чтобы реализовать нужный функционал

если честно не понимаю, чем auto fun() так уж сильно отличается... слово auto короче?

или в чём фишка?

Здравствуйте, B0FEE664, Вы писали:

BFE>У незнакомых с паттерном, такая конструкция вызывает желание дописать, например, функцию Call с параметром:
BFE>

BFE>struct fun
BFE>{
BFE>    enum ResultStatus { 
BFE>        Ok,
BFE>        WrongFormat,
BFE>        DeviceError };

BFE>        static ResultStatuc Call();
BFE>        static ResultStatuc Call(int count);
BFE>};
BFE>

BFE>В результате имеем необоснованное ре-использование ResultStatus.

А почему необоснованное?
Мало того, то, что перегрузки совпадают по типу результат, наоборот хорошо как бы...

Здравствуйте, Erop, Вы писали:

BFE>>У незнакомых с паттерном, такая конструкция вызывает желание дописать, например, функцию Call с параметром:
BFE>>

BFE>>struct fun
BFE>>{
BFE>>    enum ResultStatus { 
BFE>>        Ok,
BFE>>        WrongFormat,
BFE>>        DeviceError };

BFE>>        static ResultStatuc Call();
BFE>>        static ResultStatuc Call(int count);
BFE>>};
BFE>>

BFE>>В результате имеем необоснованное ре-использование ResultStatus.

E>А почему необоснованное?
E>Мало того, то, что перегрузки совпадают по типу результат, наоборот хорошо как бы...

Потому, что ResultStatus для Call() и Call(int) скорее всего должен быть разный. Например, для Call(int), возможно, надо добавить ResultStatus::WrongCounter с теми же последствиями, что я описал выше.

Здравствуйте, B0FEE664, Вы писали:

BFE>Потому, что ResultStatus для Call() и Call(int) скорее всего должен быть разный. Например, для Call(int), возможно, надо добавить ResultStatus::WrongCounter с теми же последствиями, что я описал выше.

IMHO, так делать плохо. Перегруженные функции должны иметь ОДИНАКОВУЮ семантику. Иначе клиентский код превращается в ребус под названием "что он позвал в этом месте???)

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:

__>>да уж лучше тогда

__>>>

__>>>struct f
__>>>{  
__>>>    enum class Res{ok, failed}; 

__>>>    Res operator()(){return Res::ok;}
__>>>};
__>>>

E>Если таки это больше нравится, то можно и так. Мне это меньше нравится. Например нельзя взять указатель на функцию...
E>Я бы вообще namespace использовал, а struct тока если в шаблон какой-то передать надо...

nаmespace нельзя объявлять внутри класса, а значит, использовать их для методов и статических функций вы не сможете.( да и, имхо, чуждая это языку программирования вещь, а потому, использовать ее надо по минимуму.)

E>>>Зачем это методам я совсем не понимаю.

__>>а чем методы хуже? им что не надо возвращать коды ошибок?

E>Ну можно же и так писать

enum FunResult { ... };
E>FunResult fun(...

E>Для функйий не очень, так как пространство имён забивается, но в нормальных классах таки обычно не так уж много имён...

в системном программировании это сплошь и рядом — когда у каждого метода свой тип возвращаемого кода, и этих методов туева куча.

__>>>>3) громоздко
E>>>что конкретно? То, что надо fun::call писать? если честно не понимаю, чем auto fun() так уж сильно отличается... слово auto короче?

или в чём фишка?

прежде, чем это писать, надо еще и ручками поработать-понабирать обертки для соответствующих функций. и что хуже всего — эти обертки сопровождаются появлением дополнительного уровня вложенности, а значит, усложняют чтение. сравните:

class CFoo
{
  static
  auto fun()
  {  
     enum class Res{ok, failed};
     //<....>
     return res;
  }
};

class CFoo
{
  struct fun 
  {
     enum class Res{ok, failed};
     static 
     Res Call()
     {
        //<....>
        return res;
     }
  };
};

а если у вас еще и вложенные классы, то может стать просто нечитаемо.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:

EP>>>Либо взять те же языки с динамической типизацией — там возвращаемый тип не виден если не лезть в документацию или в рефлексию, но ведь их используют без проблем.
__>>точно без проблем?

ведь известно же: динамические vs статические языки = гибкость vs надежность/безопасность

EP>Это ортогонально дискуссии — в нашем случае есть статические проверки.

это если падение надежности и безопасности связано только с отсутствием проверки на этапе компиляции, и не связано с ростом количества семантических ошибок самого программиста, пишущего на динамическом языке

Здравствуйте, _hum_, Вы писали:

EP>>>>Либо взять те же языки с динамической типизацией — там возвращаемый тип не виден если не лезть в документацию или в рефлексию, но ведь их используют без проблем.
__>>>точно без проблем?

ведь известно же: динамические vs статические языки = гибкость vs надежность/безопасность
EP>>Это ортогонально дискуссии — в нашем случае есть статические проверки.
__>это если падение надежности и безопасности связано только с отсутствием проверки на этапе компиляции, и не связано с ростом количества семантических ошибок самого программиста, пишущего на динамическом языке

А что конкретно тогда в динамическом языке такого, что выливается в большее количество ошибок?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:

EP>>>>>Либо взять те же языки с динамической типизацией — там возвращаемый тип не виден если не лезть в документацию или в рефлексию, но ведь их используют без проблем.
__>>>>точно без проблем?

ведь известно же: динамические vs статические языки = гибкость vs надежность/безопасность
EP>>>Это ортогонально дискуссии — в нашем случае есть статические проверки.
__>>это если падение надежности и безопасности связано только с отсутствием проверки на этапе компиляции, и не связано с ростом количества семантических ошибок самого программиста, пишущего на динамическом языке

EP>А что конкретно тогда в динамическом языке такого, что выливается в большее количество ошибок?

ну, как минимум, зависимость от контекста. программисту сложно отслеживать такие вещи на этапе написания программы, а значит, вероятность того, что он что-то неверно понял или не предусмотрел — выше.

	От:	Evgeny.Panasyuk
	Дата:	14.10.15 19:26
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	14.10.15 19:36
	Оценка:

	От:	_hum_
	Дата:	15.10.15 13:37
	Оценка:

	От:	_hum_
	Дата:	15.10.15 13:41
	Оценка:

	От:	_hum_
	Дата:	15.10.15 13:47
	Оценка:

	От:	B0FEE664
	Дата:	16.10.15 08:45
	Оценка:

	От:	Erop
	Дата:	16.10.15 09:25
	Оценка: