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

R>Если MyAbstractClass абстрактный, то такое не прокатит:

R>vector<MyAbstractClass> MyInstanceList;

R>Почему не прокатит, мне понятно.
R>Вопрос: что делать? если хочется иметь список экзямплеров, у которых есть общий абстрактный интерфейс?


R>P.S: Поиском искал, но что-то не получается.
Постараюсь ответить наиболее полно:
Варианты:

1. Хранить указатели на объекты (например std::list<MyAbstactClass *>);
   
2. Хранить умные указатели на объекты (например std::list<boost::shared_ptr<MyAbstractClass> >);
   
3. Использовать библиотеку boost.ptr_container (например boost::ptr_list<MyAbstractClass>).

Рассмотрим каждый из вариантов:

1. Хранить указатели на объекты
   Преимущества:
   
   • Не нужны дополнительные библиотеки.
   Недостатки:
   
   • Отсутствие безопасности исключений;
     
   • Неудобство использования;
     

     std::vector<MyAbstactList *> v;
     
     v.push_back(new MyImplementation(params)); //потенциальная утечка памяти как уже показал korzhik
     
     some_func(); //небезопасно
     
     //удаление объекта
     delete v[0];
     v[0] = 0;
     v.erase(v.begin() + 0);
     
     //итд еще удалять каждый объект в конце scope
     for_each(v.begin(), v.end(), deleter());

     
     
   • Констатность контейнера — не константность объектов.
     

     //Констатность контейнера - константность объектов для всех типов объектов кроме указателей.
     //Для константного контейнера указателей - всего лишь нельзя поменять значение указателя, 
     //но можно изменять объект, на который он указывает
     std::vector<some_type> v;
     std::vector<some_type> const & r = v;
     r[0].SomeNonConstMethod(); //compile-error
     
     std::vector<some_type *> v2;
     std::vector<some_type *> const & r2 = v2;
     r[0]->SomeNonConstMethod(); //ok !!!!!!!! врядли автор хотел этого

   Способы решения недостатков:
   
   • писать свои контейнеры специально предназначенные для хранения указателей;
     
   • или писать умный указатель, который за собой все подчитстит.
   Напомню std::auto_ptr неподходит для хранения в стандартных контейнерах, т.к. он не удовлетворяет требованиям CopyConstructible.
   
   
   
2. Хранить умные указатели на объекты
   В данном случае от умного указателя требуется следующее:
   
   • владение объектом;
     
   • быть CopyConstuctible — два варианта реализации: подсчет ссылок или клонирование объектов.
   Подходящие варианты: shared_ptr, linked_ptr, clone_ptr.
   Все недостатки контейнеров dumb указатели решены. Но добавился оверхэд при использовании:
   Памяти: кроме указателя на объект, добавляется количество ссылок (shared_ptr) или указатель (или два) (linked_ptr like).
   Рантайм: учет ссылок или указателей (shared_ptr, linked_ptr like), и выделение динамической памяти почти при каждом изменении контейнера, на пример при сортировке — O(nlogn) выделений динамической памяти!.
   
   
   
