Значит ли это, что я излишне усложняю? Ну ладно, черт с ним, с этим примером, но в сравнении я нашел, что вот мне больше свойствен такой образ мыслей.
Надо ли "лечиться"?
Здравствуйте, dmitry_npi, Вы писали:
_>Здравствуйте! _>Для перевода из радиан в градусы и обратно я написал такой код: _>
_>// перевод из радиан в градусы и обратно
_>template<class RealType>
_>inline RealType RadToGr(RealType rad)
_>{
_> return rad*(RealType)(180/M_PI);
_>}
_>template<class RealType>
_>inline RealType GrToRad(RealType grad)
_>{
_> return grad*(RealType)(M_PI/180);
_>}
_>
_>Значит ли это, что я излишне усложняю? Ну ладно, черт с ним, с этим примером, но в сравнении я нашел, что вот мне больше свойствен такой образ мыслей. _>Надо ли "лечиться"?
Если у вас в программе используются типы, отличные от double, то не нужно. Если же вы используете только double, то нужно быть проще -- достаточно нешаблонной inline-функции. Но не настолько просто, как у вашего старшего товарища.
Кроме того, совсем кошерно было бы так:
return grad * static_cast< RealType >( M_PI/180 );
поскольку приведения в стиле C -- опасная штука.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если у вас в программе используются типы, отличные от double, то не нужно. Если же вы используете только double, то нужно быть проще -- достаточно нешаблонной inline-функции. Но не настолько просто, как у вашего старшего товарища.
E>Кроме того, совсем кошерно было бы так: E>
E>return grad * static_cast< RealType >( M_PI/180 );
E>
E>поскольку приведения в стиле C -- опасная штука.
А для кошерности по самое не могу, можно еще ввести отдельные типы для градусов и радианов (с соответствующими преобразованиями).
После этого автор топика поймет, что первоначальный вариант усложнением не являлся
_>Значит ли это, что я излишне усложняю? Ну ладно, черт с ним, с этим примером, но в сравнении я нашел, что вот мне больше свойствен такой образ мыслей. _>Надо ли "лечиться"?
1. Что будет, если вызвать так:
const double some_rad_val = GrToRad(4);
?
2. Я сам также люблю всё усложнять и стараюсь отучаться от этого. Имхо одним из самых важных критериев использования шаблонов — значительное сокращение кода (обычно за счёт применения к разным типам). В приведённом примере такого сокращения нет.
ЗЫ. Это совсем не значит, что шаблоны не нужно использовать в принципе, они позволяют существенно облегчить жизнь, но важно научиться правильно их готовить.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
A>А для кошерности по самое не могу, можно еще ввести отдельные типы для градусов и радианов (с соответствующими преобразованиями). A>После этого автор топика поймет, что первоначальный вариант усложнением не являлся
Именно. Но тут мы получим не усложнение, а упрощение, если такое преобразование встречается в коде многократно.
Здравствуйте, Alxndr, Вы писали:
A>А для кошерности по самое не могу, можно еще ввести отдельные типы для градусов и радианов (с соответствующими преобразованиями).
Это вы отвечаете на какой-то другой вопрос.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, minorlogic, Вы писали:
M>Я не вижу в вашем коде никакого преимущества , покажите где он может дать перимущество.
M>const double G_R = M_PI / 180.0; M>... M>Лучше Grad2Rad Rad2Grad
Хм... это ты мне написал или автору исходного поста?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, dmitry_npi, Вы писали:
_>Для перевода из радиан в градусы и обратно я написал такой код: _>inline RealType RadToGr(RealType rad)
Во-первых, «градус» — это «degree», а 1 grad = π/200!
А во-вторых, именно в этом случае я бы хранил углы всегда и везде в радианах, а в нужных местах переводил бы в/из градусов. Соответственно, я бы создал функции «from_degrees» и «to_degrees». А если бы выяснилось, что они встречаются очень редко, то тогда завел бы переменные «degrees_per_radian» и «radians_per_degree».
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, dmitry_npi, Вы писали:
_>>Здравствуйте! _>>Для перевода из радиан в градусы и обратно я написал такой код:
M>Можешь пояснить зачем ? например зачем шаблоный ?
Да не в том вопрос, что шаблонный.. тем более, как мне тут показали, это решение не работает с int-инстанциацией.. Черт с ним. Я еще и не начал это использовать.
Дело в том, что вот такого уровня "решения" у меня и такого — у коллег. Ну и во всяких других моментах наподобие такого. Вот я и спрашиваю — не зря ли я усложняю. Может, следует стремиться к максимальной простоте?
Но ведь почему я так делаю? Просто мне достался проект, который так и строился — на простых решениях. И когда эти решения наложились в 100 слоёв, проект расложился, как куча г...
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, dmitry_npi, Вы писали:
_>>Для перевода из радиан в градусы и обратно я написал такой код: _>>inline RealType RadToGr(RealType rad)
RO>Во-первых, «градус» — это «degree», а 1 grad = π/200!
Знаю, что degree. Но так русскому человеку понятнее.
RO>А во-вторых, именно в этом случае я бы хранил углы всегда и везде в радианах, а в нужных местах переводил бы в/из градусов. Соответственно, я бы создал функции «from_degrees» и «to_degrees». А если бы выяснилось, что они встречаются очень редко, то тогда завел бы переменные «degrees_per_radian» и «radians_per_degree».
Здравствуйте, dmitry_npi, Вы писали:
_>Дело в том, что вот такого уровня "решения" у меня и такого — у коллег. Ну и во всяких других моментах наподобие такого. Вот я и спрашиваю — не зря ли я усложняю. Может, следует стремиться к максимальной простоте?
Ну то есть у коллег просто, понятно и работает, а у тебя, зато "более высокий уровень"? Я так тебя понял?
_>Но ведь почему я так делаю? Просто мне достался проект, который так и строился — на простых решениях. И когда эти решения наложились в 100 слоёв, проект расложился, как куча г...
Ну подумай, если эту кучу ещё и запутать до "твоего уровня". Станет ли лучше пахнуть или выглядеть
IMHO, ты главной фишки не сечёшь! Прграммирование -- деятельность ЦЕЛЕНАПРАВЛЕННАЯ. А не ради 2красоты кода" или там "современного уровня" или ещё чего.
Так что тебе правильный вопрос задали: "ЗАЧЕМ?".
Чем твоё решение лучше? Чем оно хуже ты уже вроде как начал понимать, осталось найти хотя бы какие-то плюсы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
M>>Можешь пояснить зачем ? например зачем шаблоный ?
_>Да не в том вопрос, что шаблонный.. тем более, как мне тут показали, это решение не работает с int-инстанциацией.. Черт с ним. Я еще и не начал это использовать.
Как бы совсем наоборот, получается что писанина ради писанины чтоли ? Мне например шаблонный класс будет тяжелее читать , так как придется следить за дополнительными абстракциями и их использованием. Т.е. без дополнительной функциональности это усложнение кода а значит снижение сопровождаемости.
Или болезнь молодого разработчика "посмотрите какие я знаю прикольные конструкции".
Я на сегодня знаю 2 эвристики когда использовать шаблоны.
1. Когда критической становится производительность.
2. когда шаблонное решение сможет сократить к-во кода.
_>Дело в том, что вот такого уровня "решения" у меня и такого — у коллег. Ну и во всяких других моментах наподобие такого. Вот я и спрашиваю — не зря ли я усложняю. Может, следует стремиться к максимальной простоте?
Мм... еще раз повторюсь , дело не в усложнении а в функциональности.
Следует ли стремиться к максимальной простоте , ну кажется на этот вопрос отвечали многократно . Обязательно стоит, это одна из самых сложных задач современного програмирования. Ради упрощения кода на какие только жертвы не идут , а ты сомневаешься ? не стоит.
"проще как можно проще но не проще чем необходимо"
"Легко сделать сложно , тяжело сделать просто"
_>Но ведь почему я так делаю? Просто мне достался проект, который так и строился — на простых решениях. И когда эти решения наложились в 100 слоёв, проект расложился, как куча г...
Если они были действительно простыми тогда со сложными он бы "расложился" намного раньше.
Здравствуйте, minorlogic, Вы писали:
M>>>Можешь пояснить зачем ? например зачем шаблоный ?
_>>Да не в том вопрос, что шаблонный.. тем более, как мне тут показали, это решение не работает с int-инстанциацией.. Черт с ним. Я еще и не начал это использовать.
M>Как бы совсем наоборот, получается что писанина ради писанины чтоли ? Мне например шаблонный класс будет тяжелее читать , так как придется следить за дополнительными абстракциями и их использованием. Т.е. без дополнительной функциональности это усложнение кода а значит снижение сопровождаемости. M>Или болезнь молодого разработчика "посмотрите какие я знаю прикольные конструкции". M>Я на сегодня знаю 2 эвристики когда использовать шаблоны. M>1. Когда критической становится производительность. M>2. когда шаблонное решение сможет сократить к-во кода.
В C++09 проще создавать шаблонные функции, чем нешаблонные.
Что-то вроде
auto from_degrees(auto d) -> decltype(d)
{
return d / 180. * M_PI;
}
Здравствуйте, minorlogic, Вы писали:
M>Я на сегодня знаю 2 эвристики когда использовать шаблоны. M>2. когда шаблонное решение сможет сократить к-во кода.
Это вот понятно.
M>1. Когда критической становится производительность.
А вот это поясни, пожалуйста. Ты имеешь ввиду экономию на 1 вызов по сравнению с виртуальными функциями a-la pimpl? И что, часто приходилось применять такую оптимизацию?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
M>>1. Когда критической становится производительность.
F>А вот это поясни, пожалуйста. Ты имеешь ввиду экономию на 1 вызов по сравнению с виртуальными функциями a-la pimpl? И что, часто приходилось применять такую оптимизацию?
Ну да , когда надо бы устоить полиморфное поведение для типа , написать обобщенное решение но через интерфейс будет тормозить . Например теже итераторы по контейнерам.
