Сообщение Re[10]: [trick] C++14 return unnamed structure от 12.10.2015 17:27
Изменено 12.10.2015 17:29 Went
Здравствуйте, B0FEE664, Вы писали:
W>>1. Кишки функции наружу.
BFE>В каком смысле? То, что определение описано внутри функции, а не снаружи? А typedef key key_type; у std::map — это кишки класса наружу? Нет? Почему?
Нет, в том смысле, что я не могу реализовать функцию отдельно от декларации.
W>>2. Невозможность использовать этот тип где либо еще, объявлять его явно.
BFE>Это плюс, а не минус. Это не позволит перепутать результат функции с чем-то ещё.
Кому не позволит? Разработчику библиотеки?
W>>3. Необходимость лезть в реализацию функции для поиска ее возврата.
BFE>С кодами int, bool или "не дай бог" errno() легче что-ли?
Я хотя бы знаю, что эта функция возвращает, глянув только на ее заголовок.
W>>Лучше определить структуру явно в заголовке класса.
BFE>Не легче. Это сильно засоряет scope класса бессмысленными типами имеющими отношение только к конкретным функциям.
А засорять scope обрамляющего пространства имен классами, необходимыми для реализаций этих функций, не жалко? Смотрите пункт 1 — "кишки наружу". Или я что-то не понял в задумке?
BFE>Например, функция std::stod вместо бросания исключения могла бы возвращать результат, код конвертации и указатель на константную строку с описанием ошибки.
И вместо
Писать
?
Ведь сейчас никто не мешает так делать. Заведи шаблон со всеми требуемыми полями и пиши себе:
Почему так никто не делает?
W>>1. Кишки функции наружу.
BFE>В каком смысле? То, что определение описано внутри функции, а не снаружи? А typedef key key_type; у std::map — это кишки класса наружу? Нет? Почему?
Нет, в том смысле, что я не могу реализовать функцию отдельно от декларации.
W>>2. Невозможность использовать этот тип где либо еще, объявлять его явно.
BFE>Это плюс, а не минус. Это не позволит перепутать результат функции с чем-то ещё.
Кому не позволит? Разработчику библиотеки?
W>>3. Необходимость лезть в реализацию функции для поиска ее возврата.
BFE>С кодами int, bool или "не дай бог" errno() легче что-ли?
Я хотя бы знаю, что эта функция возвращает, глянув только на ее заголовок.
W>>Лучше определить структуру явно в заголовке класса.
BFE>Не легче. Это сильно засоряет scope класса бессмысленными типами имеющими отношение только к конкретным функциям.
А засорять scope обрамляющего пространства имен классами, необходимыми для реализаций этих функций, не жалко? Смотрите пункт 1 — "кишки наружу". Или я что-то не понял в задумке?
BFE>Например, функция std::stod вместо бросания исключения могла бы возвращать результат, код конвертации и указатель на константную строку с описанием ошибки.
И вместо
auto number = std::stod("10.0");Писать
auto number = std::stod("10.0").result;?
Ведь сейчас никто не мешает так делать. Заведи шаблон со всеми требуемыми полями и пиши себе:
namespace std {
format_result<double> stod(const std::string&)
{
return ...;
}
}Почему так никто не делает?
Re[10]: [trick] C++14 return unnamed structure
Здравствуйте, B0FEE664, Вы писали:
W>>1. Кишки функции наружу.
BFE>В каком смысле? То, что определение описано внутри функции, а не снаружи? А typedef key key_type; у std::map — это кишки класса наружу? Нет? Почему?
Нет, в том смысле, что я не могу реализовать функцию отдельно от декларации.
W>>2. Невозможность использовать этот тип где либо еще, объявлять его явно.
BFE>Это плюс, а не минус. Это не позволит перепутать результат функции с чем-то ещё.
Кому не позволит? Разработчику библиотеки?
W>>3. Необходимость лезть в реализацию функции для поиска ее возврата.
BFE>С кодами int, bool или "не дай бог" errno() легче что-ли?
Я хотя бы знаю, что эта функция возвращает, глянув только на ее заголовок.
W>>Лучше определить структуру явно в заголовке класса.
BFE>Не легче. Это сильно засоряет scope класса бессмысленными типами имеющими отношение только к конкретным функциям.
А засорять scope обрамляющего пространства имен классами, необходимыми для реализаций этих функций, не жалко? Смотрите пункт 1 — "кишки наружу". Или я что-то не понял в задумке?
BFE>Например, функция std::stod вместо бросания исключения могла бы возвращать результат, код конвертации и указатель на константную строку с описанием ошибки.
И вместо
Писать
?
Ведь сейчас никто не мешает так делать. Заведи шаблон со всеми требуемыми полями и пиши себе:
Почему так никто не делает?
W>>1. Кишки функции наружу.
BFE>В каком смысле? То, что определение описано внутри функции, а не снаружи? А typedef key key_type; у std::map — это кишки класса наружу? Нет? Почему?
Нет, в том смысле, что я не могу реализовать функцию отдельно от декларации.
W>>2. Невозможность использовать этот тип где либо еще, объявлять его явно.
BFE>Это плюс, а не минус. Это не позволит перепутать результат функции с чем-то ещё.
Кому не позволит? Разработчику библиотеки?
W>>3. Необходимость лезть в реализацию функции для поиска ее возврата.
BFE>С кодами int, bool или "не дай бог" errno() легче что-ли?
Я хотя бы знаю, что эта функция возвращает, глянув только на ее заголовок.
W>>Лучше определить структуру явно в заголовке класса.
BFE>Не легче. Это сильно засоряет scope класса бессмысленными типами имеющими отношение только к конкретным функциям.
А засорять scope обрамляющего пространства имен классами, необходимыми для реализаций этих функций, не жалко? Смотрите пункт 1 — "кишки наружу". Или я что-то не понял в задумке?
BFE>Например, функция std::stod вместо бросания исключения могла бы возвращать результат, код конвертации и указатель на константную строку с описанием ошибки.
И вместо
auto number = std::stod("10.0");Писать
auto number = std::stod("10.0").result;?
Ведь сейчас никто не мешает так делать. Заведи шаблон со всеми требуемыми полями и пиши себе:
namespace std {
format_result<double> stod(const string&)
{
return ...;
}
}Почему так никто не делает?