3. Использовать библиотеку boost.ptr_container
   Это другой способ решения недостатков контейнеров указателей — создание контейнеров, специально предназначенных для хранения указателей. Лучше всех библиотеке скажет автор, поэтому ниже привожу вольный перевод boost.ptr_container.motivation:
   

   Если программист хочет использовать стандартные контейнеры для безопасного всмысле исключений хранения указателей на объекты, расположенных в куче, у него обычно есть только один выход: использовать стандартный контейнер умных указателей таких как boost::shared_ptr. Это подход работает, но не оптимален если:
   

   • владение хранимыми объектами осуществляется контейнером;
     
   • оверхэд времени выполнения не допустим (подсчет ссылок, потокобезопасность).

   Эта библиотека (boost pointer container) предоставляет контейнеры, похожие на стандартные, но для хранения объектов, расположенных в куче. Для каждого стандартного контейнера в библиотеке есть эквивалентный контейнер указателей, который владеет объектами в безопасной в смысле исключений манере. Эта библиотека предназначена для решения так называемой проблемы полиморфного класса.
   
   Преимущества pointer containers:
   

   • Безопасные в смысле исключений хранение и манипуляция указателями;
     
   • Более удобна в использовании по сравнению с std::container<boost::shared_ptr<T> >;
     
   • Отсутствие накладных расходов памяти, которые имеет std::container<boost::shared_ptr<T> >;
     
   • Обычно быстрее, чем std::container<boost::shared_ptr<T> >;
     
   • Константность контейнера — константость объектов.

   Недостатки:
   

   • Менее гибки по сравнению с контейнерами умных указателей таких как boost::shared_ptr.

   Очень рекомендую ознакомится с библиотекой тут.

Резюме:
Использовать контейнеры простых указателей крайне не рекоммендую, пожалейте себя!

if (у вас можно использовать boost и нестрашно :))
    if (контейнер владеет объектами)
        используйте boost.ptr_container;
    else
    {
        еще раз убедитесь, что без этого никак; 
        используйте стандартные контейнеры умных указателей например (boost.shared_ptr);
    }
else 
{
    во-первых вас искренне жалко;
    if (контейнер владеет объектами)
        пиши свой собственный или сдирайте реализацию boost.ptr_container;
    else
    {
        еще раз убедитесь, что без этого никак; 
        используйте стандартные контейнеры умных указателей например (tr1.shared_ptr);
    }
}

Скачать boost можно здесь .

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

R>Если MyAbstractClass абстрактный, то такое не прокатит:

R>vector<MyAbstractClass> MyInstanceList;

R>Почему не прокатит, мне понятно.
R>Вопрос: что делать? если хочется иметь список экзямплеров, у которых есть общий абстрактный интерфейс?


vector<MyAbstractClass*> или vector<boost::shared_ptr<MyAbstractClass> >

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

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

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

A>>>а такой вариант не подойдет:
A>>> vector<MyAbstractClass*> MyInstanceList;
A>>>?
R>>Э... да нежелательно, это ж потом освобождай память из-под динамически созданных экземпляров, а так все копируется и заботиться о памяти ненужно, или нет?
VE>В векторе объекты лежат подряд, это раз.
VE>Как засунуть в такой вектор MyDerviedClass ?
Если там лежат указатели, то все номально. А MyDerviedClass* r MyAbstractClas* приведется. Главное "голые" указатели туда не сувать. Только "умные уазатели". Почему — объяснили выше.

Rothmans wrote:

> Над использованием boost я напряженно размышляю, оглядываясь на начальство.
А надо!

> А можно поподробнее для чайника почему не подойдет auto_ptr?
Это не умный указатель, а автоматический, что видно из названия.
Только один auto_ptr владеет объектом. При вставке в контейнер становится непонятно кто должен владеть.
Он имеет копирующий конструктор от некостантного аргумента, т.е. правая часть разрушается.

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

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

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

LM>>Вариантов немного.
LM>>1. Писать свой умный указатель

R>auto_ptr подойдет?
здесь

Автор: _Winnie
Дата: 26.04.04

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

R>Если MyAbstractClass абстрактный, то такое не прокатит:

R>vector<MyAbstractClass> MyInstanceList;

R>Почему не прокатит, мне понятно.
R>Вопрос: что делать? если хочется иметь список экзямплеров, у которых есть общий абстрактный интерфейс?

R>P.S: Поиском искал, но что-то не получается.

Можно завести список указателей.

vector <MyAbstractClass*> MyInstanceList;

и потом

MyInstanceList. push_back (new MyAbstractClassImp);

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

MQ>

MyInstanceList. push_back (new MyAbstractClassImp);

