Здравствуйте, Sergey, Вы писали:

S>Раздельной компиляции шаблонов, разумеется. На практике нет — в стандарте она предусмотрена. Пока предусмотрена
Слушай, чего ты меня морочишь?
Поясни сам, от чего нельзя организовать виртуальный шаблонный метод?

Здравствуйте, Erop, Вы писали:

S>>Раздельной компиляции шаблонов, разумеется. На практике нет — в стандарте она предусмотрена. Пока предусмотрена
E>Слушай, чего ты меня морочишь?

Мне просто твоя аргументация показалась, мягко говоря, несостоятельной. Я выразил несогласие. В чем проблема?

E>Поясни сам, от чего нельзя организовать виртуальный шаблонный метод?

Если бы хотел на эту тему поспорить, я бы сразу пояснил, а не ставил минус. Лениво мне на эту тему флеймить. Можно придумать десяток аргументов против и пару возможных реализаций

Здравствуйте, Sergey, Вы писали:

S>Если бы хотел на эту тему поспорить, я бы сразу пояснил, а не ставил минус. Лениво мне на эту тему флеймить. Можно придумать десяток аргументов против и пару возможных реализаций

Нука-нука. Интересно бы было посмотреть на идею реализации. Только чур с сохранением принятой бизнес-практики с плагинами от третьих фирм. Чтобы ты не говорил, что плагины это де маргинальщина, я напомню тебе, что в ряде ОС прилажения являются фактически плагинами, линкуемыми системой, ещё COM-объекты бывают и т. д. и т. п.

J>Можешь конкретный пример дать? А то по предыдущему примеру (http://rsdn.ru/forum/message/2645828.1.aspx

Автор: dip_2000
Дата: 05.09.07

) ну ничего не понятно.
могу, но он будет не такой краткий

template  <class containerT>
class CAncestor
    {
    protected:
        typedef typename containerT containerType;
        typename containerType m_Container;    
        // i need this methods(putToStream/getFromStream) for virtual operator<< and virtual operator>>
        virtual std::ofstream& putToStream(std::ofstream& ofbsFile) = 0;
        virtual SOCKET& putToStream(SOCKET& stream) = 0;
    public:    
//много не относящегося к данной проблемме
        bool SendToNet(SOCKET& s)
        {
            putToStream(s);
            return true;
        }
        bool SaveToDisk(const tstring& tstrFileName)
        {
            bool Res = false;
            try
            {                
                std::ofstream ofbsFile(tstrFileName.c_str(), std::ios_base::out | std::ios_base::binary);            
                if (!ofbsFile.is_open())
                    throw (std::ios::failure("Can't open file"));

                putToStream(ofbsFile);                        
                Res = true;
            }
            catch(...)
            {
                TRACE(_T("Плохо"));
            }
            return Res;    
        }
};//CAncestor
//таких, или его наследников - несколько
template  <class containerT>
    class CContaner : public CAncestor<containerT>
    {        
    protected:
//вот здесь дублирование кода в каждом наследнике. хочется повторного использования
        virtual std::ofstream& putToStream(std::ofstream& stream)
        {
            return stream << (*this);            
        }
        virtual SOCKET& putToStream(SOCKET& stream)
        {
            return stream << (*this);            
        }
    public:    
        //тут то же всякая всячина        
        
        template <typename streamT>
        friend streamT& operator<<(streamT& stream, CThreadSafeContaner<containerT>& Self)
        {
//реализация             
            return stream;
        };    
        
};//CThreadSafeContaner end

Фактически, переводя на русский, нужен виртаульный оператор <<. Он friend по этому нельзя. Для этого используется обходной путь с виртуальным putToStream()

J>PS А что, против макросов у нас религиозное предубеждение?
1) Вобщем скорее да, чем нет
2) Коддинг стандартс И тут вобще ничего не попишешь

в последнем классе

template <typename streamT>
friend streamT& operator<<(streamT& stream, CThreadSafeContaner<containerT>& Self)

читать как

template <typename streamT>
friend streamT& operator<<(streamT& stream, CContaner<containerT>& Self)

> S>Если бы хотел на эту тему поспорить, я бы сразу пояснил, а не ставил минус. Лениво мне на эту тему флеймить. Можно придумать десяток аргументов против и пару возможных реализаций
>
> Нука-нука. Интересно бы было посмотреть на идею реализации. Только чур с сохранением принятой бизнес-практики с плагинами от третьих фирм.

Естественно, без плагинов.

> Чтобы ты не говорил, что плагины это де маргинальщина, я напомню тебе, что в ряде ОС прилажения являются фактически плагинами, линкуемыми системой, ещё COM-объекты бывают и т. д. и т. п.

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

Здравствуйте, Sergey, Вы писали:

S>Естественно, без плагинов.
S>Тем не менее, в С++ уже сейчас полно вещей, которые с плагинами не дружат. Соответственно, новая фича, несовместимая с концепцией плагинов, тоже никому не помешает.

Ну, то есть, плагины отменяем, COM забываем, и развмваем С++ дальше? А пользователи пусть что хотят, то и делают...
Оригинально...

Здравствуйте, dip_2000, Вы писали:

_>могу, но он будет не такой краткий
...
_>Фактически, переводя на русский, нужен виртаульный оператор <<. Он friend по этому нельзя. Для этого используется обходной путь с виртуальным putToStream()

Кроме уже предложенного тут

Автор: Кодт
Дата: 05.09.07

и тут

Автор: Erop
Дата: 05.09.07

решения есть и второй подход -- отказаться от того, чтобы оператор << нуждался в дружбе... Хотя это от подробностей зависит.

Например можешь сдлеать как-то так:

class CAncestor
    {
        //.........
        virtual std::string GetTextRepresentation() const;
        virtual SaveToBinary( std::vector<char>& binaryRepresentation ) const;
        virtual LoadFromBinary( std::vector<char>& binaryRepresentation );
        //.........
    }

Ну и реализуешь шаблонный operator << поверх этих методов + какой-то способ переключения (можно динамического) бинарный формат или текстовый.

> S>Естественно, без плагинов.
> S>Тем не менее, в С++ уже сейчас полно вещей, которые с плагинами не дружат. Соответственно, новая фича, несовместимая с концепцией плагинов, тоже никому не помешает.
>
> Ну, то есть, плагины отменяем, COM забываем,

Интересно, каким образом введение дополнительных возможностей в язык повлечет за собой отмену плагинов и COM?

> и развмваем С++ дальше?

Ясен пень, развиваем. Причем неплохо бы параллельно с развитием стандартизировать ABI для того, что уже есть.

> А пользователи пусть что хотят, то и делают...
> Оригинально...

А это уже давно так, и чтобы убедиться в текущем положении дел относительно плагинов, достаточно посмотреть на количество вопросов в этом форуме касательно выделения/освобождения памяти в разных dll.

Здравствуйте, Sergey, Вы писали:

S>А это уже давно так, и чтобы убедиться в текущем положении дел относительно плагинов, достаточно посмотреть на количество вопросов в этом форуме касательно выделения/освобождения памяти в разных dll.

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