Вопрос к программистам на C , Исходники ядра Linux

Цитата Ho Im @ 18.04.06, 14:56

А теперича объясни народу, будь добр, какого лешего метапрограммированию делать в _системном_ программировании (мы еще о конкретной программе -- ядре ОС -- разговаривали, когда ты впервые сюда с "шаблончиками" сунулся).

Ho Im, дело в том, что метапрограммирование - лишь один из приемов в арсенале разработчика, при умелом использовании значительно упрощающий и без того нелегкую жизнь. Разделение "системное/прикладное программирование" тут совершенно ни при чем.

Цитата BugHunter @ 18.04.06, 07:26

В С++ никто не заставляет пользоваться crtl (если уж тебя так волнует этот вопрос с загрузкой библиотек).
С++ - абсолютный аналог C по функциональности + сладкий яд

Цитата Flex Ferrum @ 18.04.06, 07:46

Хех. Что может быть проще использования boost::bind? Или boost::lambda? (примеры приведу по требованию) Но их реализация - это да. Без поллитры не разберешь. Точно также, как я без поллитры не разберу код линуксового ядра. И для меня это тоже будет казаться очень сложным. Я к тому, что сложность - понятие относительное. Как и простота. Пример с кокпитом реактивного самолета я уже приводил. Незнающий человек в обилии датчиков, тумблеров, переключателей, индикаторов просто запутается. Но это не значит, что кокпит плохо спроектирован, а самолет - отвратительно летает.

Цитата BugHunter @ 18.04.06, 12:59

Посмотри в сторону метапрограммирования. Можно с помощью шаблончиков разруливать интересные чтуки в компайл тайме (например, рекурсию некислую посчитать, вместо того, что бы с циклами и рекурсиями в рантайме возиться).

ИМХО, многие C++-ные вещи имеют одну ярко выраженную особенность: у них проблемы с ABI (Application Binary Interface). Сюда входит и name mangling, и инстанциирование шаблонов в разных единицах трансляции, и прочие штуки. А у ядра должен быть стабильный бинарный интерфейс.

Цитата

Ho Im, дело в том, что метапрограммирование - лишь один из приемов в арсенале разработчика, при умелом использовании значительно упрощающий и без того нелегкую жизнь. Разделение "системное/прикладное программирование" тут совершенно ни при чем.

Именно что при умелом. А при написании частей ядра я бы хотел иметь возможность персонально отвечать за каждую написанную строчку. В данном случае генерация кода с незнамо-какого уровня абстракции не прокатит, максимум соглашусь на препроцессор Си.

Цитата

А у ядра должен быть стабильный бинарный интерфейс.

Расскажи Линусу, а? Ему сие будет очень интересно узнать. Хотя можешь не рассказывать — binary-compatible kernel APIs suck. В директории Documentation уже валяется документ о Stable API Nonsense, который советую прочитать.

Цитата

ну, там особо сравнивать не с чем :)
А, теперь я знаю почему линух такой тормозной - потому что скомпилен gcc-ами :yes:

Знаешь, не устаю повторять что Linux -- крайне дружелюбная система, но вот друзей себе очень избирательно выбирает.
Если чел не в состоянии свои /dev/hands освободить от гнёта /dev/ass, то... Причём здесь Linux? Почему его используют всё шире и шире? Если система плоха (как M$, к примеру), то я бы не писал эти строки из Linux...

Цитата

При всем при этом, претензий к оптимизации Visual C++ у меня нет. Иногда даже диву даешься.