тут надо заметить, что если push_back кинет исключение, то объект созданный с помощью new MyAbstractClassImp утечёт.

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

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

LM>Вариантов немного.
LM>1. Писать свой умный указатель

auto_ptr подойдет?

Если MyAbstractClass абстрактный, то такое не прокатит:

vector<MyAbstractClass> MyInstanceList;

Почему не прокатит, мне понятно.
Вопрос: что делать? если хочется иметь список экзямплеров, у которых есть общий абстрактный интерфейс?


P.S: Поиском искал, но что-то не получается.

On Wed, 22 Feb 2006 18:29:38 +0200, Rothmans <46644@users.rsdn.ru> wrote:

> Если MyAbstractClass абстрактный, то такое не прокатит:
>
> vector<MyAbstractClass> MyInstanceList;
>
> Почему не прокатит, мне понятно.
> Вопрос: что делать? если хочется иметь список экзямплеров, у которых есть общий абстрактный интерфейс?
>
>
> P.S: Поиском искал, но что-то не получается.

а такой вариант не подойдет:
vector<MyAbstractClass*> MyInstanceList;
?

--
Andriy Ohorodnyk

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

R>Если MyAbstractClass абстрактный, то такое не прокатит:

R>vector<MyAbstractClass> MyInstanceList;

R>Почему не прокатит, мне понятно.
R>Вопрос: что делать? если хочется иметь список экзямплеров, у которых есть общий абстрактный интерфейс?


R>P.S: Поиском искал, но что-то не получается.

Используйте boost::shared_ptr<MyAbstractClass>

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

A>а такой вариант не подойдет:
A> vector<MyAbstractClass*> MyInstanceList;
A>?

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

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

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

A>>а такой вариант не подойдет:
A>> vector<MyAbstractClass*> MyInstanceList;
A>>?

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

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

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

A>>а такой вариант не подойдет:
A>> vector<MyAbstractClass*> MyInstanceList;
A>>?

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

Если в векторе хранить значения, то при вставке произойдёт "срезка" и полиморфизма не будет.

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

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

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

A>>>а такой вариант не подойдет:
A>>> vector<MyAbstractClass*> MyInstanceList;
A>>>?

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

K>Если в векторе хранить значения, то при вставке произойдёт "срезка" и полиморфизма не будет.

Да.. об этом я не подумал.

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

R>Если MyAbstractClass абстрактный, то такое не прокатит:

R>vector<MyAbstractClass> MyInstanceList;

R>Почему не прокатит, мне понятно.
R>Вопрос: что делать? если хочется иметь список экзямплеров, у которых есть общий абстрактный интерфейс?

В С++ только с помощью указателей на эти самые экземпляры.

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

A>Используйте boost::shared_ptr<MyAbstractClass>

Да не хотелось бы доп.библиотеки использовать.

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

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

A>>Используйте boost::shared_ptr<MyAbstractClass>
R>Да не хотелось бы доп.библиотеки использовать.
Вариантов немного.
1. Писать свой умный указатель
2. Использовать boost
3. Использовать другие библиотеки

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

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

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

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

A>>>>а такой вариант не подойдет:
A>>>> vector<MyAbstractClass*> MyInstanceList;
A>>>>?
R>>>Э... да нежелательно, это ж потом освобождай память из-под динамически созданных экземпляров, а так все копируется и заботиться о памяти ненужно, или нет?
VE>>В векторе объекты лежат подряд, это раз.
VE>>Как засунуть в такой вектор MyDerviedClass ?
LM>Если там лежат указатели, то все номально. А MyDerviedClass* r MyAbstractClas* приведется. Главное "голые" указатели туда не сувать. Только "умные уазатели". Почему — объяснили выше.

Точно! смарт-поинтерами-то я и воспользуюсь!

