Подскажите, можно ли при написании шаблонов реализацию методов помещать в *.cpp файл?
А то при небольшом изменении в реализации перекомпилируется весь проэкт, т. к. код приходится писать в *.h файле!
Здравствуйте Yuri Dursin, Вы писали:
YD>Подскажите, можно ли при написании шаблонов реализацию методов помещать в *.cpp файл? YD>А то при небольшом изменении в реализации перекомпилируется весь проэкт, т. к. код приходится писать в *.h файле!
Нельзя
А чтобы проект весь не перекомпилить — смотри книгу Мейерса "Эффективное использование С++". Там этому вопросу целая глава посвящена.
Здравствуйте Bell, Вы писали:
B>Здравствуйте Yuri Dursin, Вы писали:
YD>>Подскажите, можно ли при написании шаблонов реализацию методов помещать в *.cpp файл? YD>>А то при небольшом изменении в реализации перекомпилируется весь проэкт, т. к. код приходится писать в *.h файле!
B>Нельзя
Ну почему ж нельзя — вполне можно, если все, кто использует шаблон, сидят в том же *.cpp файле. Да и декларировать его тогда удобнее в том же cpp файлы.
B>А чтобы проект весь не перекомпилить — смотри книгу Мейерса "Эффективное использование С++". Там этому вопросу целая глава посвящена.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re: Шаблоны и их реализация
От:
Аноним
Дата:
05.04.02 10:23
Оценка:
Здравствуйте Yuri Dursin, Вы писали:
YD>Подскажите, можно ли при написании шаблонов реализацию методов помещать в *.cpp файл? YD>А то при небольшом изменении в реализации перекомпилируется весь проэкт, т. к. код приходится писать в *.h файле!
Шаблоны хорошее средство :maniac:
Если такой подход не слишком противоречит тому, что ты делаешь сейчас при помощи шаблонов, то можно сделать так: сделать класс, рассчитанный на любой тип данных и обернуть его шаблоном, вот слегка грубоватый пример:
Здравствуйте Sergey, Вы писали:
S>Здравствуйте Bell, Вы писали:
B>>Здравствуйте Yuri Dursin, Вы писали:
YD>>>Подскажите, можно ли при написании шаблонов реализацию методов помещать в *.cpp файл? YD>>>А то при небольшом изменении в реализации перекомпилируется весь проэкт, т. к. код приходится писать в *.h файле!
B>>Нельзя
S> Ну почему ж нельзя — вполне можно, если все, кто использует шаблон, сидят в том же *.cpp файле. Да и декларировать его тогда удобнее в том же cpp файлы.
И насколько часто такие ситуации встречаются в реальной жизни?
В любом случае — это частность, а мы ведь не ищем легких путей!
Рек>Это совершенно неправильный пример использования шаблонов!
Рек>Шаблоны как раз позволяют (и предназначены для того чтобы) такое не писать!
Рек>И даже не потому, что плохо написано. Рек>Такое просто не работает!
А вот Мейерс так не считает
У него есть подобный пример смеси класса-реализации и шаблонов (пример про стэк в книге "Эффективное использование")
Я не утверждаю, что именно так и надо делать, но в некоторых ситуациях такой подход имеет право на жизнь.
Здравствуйте Bell, Вы писали:
B>Здравствуйте Рек, Вы писали:
Рек>>Это совершенно неправильный пример использования шаблонов!
Рек>>Шаблоны как раз позволяют (и предназначены для того чтобы) такое не писать!
Рек>>И даже не потому, что плохо написано. Рек>>Такое просто не работает!
B>А вот Мейерс так не считает B>У него есть подобный пример смеси класса-реализации и шаблонов (пример про стэк в книге "Эффективное использование") B>Я не утверждаю, что именно так и надо делать, но в некоторых ситуациях такой подход имеет право на жизнь.
Наговариваешь ты на Мейерса...
Ну давай хотябы посмотрим на строчку
~TCollect() { delete items; };
Что здесь будет удаляться? Если удаляется массив чаров, то хорошо бы поставить [].
А деструкторы объектов находящихся в контейнере отработают?
Как ты думаешь?
А уж на реализацию Insert как интересно было бы поглядеть!..
Здравствуйте konst, Вы писали:
K>почему не работает работает K>не буду спорить на счёт чистоты стиля, конечно, нет никакой
K>вас интересовал инсёрт, вот, пожалуйста:
K>
K>его я не стал искажать — можно и ошибиться
K>и вы правы — вообще не для хранения объектов с деструктором и/или виртуальными функциями, а что делать идеальные решения не так часто встречаются
Да. Наверное ты прав и такого типа контейнер сможет работать с некоторыми типами.
(только с типами, допускающими побитовое копирование — это простые типы (int, double, указатели), и структуры из них).
А для чего такое ограничение? Что ты получаешь взамен? Сверх эффективную memcpy ?
Но ведь типы, допускающие побитовое копирование, как правило малы по размерам,
и сомнительное преимущество memcpy тут никчему. Так что я не вижу никаких преимуществ этого метода.
Шаблоны тут используются всего лишь для "автоматизации приведения", для скрытия приведения.
А ведь шаблоны позволяют обойтись совсем без приведения. И позволяют работать с любыми типами.
Вот что главное!
я когда то сам делал такую коллекцию для себя, почему именно так — не помню уже, но оно где-то потерялось; это то, что на работе я встретил, чем пользуюсь зато, почему так получилось, знаю — когда сделали коллекцию, ещё не было темплейтов и стандарта а всё переделывать, видимо, поленились да и сейчас неохота
забыл вот ещё что: любой сложности объекты можно пихать туда, только без деструкторов и виртуальных методов (последнее тоже можно, но опасно, если вожможно в другой процесс передать)
делать, но в некоторых ситуациях такой подход имеет право на жизнь.
Рек>Наговариваешь ты на Мейерса...
Рек>Ну давай хотябы посмотрим на строчку
Рек>~TCollect() { delete items; };
Рек>Что здесь будет удаляться? Если удаляется массив чаров, то хорошо бы поставить []. Рек>А деструкторы объектов находящихся в контейнере отработают? Рек>Как ты думаешь?
Рек>А уж на реализацию Insert как интересно было бы поглядеть!..
Сорри, несколько не так выразился — я имел в виду именно подход — есть класс, который обеспечивает некоторую функциональность, оперируя к примеру
void*
, и есть шаблон, который наследуется от этого класса (у Мейерса в примере — закрытое наследование). Вот этот шаблон и обеспечивает типизацию.
Я именно это имел ввиду. Т.е. с таким подходом можно и шаблон получить, и реализацию вынести в отдельную единицу компиляции.
А что касается конкретной реализации TCollect — народ уже высказался по этому поводу, я повторять не буду...
Здравствуйте Рек, Вы писали:
Рек>Здравствуйте konst, Вы писали:
K>>почему не работает работает K>>не буду спорить на счёт чистоты стиля, конечно, нет никакой
K>>вас интересовал инсёрт, вот, пожалуйста:
K>>
K>>его я не стал искажать — можно и ошибиться
K>>и вы правы — вообще не для хранения объектов с деструктором и/или виртуальными функциями, а что делать идеальные решения не так часто встречаются
Рек>Да. Наверное ты прав и такого типа контейнер сможет работать с некоторыми типами. Рек>(только с типами, допускающими побитовое копирование — это простые типы (int, double, указатели), и структуры из них).
Рек>А для чего такое ограничение? Что ты получаешь взамен? Сверх эффективную memcpy ? Рек>Но ведь типы, допускающие побитовое копирование, как правило малы по размерам, Рек>и сомнительное преимущество memcpy тут никчему. Так что я не вижу никаких преимуществ этого метода.
Рек>Шаблоны тут используются всего лишь для "автоматизации приведения", для скрытия приведения. Рек>А ведь шаблоны позволяют обойтись совсем без приведения. И позволяют работать с любыми типами. Рек>Вот что главное!
Рек>Неужели Майерс?
Вообщем то примерно такой подход ещё и Элджер описывал.
Он таким образом скрывал от пользователя реализацию класса.
(у него вообще к программистам крайне негативное отношение )
Жизнь, как игра —
идея паршивая,
графика обалденная...
Z>Да, кстати, стандарт ANSI 1998 Года по книге Страуструпа, позволяет это делать. Даже слово ключевое есть — export;
(...) Z>но вот Visuaal Studio 6.0 так не умеет и даже слова такого ключевого не знает.
Насколько я знаю, (пока) единственным компилятором, поддерживающим export, является Comeau 4.3 beta.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте Zero, Вы писали:
Z>Да, кстати, стандарт ANSI 1998 Года по книге Страуструпа, позволяет это делать. Даже слово ключевое есть — export;
Оперировать в этих вопросах к Страуструпу — пустое дело. Он бы лучше вместо своих "талмудов" сел-бы и написал компилятор,
который все, что он придумал, понимал-бы . А то получается — стандарт отдельно, а реальные программы — отдельно.
P.S.
Интересно, как можно вообще реализовать компиляцию шаблона в реаьный машинный код?
Здравствуйте Zero, Вы писали:
Z>Да, кстати, стандарт ANSI 1998 Года по книге Страуструпа, позволяет это делать. Даже слово ключевое есть — export;
Кажись, книжку я эту читал, но слова такого не встретил
[skipped]
Z>export template<class T> Z>Foo::.. Z>{
Z>};
А шо это такое? Похоже на ЭКСПОРТИРОВАНИЕ шаблона из DLL'и Z>но вот Visuaal Studio 6.0 так не умеет и даже слова такого ключевого не знает.
Так, наверное, никакой компилятор не умеет, если он не интерпретатор
ЗЫ export — слово устаревшее, оно заменено на спецификатор __declspec(dllexport).
// #import <windows.bas> class IWindows9x:protected DOS { private: virtual HANDLE EnumClouds()=0; };
Re[10]: Это не правильно!
От:
Аноним
Дата:
11.04.02 07:42
Оценка:
Здравствуйте KA, Вы писали:
KA>Здравствуйте Zero, Вы писали:
Z>>Да, кстати, стандарт ANSI 1998 Года по книге Страуструпа, позволяет это делать. Даже слово ключевое есть — export; KA>Кажись, книжку я эту читал, но слова такого не встретил :(
Глава кажется 13 (о шаблонах), самый последний подпункт.
Z>>export template<class T> Z>>Foo::.. Z>>{
Z>>}; KA>А шо это такое? Похоже на ЭКСПОРТИРОВАНИЕ шаблона из DLL'и :wow: Z>>но вот Visuaal Studio 6.0 так не умеет и даже слова такого ключевого не знает. KA>Так, наверное, никакой компилятор не умеет, если он не интерпретатор ;)
KA>ЗЫ export — слово устаревшее, оно заменено на спецификатор __declspec(dllexport).
Это не тот export! Это именно export template<class T>...!
Re[10]: Это не правильно!
От:
Аноним
Дата:
11.04.02 07:43
Оценка:
Здравствуйте al, Вы писали:
al>Здравствуйте Zero, Вы писали:
Z>>Да, кстати, стандарт ANSI 1998 Года по книге Страуструпа, позволяет это делать. Даже слово ключевое есть — export;
al>Оперировать в этих вопросах к Страуструпу — пустое дело. Он бы лучше вместо своих "талмудов" сел-бы и написал компилятор, al>который все, что он придумал, понимал-бы :). А то получается — стандарт отдельно, а реальные программы — отдельно.
Ну это я так... вспомнил.
al>P.S. al>Интересно, как можно вообще реализовать компиляцию шаблона в реаьный машинный код?