Не надо "даваться диву" :D:D:D А у меня есть претензии. Сам видел те примеры, которые я приводил. Так вот. ТАК нельзя! И, если за компиль с меня берут денег и впихивают мне какие-то "новые, революционные решения" (как "нагрузку ко всему этому), то дайте мне качество, а не "видение". Либо я просто не использую данный компиль и систему, для которой оно работает. Я использую альернативу (в таком случае).

Сам вспомни -- сколько понтов было вокруг MFC? Ну, и? И что? А ничего -- шаг влево-вправо и тебя ждёт дорога в Win 32 API. Пример с работой с COM-портом приводить? Или остановимся на том C++-подобном сервисе, исходник коего я уже приводил...

Знаешь, мне нравится "раздельное питание". Как пример -- посмотри GNOME bindings. Да. GNOME et al написан на С. Но кто сказал, что на Perl/Java/C++/Python нельзя для него писать? Пожалуйтса. И GLADE поддерживает эти языки...

Что меня более всего бесит в том, что называется "программированием" для M$, так это то, что мало написать код. Надо ещё и угадать видение M$... Чтобы потом всё это не переколпачивать за-ново. Если ты пишешь на С#, то ты круче яиц вкрутую, а если на С (с Win 32 API), ламо полнейшее, не видящее "новых веяний".

И скажи мне что это не так... :D:D:D

Цитата

какого лешего метапрограммированию делать в _системном_ программировании (мы еще о конкретной программе -- ядре ОС -- разговаривали, когда ты впервые сюда с "шаблончиками" сунулся).

Ну, по извечной российской традиции, он сунулся явно не с тем и не туда. Правда, "куда именно" он так, боюсь, и не понял, ибо у него... Linux тормозит... :D:D:D:D:D:D

Цитата

ИМХО, многие C++-ные вещи имеют одну ярко выраженную особенность: у них проблемы с ABI (Application Binary Interface). Сюда входит и name mangling, и инстанциирование шаблонов в разных единицах трансляции, и прочие штуки. А у ядра должен быть стабильный бинарный интерфейс.

Уверяю тебя, это было бы половиной беды. Вся беда в том, что все эти "сладкие яды" требуют объёмов кода, который должен либо быть интегрирован в ядро, либо загружаться вместе с ядром. А это весьма проблематично. По этой причине, для решения вполне простых (относительно иного ПО) задач, и используются довольно простые подходы.

На самом-то деле, в "ядре" Linux всего "ничего" -- планировщик, система управления памятью, прерываниями и реализации интерфейсов (в частности -- стек TCP/IP и "виртуальные ФС", позволяющие Linux работать с любой ФС, если она описана в соотв. виде). Механизм реализации "системных вызовов" (это ближе к "ресурсам") и ряд служебных вещей (ФС proc, к примеру).

Всё остальное надстраивается из модулей. Всё. Больше там нет ничего.

Цитата

В директории Documentation уже валяется документ о Stable API Nonsense, который советую прочитать.

Ну, собственно, и я то же про тоже. Почти. Другой аспект -- мне просто непонятно стремление "неофитов" и всяческих "неформалов" перестраивать то, что стабильно работает (и, замечу, без их помощи) вот уже столько лет. Смысл? Чтобы написать вычисление "числа Фибоначчи" по-новому?

Ребят, IMHO, вы просто "переседели" в windoZe... :D:D:D

Цитата the_Shadow @ 19.04.06, 06:34

Не надо "даваться диву" :D:D А у меня есть претензии. Сам видел те примеры, которые я приводил. Так вот. ТАК нельзя! И, если за компиль с меня берут денег и впихивают мне какие-то "новые, революционные решения" (как "нагрузку ко всему этому), то дайте мне качество, а не "видение". Либо я просто не использую данный компиль и систему, для которой оно работает. Я использую альернативу (в таком случае).

Видимо, ты не совсем правильно меня понял. Я имел ввиду, что у меня нет претензий к оптимизатору, встроенному в компилятор Visual C++. А теперь давай подумаем, какая связь между с возможностями компилятора по оптимизации и библиотекой MFC?

Цитата the_Shadow @ 19.04.06, 06:34

Уверяю тебя, это было бы половиной беды. Вся беда в том, что все эти "сладкие яды" требуют объёмов кода, который должен либо быть интегрирован в ядро, либо загружаться вместе с ядром. А это весьма проблематично. По этой причине, для решения вполне простых (относительно иного ПО) задач, и используются довольно простые подходы.

Шад, у меня есть сильное подозрение, что ты берешься судить о том, что знаешь лишь в общих чертах. Специальной поддержки от CRTL в С++ требуют только две вещи - исключения и RTTI. Но и то и другое совершенно не обязательно для использования.

Цитата Ho Im @ 18.04.06, 21:33

Именно что при умелом. А при написании частей ядра я бы хотел иметь возможность персонально отвечать за каждую написанную строчку. В данном случае генерация кода с незнамо-какого уровня абстракции не прокатит, максимум соглашусь на препроцессор Си.

Подробнее. Что ты имеешь ввиду?

Цитата

А теперь давай подумаем, какая связь между с возможностями компилятора по оптимизации и библиотекой MFC?

Извини, но это -- единый ПРОДУКТ.
Как из песни слов не выкинуть, так и из windoZe её отдельную часть. По-пробуй перенастроить среду так, чтобы не использовать чего-то из этого...

Теперь, другой аспект (или, если угодно, другими словами) -- хорошо. Пусть всё так. Но объясни мне -- о какой оптимизации может идти речь, если мы просто... включим windows.h в секции include? Что произойдёт после этого? Ссылки, говоришь, будут сформированы? Ну, да...

А вопрос можно -- а на фиг они мне в коде, скажем так, где ole, к примеру, не используется? Почему этого не происходит в Linux?

Цитата

Шад, у меня есть сильное подозрение, что ты берешься судить о том, что знаешь лишь в общих чертах. Специальной поддержки от CRTL в С++ требуют только две вещи - исключения и RTTI. Но и то и другое совершенно не обязательно для использования.

Хорошая новость. Постараюсь запомнить. :D:D:D
А сколько в мегабайтах отвешивается на exceptions & RTTI? Угу... "Сколько вешать в граммах?" :D:D:D Как это реализовано в Linux? Мы же о его ядре столь вольно рассуждаем.

Итак, чего скажешь? Предложишь поддержку exceptions & RTTI оформить как модули ядра? Гы-гы... Сам-то понял, чего сказал? :D:D:D

Цитата

Подробнее. Что ты имеешь ввиду?

Можно я? Ну пожалуйста... :D:D:D

Он имеет ввиду то, что код на С (с макросами) переводится в асм и, далее, просто переводится в объектник с выходом на маш. коды. Это, собственно, то, что происходит при любой компиляции и линковке.

Для С++ потребуется дополнительно "расшифровать" используемые конструкции в то же, что на С получается при использовании средств самого языка+препроцессор. Ты явно пропустил мой пассажикссс про "портируемый ассемблер". А зря.

Рекомендуемая мера пресечения -- взять код (равнозначный в части сложности) и прогнать его через gcc -S. Т.е., написать некий алгоритм, сложнее hellow world на С и С++ и посмотреть на ассемблерный код. Я это видел. Спасибо. Больше не хочу.

Как только мы берёмся за рычажки под названием template (один из моментов) становится всё довольно весело. Теперь, внимание -- а всегда ли нужен, к примеру тот же template? Если целевая система полностью детерминирована, все типы данных и их использование могут быть описаны в пределах формальной логики? Не усложняем ли мы то, что довольно просто по своей сути?

Цитата the_Shadow @ 19.04.06, 07:20

По-пробуй перенастроить среду так, чтобы не использовать чего-то из этого...

В смысле? Писать без MFC? Ты уверен, что знаешь, о чем говоришь?

Цитата the_Shadow @ 19.04.06, 07:20

Но объясни мне -- о какой оптимизации может идти речь, если мы просто... включим windows.h в секции include? Что произойдёт после этого? Ссылки, говоришь, будут сформированы? Ну, да...

Хм. И что же произойдет? Мне почему-то кажется, что то же, что и при подключении, например, stdio.h. Ну будет видно какое-то количество функций и структур. А что еще? И при чем здесь оптимизация?

Цитата the_Shadow @ 19.04.06, 07:20

А сколько в мегабайтах отвешивается на exceptions & RTTI?

А зачем отвешивать? Не используй и не будет отвешиваться.

Сообщение отредактировано: trainer - 19.04.06, 07:37

Цитата

Не используй и не будет отвешиваться.

Я о том же.

Цитата

В смысле? Писать без MFC? Ты уверен, что знаешь, о чем говоришь?

Так. Либо я чего-то не правильно объясняю, либо снег не завезли... :D:D:D

А давай проще -- возьмём компилятор lcc (есть такой) и проанализируем то, что происходит с его кодом (какой он), почему столь мелкий бинарь получается и почему он генерит код, весьма сильно отличающийся по размеру от кода, генерируемого Visual C/C++?

Цитата

Ну будет видно какое-то количество функций и структур. А что еще?

Собственно, ничего. Вот только вопрос -- почему такое большое... А так... Да ничего, ровным счётом ничего... См. выше про lcc... :D:D:D

Цитата the_Shadow @ 19.04.06, 07:20

Извини, но это -- единый ПРОДУКТ.

Не извиню. Это разные продукты. Ведь не будешь же ты утверждать, что любой компилятор, который может компилировать код под Windows является частью Windows?

Цитата the_Shadow @ 19.04.06, 07:20

Теперь, другой аспект (или, если угодно, другими словами) -- хорошо. Пусть всё так. Но объясни мне -- о какой оптимизации может идти речь, если мы просто... включим windows.h в секции include? Что произойдёт после этого? Ссылки, говоришь, будут сформированы? Ну, да...

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

Цитата the_Shadow @ 19.04.06, 07:20

А сколько в мегабайтах отвешивается на exceptions & RTTI? Угу... "Сколько вешать в граммах?" :D:D Как это реализовано в Linux? Мы же о его ядре столь вольно рассуждаем.

Итак, чего скажешь? Предложишь поддержку exceptions & RTTI оформить как модули ядра? Гы-гы... Сам-то понял, чего сказал? :D:D

Я? Я этого не говорил. Это сказал ты. Я же сказал:

Цитата Flex Ferrum @ 19.04.06, 07:03

Но и то и другое совершенно не обязательно для использования.

Поясняю - никто не заставляет тебя использовать исключения и RTTI, если они тебе не нужны. Еще вопросы есть?

Цитата the_Shadow @ 19.04.06, 07:20

Для С++ потребуется дополнительно "расшифровать" используемые конструкции в то же, что на С получается при использовании средств самого языка+препроцессор. Ты явно пропустил мой пассажикссс про "портируемый ассемблер". А зря.

Нет, нет и еще раз нет. Ты забываешь, что и для С, и для С++ компилятор, прежде чем гнать объектный код, должен построить дерево синтаксического разбора. Еще раз говорю - эта фаза есть и при компиляции кода на С, и при компиляции кода на С++. Всяческие шаблоны и т. п. исчезают на уровне построения этого дерева, и на кодогенератор подаются уже препарированные конструкции. Так что мне не совсем понятно - что же именно тебя смущает? Если только увеличивающееся время компиляции...

Добавлено 19.04.06, 07:48

Цитата the_Shadow @ 19.04.06, 07:37

А давай проще -- возьмём компилятор lcc (есть такой) и проанализируем то, что происходит с его кодом (какой он), почему столь мелкий бинарь получается и почему он генерит код, весьма сильно отличающийся по размеру от кода, генерируемого Visual C/C++?

А ты сам пробовал ответить на этот "почему?"? Ты компилировал один и тот же исходник?

Цитата mo3r @ 18.04.06, 16:46

Цитата BugHunter @ 18.04.06, 07:26

В С++ никто не заставляет пользоваться crtl (если уж тебя так волнует этот вопрос с загрузкой библиотек).
С++ - абсолютный аналог C по функциональности + сладкий яд

Цитата Flex Ferrum @ 18.04.06, 07:46

Хех. Что может быть проще использования boost::bind? Или boost::lambda? (примеры приведу по требованию) Но их реализация - это да. Без поллитры не разберешь. Точно также, как я без поллитры не разберу код линуксового ядра. И для меня это тоже будет казаться очень сложным. Я к тому, что сложность - понятие относительное. Как и простота. Пример с кокпитом реактивного самолета я уже приводил. Незнающий человек в обилии датчиков, тумблеров, переключателей, индикаторов просто запутается. Но это не значит, что кокпит плохо спроектирован, а самолет - отвратительно летает.

Цитата BugHunter @ 18.04.06, 12:59

Посмотри в сторону метапрограммирования. Можно с помощью шаблончиков разруливать интересные чтуки в компайл тайме (например, рекурсию некислую посчитать, вместо того, что бы с циклами и рекурсиями в рантайме возиться).

ИМХО, многие C++-ные вещи имеют одну ярко выраженную особенность: у них проблемы с ABI (Application Binary Interface). Сюда входит и name mangling, и инстанциирование шаблонов в разных единицах трансляции, и прочие штуки. А у ядра должен быть стабильный бинарный интерфейс.

Что такое ABI (Application Binary Interface) ?

Цитата plan699 @ 19.04.06, 07:49

Что такое ABI (Application Binary Interface) ?

Интерфейс взаимодействия между уже откомпилированными модулями (это если совсем по-простому). mo3r говорит о том, что нет стандартов (и спецификаций) на то, как, например, должны выглядить уже скомпилированные классы в памяти, под какими именами из модулей должны экспортироваться функции, как принимать скрытые параметры и т. п. Все это затрудняет взаимодействие между модулями, скомпилированными разными компиляторами/с разными опциями компиляции.

Цитата

Ведь не будешь же ты утверждать, что любой компилятор, который может компилировать код под Windows является частью Windows?

Не буду в отношении любого компилятора. В отношении Visual -- буду.

Цитата

Еще вопросы есть?

Не-а. Если честно, то и не было. Это БухгХантер влез со своими "шаблончиками"... :D:D:D

Цитата

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

Давай развеем.
Ты говоришь о компиляторе. А про линкер забыли? Иначе, тебе придётся объяснить вот это:

Цитата

Примерно так и рассуждает M$, рекомендуя для висты 3ГГц-овый проц, 2ГБ оперативы и 256МБ видеопамяти... :)

Кстати, мне дополнительно инересен ещё и вопрос про компилятор. Если мы можем отделить M$ от его Visual, то... почему всё так плохо?
Или они перешли на lcc?

А ситуация под Linux тебе, по-моему, известна. Ты можешь использовать gcc, но, на явно-Intel "камне", можешь и интеловский компиль использовать... И всё будет собираться без проблем. Проверял.

Цитата

Еще раз говорю - эта фаза есть и при компиляции кода на С, и при компиляции кода на С++. Всяческие шаблоны и т. п. исчезают на уровне построения этого дерева, и на кодогенератор подаются уже препарированные конструкции. Так что мне не совсем понятно - что же именно тебя смущает? Если только увеличивающееся время компиляции...

Про "дерево синтаксического разбора" -- верно.

Про то, что в дереве синтаксического разбора отсутствует код и данные, необходимые для реализации тех или иных механизмов -- нет. Если только они не вкючены в библиотеки времени исполнения. Но и то, при линковке, создаются ссылки на эти библиотеки и генерируется код для использования этих механизмов, описанных в библиотеках. Flex, абсолютно "бесплатных" решений просто нет. И всегда за что-то приходится платить чем-то. Чем больше у тебя "механизмов" (рычажков и кнопочек) тем больший код нужен для обслуживания всего этого. И вот только не надо про то, что "да сколько там того кода и какие у нас процессора"... :D:D:D

В случае с С (для Linux) всё проще. Намного.

Добавлено 19.04.06, 08:03

Цитата

А ты сам пробовал ответить на этот "почему?"? Ты компилировал один и тот же исходник?

Oui, messir... Рекомендую не верить мне на слово, а собрать С-код самому (с Win 32 API).

А вот на вопрос "почему" забил. Нехватало мне ещё с мастдаем разбираться. Меня удовлетворяет M$ DevStudio 2005, eM$ (для WinCE и прочих поделок). Это касаемо M$. Если люди хотят работать на дерьме, то почему бы мне на этом денег не заработать? :D:D:D

Цитата

Все это затрудняет взаимодействие между модулями, скомпилированными разными компиляторами/с разными опциями компиляции.

По этой (одной из причин) для ядра Linux это идёт в сад. Прямым ходом.

Цитата the_Shadow @ 19.04.06, 07:37

Так. Либо я чего-то не правильно объясняю, либо снег не завезли...

Странно. А почему я могу писать, например, консольные порграммы безо всяких MFC? У меня компилятор неправильный?

Добавлено 19.04.06, 09:12

Цитата the_Shadow @ 19.04.06, 07:37

возьмём компилятор lcc (есть такой) и проанализируем то, что происходит с его кодом (какой он)

Ну давай. Где-то на CD он у меня валяется.

Цитата the_Shadow @ 19.04.06, 07:37

почему столь мелкий бинарь получается

Исполнимый файл? Я тебе и без просмотра скажу. У него RTL меньше. Да и оптимизацию надо смотреть.

Цитата the_Shadow @ 19.04.06, 07:37

почему он генерит код, весьма сильно отличающийся по размеру от кода, генерируемого Visual C/C++?

Ну помимо всего прочего, размер зависит и от способности компилятора к оптимизации. Я, помнится, в алгоритмах выкладывал дизассемблированную функцию перемножения векторов. Там и Intel С++ и Metrowerks развернули циклы на пару килобайт кода. И за счет этого обставили паскаль по быстродействию раза в 3 и сравнялись с оптимизированной вручную на ассемблере. А если не разворачивать - будет сотня байт.

Сообщение отредактировано: trainer - 19.04.06, 09:15

Цитата

Странно. А почему я могу писать, например, консольные порграммы безо всяких MFC? У меня компилятор неправильный?

Хе-хе... Не про то речь. Возьми какой-нибудь helloworld :D:D:D для Win и Lin и посмотри его внимательно до линковки, после, как асм-код и т.д. и т.п. Т.е., если начинаем исследовать код, то вылезают вполне интересные вещи. В частности то, что архитектура Linex, в общем и целом обеспечивает более "лёгкий" код. Вот и всё. Причём, изначально и безо всякого моего (как проггера) участия.

Цитата

Исполнимый файл? Я тебе и без просмотра скажу. У него RTL меньше. Да и оптимизацию надо смотреть.

А я-то как раз вот об этом... Если вспомнить наш с Flex'ом флейм про Visual... :D:D:D
Я, кстати, про то же и рассказываю... :D:D:D

Цитата

Ну помимо всего прочего, размер зависит и от способности компилятора к оптимизации. Я, помнится, в алгоритмах выкладывал дизассемблированную функцию перемножения векторов. Там и Intel С++ и Metrowerks развернули циклы на пару килобайт кода. И за счет этого обставили паскаль по быстродействию раза в 3 и сравнялись с оптимизированной вручную на ассемблере. А если не разворачивать - будет сотня байт. :)