Здравствуйте, Rothmans, Вы писали:
<skipped>
LM>>Если там лежат указатели, то все номально. А MyDerviedClass* r MyAbstractClas* приведется. Главное "голые" указатели туда не сувать. Только "умные уазатели". Почему — объяснили выше.
R>Точно! смарт-поинтерами-то я и воспользуюсь!
В boost::shared_ptr это кто? Вы не хотите использовать внешние библиотеки, а в "стандартном" С++ естб только один умный указатель std::auto_ptr. Его сувать в контейнер нельзя.

P.S. Не считайте, что boost — крайне редкий зверь. Он очень полезный. www.boost.org

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

LM>Здравствуйте, Rothmans, Вы писали:
LM><skipped>
LM>>>Если там лежат указатели, то все номально. А MyDerviedClass* r MyAbstractClas* приведется. Главное "голые" указатели туда не сувать. Только "умные уазатели". Почему — объяснили выше.
R>>Точно! смарт-поинтерами-то я и воспользуюсь!
LM>В boost::shared_ptr это кто? Вы не хотите использовать внешние библиотеки, а в "стандартном" С++ естб только один умный указатель std::auto_ptr. Его сувать в контейнер нельзя.

LM>P.S. Не считайте, что boost — крайне редкий зверь. Он очень полезный. www.boost.org

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

Всем большое спасибо!

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

>> А можно поподробнее для чайника почему не подойдет auto_ptr?
_>Это не умный указатель, а автоматический, что видно из названия.
Он очень даже умный, у него просто семантика такая.
_>Только один auto_ptr владеет объектом. При вставке в контейнер становится непонятно кто должен владеть.
Сумбурно, но примерно так
Он имеет копирующий конструктор от некостантного аргумента
Это не важно, он обычный копирующий конструктор (12.8p2), но не выполняется условие CopyConstructible (20.1.3p1 Table 30) #2 u == T(u) и Assignable (23.1p4 Table 64) #1.
_>, т.е. правая часть разрушается.

Pavel Chikulaev wrote:

>> > А можно поподробнее для чайника почему не подойдет auto_ptr?
> _>Это не умный указатель, а автоматический, что видно из названия.
> Он очень даже умный, у него просто семантика такая.
Ну... Понятие ума неформализуемо

> _>Только один auto_ptr владеет объектом. При вставке в контейнер
> становится непонятно кто должен владеть.
> Сумбурно, но примерно так
> Он имеет копирующий конструктор от некостантного аргумента
> Это не важно, он обычный копирующий конструктор (12.8p2), но не
> выполняется условие CopyConstructible (20.1.3p1 Table 30) #2 u == T(u) и
> Assignable (23.1p4 Table 64) #1.
auto_ptr(
auto_ptr<Type>& _Right
) throw( );

А "нормальные" классы должны иметь:

Obj(
const Obj& _Right
) throw( );

Т.е. порядочный компилятор должен отказываться компилировать std::vector< std::auto_ptr<int> >.
И другие классы, у которых копиктор "неправильный".

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

PC>Скачать boost можно здесь .

А здесь — алгоритмы адаптированные для использования с полиморфными контейнерами.

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

_>Pavel Chikulaev wrote:

>>> > А можно поподробнее для чайника почему не подойдет auto_ptr?
>> _>Это не умный указатель, а автоматический, что видно из названия.
>> Он очень даже умный, у него просто семантика такая.
_>Ну... Понятие ума неформализуемо
Прикольно, он и правда не smart В стандарте нет такого названия.
Однако в TR1 все стали умными.

>> _>Только один auto_ptr владеет объектом. При вставке в контейнер
>> становится непонятно кто должен владеть.
>> Сумбурно, но примерно так
>> Он имеет копирующий конструктор от некостантного аргумента
>> Это не важно, он обычный копирующий конструктор (12.8p2), но не
>> выполняется условие CopyConstructible (20.1.3p1 Table 30) #2 u == T(u) и
>> Assignable (23.1p4 Table 64) #1.
_>auto_ptr(
_> auto_ptr<Type>& _Right
_>) throw( );

