Russian Qt Forum

Решил сделать контейнер аля QStringList.


Проблема 1. Реализация должна быть в h-файле. Причем, если используется внутри библиотеки  - можно и в cpp, а если экспортируется, то нельзя. Кто-нибудь знает почему?

Проблема 2. У QList нет метода, возвращающего T&. Поэтому в методах CMyClassList приходится писать (*this)[_i]. Или сделать функцию
То ли троли забыли, то ли наследоваться от QList это плохо.

А зачем наследоваться от QList?

typedef QList<CMyClass> CMyClassList;
Может это все что нужно?

Сначала было так. Но потом начали появляться операции над всеми элементами контейнера. Например, вызвать определённый метод. Думал сделать QList членом класса, но CMyClassList - контейнер, и используется как контейнер. Наследование самое оно.
Например, QstrinList.

Неверным путем идешь, товарищ. :)
Определенный метод для всем лучше сделать через стандартные алгоритмы и свой функтор.

Не понял.

Образный пример:

C++ (Qt)
CMyClass {
.........
public:
   void someFunction ();
.........
}
...................
struct CMyClassFunctor {
void operator() (CMyClass *c) {c->someFunction ();}
}
.............
QList <CMyClass*> list;
std::for_each (list.begin(), list.end(), CMyClassFunctor ());

Пантер, что же плохого в насдовании?

Отвечу вопросом на вопрос: а зачем оно в данном случае? Бритва Оккама (http://ru.wikipedia.org/wiki/%D0%91%D1%80%D0%B8%D1%82%D0%B2%D0%B0_%D0%9E%D0%BA%D0%BA%D0%B0%D0%BC%D0%B0)

Суть в том, что бы избавиться от таких конструкций по всему коду. Отличий от цикла, проходящего по всем элементам, не много.

И 10 функторов смотрятся "хуже", чем 10 методов одного класса. А если два таких списка?

Тогда лучше QList агрегировать в свой класс. Не нужно наследоваться от классов, которые не созданы для наследования.

не понял, oprator[] же возвражает норм ссылку, а at() конст ссылку.

Ну как сказать. С одной стороны вроде да, все можно делать теми "функторами". А с другой - ну так оно неряшливо смотрится, что желание Sasa иметь "человеческий" класс очень понятно. Откуда у Вас взялся CMyClass? Чему он служит кроме "функтора"? Отож.

Если наследуешься от класса, который для этого не предназначен, можешь огрести косяков. А на счет неряшливости я что-то совсем не понял. Если именно о "красивости" хедера идет разговор, то лучше всего заюзать пимпл.

наследовался от кулиста косяков не было. предназначен наследоваться, не предназначен - какая разница

Такая, что деструктор не обязательно виртуальный, внутренности (private) скрыты и что в них - хз (т.е. нету полного контроля над внутренней реализацией), protected в большинстве отсутствует.

класс будет жить на стеке и виртуальный дестр ему не нужен

Ога. Это типа такое ограничение? А вдруг забуду и сделаю его в куче? Т.е. захочу удалить через указатель на QList.

Чего-то я тоже не понимаю, что плохого в наследовании от QList?

то ты перейдешь в разряд быдлокодеров. Нахрена майлист кастить к базовому классу?

Ну, и в методах получается


Мало того, что выглядит страшно, так она ещё подсвечивается в IDE не как метод.


В коде этот класс используется как контейнер. Можно, конечно, переопределить кучу методов, да так, чтоб не ошибиться с со всякими const, &, << и т.д. Долго и ошибкоопастно.

Вот здесь я делаю такой изврат:
http://qtcoder.blogspot.com/2010/02/directmap-map.html (http://qtcoder.blogspot.com/2010/02/directmap-map.html)

C++ (Qt)
template <class Key, class Value>
class DirectMap : private QList<QPair<Key, Value> >
{
public:
  //! Добавляем пару
  void append(const Key &, const Value &);
  //! Список ключей
  QList<Key> keys() const;
  //!
  Value operator[](const Key & key) const;
};
 
 
 

А зачем дублировать информацию о ключах, ведь её можно извлечь из  QList<QPair<Key, Value> >?
И почему просто не воспользоваться QMap?

Ой, совсем брежу)) QList - эт ж не член)) Первый вопрос решён))

по второму вопросу можно узнать ответ, прочитав каменты по той ссылке, что приведена перед фрагментом кода

Ясненько)

А чего это "ссылка" производит такое магическое действие?  :) Я вот читаю и не врубаюсь

На то он и map (красно-черное дерево) чтобы автоматом упорядочиваться, зачем называть это недостатком?

Не жирно ли будет работать линейным перебором? Если "так надо" то с тем же успехом можно задействовать любой контейнер прямого доступа, а прятать это в операторе [] - никак не гуд. Если я чего-то не понял - поясните.

На то он и map (красно-черное дерево) чтобы автоматом упорядочиваться, зачем называть это недостатком?

Ну не недостаток.
Я хочу мап, в котором ключи не упорядочиваются.

Не жирно ли будет работать линейным перебором? Если "так надо" то с тем же успехом можно задействовать любой контейнер прямого доступа, а прятать это в операторе [] - никак не гуд. Если я чего-то не понял - поясните.
[/quote]

Согласен, код неоптимален, но общая идея как раз в том, чтобы спрятать в операторе [] процесс доступа к данным.