Во-во-во... 5 (пять!) баллов.
Вот по этой-то причине до разного рода споров (в т.ч. и х?ли-варных) я и предлагаю по-смотреть код с опцией -S. При разных режимах оптимизации. Вот тогда мы более-менее поймём что же там на самом-то деле происходит. А не будем огульно говорить что Линукс тормозит по причине того, что там с gcc всё скомпилировано... :D:D:D

Цитата the_Shadow @ 19.04.06, 07:58

Кстати, мне дополнительно инересен ещё и вопрос про компилятор. Если мы можем отделить M$ от его Visual, то... почему всё так плохо?

Слушай, если плотник сколотил кособокий дом со щелями - это, наверное, молоток и топор виноваты?

Цитата the_Shadow @ 19.04.06, 07:58

Ты говоришь о компиляторе. А про линкер забыли? Иначе, тебе придётся объяснить вот это:

Не придется. Линкер подключает то, что ему сказали подключать. Убери из настроек линкера ненужные библиотеки импорта (которые туда добавляются при создании проекта "по умолчанию"), и таблица импорта не будет такой пухлой.

Цитата the_Shadow @ 19.04.06, 07:58

Не-а. Если честно, то и не было. Это БухгХантер влез со своими "шаблончиками"... :D:D

Какое имеет отношение RTTI к шаблонам?

Цитата the_Shadow @ 19.04.06, 07:58

Про то, что в дереве синтаксического разбора отсутствует код и данные, необходимые для реализации тех или иных механизмов -- нет. Если только они не вкючены в библиотеки времени исполнения. Но и то, при линковке, создаются ссылки на эти библиотеки и генерируется код для использования этих механизмов, описанных в библиотеках. Flex, абсолютно "бесплатных" решений просто нет. И всегда за что-то приходится платить чем-то. Чем больше у тебя "механизмов" (рычажков и кнопочек) тем больший код нужен для обслуживания всего этого. И вот только не надо про то, что "да сколько там того кода и какие у нас процессора"... :D:D

Согласен, бесплатных решений нет. Цена использования шаблонов - увеличение времени компиляции. Это, конечно, не совсем правильное сравнение, но, если совсем упрощенно, то шаблон - это сильно улучшенная версия макроса. Но, в отличии от макроса, который "исчезает" после обработки кода препроцессором, шаблон существет на этапе компиляции, что и составляет одно из основных его отличий от макроопределения. Другое отличие - шаблон может по-разному "раскрываться" в зависимости от того, с какими параметрами его инстанцируют.