_>А "нормальные" классы должны иметь:

_>Obj(
_> const Obj& _Right
_>) throw( );
Это совсем не обязательно. Главное, что выполнялось:

T t;
u == T(u); //CopyConstuctible
u = t;
u == t; //Assignable;

А какая сигнатура не важно, ссылки я тебе дал, да и спецификация исключений может быть любой — пусть кидают, нигому не жалко.

_>Т.е. порядочный компилятор должен отказываться компилировать std::vector< std::auto_ptr<int> >.
_>И другие классы, у которых копиктор "неправильный".
Они не должны, это UB (см. 20.4.5p3), и стандартная библиотека не обязана информировать об этом пользователя.
Жди concepts из С++0х

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

I>А здесь — алгоритмы адаптированные для использования с полиморфными контейнерами.

А зачем? Всё уже есть, но они реализованы как члены-функции. Если не хватит легко добавить новые:

bool comp(some_type & lhs, some_type & rhs)
{
    //
} 
void foo()
{
    ptr_vector<some_type> v;
    std::stable_sort(v.begin().base(), v.end().base(), boost::make_void_ptr_indirect_fun(comp));
}

Да и я очень сомневаюсь, что все стандартные алгоритмы применимы и/или нужны для контейнеров указателей.

На данный момент в boost.ptr_container реализованны следующие алгоритмы:
sort, unique, erase_if, merge.

Pavel Chikulaev wrote:
> >> _>Это не умный указатель, а автоматический, что видно из названия.
> >> Он очень даже умный, у него просто семантика такая.
> _>Ну... Понятие ума неформализуемо
> Прикольно, он и правда не smart В стандарте нет такого названия.
> Однако в TR1 все стали умными.
Декларативная умность. :о)
> Это совсем не обязательно. Главное, что выполнялось:
> T t;
> u == T(u); //CopyConstuctible
> u = t;
> u == t; //Assignable;
>
>
> А какая сигнатура не важно, ссылки я тебе дал, да и спецификация
> исключений может быть любой — пусть кидают, нигому не жалко.
Ну да, исключения тут не при чём, я просто из msdn скопировал как есть.
Дело в том, что многие методы берут константную ссылку, например

*void push_back(*
* const Type& *_Val
*);
*Т.е. ты просто не сможешь сделать /push_back(auto_ptr)/, т.к. этот метод использует копирующий конструктор от неконстантной ссылки. А мы можем дать только константную.

> _>Т.е. порядочный компилятор должен отказываться компилировать
> std::vector< std::auto_ptr<int> >.
> _>И другие классы, у которых копиктор "неправильный".
> Они не должны, это UB (см. 20.4.5p3), и стандартная библиотека не
> обязана информировать об этом пользователя.
> Жди concepts из С++0х
Те условия, которые ты привёл в общем случае невозможно проверить даже
теоретически. Но компилятор хотя бы может проверить сигнатуры.

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

_>Ну да, исключения тут не при чём, я просто из msdn скопировал как есть.
_>Дело в том, что многие методы берут константную ссылку, например

_>*void push_back(*
_>* const Type& *_Val
_>*);
_>*Т.е. ты просто не сможешь сделать /push_back(auto_ptr)/, т.к. этот метод использует копирующий конструктор от неконстантной ссылки. А мы можем дать только константную.
??? Да какая разница!

The auto_ptr provides a semantics of strict ownership. An auto_ptr owns the object it holds a
pointer to. Copying an auto_ptr copies the pointer and transfers ownership to the destination. If more
than one auto_ptr owns the same object at the same time the behavior of the program is undefined.
[Note: The uses of auto_ptr include providing temporary exception-safety for dynamically allocated
memory, passing ownership of dynamically allocated memory to a function, and returning dynamically
allocated memory from a function. auto_ptr does not meet the CopyConstructible and
Assignable requirements for Standard Library container elements and thus instantiating a Standard
Library container with an auto_ptr results in undefined behavior. —end note]

