Программе требуется работать с несколькими файлами, причем их количество заранее неизвестно. vector не позволяет хранить ifstream'ы. Где же их хранить?

Здравствуйте, Аноним, Вы писали:

А>Программе требуется работать с несколькими файлами, причем их количество заранее неизвестно. vector не позволяет хранить ifstream'ы. Где же их хранить?

А указатели на ifstream'ы vector может хранить?

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

А>>Программе требуется работать с несколькими файлами, причем их количество заранее неизвестно. vector не позволяет хранить ifstream'ы. Где же их хранить?

D>А указатели на ifstream'ы vector может хранить?

Кривовато это как-то...

Здравствуйте, Аноним, Вы писали:

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

А>>>Программе требуется работать с несколькими файлами, причем их количество заранее неизвестно. vector не позволяет хранить ifstream'ы. Где же их хранить?

D>>А указатели на ifstream'ы vector может хранить?

А>Кривовато это как-то...
Это почему же? Это обычная практика создания множества объектов и хранения их указателей в списках. А еще лучше пользоваться "умными указателями".

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

D>>>А указатели на ifstream'ы vector может хранить?

А>>Кривовато это как-то...
D>Это почему же? Это обычная практика создания множества объектов и хранения их указателей в списках.

Ничего обычного здесь нет. Единственным оправданием для хранения указателей может быть IMHO только хранение разных объектов. То есть создаем разные объекты от одного класса и делаем веткор указателей на этот класс.

Если же объекты одинаковы, то какие принципиальные проблемы могут помешать хранению их в неком контейнере? Нет, я понимаю — проблема в создании конструктора копий, который должен копировать хендл открытого файла, — но с точки зрения тупого пользователя СТЛ — неужели нельзя создать контейнер для хранения файлов?

D> А еще лучше пользоваться "умными указателями".

Фигня все ваши умные указатели. Если их нельзя хратить в контейнере, то толку от них — 0

D>> А еще лучше пользоваться "умными указателями".
А>Фигня все ваши умные указатели. Если их нельзя хратить в контейнере, то толку от них — 0
они разные бывают. бывают std::auto_ptr — их нельзя, а бывают boost::shared_ptr (и их аналоги) — их можно.
А вот на счет фигни — вы просто видимо не обо всех знаете

Здравствуйте, Аноним, Вы писали:

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

D>>>>А указатели на ifstream'ы vector может хранить?

А>>>Кривовато это как-то...
D>>Это почему же? Это обычная практика создания множества объектов и хранения их указателей в списках.

А>Ничего обычного здесь нет. Единственным оправданием для хранения указателей может быть IMHO только хранение разных объектов. То есть создаем разные объекты от одного класса и делаем веткор указателей на этот класс.

А>Если же объекты одинаковы, то какие принципиальные проблемы могут помешать хранению их в неком контейнере? Нет, я понимаю — проблема в создании конструктора копий, который должен копировать хендл открытого файла, — но с точки зрения тупого пользователя СТЛ — неужели нельзя создать контейнер для хранения файлов?

D>> А еще лучше пользоваться "умными указателями".

А>Фигня все ваши умные указатели. Если их нельзя хратить в контейнере, то толку от них — 0

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

Здравствуйте, <Аноним>, Вы писали:

А>>>Кривовато это как-то...
D>>Это почему же? Это обычная практика создания множества объектов и хранения их указателей в списках.

А>Ничего обычного здесь нет. Единственным оправданием для хранения указателей может быть IMHO только хранение разных объектов. То есть создаем разные объекты от одного класса и делаем веткор указателей на этот класс.

Почему если указатель, то сразу полиморфизм? Это предрассудки какие-то.
Указатель — это ещё и разделяемое владение.

А>Если же объекты одинаковы, то какие принципиальные проблемы могут помешать хранению их в неком контейнере? Нет, я понимаю — проблема в создании конструктора копий, который должен копировать хендл открытого файла, — но с точки зрения тупого пользователя СТЛ — неужели нельзя создать контейнер для хранения файлов?

Если этот "некий" контейнер — вектор указателей на объекты, то принципиальных проблем нет.
Так же, как и рукодельный список. Или массив постоянной размерности (boost::array). В общем, любой контейнер, не практикующий копирование.

А вообще, в STL-контейнерах хранятся значения — т.е. объекты, копии которых неразличимы между собой.
Понятно, что ifstream ни по формальным признакам, ни по существу к таковым не относится.

А указатели и дескрипторы — относятся.
Так что пожалуйста: vector<FILE*>, vector<HANDLE>, vector<int> в твоём распоряжении. (Плюс код, следящий за закрытием).

