Значит ли это, что я излишне усложняю? Ну ладно, черт с ним, с этим примером, но в сравнении я нашел, что вот мне больше свойствен такой образ мыслей.
Надо ли "лечиться"?
Здравствуйте, 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? И что, часто приходилось применять такую оптимизацию?
Ну да , когда надо бы устоить полиморфное поведение для типа , написать обобщенное решение но через интерфейс будет тормозить . Например теже итераторы по контейнерам.
Про то, на кой вообще тут шаблон я даже и не спрашиваю. Просто потому, что уверен, что ответа не будет
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, frogkiller, Вы писали:
M>>1. Когда критической становится производительность.
F>А вот это поясни, пожалуйста. Ты имеешь ввиду экономию на 1 вызов по сравнению с виртуальными функциями a-la pimpl? И что, часто приходилось применять такую оптимизацию?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, dmitry_npi, Вы писали:
_>>Для перевода из радиан в градусы и обратно я написал такой код: _>>inline RealType RadToGr(RealType rad)
RO>Во-первых, «градус» — это «degree», а 1 grad = π/200!
в каком смысле 1 градус = pi/200?
если 2*Pi=360град
Здравствуйте, merk, Вы писали:
RO>>Во-первых, «градус» — это «degree», а 1 grad = π/200! M>в каком смысле 1 градус = pi/200?
"grad" — это переводится как "град", а не как градус. Один град — это одна сотая часть прямого угла.
По легенде, это чтобы прапорщики не путали прямой угол с температурой кипения воды.
Здравствуйте, minorlogic, Вы писали:
F>>А вот это поясни, пожалуйста. Ты имеешь ввиду экономию на 1 вызов по сравнению с виртуальными функциями a-la pimpl? И что, часто приходилось применять такую оптимизацию? M>Ну да , когда надо бы устоить полиморфное поведение для типа , написать обобщенное решение но через интерфейс будет тормозить . Например теже итераторы по контейнерам.
Знаешь, мне доводилось писать достаточно критичные к производительности вещи — основные проблемы приходилось решать с I/O — по сравнению с этим лишний переход даже на достаточно большом количестве данных был незаметен. Я это к тому, что имхо существует довольно ограниченнный класс задач-числодробилок, в котором подобная оптимизация является непреждевременной.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Знаешь, мне доводилось писать достаточно критичные к производительности вещи — основные проблемы приходилось решать с I/O — по сравнению с этим лишний переход даже на достаточно большом количестве данных был незаметен. Я это к тому, что имхо существует довольно ограниченнный класс задач-числодробилок, в котором подобная оптимизация является непреждевременной.
Я не могу оценить круг твоих задач с которыми ты сталкивался . Я довольно часто работаю над критичными по скорости задачами , и довольно часто возникает вопрос, писать ли шаблонную реализацию дабы не потерять в скорости.
Здравствуйте, minorlogic, Вы писали:
F>>Знаешь, мне доводилось писать достаточно критичные к производительности вещи — основные проблемы приходилось решать с I/O — по сравнению с этим лишний переход даже на достаточно большом количестве данных был незаметен. Я это к тому, что имхо существует довольно ограниченнный класс задач-числодробилок, в котором подобная оптимизация является непреждевременной.
M>Я не могу оценить круг твоих задач с которыми ты сталкивался . Я довольно часто работаю над критичными по скорости задачами , и довольно часто возникает вопрос, писать ли шаблонную реализацию дабы не потерять в скорости.
Вот поэтому я и просил тебя в самом начале привести пример. Желательно хоть с какими-нибудь цифирками, не для того, чтобы раскритиковать — мне честно интересно. (Про мои задачи — например, недокорба, заточенная на прозрачный обмен очень большим количеством мелких сообщений между парой десятков клиентов — упиралось исключительно в I/O.)
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Вот поэтому я и просил тебя в самом начале привести пример. Желательно хоть с какими-нибудь цифирками, не для того, чтобы раскритиковать — мне честно интересно. (Про мои задачи — например, недокорба, заточенная на прозрачный обмен очень большим количеством мелких сообщений между парой десятков клиентов — упиралось исключительно в I/O.)
Пример номер 1: итерация по коллекции
Пример номер 2: обработка изображений с различными форматами пиксенла.
Здравствуйте, minorlogic, Вы писали:
F>>Вот поэтому я и просил тебя в самом начале привести пример. Желательно хоть с какими-нибудь цифирками, не для того, чтобы раскритиковать — мне честно интересно.
M>Пример номер 1: итерация по коллекции M>Пример номер 2: обработка изображений с различными форматами пиксенла.
Хм... это не совсем те примеры, которые я ожидал увидеть. Имхо решения в них вызваны соображениями дизайна, а не производительности. Ну, или как минимум требуют пояснений о способе использования.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
M>>Пример номер 1: итерация по коллекции M>>Пример номер 2: обработка изображений с различными форматами пиксенла.
F>Хм... это не совсем те примеры, которые я ожидал увидеть. Имхо решения в них вызваны соображениями дизайна, а не производительности. Ну, или как минимум требуют пояснений о способе использования.
M>Возможно тут чуть шире , я попытался изложить свои мысли.
Я помню этот топик. Но там тоже не приведено аргументов, показывающих значительное повышение производительности в конкретных задачах, и я начинаю подозревать, что причина твоего утверждения — абстрактные рассуждения о сокращении на один переход последовательности вызовов при обращении к членам/методам. При этом совершенно не расрыта тема оптимизации компиляторов.
Ещё раз повторю свой вопрос: на каких задачах у тебя профайлер выявил узкое место — обращение к _vtable, так что это потребовало переписать код с использованием шаблонов?
(Поясняю, почему мне не понравились твои два примера выше по ветке. Итерация по коллекции — классическая задача, вот уже десять лет решаемая на шаблонах. Всякие извращения типа билдеровского TList'а только подтверждают общую практику. Во втором примере с обработкой изображений с различным форматом пикселей также напрашивается решение, основанное на шаблонах, ввиду явного применения одних и тех же алгоритмов к разным данным. В этом случае шаблонную библиотеку реализовать проще, чем нешаблонную — прослеживается аналогия с stl. Итого: в обоих случаях, на мой взгляд, критерием выбора шаблонов послужили исключительно соображения дизайна. Но, возможно, я не знаю каких-то специфических особенностей твоих задач, в которых действительно inline-оптимизация шаблонов сыграла важную роль — вот я и интересуюсь эти особенностями.)
Курица — это инструмент, с помощью которого одно яйцо производит другие.
F>(Поясняю, почему мне не понравились твои два примера выше по ветке. Итерация по коллекции — классическая задача, вот уже десять лет решаемая на шаблонах. Всякие извращения типа билдеровского TList'а только подтверждают общую практику.
Мотивация обходить контейнер с помощью шаблонного итератора и является скорость. Как альтернатива предлагаю рассмотреть вариант с абстрактным итератором. Решение было бы намного более гибкое, имплементация скрыта и т.п.
F>Во втором примере с обработкой изображений с различным форматом пикселей также напрашивается решение, основанное на шаблонах, ввиду явного применения одних и тех же алгоритмов к разным данным. В этом случае шаблонную библиотеку реализовать проще, чем нешаблонную — прослеживается аналогия с stl.
Сравни с реализацией на абстрактном пикселе заданного формата или написанием N реализаций по к-ву форматов пиксела.
F>Итого: в обоих случаях, на мой взгляд, критерием выбора шаблонов послужили исключительно соображения дизайна. Но, возможно, я не знаю каких-то специфических особенностей твоих задач, в которых действительно inline-оптимизация шаблонов сыграла важную роль — вот я и интересуюсь эти особенностями.)
Я не понимаю твой критерий "соображения дизайна". Для оценки того или иного решения можно сравнить несколько вариантов.
Здравствуйте, minorlogic, Вы писали:
M>Производительность не повышается , она НЕ ПАДАЕТ.
Бр... Ты в двух топиках утверждал, что следует применять шаблоны для повышении производительности, а теперь получается, что она всего лишь не падает.
Я понял: никаких измерений в реальных приложениях ты не производил. Собственно, рассуждать о достоинствах или недостатках каждого подхода, в том числе и по скорости, можно долго (и приводить аргументы, что реализация с динамическим полиморфизмом может быть быстрее, например, т.к. за счёт меньшего размера целиком помещается в кэше), но абсолютно бесперспективно, если аргументы не подкреплены реальными цифрами, полученными в реальной работе. За сим больше вопросов не имею.
M>Мотивация обходить контейнер с помощью шаблонного итератора и является скорость. Как альтернатива предлагаю рассмотреть вариант с абстрактным итератором. Решение было бы намного более гибкое, имплементация скрыта и т.п.
Опять сферический конь в вакууме.
M>Сравни с реализацией на абстрактном пикселе заданного формата или написанием N реализаций по к-ву форматов пиксела.
И ещё один.
F>>Итого: в обоих случаях, на мой взгляд, критерием выбора шаблонов послужили исключительно соображения дизайна. Но, возможно, я не знаю каких-то специфических особенностей твоих задач, в которых действительно inline-оптимизация шаблонов сыграла важную роль — вот я и интересуюсь эти особенностями.)
M>Я не понимаю твой критерий "соображения дизайна". Для оценки того или иного решения можно сравнить несколько вариантов.
Я имел ввиду удобство разработки и сопровождения кода — скорость написания, размер кода, глубину иерархии, зависимости между разными частями и тд. — т.е. вещи, играющие роль в design-time.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, minorlogic, Вы писали:
M>>Производительность не повышается , она НЕ ПАДАЕТ.
F>Бр... Ты в двух топиках утверждал, что следует применять шаблоны для повышении производительности, а теперь получается, что она всего лишь не падает.
Я говорил про критические к скорости приложения.
F>Я понял: никаких измерений в реальных приложениях ты не производил.
Если ты лучше чем я знаешь какие я проводил замеры , тогда общайся дальше сам с собой . Удачи.
Здравствуйте, minorlogic, Вы писали:
M>Я говорил про критические к скорости приложения. F>>Я понял: никаких измерений в реальных приложениях ты не производил. M>Если ты лучше чем я знаешь какие я проводил замеры ,
Я три раза просил тебя уточнить, как и где именно шаблонная реализация давала выигрыш в производительности по сравнению в реализацией на виртуальных функциях, ощутимый по сравнению с другими частями приложения, чтобы это не расценивалось как преждевременная оптимизация. Но ты упорно это игнорировал и предлагал умозрительные сравнения вместо информации о том, что и как измерял. (Я не спорю, умозрительно или на синтетическом тесте можно получить заметную разницу — но стоит ли овчинка выделки? Ты можешь заоптимизировать итерирование по коллекции, заинлайнить специфическую информацию о форматах пикселей — но что толку, если приложение будет безбожно тормозить на отрисовке на экране или пересылке по сети, и ты получишь 0.1% производительности?) И, по-твоему, какой я должен был сделать вывод?
M> тогда общайся дальше сам с собой . Удачи.
не обижайся, пожалуйста. Я ни коим образом не хотел тебя обидеть или усомниться в твоей компетентности
Курица — это инструмент, с помощью которого одно яйцо производит другие.
А как ты себе это представляешь ? я данные профилировки храню по несколько лет ? или специально для тебя подниму старый код и организую тесты ?
если кратко то например функция постороения пирамиды изображений тормозила с имплементацией через виртуальные функции примерно на 50% в сравнении с хорошо отоптимизированной под конкретный тип данных.
вторая версия этой функции реализовывала свой хардкод под различные типы пиксела и содержала 3 версии схожей имплементации.
третья версия (пока последняя) содержит шаблонную по типу реализацию , где шаблонными являются такжде операции над пикселом. Третья версия содержала только один кода алгоритма и не проигрывала в скорости захардкоженным версиям.
В этом примере тип пиксела и операции над ними являются полиморфными по потношению к коду алгоритма.
Здравствуйте, minorlogic, Вы писали:
M>А как ты себе это представляешь ? я данные профилировки храню по несколько лет ? или специально для тебя подниму старый код и организую тесты ?
Вполне подойдёт краткая характеристика по типу того, что ты написал ниже.
M>если кратко то например функция постороения пирамиды изображений тормозила с имплементацией через виртуальные функции примерно на 50% в сравнении с хорошо отоптимизированной под конкретный тип данных. M>вторая версия этой функции реализовывала свой хардкод под различные типы пиксела и содержала 3 версии схожей имплементации. M>третья версия (пока последняя) содержит шаблонную по типу реализацию , где шаблонными являются такжде операции над пикселом. Третья версия содержала только один кода алгоритма и не проигрывала в скорости захардкоженным версиям. M>В этом примере тип пиксела и операции над ними являются полиморфными по потношению к коду алгоритма.
Во! именно этого я и добивался от тебя всё это время А теперь ещё немного уточни, пожалуйста,
1) указанный выигрыш был получен на тестах именно данной функциональности или замерян на рабочем приложении, в котором помимо этого есть и другие функции, работающие одновременно с данной, или же это единственная функция приложения
2) какой тип приложения: сервер, графический клиент или "консольная" утилита (т.е. может быть не отдельная программа, а некая функциональность большой программы, работающая без интерактивного отображения)
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Во! именно этого я и добивался от тебя всё это время А теперь ещё немного уточни, пожалуйста, F>1) указанный выигрыш был получен на тестах именно данной функциональности или замерян на рабочем приложении, в котором помимо этого есть и другие функции, работающие одновременно с данной, или же это единственная функция приложения
Я писал именно про отдельную функцию . В приложении же присутствовало достаточно много и другого кода. Эта функция занимала около 30 — 50% от всего времени работы. В целом от перехода на шаблонный тип пиксела во многоих алгоритмах обработки , общая скорость возрасла примерно на 30% по сравнению с использованием абстрвктного типа пиксела.
F>2) какой тип приложения: сервер, графический клиент или "консольная" утилита (т.е. может быть не отдельная программа, а некая функциональность большой программы, работающая без интерактивного отображения)
Консольное приложение , а также часть графической библиотеки использующейся в нескольких коробочных приложениях
//====================================
Преимущества использования шаблонного полиморфизма обычно ощущается на достаточно мелких операциях типа проходу по коллекции , простые арифметические операции , копирование даных маленькими порциями и т.п.
Разница эта появляется не только от вызова через таблицу виртуальных функций (что в целом не очень дорого) но и в возможности инлайна шаблонных объектов и операций над ними.
Здравствуйте, dmitry_npi, Вы писали:
_>Здравствуйте! _>Для перевода из радиан в градусы и обратно я написал такой код: _>
_>// перевод из радиан в градусы и обратно
_>template<class RealType>
_>inline RealType RadToGr(RealType rad)
_>{
_> return rad*(RealType)(180/M_PI);
_>}
_>
_>А мой коллега, человек старшего поколения, и шаблоны не очень любящий, такой:
_>
Здравствуйте, Alxndr, Вы писали:
A>А для кошерности по самое не могу, можно еще ввести отдельные типы для градусов и радианов (с соответствующими преобразованиями). A>После этого автор топика поймет, что первоначальный вариант усложнением не являлся
А для полной кошерности надо еще ввести классы Gradus, Minute, Second, соответсвующие конструкторы (например, Gradus(Minute), соответствующие operator приведения, добавить всякие operator арифметики (к минутам градусы прибавить и т.п.) В общем, меньше чем на 200-300 строк кода это ИМХО никак не тянет. Зато как красиво смотреться будет . И сколько времени можно на это потратить!
Маленький вопрос сторонникам всех эти классов и темплейтов — как вы считаете, до появления C++ (и даже С) программисты градусы в радианы и обратно правильно переводили или нет ?
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>А для кошерности по самое не могу, можно еще ввести отдельные типы для градусов и радианов (с соответствующими преобразованиями). A>>После этого автор топика поймет, что первоначальный вариант усложнением не являлся
PD>А для полной кошерности надо еще ввести классы Gradus, Minute, Second, соответсвующие конструкторы (например, Gradus(Minute), соответствующие operator приведения, добавить всякие operator арифметики (к минутам градусы прибавить и т.п.) В общем, меньше чем на 200-300 строк кода это ИМХО никак не тянет. Зато как красиво смотреться будет . И сколько времени можно на это потратить!
Да уж, один раз потратить на это время и — если постоянно работаем с градусами/минутами/секундами — забыть о проблемах перевода физических величин (уменьшение кода + многие ошибки уйдут).
PD>Маленький вопрос сторонникам всех эти классов и темплейтов — как вы считаете, до появления C++ (и даже С) программисты градусы в радианы и обратно правильно переводили или нет ?
Нет, что Вы, что Вы, все эти классы и шаблоны излишества современной испорченной молодежи.
Закаленным бойцам дучше бы писать в стиле Фортран.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А для полной кошерности надо еще ввести классы Gradus, Minute, Second, соответсвующие конструкторы (например, Gradus(Minute), соответствующие operator приведения, добавить всякие operator арифметики (к минутам градусы прибавить и т.п.) В общем, меньше чем на 200-300 строк кода это ИМХО никак не тянет. Зато как красиво смотреться будет . И сколько времени можно на это потратить!
Как я уже указывал, это уже сделали за нас. Осталось только воспользоваться плодами чужого труда.
PD>Маленький вопрос сторонникам всех эти классов и темплейтов — как вы считаете, до появления C++ (и даже С) программисты градусы в радианы и обратно правильно переводили или нет ?
Переводить-то они переводили, да вот только компайлер им по польцам при этом не давал.
Здравствуйте, Alxndr, Вы писали:
A>Да уж, один раз потратить на это время и — если постоянно работаем с градусами/минутами/секундами — забыть о проблемах перевода физических величин (уменьшение кода + многие ошибки уйдут).
А можно пример реальной ошибки в реальном проекте, связанной с переводом из радианов в градусы ? В общем, был ли мальчик ?
И пример уменьшения кода тоже, если можно.
Ну а потом — почему только из радианов в градусы ? Еще можно строк 500 потратить на киловатт-часы, калории, джоули и т.д.. Потом на ньютоны и килограммы. А еще лучше сразу начать фундаментальную библиотеку классов писать SI/CGS. Тут никак меньше чем парой человеко-лет не обойдешься
PD>>Маленький вопрос сторонникам всех эти классов и темплейтов — как вы считаете, до появления C++ (и даже С) программисты градусы в радианы и обратно правильно переводили или нет ?
A>Нет, что Вы, что Вы, все эти классы и шаблоны излишества современной испорченной молодежи.
Именно
A>Закаленным бойцам дучше бы писать в стиле Фортран.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А можно пример реальной ошибки в реальном проекте, связанной с переводом из радианов в градусы ? В общем, был ли мальчик ?
Была известная реальная ошибка, но проблема была не с радианами и градусами, а с фунт-силами и ньютонами
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А можно пример реальной ошибки в реальном проекте, связанной с переводом из радианов в градусы ? В общем, был ли мальчик ?
Да полно таких ошибок на самом деле. Например, когда мы управляли марсианским ровером в процессе последнего ICFP contest, были баги именно с переводом градусов в радианы .
Если посмотреть чуть шире, то такая ошибка (смешивание разнотипных с точки зрения предметной области, но однотипных с точки зрения языка программирования сущностей) встречается сплошь и рядом. Примеры — строки в разных кодировках, числа с разной endiannes, сырые строки и escape-нутые (весь cross-site scripting на подобных багах держится).
Здравствуйте, palm mute, Вы писали:
PD>>А можно пример реальной ошибки в реальном проекте, связанной с переводом из радианов в градусы ? В общем, был ли мальчик ?
PM>Да полно таких ошибок на самом деле. Например, когда мы управляли марсианским ровером в процессе последнего ICFP contest, были баги именно с переводом градусов в радианы .
PM>Если посмотреть чуть шире, то такая ошибка (смешивание разнотипных с точки зрения предметной области, но однотипных с точки зрения языка программирования сущностей) встречается сплошь и рядом. Примеры — строки в разных кодировках, числа с разной endiannes, сырые строки и escape-нутые (весь cross-site scripting на подобных багах держится).
Причем, что обидно, еще 20-30 лет назад были созданы обычные императивные языки, которые подобные ошибки устраняли чуть ли не напрочь. Всего-то нужно было ввести strict typedef-ы: когда из одного и того же базового типа получается произвольное количество несовместимых между собой подтипов. Вроде того, как это сейчас делается в D:
typedef float radians;
typedef float degres;
const radians one_radian = 1;
degres d = one_radian * 5; // А тут нам компилятор по рукам, по рукам!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Причем, что обидно, еще 20-30 лет назад были созданы обычные императивные языки, которые подобные ошибки устраняли чуть ли не напрочь. Всего-то нужно было ввести strict typedef-ы: когда из одного и того же базового типа получается произвольное количество несовместимых между собой подтипов. Вроде того, как это сейчас делается в D: E>
E>typedef float radians;
E>typedef float degres;
E>const radians one_radian = 1;
E>degres d = one_radian * 5; // А тут нам компилятор по рукам, по рукам!
E>
А где автоматический пересчёт one_radian в degres? А в Boost.Units и это есть.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну а потом — почему только из радианов в градусы ? Еще можно строк 500 потратить на киловатт-часы, калории, джоули и т.д.. Потом на ньютоны и килограммы. А еще лучше сразу начать фундаментальную библиотеку классов писать SI/CGS. Тут никак меньше чем парой человеко-лет не обойдешься
В библиотеке, которую я привёл, именно что полная система SI/CGS и имплементирована. Но посмотреть документацию ведь так сложно! Тупо флеймить куда проще!
_>В библиотеке, которую я привёл, именно что полная система SI/CGS и имплементирована. Но посмотреть документацию ведь так сложно! Тупо флеймить куда проще!
Посмотрел. Спасибо. Теперь буду знать, что для того, чтобы перевести из ньютонов в килограммы, надо прочитать 450 страниц документации, скачать некие файлы, увеличить размер EXE на десяток килобайт и добавить DLL.
Здравствуйте, Klapaucius, Вы писали:
K>Была известная реальная ошибка, но проблема была не с радианами и градусами, а с фунт-силами и ньютонами
K>здесь.
Нет, батенька, не пойдет.
>used Imperial units (pound-seconds) instead of the metric units (newton-seconds) as specified by NASA
Здесь не ошибка перевода из одной системы в другую, а использование не той единицы. Тут Вам никакая библиотека не поможет — если надо в формуле использовать newton-seconds, а вы вводите величину в pound-seconds, вам никто не поможет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, skeptik_, Вы писали:
_>>В библиотеке, которую я привёл, именно что полная система SI/CGS и имплементирована. Но посмотреть документацию ведь так сложно! Тупо флеймить куда проще!
PD>Посмотрел. Спасибо. Теперь буду знать, что для того, чтобы перевести из ньютонов в килограммы, надо прочитать 450 страниц документации, скачать некие файлы, увеличить размер EXE на десяток килобайт и добавить DLL.
ОК, желаю Вам и дальше присваивать килограммам -- ньютоны, футам -- метры, а амперам -- кулоны. Viel Glück dabei!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, skeptik_, Вы писали:
_>>ОК, желаю Вам и дальше присваивать килограммам -- ньютоны, футам -- метры,
PD>Спасибо. До сих пор проблем никогда не имел, надеюсь и дальше их не иметь.
>>а амперам -- кулоны.
PD>А вот за такое надо обратно в школу отправлять
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Маленький вопрос сторонникам всех эти классов и темплейтов — как вы считаете, до появления C++ (и даже С) программисты градусы в радианы и обратно правильно переводили или нет ?
Ариан-5 убедительно продемонстрировал ответ на этот вопрос.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Klapaucius, Вы писали:
K>>Была известная реальная ошибка, но проблема была не с радианами и градусами, а с фунт-силами и ньютонами
K>>здесь.
PD>Нет, батенька, не пойдет.
>>used Imperial units (pound-seconds) instead of the metric units (newton-seconds) as specified by NASA
PD>Здесь не ошибка перевода из одной системы в другую, а использование не той единицы. Тут Вам никакая библиотека не поможет — если надо в формуле использовать newton-seconds, а вы вводите величину в pound-seconds, вам никто не поможет.
Значит, Вы считаете, что программист бодренько писал бы: quantity<length> x = 2.0 * feet; используя при этом метры?
Здравствуйте, skeptik_, Вы писали:
E>>Всего-то нужно было ввести strict typedef-ы: когда из одного и того же базового типа получается произвольное количество несовместимых между собой подтипов. Вроде того, как это сейчас делается в D: E>>
E>>typedef float radians;
E>>typedef float degres;
E>>const radians one_radian = 1;
E>>degres d = one_radian * 5; // А тут нам компилятор по рукам, по рукам!
E>>
_>А где автоматический пересчёт one_radian в degres?
Для тех, кто в boos..., ой, в танке, повторяю: strict typedef-ы предназначены для того, чтобы запретить любое неявное автоматическое преобразование. Благодоря им разработчик должен указать, что именно он хочет сделать:
degres d = radian_to_degres( one_radian * 5 );
или же
degres d = one_degree * 5;
_> А в Boost.Units и это есть.
Нет бога кроме C++а, а Boost -- пророк его. Аминь.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, skeptik_, Вы писали:
PD>>Спасибо. До сих пор проблем никогда не имел, надеюсь и дальше их не иметь.
>>>а амперам -- кулоны.
PD>>А вот за такое надо обратно в школу отправлять
_>А килограммы и ньютоны значит одной размерности?
Килограммы (силы, а не массы) и ньютоны — это разные единицы измерения одной и той же величины (силы), и их можно переводить друг в друга. А вот кулоны и амперы — это разные величины (единица количества электричества и единица силы тока) , а поэтому за перевод из кулонов в амперы или обратно надо отправлять в среднюю школу .
Мягко выражаясь, немного не та ситуация. Ошибка-то была в подпрограмме преобразования . Без нее в любом случае бы не обошлись, но вот, увы, ошибочка вкралась. Бывает.
А я все же просил пример по ошибке при умножении на 180 и делении на PI. Или наоборот.
Кстати, маленький вопрос. А просто для умножения на 180 (ну не знаю зачем это надо) тоже нужно специальную подпрограмму писать или нет ?
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Ариан-5 убедительно продемонстрировал ответ на этот вопрос.
PD>Ну что же, почитаем.
PD>http://newman-by.livejournal.com/53420.html
>>Ошибка крылась в подпрограмме, которая превращала 64-битные числа с плавающей запятой в 16-битные целые числа
PD>или здесь
PD>http://drcrasher.livejournal.com/1144632.html
>>одна из вспомогательных подпрограмм попыталась преобразовать длинное целое значение в короткое без проверки величины значения
PD>Мягко выражаясь, немного не та ситуация. Ошибка-то была в подпрограмме преобразования . Без нее в любом случае бы не обошлись, но вот, увы, ошибочка вкралась. Бывает.
Вообще-то это офтопик, но с моей дилетанской точки зрения, проблема Ариан-5 была не в коде, а в организации разработки: часть ПО от Ариан-4 была переиспользована в Ариан-5 без проведения анализа безопасности подобного переиспользования. В результате чего ошибка как раз возникла в коде ПО для Ариан-4, который был совершенно корректен для условий Ариан-5.
Здравствуйте, eao197, Вы писали:
_>>А где автоматический пересчёт one_radian в degres?
E>Для тех, кто в boos..., ой, в танке, повторяю: strict typedef-ы предназначены для того, чтобы запретить любое неявное автоматическое преобразование. Благодоря им разработчик должен указать, что именно он хочет сделать: E>
E>degres d = radian_to_degres( one_radian * 5 );
E>
E>или же E>
E>degres d = one_degree * 5;
E>
Тут прикол в чём, скажем из 2.0 * meter нельзя вычесть 3.0 * kilogram, компилятор ругаться будет. А вот из 2.0 * meter вычесть 3.0 * foot -- можно. Ибо для этой пары юнитов определено приведение, и компилятор автоматически вставит умножение футов на 0,3048 (или сколько там...). В итоге runtime у нас получится не менее эффективный чем использование голых интегральных типов, но при этом мы имеем абсолютную type safety и автоматическое применение разрещённых преобразований.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, skeptik_, Вы писали:
PD>>>Спасибо. До сих пор проблем никогда не имел, надеюсь и дальше их не иметь.
>>>>а амперам -- кулоны.
PD>>>А вот за такое надо обратно в школу отправлять
_>>А килограммы и ньютоны значит одной размерности?
PD>Килограммы (силы, а не массы) и ньютоны — это разные единицы измерения одной и той же величины (силы), и их можно переводить друг в друга. А вот кулоны и амперы — это разные величины (единица количества электричества и единица силы тока) , а поэтому за перевод из кулонов в амперы или обратно надо отправлять в среднюю школу .
Простите, но я в первой жизни физик по образованию, и могу вам сказать, это несколько разные размерности.
Здравствуйте, skeptik_, Вы писали:
_>Тут прикол в чём, скажем из 2.0 * meter нельзя вычесть 3.0 * kilogram, компилятор ругаться будет. А вот из 2.0 * meter вычесть 3.0 * foot -- можно. Ибо для этой пары юнитов определено приведение, и компилятор автоматически вставит умножение футов на 0,3048 (или сколько там...). В итоге runtime у нас получится не менее эффективный чем использование голых интегральных типов, но при этом мы имеем абсолютную type safety и автоматическое применение разрещённых преобразований.
При наличии строгих тайпдефов, мы можем написать:
typedef float length_t;
// Меры длины указываются в миллиметрах:const length_t meter = 1000;
const length_t feet = 304.8;
...
length_t a = 2.0*meter - 3.0*feet;
Какие проблемы с type safety и производительностью будут у этого кода по сравнению с Boost.Unit?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, skeptik_, Вы писали:
_>>Тут прикол в чём, скажем из 2.0 * meter нельзя вычесть 3.0 * kilogram, компилятор ругаться будет. А вот из 2.0 * meter вычесть 3.0 * foot -- можно. Ибо для этой пары юнитов определено приведение, и компилятор автоматически вставит умножение футов на 0,3048 (или сколько там...). В итоге runtime у нас получится не менее эффективный чем использование голых интегральных типов, но при этом мы имеем абсолютную type safety и автоматическое применение разрещённых преобразований.
E>При наличии строгих тайпдефов, мы можем написать: E>
E>typedef float length_t;
E>// Меры длины указываются в миллиметрах:
E>const length_t meter = 1000;
E>const length_t feet = 304.8;
E>...
E>length_t a = 2.0*meter - 3.0*feet;
E>
У тебя feet -- просто константа определённого типа. В бусте foot -- это тип размерности, гарантирующий типобезопастность для любого выбранного нами базисного типа (никак шаблон!).Твоё решение даже близко не стояло. Объяснять мне уже надоело, читай документацию, если интересно. Для этого надо качать последний пререлиз с sourceforge'а. Кстати, когда я сначала увидел в review schedule "библиотека для физическиз типов", я тоже сперва подумал -- а нафига такие сложности. Когда же вышла бета 1.36, я почитал доки, и понял, что это очень элегантно, удобно в использовании, и типобезовасно. И расширяемо -- можно легко сделать типы для валют например, или px <-> em, или ещё чего.
Нельзя кстати сказать, что я всегда за -- я например рад, что библиотеку для логгирования уже дважды прокатили, мне она совсем не нравится: типичный overdesign. Или например property map — я и сейчас считаю, что ей в бусте делать нечего. Короче, религиозного отношения у меня к бусту нет. Просто надо понимать, что это очень неплохо протестированная библиотека. И те либы, которые могут в этом с ней сравниться, как правило не менее, а скорее более монстрозны, например ACE, или wxWidgets или Qt...
Здравствуйте, skeptik_, Вы писали:
_>>>Тут прикол в чём, скажем из 2.0 * meter нельзя вычесть 3.0 * kilogram, компилятор ругаться будет. А вот из 2.0 * meter вычесть 3.0 * foot -- можно. Ибо для этой пары юнитов определено приведение, и компилятор автоматически вставит умножение футов на 0,3048 (или сколько там...). В итоге runtime у нас получится не менее эффективный чем использование голых интегральных типов, но при этом мы имеем абсолютную type safety и автоматическое применение разрещённых преобразований.
E>>При наличии строгих тайпдефов, мы можем написать: E>>
E>>typedef float length_t;
E>>// Меры длины указываются в миллиметрах:
E>>const length_t meter = 1000;
E>>const length_t feet = 304.8;
E>>...
E>>length_t a = 2.0*meter - 3.0*feet;
E>>
_>У тебя feet -- просто константа определённого типа. В бусте foot -- это тип размерности, гарантирующий типобезопастность для любого выбранного нами базисного типа (никак шаблон!).Твоё решение даже близко не стояло.
Ты не ответил на мой вопрос: какие проблемы с безопасностью и скоростью у приведенного мной кода?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, skeptik_, Вы писали:
_>>>>Тут прикол в чём, скажем из 2.0 * meter нельзя вычесть 3.0 * kilogram, компилятор ругаться будет. А вот из 2.0 * meter вычесть 3.0 * foot -- можно. Ибо для этой пары юнитов определено приведение, и компилятор автоматически вставит умножение футов на 0,3048 (или сколько там...). В итоге runtime у нас получится не менее эффективный чем использование голых интегральных типов, но при этом мы имеем абсолютную type safety и автоматическое применение разрещённых преобразований.
E>>>При наличии строгих тайпдефов, мы можем написать: E>>>
E>>>typedef float length_t;
E>>>// Меры длины указываются в миллиметрах:
E>>>const length_t meter = 1000;
E>>>const length_t feet = 304.8;
E>>>...
E>>>length_t a = 2.0*meter - 3.0*feet;
E>>>
_>>У тебя feet -- просто константа определённого типа. В бусте foot -- это тип размерности, гарантирующий типобезопастность для любого выбранного нами базисного типа (никак шаблон!).Твоё решение даже близко не стояло.
E>Ты не ответил на мой вопрос: какие проблемы с безопасностью и скоростью у приведенного мной кода?
А если мне в другом месте программы нужны не миллиметры, а парсеки? Дальше что? У тебя всё жестко завязано на float и миллиметры. Гибкость нулевая. Самодокументированность кода -- тоже. Когда я пишу: quantity<length> x = 5 * foot; -- сразу ясно: это во-первых длина, и во-вторых это футы. А ты пишешь: length_t x = 5. И что из этого ясно? Длина какая-то. В попугаях наверно. А потом роверы на марсе попугаев ищут.
Здравствуйте, skeptik_, Вы писали:
_>>>>>Тут прикол в чём, скажем из 2.0 * meter нельзя вычесть 3.0 * kilogram, компилятор ругаться будет. А вот из 2.0 * meter вычесть 3.0 * foot -- можно....В итоге runtime у нас получится не менее эффективный чем использование голых интегральных типов, но при этом мы имеем абсолютную type safety и автоматическое применение разрещённых преобразований.
E>>>>При наличии строгих тайпдефов, мы можем написать: E>>>>
E>>>>typedef float length_t;
E>>>>// Меры длины указываются в миллиметрах:
E>>>>const length_t meter = 1000;
E>>>>const length_t feet = 304.8;
E>>>>...
E>>>>length_t a = 2.0*meter - 3.0*feet;
E>>>>
_>>>У тебя feet -- просто константа определённого типа. В бусте foot -- это тип размерности, гарантирующий типобезопастность для любого выбранного нами базисного типа (никак шаблон!).Твоё решение даже близко не стояло.
E>>Ты не ответил на мой вопрос: какие проблемы с безопасностью и скоростью у приведенного мной кода? _>А если мне в другом месте программы нужны не миллиметры, а парсеки? Дальше что?
Где ответ на мой вопрос?
Я специально оставил и выделил твои пожелания -- выражение (2*meter-3*feet) должно быть допустимым, должно быть эффективным и безопасным. Тогда как (2*meter-3*kilogram) недопустимо на уровне компиляции. В подходе со строгими тайпдефами какие из высказанных тобой пожеланий не выполняются?
_> У тебя всё жестко завязано на float и миллиметры.
На float завязано только определение length_t. Одно место.
На миллиметры завязаны только определения констант meter и feet. Это опять же одно место. Вся остальная программа от этих определений зависит не сильно. Да и любая другая система мер и весов должна быть привязана к каким-то абсолютным величинам, иначе невозможно будет выразить meter через feet и обратно.
_>Когда я пишу: quantity<length> x = 5 * foot; -- сразу ясно: это во-первых длина, и во-вторых это футы. А ты пишешь: length_t x = 5. И что из этого ясно?
Ясно, что ты себе позволяешь писать 5 * feet, а воот мне ты этого права не оставляешь.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
_>>Когда я пишу: quantity<length> x = 5 * foot; -- сразу ясно: это во-первых длина, и во-вторых это футы. А ты пишешь: length_t x = 5. И что из этого ясно?
E>Ясно, что ты себе позволяешь писать 5 * feet, а воот мне ты этого права не оставляешь.
Естественно не оставляю! У тебя это константа отличная от единицы, если ты на неё умножишь, значение изменится!
Кстати, где в C++ твои строгие тайпдефы? Обсуждаем сферического коня в вакууме?
Итак, по поводу моего вопроса о безопасности и скорости слив защитан.
_>>>Когда я пишу: quantity<length> x = 5 * foot; -- сразу ясно: это во-первых длина, и во-вторых это футы. А ты пишешь: length_t x = 5. И что из этого ясно?
E>>Ясно, что ты себе позволяешь писать 5 * feet, а воот мне ты этого права не оставляешь. _>Естественно не оставляю! У тебя это константа отличная от единицы, если ты на неё умножишь, значение изменится! _>Кстати, где в C++ твои строгие тайпдефы? Обсуждаем сферического коня в вакууме?
Почитай, что я писал:
Причем, что обидно, еще 20-30 лет назад были созданы обычные императивные языки, которые подобные ошибки устраняли чуть ли не напрочь. Всего-то нужно было ввести strict typedef-ы: когда из одного и того же базового типа получается произвольное количество несовместимых между собой подтипов. Вроде того, как это сейчас делается в D
Определение подтипов было еще в Pascal, если не ошибаюсь. Более двадцати лет назад появился язык Ada, в которых подтипы были одним из основных элементов безопасного программирования. В современных языках строгие тайпдефы есть в D.
То, что C++ на пороге принятия нового стандарта нуждается в шаблонных библиотеках для вещей, которые в Ada были двадцать лет назад, это проблемы C++. И его фанатичных зашоренных защитников.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Ладно, если ты не в состоянии понять, что данная либа делает больше чем твои тапдефы, то я умываю руки. Пойми впрочем, я не против таких тайпдефов, но я реалист и прагматик -- в С++ их нет, и в ближайшем времени не будет. А на Паскале пиши сам, если у тебя есть склонность к мазохизму.
Здравствуйте, skeptik_, Вы писали:
_>Значит, Вы считаете, что программист бодренько писал бы: quantity<length> x = 2.0 * feet; используя при этом метры?
Здравствуйте, Sinclair, Вы писали:
E>>Может быть Sinclair хотел сказать о Mars Climate Orbiter? S>Да, прошу прощения. В голове обе катастрофы слиплись в одну.
Если верить Wikipedia, то корни проблемы там те же, что и в случае с Арианом:
The problem arose partly because the software had been adapted from use on the earlier Mars Climate Orbiter, without proper testing before launch, and partly because the navigation data provided by this software was not cross-checked while in flight.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, skeptik_, Вы писали:
PD>>Килограммы (силы, а не массы) и ньютоны — это разные единицы измерения одной и той же величины (силы), и их можно переводить друг в друга. А вот кулоны и амперы — это разные величины (единица количества электричества и единица силы тока) , а поэтому за перевод из кулонов в амперы или обратно надо отправлять в среднюю школу . _>Простите, но я в первой жизни физик по образованию, и могу вам сказать, это несколько разные размерности.
Мне что-то припоминается, что 1 кгС = 9.8Н. Или нет ? Я в первой жизни химик, но этому меня вроде учили еще в средней школе.
Здравствуйте, dmitry_npi, Вы писали:
_>Здравствуйте! _>Для перевода из радиан в градусы и обратно я написал такой код: _>
_>// перевод из радиан в градусы и обратно
_>template<class RealType>
_>inline RealType GrToRad(RealType grad)
_>//...
_>
Ужасно. В какой-то момент этой функции будет скормлено целое число, и придётся долго искать, почему программа не работает.
Не проще ли изначально постановить, что углы будут храниться только в double, а решение "коллеги, человека старшего поколения" будет тому дополнительной гарантией. Как только кто-то по недоразумению решил держать угол в int — сразу компилятором хрясь по рукам!
Здравствуйте, dmitry_npi, Вы писали:
RO>>Во-первых, «градус» — это «degree», а 1 grad = π/200! _>Знаю, что degree. Но так русскому человеку понятнее.
Так нужно писать не сокращённо: radian_per_gradus, radian_per_grad.
А с учётом того, что эти два имени легко перепутать, то нужно намеренно ввести различие. Будет менее понятно (если человек не знает английского), но станет бросаться в глаза.
RO>>А во-вторых, именно в этом случае я бы хранил углы всегда и везде в радианах, а в нужных местах переводил бы в/из градусов. Соответственно, я бы создал функции «from_degrees» и «to_degrees». А если бы выяснилось, что они встречаются очень редко, то тогда завел бы переменные «degrees_per_radian» и «radians_per_degree».
_>Спасибо.
Кстати, из названия "угол_измеренный_в_радианах * градусов_в_радиане" понятно, что на выходе получаются градусы.
А из загадочного "градус_радиан" — то ли делить нужно, то ли умножать. Знак подчёркивания — это не знак стрелки.
Можно договориться, что преобразование "из_градусов_в_радианы", "из_радианов_в_градусы" (или "в_градусы_из_радианов") применяется всегда через умножение. Но это — элемент конвенции.
В английском языке это выглядит deg_to_rad (или deg2rad), deg_from_rad.
Кстати, для чтения удобнее _to_ применять постфиксно, а _from_ — префиксно:
double r = M_PI/2; // некий угол, померяный в радианахdouble g1 = grad_from_deg* deg_from_rad* r;
double g2 = r *rad_to_deg *deg_to_grad;
Здравствуйте, Cyberax, Вы писали:
C>"grad" — это переводится как "град", а не как градус. Один град — это одна сотая часть прямого угла. C>По легенде, это чтобы прапорщики не путали прямой угол с температурой кипения воды.
Здравствуйте, minorlogic, Вы писали:
M>Я на сегодня знаю 2 эвристики когда использовать шаблоны. M>1. Когда критической становится производительность. M>2. когда шаблонное решение сможет сократить к-во кода.
Ещё не забывай про возможности рефакторинга.
Голое преобразование (на встроенных операторах)
— чтобы внести изменение в логику, придётся переписать все вхождения
— подвержено опечаткам (достаточно перепутать * и /, не говоря уже про + или -, и всё полетело)
Поэтому первый этап — это инлайновые функции, а второй — шаблоны выражений (на которые можно навесить и контроль единиц измерения).
Пример, зачем нужно менять логику: дебаг.
double deg_to_rad(double d)
{
assert(0 <= d && d <= 360); // мы же договорились не перекручивать?!return d * (M_PI / 180);
}
Иная арифметика.
double deg_to_rad(int d) // ускоренная версия, если FPU медленное
{
d %= 360;
if(d<0) d += 360;
return angles[d];
}
Переход к фиксированной точке
int deg_cent_to_rad_cent(int dc) // от сотых градуса к сотым радиана
{
d %= 36000; if(d<0) d += 36000;
return rad_of_deg[d/100] + rad_of_cent[d%100];
}
Не приведи господь руками инлайнить такие конструкции, правда же?
Здравствуйте, minorlogic, Вы писали:
M>Я туплю , где в примкерах были шаблоны. или я мысль потерял ?
Наверное, потерял.
Мысль была такая: иногда нужно менять логику. Удобнее это делать централизованно, в инлайновых функциях (которыми, в частности, являются шаблоны).
Далее — примеры внедрений в логику: ассерты, производительность, смена арифметики.
С арифметикой, кстати, прямая дорога к шаблонам выражений. Чтобы можно было смешивать фиксированную и плавающую арифметику, например. И чтобы можно было смешивать разные единицы измерений.
Перекуём баги на фичи!