The type of objects stored in these components(containers) must meet the requirements of CopyConstructible
types (20.1.3), and the additional requirements of Assignable types.

>> _>Т.е. порядочный компилятор должен отказываться компилировать
>> std::vector< std::auto_ptr<int> >.
>> _>И другие классы, у которых копиктор "неправильный".
>> Они не должны, это UB (см. 20.4.5p3), и стандартная библиотека не
>> обязана информировать об этом пользователя.
>> Жди concepts из С++0х
_>Те условия, которые ты привёл в общем случае невозможно проверить даже
_>теоретически. Но компилятор хотя бы может проверить сигнатуры.
Уж лучше тогда так:

struct CopyConstructible;
struct Assignable;

class my_type
{
//...
public:
    boost::mpl::vector<CopyConstructible, Assignable> concepts;
};

class auto_ptr
{
//...
public:
    boost::mpl::vector<> concepts;
};

template<typename T>
struct vector
{
    ~vector()
    {
        //...
        BOOST_STATIC_ASSERT(boost::mpl::has_key<typename T::concepts, CopyConstructible>::type::value);
        BOOST_STATIC_ASSERT(boost::mpl::has_key<typename T::concepts, Assignable>::type::value);
    }    
};

Pavel Chikulaev wrote:

> _>Ну да, исключения тут не при чём, я просто из msdn скопировал как есть.
> _>Дело в том, что многие методы берут константную ссылку, например
>
> _>*void push_back(*
> _>* const Type& *_Val
> _>*);
> _>*Т.е. ты просто не сможешь сделать /push_back(auto_ptr)/, т.к. этот
> метод использует копирующий конструктор от неконстантной ссылки. А мы
> можем дать только константную.
> ??? Да какая разница!
Эм... Я немного о другом говорю.

> struct CopyConstructible;
> struct Assignable;
>
> class my_type
> {
> //...
> public:
> boost::mpl::vector<CopyConstructible, Assignable> concepts;
> };
Ты просто постулируешь, что твой тип обладает этими свойствами, но обладает ли он на самом деле — невозможно. Так что
смысла от таких штук я не вижу.
Но С++ может хотя бы проверять константность. Кстати, assignable/copyconstuctible можно проще запретить
"private:operator=;Class(const &);"
А если говорить о другом подходе (С++0x ?..) то, имхо, лучше просто отменить неявно создаваемые копикторы и ассигнеры —
ибо, по-моему, проблемы только от них (да и были они сделаны исключительно ради совместимости с С). Тогда тип без явно
написанных этих методов просто не будет возможным помещать в контейнеры, например.

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

_>Ты просто постулируешь, что твой тип обладает этими свойствами, но обладает ли он на самом деле — невозможно.
Проверить-то нельзя, поэтому нужно доверится typename T::concepts
_>Так что смысла от таких штук я не вижу.
_>Но С++ может хотя бы проверять константность. Кстати, assignable/copyconstuctible можно проще запретить
_>"private:operator=;Class(const &);"
Это разные вещи. нужно гарантировать t == T(t), и u = t, u == t. для всех t.

_>А если говорить о другом подходе (С++0x ?..) то, имхо, лучше просто отменить неявно создаваемые копикторы и ассигнеры —
_>ибо, по-моему, проблемы только от них (да и были они сделаны исключительно ради совместимости с С). Тогда тип без явно
_>написанных этих методов просто не будет возможным помещать в контейнеры, например.
Нет обратной совместимости — значит такого не будет никогда.

Pavel Chikulaev wrote:

> _>Ты просто постулируешь, что твой тип обладает этими свойствами, но
> обладает ли он на самом деле — невозможно.
> Проверить-то нельзя, поэтому нужно доверится typename T::concepts
А толку? Если это обязать, то не будет обратной совместимости, если сделать рекомендацией, то нафиг никому не нужно —
смысла ноль. Может для других ситуаций concepts будет полезным, но в этой ситуации бесполезно.

