Вот дожил до 45 лет и не знаю, зачем в С++ шаблоны.
Вот... совсем. Не использую их, да и всё тут.
Не, конечно vector<int> написать могу.
И прочее использование STL-я.
Но больше ничего с шаблонами не делаю.
Люди! А для чего вы используете шаблоны?
Может я чего упускаю?
Сложные программы пишу, например, в известном САПРе OrCad есть мой код.
Ну например графика. OpenGL для десктопов поддерживает double, a OpenGL ES толкьо float
Видимо имеет смысл делать матрицы и вектора (в смысле не контейнеры, а из геометрии) типо-независимыми? Шаблоны тут удобны
Здравствуйте, Varavva, Вы писали:
V>Здравствуйте, alpha21264, Вы писали:
V>Ну например графика. OpenGL для десктопов поддерживает double, a OpenGL ES толкьо float V>Видимо имеет смысл делать матрицы и вектора (в смысле не контейнеры, а из геометрии) типо-независимыми? Шаблоны тут удобны
Эээ... это одновременно, или это две разные сборки? Одна для OpenGL, другая для OpenGL ES?
Просто если это второе, то я бы обошелся typedef в каком-нибудь хедере.
Ну то есть идея-то понятна, немного разные типы в одной и той же функции.
Просто я пытался вообразить себе случай, когда это нужно и не вообразил.
А ещё какие случаи бывают?
Здравствуйте, alpha21264, Вы писали:
A>Народ!
A>Вот дожил до 45 лет и не знаю, зачем в С++ шаблоны. A>Вот... совсем. Не использую их, да и всё тут. A>Не, конечно vector<int> написать могу. A>И прочее использование STL-я. A>Но больше ничего с шаблонами не делаю. A>
A>Люди! А для чего вы используете шаблоны? A>Может я чего упускаю? A>
A>Сложные программы пишу, например, в известном САПРе OrCad есть мой код. A>
100%, сам юзаю их тока для контейнеров и всяких функторов/эвентов, всё
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, alpha21264, Вы писали:
A>Вот дожил до 45 лет и не знаю, зачем в С++ шаблоны. A>Вот... совсем. Не использую их, да и всё тут. A>Не, конечно vector<int> написать могу. A>И прочее использование STL-я. A>Но больше ничего с шаблонами не делаю.
A>Люди! А для чего вы используете шаблоны? A>Может я чего упускаю?
В общем-то ничего не упускаешь. Есть код и есть код.
Один решает конкретную задачу (твой случай), другой предполагается пихать во все дыры (та же стандартная библиотека).
Ооочень редко приходится использовать шаблоны для каких-нибудь адаптеров для получения данных там, где нет места "традиционному" полиморфизму.
Типа получить координаты пинов и вий. Но это просто чтобы дважды код не писать.
A>Сложные программы пишу, например, в известном САПРе OrCad есть мой код.
Агаааа, конкурент! А мой — в Hyperlynx, Expedition, TopoR, Simbeor
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, alpha21264, Вы писали:
A>Люди! А для чего вы используете шаблоны? A>Может я чего упускаю? A>
Templates делают ваш код коротким, максимально структурированным и reusable. Не бесплатно — сложность понимания кода и его отладка увеличатся, время компиляции также.
Здравствуйте, a_g_99, Вы писали:
__>Templates делают ваш код коротким, максимально структурированным и reusable.
это маркетинг и теория, в реальности всё совсем по другому
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, a_g_99, Вы писали:
K>>это маркетинг и теория, в реальности всё совсем по другому
__>Что же в вашей "реальности" по другому?
А в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут. Вот сделать код нечитабельным — это запросто (таких примеров предостаточно).
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, Kingofastellarwar, Вы писали:
K>>это маркетинг и теория, в реальности всё совсем по другому
__>Что же в вашей "реальности" по другому?
ну например в моей реальности любой шаблон рано или поздно сталкивается с тем, что как тока в каком-ньть месте логика хоть чуть-чуть зависит от типа то шаблон становится бесполезным
а вообще в 99% случаев просто нет ниткакой необходимости что-то типизировать
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, alpha21264, Вы писали:
A>>Люди! А для чего вы используете шаблоны? A>>Может я чего упускаю? A>>
__>Templates делают ваш код коротким, максимально структурированным и reusable. Не бесплатно — сложность понимания кода и его отладка увеличатся, время компиляции также.
Ну вот я так и знал, что обязательно будут священные войны.
А зачем нужно такое средство, при котором увеличивается сложность понимания и отладки?
Ведь сложность понимания для программиста — один из важных параметров, если не самый важный.
Вопрос-то был не про это. Не про то, нужны ли ли не нужны шаблоны. Допустим, нужны.
А про то, как вы их используете.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут. Вот сделать код нечитабельным — это запросто (таких примеров предостаточно).
Ну что за детский сад. "в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут".
В реальности у вас проект со sloc за 1m и 100500 классов которые "чуть чуть" различаются. И вам нужно создать единую концепцию чтобы не завязнуть в крутом копи-пасте.
В зависимости от сложности уровень абстракции повышается — это цена которую вы платите за сложность. Нет смысла этого пугаться.
Здравствуйте, Kingofastellarwar, Вы писали:
K>ну например в моей реальности любой шаблон рано или поздно сталкивается с тем, что как тока в каком-ньть месте логика хоть чуть-чуть зависит от типа то шаблон становится бесполезным
Специализуйте вашим типом. Это просто инструмент а не святой грааль.
Здравствуйте, Kingofastellarwar, Вы писали:
K>ну например в моей реальности любой шаблон рано или поздно сталкивается с тем, что как тока в каком-ньть месте логика хоть чуть-чуть зависит от типа то шаблон становится бесполезным
Для этого случая, внезапно, придуманы специализации.
Здравствуйте, alpha21264, Вы писали:
A>Ну вот я так и знал, что обязательно будут священные войны.
А чего ты ожидал, создавая тему в КСВ?
A>Вопрос-то был не про это. Не про то, нужны ли ли не нужны шаблоны. Допустим, нужны. A>А про то, как вы их используете.
Так надо было задавать вопрос в С/С++, а не в КСВ.
Здравствуйте, alpha21264, Вы писали:
A>Люди! А для чего вы используете шаблоны?
В общем случае для случаев, когда в С пишут макросы.
Банально: контейнеры, врапперы, прочая кодогенерация.
С шаблонами надо аккуратно, у неопытных падаванов есть риск написать на шаблонах всё и это на стороную тёмную их приведёт.
Самый конечно смак — variadic templates. Офигенная штука для написания всяких быстрых typesafe printf-style логгеров.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>А в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут. Вот сделать код нечитабельным — это запросто (таких примеров предостаточно).
__>Ну что за детский сад. "в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут". __>В реальности у вас проект со sloc за 1m и 100500 классов которые "чуть чуть" различаются. И вам нужно создать единую концепцию чтобы не завязнуть в крутом копи-пасте.
От проекта зависит. Если это какая-нибудь ORM, то да, похожести будет много.
Что касается проекта топикстартера, то там будет куча очень разного кода, где повторяющихся частей от силы процентов 10.
В основном из повторяющегося это контейнеры, какие-нибудь адаптеры и небольшие низкоуровневые алгоритмы.
Т.е. "кирпичики".
Все, что из них собирается, обычно создается в одном экземпляре и шаблонить там нет смысла — не пригодится. А вот неудобств, типа весь код в .h файле, добавит.
__>В зависимости от сложности уровень абстракции повышается — это цена которую вы платите за сложность. Нет смысла этого пугаться.
Многие помнят Климовскую библиотеку Dockable windows для WTL. Все круто, шаблоны везде, куда ни плюнь. Но отлаживать и расширять это поделие было практически невозможно. Разумный предел должен быть.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, alpha21264, Вы писали:
A>А зачем нужно такое средство, при котором увеличивается сложность понимания и отладки? A>Ведь сложность понимания для программиста — один из важных параметров, если не самый важный.
Сложность просто повышает порог входа для специалиста. Если бы все было просто, вознаграждение программистов было бы весьма низким
A>Вопрос-то был не про это. Не про то, нужны ли ли не нужны шаблоны. Допустим, нужны. A>А про то, как вы их используете.
В соответствии с их предназначением. Если не боитесь прослыть национал-предателем, можете почитать вражеские книги Александреску, Мейерса и Саттера. Там более менее разжевано. Гораздо более эффективный вариант — сделать быстрое ревью на гитхабе какого-нибудь блинка.
Здравствуйте, alpha21264, Вы писали:
A>Вот дожил до 45 лет и не знаю, зачем в С++ шаблоны.
дожил до 80 лет, но так и не понял зачем все эти формульные трансляторы? простой пример — моя программа ищущая дубликаты данных, работает со скоростью один байт/такт, а вражеская созданная компилятором — втрое медленней. недавно читал статью с FAST'12, где этот алгоритм перенесли на GPU поскольку на CPU он видите ли лажает. а всё потому что нынешняя молодёжь не умеет в машкодах писать
в общем, я считаю что компиляторы и калькуляторы — это зло. и начать бороться с ними надо с детсада. вместо айфона выдавать каждому ребёнку бз-34, это и для мускулов нагрузка, и для ума
всяких сопливых детей младше 80 прошу в тему не писать
Здравствуйте, BulatZiganshin, Вы писали:
BZ>в общем, я считаю что компиляторы и калькуляторы — это зло. и начать бороться с ними надо с детсада. вместо айфона выдавать каждому ребёнку бз-34, это и для мускулов нагрузка, и для ума
бз-34 раслаюляет, тк в системе команд даже * и "/" есть, обратная польская запись, нормальный индикатор, клавиатура и БП от холодильника не сбрасываеться
лучше ИК80 без ROM, с поразрядным вводом и контролем на светодиодах (видел такую систему, занрузчик монитора с перфоленты по понедельникам вносили вручную)
Здравствуйте, Lazin, Вы писали:
A>>Вот дожил до 45 лет и не знаю, зачем в С++ шаблоны. L>Для того, чтобы потом офигевать от мегабайтных ошибок компиляции.
Ты их просто overcook
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
А не надо использовать стандартные библиотеки. Они на то и стандартные чтоб покрывать как можно бОльшую площадь платформ, оттого работают на них одинаково плохо и спроектированы по общему знаменателю.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
CC>А не надо использовать стандартные библиотеки. Они на то и стандартные чтоб покрывать как можно бОльшую площадь платформ, оттого работают на них одинаково плохо и спроектированы по общему знаменателю.
Да-да, надо использовать самописные с непонятным интерфейсом и никому не известным количеством внутренних багов!
А вот у меня вот так все отлично работает, аж в двух вариантах:
auto ns1 = chrono::duration<double, nano>(end - start).count();
auto ns2 = chrono::nanoseconds(end - start).count();
Не говоря уже о том, что даже в стандартной поставке есть сразу 3 таймера: system_clock, steady_clock, high_resolution_clock (и реализация/платформа может добавить свои, если они есть, с внешнего генератора, например).
Я вообще фигею просто. Сначала кричат, что стандартная библиотека плохая, потому что в ней всего один генератор псевдослучайных чисел, взыскательных пользователей не удовлетворяет.
Ладно, дают им на выбор туеву хучу оных (побогаче, чем в Rust): http://en.cppreference.com/w/cpp/numeric/random — на выбор и алгоритмы (включая аппаратный источник!), и распределения (штук двадцать!)
Так нет же, опять крик: теперь заставляют выбирать!
Вы, блин, определитесь уже наконец, что вам нужно — функциональный инструмент или поделка для домохозяек из серии "640к хватит всем".
Не говоря уже о том, что если ты собираешься использовать один единственный генератор, то просто делаешь
И тем более уж не говоря о том, что если ему нужно генерить простые инты, а не обобщенное хз что из mt19937 (у которого, к слову, result_type прописан в Стандарте), то достаточно просто написать uniform_int_distribution<> и не парить никому мозг страшным mt19937::result_type.
И, опять же, не говоря о том, что и в Rust полноценная генерация совсем не короче, чем плюсовая версия:
use std::rand;
use std::rand::distributions::{Normal, IndependentSample};
// mean 2, standard deviation 3let normal = Normal::new(2.0, 3.0);
let v = normal.ind_sample(&mut rand::task_rng());
#include <random>
std::mt19937 gen(std::random_device()());
// mean 2, standard deviation 3
std::normal_distribution<> normal(2,3);
auto v = normal(gen);
CC>А не надо использовать стандартные библиотеки. Они на то и стандартные чтоб покрывать как можно бОльшую площадь платформ, оттого работают на них одинаково плохо и спроектированы по общему знаменателю.
Можно ткнуть пальцем, в каком месте chrono/random работают плохо?
Здравствуйте, jazzer, Вы писали:
J>Можно ткнуть пальцем, в каком месте chrono/random работают плохо?
К рандому у меня лично претензии performance плана: правильная реализация Mersenne на моей машине выдаёт ~7.8 Gb/s fillrate (2Gb за 0.254 сек). Библиотечный до этого "несколько" не дотягивает.\
Колво разных генераторов — радует. Но код внутри оставляет ощущение overcomplicated и overengineered.
chrono просто overcomplicated. Ну и по качеству реализации тоже так себе: в гнусной версии это просто обёртка над time_t, какой там HRT. На винде в код не смотрел, но HRT выдаёт очень даже low resolution значения. Я интринсиками или системным API получаю более точные цифры.
Если заглянуть в код то, если цензурно, "сложно о простом" будет самым точным описанием. Там Александреску не просто укусил, он авторов грыз походу недели две а то и больше.
Как generic библиотеки они ОК.
Но есть лучше.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
J>Не говоря уже о том, что даже в стандартной поставке есть сразу 3 таймера: system_clock, steady_clock, high_resolution_clock (и реализация/платформа может добавить свои, если они есть, с внешнего генератора, например).
Дада, стандартная поставка.
typedef system_clock high_resolution_clock;
По умолчанию даже монотоник на system_clock завёрнута.
J>Я вообще фигею просто. Сначала кричат, что стандартная библиотека плохая, потому что в ней всего один генератор псевдослучайных чисел, взыскательных пользователей не удовлетворяет. J>Ладно, дают им на выбор туеву хучу оных (побогаче, чем в Rust): http://en.cppreference.com/w/cpp/numeric/random — на выбор и алгоритмы (включая аппаратный источник!), и распределения (штук двадцать!)
Если бы они ещё и написаны были хорошо с точки зрения производительности.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, landerhigh, Вы писали:
CC>>А не надо использовать стандартные библиотеки. Они на то и стандартные чтоб покрывать как можно бОльшую площадь платформ, оттого работают на них одинаково плохо и спроектированы по общему знаменателю.
L>Да-да, надо использовать самописные с непонятным интерфейсом и никому не известным количеством внутренних багов!
Чтоб далеко за примером не ходить: у нас уже есть OpenSSL, написанный известными личностями, с простым, удобным и понятным интерфейсом (и особенно кодом внутри) и совершенно без багов.
Не боги горшки обжигают.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
L>>Да-да, надо использовать самописные с непонятным интерфейсом и никому не известным количеством внутренних багов! CC>Чтоб далеко за примером не ходить: у нас уже есть OpenSSL, написанный известными личностями, с простым, удобным и понятным интерфейсом (и особенно кодом внутри) и совершенно без багов. CC>Не боги горшки обжигают.
Здравствуйте, CreatorCray, Вы писали:
CC>Если бы они ещё и написаны были хорошо с точки зрения производительности.
Т.е. у тебя претензии не к стандартной библиотеке (т.е. к интерфейсу) производства комитета по С++, а к конкретной реализации производства конкретного компиляторостроителя?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>Можно ткнуть пальцем, в каком месте chrono/random работают плохо?
CC>К рандому у меня лично претензии performance плана: правильная реализация Mersenne на моей машине выдаёт ~7.8 Gb/s fillrate (2Gb за 0.254 сек). Библиотечный до этого "несколько" не дотягивает.\
ну т.е. претензии к реализации, а не к самой библиотеке. ОК.
Здравствуйте, landerhigh, Вы писали:
L>А с каких это пор OpenSSL вошел в стандарт C++?
Я про доверие к несамописным библиотекам.
Стандарт описывает только интерфейс и контракты. Кто будет писать имплементацию стандарт не определяет.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
L>>А с каких это пор OpenSSL вошел в стандарт C++? CC>Я про доверие к несамописным библиотекам.
А кто говорил про доверие к несамописным библиотекам?
CC>Стандарт описывает только интерфейс и контракты. Кто будет писать имплементацию стандарт не определяет.
Здравствуйте, jazzer, Вы писали:
J>ну т.е. претензии к реализации, а не к самой библиотеке. ОК.
То как она спроектирована (всё на шаблонах) даёт основания считать что сделать нормальную реализацию некоторых алгоритмов (того же мерсена, который крайне выигрывает от правильно написанного SSE) будет геморно, поэтому никто делать её просто не станет. А нафига — и так ведь сносно работает.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
J>Т.е. у тебя претензии не к стандартной библиотеке (т.е. к интерфейсу) производства комитета по С++, а к конкретной реализации производства конкретного компиляторостроителя?
1. Любая реализация будет ограничена заданными рамками интерфейса.
2. В проект пойдёт код из "конкретной реализации" а не абстрактный стандарт.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>Т.е. у тебя претензии не к стандартной библиотеке (т.е. к интерфейсу) производства комитета по С++, а к конкретной реализации производства конкретного компиляторостроителя?
CC>1. Любая реализация будет ограничена заданными рамками интерфейса. CC>2. В проект пойдёт код из "конкретной реализации" а не абстрактный стандарт.
Т.е. ты фактически утверждаешь, что в рамках описанного в Стандарте интерфейса невозможно написать эффективную реализацию?
Здравствуйте, landerhigh, Вы писали:
L>А кто говорил про доверие к несамописным библиотекам?
Ты
L>Да-да, надо использовать самописные...
Мы тут обсуждаем твою конкретную претензию к источнику кода. После того как выясним что самописные библиотеки ничем не хуже не-самописных можно будет двигаться дальше.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>ну т.е. претензии к реализации, а не к самой библиотеке. ОК. CC>То как она спроектирована (всё на шаблонах) даёт основания считать что сделать нормальную реализацию некоторых алгоритмов (того же мерсена, который крайне выигрывает от правильно написанного SSE) будет геморно, поэтому никто делать её просто не станет. А нафига — и так ведь сносно работает.
Э-э-э... Специализации для SSE-совместимых типов никто не отменял (SSE все равно только с конкретными типами будет работать).
Здравствуйте, jazzer, Вы писали:
J>Т.е. ты фактически утверждаешь, что в рамках описанного в Стандарте интерфейса невозможно написать эффективную реализацию?
Думаю что можно. Но это будет геморройнее, поэтому вряд ли кто либо это станет делать ради стандартной либы.
Куда проще будет сделать нешаблонную версию и забацать её как полагается.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
J>Э-э-э... Специализации для SSE-совместимых типов никто не отменял (SSE все равно только с конкретными типами будет работать).
Можешь попробовать реализовать.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>Т.е. ты фактически утверждаешь, что в рамках описанного в Стандарте интерфейса невозможно написать эффективную реализацию? CC>Думаю что можно. Но это будет геморройнее, поэтому вряд ли кто либо это станет делать ради стандартной либы. CC>Куда проще будет сделать нешаблонную версию и забацать её как полагается.
и что же помешает позвать эту нешаблонную версию из соответствующей специализации стандартной функции?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>Э-э-э... Специализации для SSE-совместимых типов никто не отменял (SSE все равно только с конкретными типами будет работать). CC>Можешь попробовать реализовать.
Ну если бы мне это было нужно, реализовал бы. Например, некоторые stl-ные алгоритмы я специализировал для конкретных типов, полет нормальный.
В общем, в сухом остатке, претензий к самой библиотеке у тебя нет, есть претензии к конкретным реализациям, и есть смутные подозрения, что подсунуть правильную реализацию, оставаясь в рамках интерфейса, будет трудно.
Я правильно резюмировал?
Здравствуйте, CreatorCray, Вы писали:
L>>А кто говорил про доверие к несамописным библиотекам? CC>Ты CC>
L>Да-да, надо использовать самописные...
CC>Мы тут обсуждаем твою конкретную претензию к источнику кода. После того как выясним что самописные библиотеки ничем не хуже не-самописных можно будет двигаться дальше.
Кому, надо, тот понял, что я имею в виду. А дальше кормить тролля я не намерен.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>в общем, я считаю что компиляторы и калькуляторы — это зло. и начать бороться с ними надо с детсада. вместо айфона выдавать каждому ребёнку бз-34, это и для мускулов нагрузка, и для ума
Эээ... А почему не Б3-21? Еще сильнее к экономии приучит. У него, ЕМНИП, 7 регистров против 14 у 34-ки.
BZ>в общем, я считаю что компиляторы и калькуляторы — это зло. и начать бороться с ними надо с детсада. вместо айфона выдавать каждому ребёнку бз-34, это и для мускулов нагрузка, и для ума
даешь тачку-смартфон и чемодан с аккумулятором в массы!
80% людей оценивают свое мастерство выше среднего...
__>>Что же в вашей "реальности" по другому?
SVZ>А в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут. Вот сделать код нечитабельным — это запросто (таких примеров предостаточно).
Ты что, GUI приложения пишешь?
Ощущается так.
Шаблоны позволяют писать БОЛЕЕ БЫСТРЫЙ код. Шаблоны дают компилятору возможность соптимизировать код под определённый тип, и это значительно ускоряет.
Например, пишешь ты массив через шаблоны. Ну или кэш подкачки с диска. Дела это не меняет.
Если бы ты писал универсальный код на С, адресация (*) разложилась на ассемблере как
mov eax, index
mov edx, sizeof(ParameterType)
mul eax
add eax, base
здесь операция умножения mul весьма медленная!!! это будет работать плохо и долго
А для шаблона с параметром длиной 9 компилятор сможет записать
lea eax, [edx][edx*8]
это ЗНАЧИТЕЛЬНО увеличивает скорость доступа!!! К кэшу или к массиву, например.
При этом подобные оптимизации компилятор способен делать для большинства длин типов, например, для 3, 5,7,8 и так далее
И для типа каждой длины компилятор сгенерит оптимальный код. Индивидуально.
Плата за это — это раздувание кода: шаблон не создаёт тип, тип создаётся для каждой вариации шаблона.
И компилер для каждого набора параметров будет генерить свой код массива, например.
Использовал код массива для 20 типов — получил 20 наборов функций для работы с массивом.
И вообще: то, что вы не умеете пользоватся инструментом, ещё не значит, что он не нужен. Просто нужно знать свой манёвр: когда и какой инструмент использовать хорошо, когда плохо, а когда на вкус разработчика.
Резюмирую: шаблоны мощное средство написания оптимального кода, приводящее к раздуванию размера итогового исполнимого файла.
Здравствуйте, Molchalnik, Вы писали: M>Здравствуйте, Stanislav V. Zudin, Вы писали:
__>>>Что же в вашей "реальности" по другому? SVZ>>А в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут. Вот сделать код нечитабельным — это запросто (таких примеров предостаточно). M>Ты что, GUI приложения пишешь? M>Ощущается так.
Хе-хе, не совсем. Хотя и гуя предостаточно. M>Шаблоны позволяют писать БОЛЕЕ БЫСТРЫЙ код. Шаблоны дают компилятору возможность соптимизировать код под определённый тип, и это значительно ускоряет.
M>Например, пишешь ты массив через шаблоны. Ну или кэш подкачки с диска. Дела это не меняет.
. M>В массиве пишешь адресацию типа
M>ParameterType & address_of_type = base[index]; (*)
M>Задаёшь написанный массив для типа длинной 9 бит
M>Если бы ты писал универсальный код на С, адресация (*) разложилась на ассемблере как
M>mov eax, index M>mov edx, sizeof(ParameterType) M>mul eax M>add eax, base
M>здесь операция умножения mul весьма медленная!!! это будет работать плохо и долго
M>А для шаблона с параметром длиной 9 компилятор сможет записать
M>lea eax, [edx][edx*8]
M>это ЗНАЧИТЕЛЬНО увеличивает скорость доступа!!! К кэшу или к массиву, например.
M>При этом подобные оптимизации компилятор способен делать для большинства длин типов, например, для 3, 5,7,8 и так далее
M>И для типа каждой длины компилятор сгенерит оптимальный код. Индивидуально.
M>Плата за это — это раздувание кода: шаблон не создаёт тип, тип создаётся для каждой вариации шаблона.
M>И компилер для каждого набора параметров будет генерить свой код массива, например.
M>Использовал код массива для 20 типов — получил 20 наборов функций для работы с массивом.
Превосходно, ты привел пример контейнера, который используется для 20 разных типов. В данном случае логично использовать шаблоны. Кстати, если бы ты был чуточку внимательнее, я этот случай упоминал в сообщении строчкой выше:
В основном из повторяющегося это контейнеры, какие-нибудь адаптеры и небольшие низкоуровневые алгоритмы.
Т.е. "кирпичики".
А если задача стоит, ну скажем, написать восстановление электрической схемы из геометрических примитивов, то куда ты присобачишь шаблоны? Задача одна, выполняется для одного вполне определенного набора данных и параметризировать ее смысла нет. А таких задач, что у меня, что у топикстартера как раз примерно 90% от общего кода. M>И вообще: то, что вы не умеете пользоватся инструментом, ещё не значит, что он не нужен. Просто нужно знать свой манёвр: когда и какой инструмент использовать хорошо, когда плохо, а когда на вкус разработчика.
Да ладно, что нас старых попрекать-то, кодим как можем... M>Резюмирую: шаблоны мощное средство написания оптимального кода, приводящее к раздуванию размера итогового исполнимого файла.
Все-таки не удержусь и проедусь по твоему примеру.
Ну вот имеем мы твой массив
std::vector<ParameterType> base;
Куда нужно воткнуть шаблон, чтобы компилятор поменял вычисление смещения?
Или я неправильно понял и ты имел в виду работу с массивом байт, типа такого:
т.к. размер типа известен на этапе компиляции и поэтому код подвергается дополнительным оптимизациям на ассемблерном уровне.
Первый же код хорош тем, что он будет существовать в единственном экземпляре для всех типов. Объём кода меньше.
SVZ>Или я неправильно понял и ты имел в виду работу с массивом байт, типа такого: SVZ>
уточняю: нет разницы между конкретной реализацией и реализацией шаблона. Шаблон — лишь метод получения конкретной реализации кода.
Разница возникает, когда ты пишешь универсальный код в стиле C++ vs универсальный код в стиле C
В первом случае компилятор знает размер типа на этапе компиляции, и поэтому может эффективно оптимизировать.
Во втором размер типа передаётся как параметр, что требует дополнительно пушить параметр в стек, неоптимально выполнять вычислительные действия с ним и так далее.
Здравствуйте, jazzer, Вы писали:
J>В общем, в сухом остатке, претензий к самой библиотеке у тебя нет
К многим её частям есть — overcomplicated и overengineered интерфейс, который тянет за собой множество проблем реализации.
J> есть претензии к конкретным реализациям
Имеются, верно.
Надо заметить что во многом реализации сделаны чтоб удовлетворять требованиям интерфейса. Кстати я допускаю что в этих рамках сделано максимально хорошо.
Но overall результат получается увы довольно средний.
Далеко ходить не надо, уже кстати обсасывали — стандартный std::sort ускоряется в несколько раз если научить его принимать tree way comparison operator вместо operator < (). И чем тяжелее компаратор — тем лучше это видно.
На том же самом алгоритме.
Выходит в угоду интерфейсу сделано намеренное ухудщение О характеристик алгоритма. Я кстати в той теме показал как можно было сделать sort внутри с 3-way а снаружи сделать стаб для less only.
J> и есть смутные подозрения, что подсунуть правильную реализацию, оставаясь в рамках интерфейса, будет трудно.
Не смутные, а так верно, да.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
CC>>Куда проще будет сделать нешаблонную версию и забацать её как полагается. J>и что же помешает позвать эту нешаблонную версию из соответствующей специализации стандартной функции?
Рамки заданного интерфейса.
Например банальное получение по одному значению через operator() жрёт приличный кусок CPU и что то не очень хочет оптимизироваться.
Далее, стандартный интерфейс не ограничивает никак alignment, который требуется для SSE. Unaligned access же либо кинет exception либо (если использовать соответсвующие интринсики для выгрузки в память) будет заметно медленнее.
Думаешь я не пробовал?
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Возьми любую сложную программу на С++, которую писали люди, знающие С++, и там будут шаблоны.
"сложная" — это где много LOC, много модулей в архитектуре.
Например LLVM или Chromium.
Если ты нашел программу без шаблонов — покажи нам, мы поясним где ими можно улучшить код.
Здравствуйте, alpha21264, Вы писали:
A>Люди! А для чего вы используете шаблоны? A>Может я чего упускаю? A> A>Сложные программы пишу, например, в известном САПРе OrCad есть мой код. A>
Понятно что можно и без них. Как можно и без ООП, и без ФП, и даже без процедурного программирования. На ассемблере можно.
Проблема шаблонов в том, что они используются для "метапрограммирования на шаблонах", которое скорее всего изначально не задумывалось. Вот отсюда и навороты типа буста, и километровые сообщения об ошибках, и увеличенное время компиляции (хотя это скорее следствие дурацкого наследия cи — системы include вместо модулей). Но программистам понравилась возможность не ждать десятилетиями нового стандарта, а получать недостающие фичи языка сразу. Поэтому, несмотря на все недостатки и неудобства, оно работает и им пользуются.
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
Здравствуйте, CreatorCray, Вы писали:
CC>Далеко ходить не надо, уже кстати обсасывали — стандартный std::sort ускоряется в несколько раз если научить его принимать tree way comparison operator вместо operator < (). И чем тяжелее компаратор — тем лучше это видно. CC>На том же самом алгоритме. CC>Выходит в угоду интерфейсу сделано намеренное ухудщение О характеристик алгоритма. Я кстати в той теме показал как можно было сделать sort внутри с 3-way а снаружи сделать стаб для less only.
Тот же Степанов говорит, что алгоритмов должно быть много, если один алгоритм выигрывает у другого в чём-то, а в чём-то наоборот проигрывает — то нужны оба, чтобы покрыть всё алгоритмическое пространство.
Вот конкретно его слова про insertion sort в STL:
By the way, does STL have insertion sort inside? It has, of course it does.
So, what happend during standartization process: they took something which was in the library and was used by the library and threw it out. The argument was: "oh, we already have too many sorts".
Is it a good argument "too many sorts"? No, you need to have as many sorts as people might need when they do practical things.
Посмотри его Notes on Programming, там, например, разбирается 3-way partition, который упорядочивает элементы в соответствии с функцией, которая возвращает 0, 1, 2.
То что в стандарте нет другого sort — это недостаток стандарта, а никак не интерфейса std::sort
Здравствуйте, CreatorCray, Вы писали:
J>>Э-э-э... Специализации для SSE-совместимых типов никто не отменял (SSE все равно только с конкретными типами будет работать). CC>Можешь попробовать реализовать.
Eigen без проблем использует внутри SSE/NEON/AltiVec.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, alpha21264, Вы писали:
A>Возьми любую сложную программу на С++, которую писали люди, знающие С++, и там будут шаблоны. A>"сложная" — это где много LOC, много модулей в архитектуре.
Много чего? Ты когда пишешь, подразумевай, что мне набор терминов тоже мало знаком.
Хоть ссылку на Википедию ставь.
A>Если ты нашел программу без шаблонов — покажи нам, мы поясним где ими можно улучшить код.
Ну например CUPS. Это сервер печати в Линуксе. (Есть в исходных кодах).
Здравствуйте, CreatorCray, Вы писали:
CC>Далее, стандартный интерфейс не ограничивает никак alignment, который требуется для SSE. Unaligned access же либо кинет exception либо (если использовать соответсвующие интринсики для выгрузки в память) будет заметно медленнее. CC>Думаешь я не пробовал?
видимо давно не пробовал. unaligned access уже давно бесплатен, хуже того — в vex-coded операциях выравнивания операндов из памяти не требуется
Здравствуйте, Molchalnik, Вы писали:
M>Если бы ты писал универсальный код на С
Это как?
M> адресация (*) разложилась на ассемблере как M>mov eax, index M>mov edx, sizeof(ParameterType) M>mul eax M>add eax, base
Уже неверно. sizeof (ParameterType) — константа.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>То что в стандарте нет другого sort — это недостаток стандарта, а никак не интерфейса std::sort
Ну дык интерфейс std::sort это же часть стандарта.
О чём собственно и речь.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, BulatZiganshin, Вы писали:
BZ>видимо давно не пробовал. unaligned access уже давно бесплатен
Для SSE?
BZ> хуже того — в vex-coded операциях выравнивания операндов из памяти не требуется
Давно не смотрел на новые команды, надо будет глянуть.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
EP>>То что в стандарте нет другого sort — это недостаток стандарта, а никак не интерфейса std::sort CC>Ну дык интерфейс std::sort это же часть стандарта. CC>О чём собственно и речь.
Есть 3-way sort, есть predicate-based sort — обе имеют свои плюсы и минусы. Predicate-based — самая общая.
А есть ещё всякие integer sort, которые тоже имеют своё практическое применение.
В чём твоя претензия? В том что нет других видов сортировок в стандарте? Я думаю многие с этим согласятся (к слову сказать, в ISO C++ разных сортировок больше чем в других языках).
Но что-то не пойму, а как вообще это относится к шаблонам?
Здравствуйте, alpha21264, Вы писали:
A>Много чего? Ты когда пишешь, подразумевай, что мне набор терминов тоже мало знаком. A>Хоть ссылку на Википедию ставь.
позволю себе вмешаться, по-моему это lines of code
Здравствуйте, alpha21264, Вы писали:
A>>Возьми любую сложную программу на С++, которую писали люди, знающие С++, и там будут шаблоны. A>>"сложная" — это где много LOC, много модулей в архитектуре.
A>Много чего? Ты когда пишешь, подразумевай, что мне набор терминов тоже мало знаком.
это сокращение, а не термин.
сокращения типа KB,MB,GB — тоже расшифровывать? A>Хоть ссылку на Википедию ставь.
викичто? тебя гугл чтоли забанил?
A>>Если ты нашел программу без шаблонов — покажи нам, мы поясним где ими можно улучшить код. A>Ну например CUPS. Это сервер печати в Линуксе. (Есть в исходных кодах).
на С++, да?
Здравствуйте, CreatorCray, Вы писали:
EP>>Eigen без проблем использует внутри SSE/NEON/AltiVec. CC>А интерфейс у него как у random?
Eigen я привёл как пример использования шаблонов с SSE. Его легко адаптировать к любым интринсинкам как раз через специализацию. Например базовый код для SSE — 650 строк, если брать весь, со спец. функциями и специализациями для std::complex, то получается 1.5k строк — и это всё, SSE там больше нет — всё остальное в общем виде.
Здравствуйте, CreatorCray, Вы писали:
BZ>>видимо давно не пробовал. unaligned access уже давно бесплатен CC>Для SSE?
да. процессору уже всё равно какую команду (mova,movu,ld) ты исполняешь, остались только бессмысленные проверки для mova и reg-mem операций. а при использовании vex нет и проверок
Здравствуйте, Molchalnik, Вы писали:
M>Кто ж спорит, константа. Что не верного? Загрузка константы в регистр. Например, при размере ParameterType в 9 байт туда будет загружатся 9
Для константы будет сгенерён точно такой же LEA eax, [eax+eax*8] как и для шаблонного.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, BulatZiganshin, Вы писали:
BZ>да. процессору уже всё равно какую команду (mova,movu,ld) ты исполняешь, остались только бессмысленные проверки для mova и reg-mem операций. а при использовании vex нет и проверок
Это радует. Спасибо за инфу.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, alpha21264, Вы писали:
A>>>Люди! А для чего вы используете шаблоны?
J>>Для зарабатывания денег.
A>Это очень общий ответ.
Да нет, самый что ни на есть конкретный, Строуструп не зря же сделал С++ именно таким:
C. Hо это же история века. Я просто хотел чтоб мои приятели-программисты помнили меня за то, что я для них сделал. Знаете как сейчас оплачивается программирование на C++ ?
И. Последнее, что я слышал — настоящие профессионалы зарабатывают $70-80 в час.
C. Понимаете теперь? И я уверен, что он заслуживает этих денег. Отслеживание всех этих ловушек, которые я встроил в C++ — не легкая работа.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Molchalnik, Вы писали:
M>>Кто ж спорит, константа. Что не верного? Загрузка константы в регистр. Например, при размере ParameterType в 9 байт туда будет загружатся 9 CC>Для константы будет сгенерён точно такой же LEA eax, [eax+eax*8] как и для шаблонного.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, Няшка, Вы писали:
Н>>Аналоговые гораздо проще и быстрее!
A>Вообще-то нынешние цифровые уже обогнали аналоговые. И превратились в DSP.
1. Я бы не стал так однозначно утверждать.
2. Развитие аналоговых компьютеров остановилось.
3. От решаемых задач тоже всё сильно зависит.
Я боюсь, что мне не хватит "базы", чтобы доказывать состоятельность аналоговых компьютеров, но можно отталкиваться от того, что цифровым компьютерам до человеческого мозга пока далеко.
80% людей оценивают свое мастерство выше среднего...
Здравствуйте, Няшка, Вы писали:
Н>Я боюсь, что мне не хватит "базы", чтобы доказывать состоятельность аналоговых компьютеров, но можно отталкиваться от того, что цифровым компьютерам до человеческого мозга пока далеко.
Здравствуйте, Няшка, Вы писали:
Н>>>Аналоговые гораздо проще и быстрее!
A>>Вообще-то нынешние цифровые уже обогнали аналоговые. И превратились в DSP.
Н>1. Я бы не стал так однозначно утверждать. Н>2. Развитие аналоговых компьютеров остановилось.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, alpha21264, Вы писали:
A>>>Возьми любую сложную программу на С++, которую писали люди, знающие С++, и там будут шаблоны. A>>>"сложная" — это где много LOC, много модулей в архитектуре.
A>>Много чего? Ты когда пишешь, подразумевай, что мне набор терминов тоже мало знаком. A>это сокращение, а не термин. A>сокращения типа KB,MB,GB — тоже расшифровывать?
Если рядом с цифрой, то я бы догадался. Если в тексте, то нет.
A>>Хоть ссылку на Википедию ставь. A>викичто? тебя гугл чтоли забанил?
Гугл выдаёт ссылку на чистящее средство.
Я предположил, что ты не это имел в виду.
A>>>Если ты нашел программу без шаблонов — покажи нам, мы поясним где ими можно улучшить код. A>>Ну например CUPS. Это сервер печати в Линуксе. (Есть в исходных кодах). A>на С++, да?
А какая разница на С или на С++?
Наверное по сравнению с более простым (примитивным) языком проще преимущества показать?
Ну хорошо, давай возьмём библиотеку Qt. Она на С++.
Там даже есть своя библиотека контейнеров и она на темплейтах.
Но весь остальной код почему-то без них.
PS.
В очередной раз обращаю внимание — я не утверждаю, что шаблоны не нужны.
Я хочу посмотреть примеры, где они дают существенный выигрыш. С самообразовательной целью.
Судя по количеству смайликов, я всё же не совсем ясно объяснил.
Если писать универсальный код на C и писать универсальный код на шаблонах C++, то второй вариант будет производительнее.
Я это отдельно и в явном виде обозначил.
Но некоторые товарищи почему-то тут же начали сравнивать неуниверсальный код, код для конкретного типа, с кодом на шаблонах.
Естественно, абсолютно нет разницы, как вы получите код X — напишете его ручками, или этот код сгенерит шаблон, после инстанцирования заданных шаблонных параметров.
Главное — помнить, что шаблон не является кодом. Шаблон можно сравить с формой для отливки кода. Код появляется только в момент инстанцирования, при задании конкретных параметров, и для каждого набора параметров он дублируется, а заодно оптимизируется индивидуально. В этом-то и его сила — в индивидуальной оптимизации для каждой инстанции.
Здравствуйте, alpha21264, Вы писали:
A>PS. A>В очередной раз обращаю внимание — я не утверждаю, что шаблоны не нужны. A>Я хочу посмотреть примеры, где они дают существенный выигрыш. С самообразовательной целью. A>
1. Напиши оптимальный кэш на плюсах, а потом на чистом си, и сравни производительность
2. Изучи статический полиморфизм. В отличии от динамического полиморфизма, он более производителен.
3. Чтобы каждый раз, когда тебе понадобится вектор, не прибивать его гвоздями к этому куску кода и к этому типу
Я видел очень старый код, смешанный на СИ и СИ плюс плюс, и ассемблере, где было очень много копипасты и велосипедов. В каждом месте каждый новый программер писал свой вектор, прибивали гвоздями свой кэш подкачки из файла для специфических типов. Бррр, жуть.
Шаблоны разруливают это на раз.
А где ты возьмешь ParameterType в "универсальный код на С"?
Макросами выкружишь?
А иначе ParameterType будет void* и sizeof (ParameterType) будет рантаймом, вместе с вытекающим из этого
mul eax
Здравствуйте, alpha21264, Вы писали:
A>Ну хорошо, давай возьмём библиотеку Qt. Она на С++. A>Там даже есть своя библиотека контейнеров и она на темплейтах. A>Но весь остальной код почему-то без них. A>
Это не правда.
Здравствуйте, Patalog, Вы писали:
CC>>Уже неверно. sizeof (ParameterType) — константа. P>А где ты возьмешь ParameterType в "универсальный код на С"?
Это надо спрашивать у автора. Мне тоже интересно.
P>Макросами выкружишь? P>А иначе ParameterType будет void* и sizeof (ParameterType) будет рантаймом, вместе с вытекающим из этого
Дык ведь sizeof это всегда константа
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Patalog, Вы писали:
CC>>>Уже неверно. sizeof (ParameterType) — константа. P>>А где ты возьмешь ParameterType в "универсальный код на С"? CC>Это надо спрашивать у автора. Мне тоже интересно.
.
P>>Макросами выкружишь? P>>А иначе ParameterType будет void* и sizeof (ParameterType) будет рантаймом, вместе с вытекающим из этого
CC>Дык ведь sizeof это всегда константа
Вот только есть у меня сомнения относительно шибкого ускорения lea vs mov.
В одном из проектов у нас был собственный аналог std::vector. Массив был шаблонный, но память под элементы выделяли как массив байт. Т.е. внутри работали как в старом добром Си, с приведением типа. Тип данных только в интерфейсной части и при вычислении размера элемента и все такое... Применялся он только для POD типов. При перевыделении памяти использовали memcpy, вместо поэлементного копирования.
Дык тесты однозначно показывали скорость работы много выше, чем у std::vector, хотя, казалось бы, у компилятора не было информации о фактическом размере элементов и все такое.
Это было в 2009-2010 гг. Возможно сейчас, на других процессорах и с другими компиляторами картина будет другой.
Было бы любопытно ознакомиться с реальными замерами, вместо теоретических рассуждений "что мог бы сделать компилятор...".
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Вот только есть у меня сомнения относительно шибкого ускорения lea vs mov. SVZ>В одном из проектов у нас был собственный аналог std::vector. Массив был шаблонный, но память под элементы выделяли как массив байт. Т.е. внутри работали как в старом добром Си, с приведением типа. Тип данных только в интерфейсной части и при вычислении размера элемента и все такое... Применялся он только для POD типов. При перевыделении памяти использовали memcpy, вместо поэлементного копирования. SVZ>Дык тесты однозначно показывали скорость работы много выше, чем у std::vector, хотя, казалось бы, у компилятора не было информации о фактическом размере элементов и все такое. SVZ>Это было в 2009-2010 гг. Возможно сейчас, на других процессорах и с другими компиляторами картина будет другой.
Если требуется работать именно как с массивом байт, то информация о типе особо не поможет.
(тем не менее, предполагаю, что хотя вы и работали как с массивом байт — информация о типе всё равно использовалась, например при вычислении смещения элемента вы же использовали sizeof(T)?)
Более того, ваш vector, скорей всего не был полным аналогом std::vector'а по функциональности и exception safety.
Вот кстати, sizeof(T) для qsort передаётся из-вне, то есть является runtime значением. Стандартный C подход (точнее "без-шаблонный").
SVZ>Было бы любопытно ознакомиться с реальными замерами, вместо теоретических рассуждений "что мог бы сделать компилятор...".
Если тебе интересен какой-то конкретный case — то можем разобрать его, с замерами и ассемблерными листингами. Но только давай не в КСВ.
Здравствуйте, alpha21264, Вы писали:
A>Народ!
Не поддаваться на провокации!
A>Вот дожил до 45 лет и не знаю, зачем в С++ шаблоны.
Тут нечем гордиться.
A>Люди! А для чего вы используете шаблоны?
Чтобы глумиться над окружающими, и видеть их лица, когда они потерялись в приоритетах шаблонов функций.
A>Может я чего упускаю?
Уже упустил.
A>Сложные программы пишу, например, в известном САПРе OrCad есть мой код.
Даешь C++11!!!
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Если тебе интересен какой-то конкретный case — то можем разобрать его, с замерами и ассемблерными листингами. EP>Но только давай не в КСВ.
А где же ещё компьютерные срачи устраивать?
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Бывает, когда надо. Вот например есть у нас массив структурок разных, но имеющих поле строковое, и приспичило нам посчитать общую длину строк в этих структурах — пишем шаблонную функу которая проходит по массиву структур T и выдает на-гора сумму T::somestring. Пример кстати не надуманный, а вполне себе некогда юзаный мной в весьма низкоуровневом коде — в хуках на NtQueryDirectoryFile и ему подобных для подсчета общей длины структур которые вернуть возможно Получается быстро и наглядно.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, alpha21264, Вы писали:
A>Ну хорошо, давай возьмём библиотеку Qt. Она на С++. A>Там даже есть своя библиотека контейнеров и она на темплейтах. A>Но весь остальной код почему-то без них.
Ну ведь ничто не мешает перед тем как делать утверждение, сначала его проверить.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, alpha21264, Вы писали:
A>>Ну хорошо, давай возьмём библиотеку Qt. Она на С++. A>>Там даже есть своя библиотека контейнеров и она на темплейтах. A>>Но весь остальной код почему-то без них.
MTD>Ну ведь ничто не мешает перед тем как делать утверждение, сначала его проверить.
Здравствуйте, ononim, Вы писали:
O>Бывает, когда надо. Вот например есть у нас массив структурок разных, но имеющих поле строковое, и приспичило нам посчитать общую длину строк в этих структурах — пишем шаблонную функу которая проходит по массиву структур T и выдает на-гора сумму T::somestring. Пример кстати не надуманный, а вполне себе некогда юзаный мной в весьма низкоуровневом коде — в хуках на NtQueryDirectoryFile и ему подобных для подсчета общей длины структур которые вернуть возможно Получается быстро и наглядно.
Чё-то непонятно.
А в массиве лежат структуры одного типа?
А поле строковое у всех типов структур называется одинаково?
Вот дожил до 45 лет и не знаю, зачем в Nemerle макросы.
Вот... совсем. Не использую их, да и всё тут.
Не, конечно assert написать могу.
И прочее использование макросов.
Но больше ничего с макросами не делаю.
Люди! А для чего вы используете макросы?
Может я чего упускаю?
Сложные программы пишу, например, в известном Firefox есть мой код.
Здравствуйте, alpha21264, Вы писали:
A>Люди! А для чего вы используете шаблоны? A>Может я чего упускаю? A>
Изначально шаблоны вводились в C++ для реализации парадигмы обобщённого программирование (для этих же целей существуют различные generic'и в языках типа java/c#). Но оказалось, что данный механизм позволяет так же и довольно эффективно реализовывать парадигму метапрограммирования, причём это МП времени компиляции — не имеет никаких накладных расходов. Эти техники получили широкое развитие и являются одним из главных векторов развития C++ в данное время. Правда синтаксис в итоге получается ужасным (в сравнение с языками, где подобное МП задумывалось изначально, типа D и т.п.) и части очевидных возможностей всё же не хватает.
Подводя итоги. Шаблоны C++ реализуют:
— обобщённое программирование, на отличном уровне и с нормальным синтаксисом
— метапрограммирование времени компиляции на среднем уровне и с сомнительным синтаксисом.
Отдельно можно отметить, что второй пункт хотя и реализован не очень, но это является единственной реализацией подобного в мейнстрим языках. И одной из немногих среди языков вообще.
============
Ну а если говорить лично обо мне, то можно опять же разделить использование шаблонов на 2 части: использование чужих и написание своих. С использование своих думаю всё очевидно — и стандартная библиотека и Boost (де факто стандартная библиотека) напичканы шаблонами (причём и в качестве ОП и в качестве МП). Если же говорить про написание своих, то тоже встречается, но уже несколько реже, т.к. большинство "велосипедов" уже есть в подключённых библиотеках.
O>>Бывает, когда надо. Вот например есть у нас массив структурок разных, но имеющих поле строковое, и приспичило нам посчитать общую длину строк в этих структурах — пишем шаблонную функу которая проходит по массиву структур T и выдает на-гора сумму T::somestring. Пример кстати не надуманный, а вполне себе некогда юзаный мной в весьма низкоуровневом коде — в хуках на NtQueryDirectoryFile и ему подобных для подсчета общей длины структур которые вернуть возможно Получается быстро и наглядно. K>Чё-то непонятно. K>А в массиве лежат структуры одного типа?
Ну там хитрый массив — в буфере лежит этакий связный список, элемент каждого одним из своих полей имеет смещение от себя до следующего
K>А поле строковое у всех типов структур называется одинаково?
Да. Вобщем чтоб дальше не объяснятся, вот эти структуры: раз, два, три, четыреetc
И вот предположим задачка: вам надо из списка таких структур изъять элемент относящийся к файлу "foobar.txt"...
Как много веселых ребят, и все делают велосипед...
Здравствуйте, alpha21264, Вы писали:
A>Ну хорошо, давай возьмём библиотеку Qt. Она на С++. A>Там даже есть своя библиотека контейнеров и она на темплейтах. A>Но весь остальной код почему-то без них. A>