D>> А еще лучше пользоваться "умными указателями".

А>Фигня все ваши умные указатели. Если их нельзя хратить в контейнере, то толку от них — 0

Это ваши указатели фигня, а наши — не фигня.
Во-первых, boost::shared_ptr
Во-вторых, как это ни прикольно звучит, ATL::CAutoPtr — но только в связке с ATL::CAutoPtrArray.

Здравствуйте, Аноним, Вы писали:

D>> А еще лучше пользоваться "умными указателями".

А>Фигня все ваши умные указатели. Если их нельзя хратить в контейнере, то толку от них — 0

А ifstream'ы — это тоже фигня, поскольку их нельзя хратить в контейнере

Здравствуйте, Аноним, Вы писали:

А>Есть ограничения на количество одновременно открытых файлов для ОС.
Обычно это ограничение можно конфигурировать.
Ты правда думаешь, что сервера, напрмер тот на которо мживёт этот сайт, не могут открыть больше 90 файлов одновремекнно?

Здравствуйте, Аноним, Вы писали:

А>Программе требуется работать с несколькими файлами, причем их количество заранее неизвестно. vector не позволяет хранить ifstream'ы. Где же их хранить?

К сожалению, STL не позволяет хранит в контейнерах объекты, не имеющие семантики значения.
Один выход

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

тебе уже предложили.
Второй, если нет охоты привлекать библиотеки или искать замену STL -- написать простой хак какой-нибудь. Например такой:

template<typename T>
class CppNoncopybleObjectEnvelope {
public:
    CppNoncopybleObjectEnvelope() : obj( 0 ) {}
    CppNoncopybleObjectEnvelope( const CppNoncopybleObjectEnvelope& other ) : obj( 0 )
    { 
       if( other.obj != 0 ) 
           assign( other.obj ); 
    }

    templte<typename T1>
    CppNoncopybleObjectEnvelope( T1 a1 ) : obj( 0 )
        { assign( new CHolder( a1 ) ); }

    templte<typename T1, typename T2>
    CppNoncopybleObjectEnvelope( T1 a1, T2 a2 ) : obj( 0 )
        { assign( new CHolder( a1, a2 ) ); }

    templte<typename T1, typename T2, typename T3>
    CppNoncopybleObjectEnvelope( T1 a1, T2 a2, T3 a3 ) : obj( 0 )
        { assign( new CHolder( a1, a2, a3 ) ); }

    ~CppNoncopybleObjectEnvelope() { release(); }

    // Тип аргумента такой специально!!!
    CppNoncopybleObjectEnvelope& operator=( CppNoncopybleObjectEnvelope other ) 
        { std::swap( other.obj, obj ); }

    T* operator->() { return GetPtr(); }
    const T* operator->() const { return GetPtr(); }
    T& operator * () { return *GetPtr(); }
    const T& operator * () const { return *GetPtr(); }

    // Неоператорный интерфейс
    void Assign( CppNoncopybleObjectEnvelope other )    // Тип аргумента такой специально!!!
        { std::swap( obj, other.obj ); }
    void Release() { release(); }
    T* GetPtr() { assert( !IsNull() ); return &obj->Object; }
    const T* GetPtr() const { assert( !IsNull() ); return &obj->Object; }
    bool IsNull() const { return obj != 0; }
    
private:
    struct CHolder {
        T Object;
        int Count;
        
        CHolder() : Count( 0 ) {}

        templte<typename T1>
        CHolder( T1 a1 ) : Count( 0 ), Object( a1 ) {}

        templte<typename T1, typename T2>
        CHolder( T1 a1, T2 a2 ) : Count( 0 ), Object( a1, a2 ) {}

        templte<typename T1, typename T2, typename T3>
        CHolder( T1 a1, T2 a2, T3 a3 ) : Count( 0 ), Object( a1, a2, a3 ) {}

    } obj;

    // Для многопоточного окружения эти две функции нужно переписать!!!
    static int incRefCount( int& count ) { return ++count; }
    static int decRefCount( int& count ) { return --count; }
    
    void assign( CHolder* toAssign )
    {
        assert( toAssign != 0 && toAssign->Count >= 0 );
        obj = toAssign;
        incRefCount( obj->Count );
    }

    void release()
    {
        if( obj == 0 )
            return;
        assert( obj != 0 && obj->Count > 0 );
        if( decRefCount( obj->Count ) == 0 )
            delete obj;
        ob j = 0;
    }
};

Такие штуки уже можно довольно легко хранить в std::vector, а если ещё и шаблонный operator<< (CppNoncopybleObjectEnvelope<TStream>&, T) определить, то вобще проблемы не будет почти никакой