> _>Так что смысла от таких штук я не вижу.
> _>Но С++ может хотя бы проверять константность. Кстати,
> assignable/copyconstuctible можно проще запретить
> _>"private:operator=;Class(const &);"
> Это разные вещи. нужно гарантировать t == T(t), и u = t, u == t. для всех t.
Просто "обидно", что это может проверить только человек. Хочется, чтобы максимально возможную часть работы выполнял
компилятор.

> _>А если говорить о другом подходе (С++0x ?..) то, имхо, лучше просто
> отменить неявно создаваемые копикторы и ассигнеры —
> _>ибо, по-моему, проблемы только от них (да и были они сделаны
> исключительно ради совместимости с С). Тогда тип без явно
> _>написанных этих методов просто не будет возможным помещать в
> контейнеры, например.
> Нет обратной совместимости — значит такого не будет никогда.
Как будто между C и C++ есть совместимость.


Проблема в том, что если кто-то пишет что-то вроде:

class MyClass
{
public:
MyClass() {field_ = new char[100];}
~MyClass {delete field_;}
private:
char *field_;
};
А потом решает такое использовать в контейнере или просто возвращать по значению — дело дрянь.
Для С это было приемлимо, а вот в С++ — большая гадость.

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

_>Проблема в том, что если кто-то пишет что-то вроде:

_>class MyClass
_>{
_>public:
_> MyClass() {field_ = new char[100];}
_> ~MyClass {delete field_;}
_>private:
_> char *field_;
_>};
_>А потом решает такое использовать в контейнере или просто возвращать по значению — дело дрянь.
_>Для С это было приемлимо, а вот в С++ — большая гадость.

А нельзя ли поподробнее, почему такой класс -- это дрянь в С++?
PS.: Разве в С были классы? Как же тогда это было приемлемо в С?

Rothmans wrote:

> _>Для С это было приемлимо, а вот в С++ — большая гадость.
> А нельзя ли поподробнее, почему такой класс -- это дрянь в С++?
Выполни такой код в debug сборке и попробуй разобраться, почему вываливается ошибка проверки памяти.

class MyClass
{
public:
MyClass() {field_ = new char[100];}
~MyClass() {delete field_;}
private:
char *field_;
};

int _tmain(int argc, _TCHAR* argv[])
{
MyClass a;
MyClass b = a;
return 0;
}

Так вот я хочу, чтобы такой код не компилировался вообще.

> PS.: Разве в С были классы?
Были структуры. Копировать структуры почленно — можно. Объекты — в большинстве случаев — нельзя.

>Как же тогда это было приемлемо в С?
Не было деструкторов. И вызовы каждой функции были явными.

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

_>Rothmans wrote:

>> _>Для С это было приемлимо, а вот в С++ — большая гадость.
>> А нельзя ли поподробнее, почему такой класс -- это дрянь в С++?
_>Выполни такой код в debug сборке и попробуй разобраться, почему вываливается ошибка проверки памяти.

_>class MyClass
_>{
_>public:
_> MyClass() {field_ = new char[100];}
_> ~MyClass() {delete field_;}
_>private:
_> char *field_;
_>};

_>int _tmain(int argc, _TCHAR* argv[])
_>{
_> MyClass a;
_> MyClass b = a;
_> return 0;
_>}

_>Так вот я хочу, чтобы такой код не компилировался вообще.

Разве тут проблема не решится определением копирующего конструктора? Все остальное можно оставить и оно будет ок, или?

Rothmans wrote:
>
> Разве тут проблема не решится определением копирующего конструктора? Все
> остальное можно оставить и оно будет ок, или?

Решится. Но, по-моему, об этом должен сказать компилятор (и он без проблем может!), а не вдруг обнаружить программист
после отладки.