Реализация таблицы
Пользователь выбирает каталоги и файлы для каталогов, прога вычисляет некоторые данные для каждого из выбранных файлов. Вопрос: как этовсе хранить? Ну есть ли какие нибудь классы или средства для удобной работы с такими данными (типа STL)
Желательно пример!
Народ, а не подскажите, как с помощью STL сделать таблицу типа: путь, файл, размер, уникальное чило.
Желательно пример!
STL предназначен для работы с коллекциями объектов (любого типа). так что просто заведи свой объект и создай вектор от него, например так
class Mik
{
private:
AnsiString strPath;
AnsiString strFile;
int iSize;
int iUnique;
};
class MikTable : public vector<Mik>
{
....
};
class Mik
{
private:
AnsiString strPath;
AnsiString strFile;
int iSize;
int iUnique;
};
class MikTable : public vector<Mik>
{
....
};
Не порождайте MikTable от vector<Mik> публичным образом. Потому что это не нужно, никаких особых преференций от этого не получишь. Достаточно просто объявить
Ещё, раз уж речь зашла о STL, то, пожалуй, стоит заменить AnsiString на string. Завтра мы откажемся от Борланда (а вдруг?!!), а переделывать минимум.
Не порождайте MikTable от vector<Mik> публичным образом. Потому что это не нужно, никаких особых преференций от этого не получишь. Достаточно просто объявить
Да, иногда более полезно писать не class MikTable : public vector<Mik>, а class MikTable : private vector<Mik>, так как таким образом скрывается реализация. А что касается typedef, то тут не могу согласиться. Наследование в отличие от typedef позволяет в каком-нибудь другом файле написать:
class MikTable;
....
MikTable *mt;
без знания определения MikTable. С typedef такой фокус не проходит.
я думаю что если завтра мы откажемся от Borland, то переделывать вряд ли будет минимум, а с Borland использовать AnsiString намного удобнее чем STL string, так как все properties и аргументы Borland функций используют AnsiString.
Да, иногда более полезно писать не class MikTable : public vector<Mik>, а class MikTable : private vector<Mik>, так как таким образом скрывается реализация. А что касается typedef, то тут не могу согласиться. Наследование в отличие от typedef позволяет в каком-нибудь другом файле написать:
class MikTable;
....
MikTable *mt;
без знания определения MikTable. С typedef такой фокус не проходит.
В каком-нибудь другом - это в заголовочном. Да, таким образом можно съэкономить пятьдесят-восемьдесят милисекунд при компиляции заголовка. На мой взгляд, больше пользы от такого объявления нет. Если цель - полиморфно использовать MikTable, то тогда придётся определять пригоршню нужных функций и перенаправлять их собственно вектору. В таком случае и приватное наследование ни к чему, лучше использовать закрытый член:
private:
vector<Mik> TableImp;
public:
const Mik& operator[](int) const;
Mik& operator[](int);
//...........................
};
Да ещё итераторы.
Если тщательно отделять пользовательский интерфейс от внутренней логики программы, то переделывать действительно придется не слишком много. Ничто так не осложняет переход на другой каркас классов GUI как применение изощренных визуальных контролов, удобовосприятие которых сомнительно, и смешение кода логики и кода GUI.
А Билдер, как RAD, не препятствует этому. Более того, все мы, по мере освоения, читали в различных книгах замечательные примеры, где в обработчиках событий реализованы смысл и цель программы. Авторы книг хотели как лучше, а непредвзятый читатель воспринимает как всегда.
Typedef же имеет смысл применять только в объявлении типов указателей на функции, другого смысла в нём нет, всё остальное проще и удобнее делать наследованием классов. Относительно же использования агрегации вектора в противоположность наследованию от него это тоже верно, однако у меня например в реальной практике обычно идёт public наследование, так как достаточно часто удобно пользоваться этим классом именно как коллекцией, со всеми STL алгоритмами, итераторами и т.п.
Однако большого смысла не использовать AnsiString всё-таки нет, так как даже если на каком-то другом компиляторе такого класса не окажется, его не сложно и написать, а его тспользование в BCB позволяет не писать при каждом взаимодействии с GUI .c_str() что красоты и понятности программе не прибавляет.
И не лень переписывать написанное? Дяди постарались, дяди сделали. Зачем изобретать велосипед?
Вообще не согласен. Typedef хорошо подходит для объявлений коротких имен для шаблонных классов.
vector<Mik> как таковой (или typedef'ная MikTable) и есть коллекция со всеми STL алгоритмами, итераторами и т.п.. Пользуйся на здоровье. Допустим, хочется добавить MikTable какие-либо дополнительные функции, ну тогда закрытое наследование ещё можно как-то оправдать. А публичное - не обнаруживаю смысла.
А зачем, кстати, коллекции, которой является MikTable, ещё какие-то обязанности? Ей и своих хватает. Эти дополнительные обязанности логичнее поручить другому классу, MikTableObliged, пусть он и горбатится.
И не лень переписывать написанное? Дяди постарались, дяди сделали. Зачем изобретать велосипед?
Да не переписывать, просто сделать переходник к тому же string. А в BCB пользоваться AnsiString намного удобнее чем string, согласен?
Вообще не согласен. Typedef хорошо подходит для объявлений коротких имен для шаблонных классов.
Ну мы же вроде договорились что для этого придётся везде где используются указатели на объект этого класса включать определение класса, что создаёт ненужную привязку к реализации, дело не во времени компиляции.
vector<Mik> как таковой (или typedef'ная MikTable) и есть коллекция со всеми STL алгоритмами, итераторами и т.п.. Пользуйся на здоровье.
Я про это и написал :) Ты сам с собой споришь?
Публичное - вместо твоего typedef, так как typedef не обеспечивает того сервиса который даёт наследование
А зачем, кстати, коллекции, которой является MikTable, ещё какие-то обязанности? Ей и своих хватает. Эти дополнительные обязанности логичнее поручить другому классу, MikTableObliged, пусть он и горбатится.
Конечно, вполне возможна и во многих случаях полезна такая реализация. Однако по моему опыту (ну не слишком уж маленькому), чаще всего добавить в MikTable несколько полезных методов (обычно обрабатывающими её же данные) достаточно и не приходится делать дополнительные классы, которые над ней глумятся. В общем универсального решения не существует, надо смотреть по ситуации. НО (!) публичное наследование такого вида намного более удобно в дальнейшей работе чем typedef, это факт.
Что касается мест, где используется указатель на коллекцию, то указателем можно просто манипулировать, не вдаваясь в подробности указываемого объекта, и можно оперировать этим объектом. Для второго варианта все равно придется включать реализацию или интерфейс. Если MikTable - интерфейс (абстрактный класс), то для реализации следует использовать закрытое наследование или агрегирование. Если же MikTable - реализация, открыто порождённая от vector<Mik>, то какой тут выигрыш?
Да что, собственно, копья ломать. Лишь бы работало!!! Хе-хе.
Проблема в том что мы уже весьма далеко ушли от темы изначального вопроса. Так что чтобы не продолжать весь этот офтопик, предлагаю на этом и поставить точку. Было приятно побеседовать.