Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Попытки сделать именно контейнер (коллекцию), т.е. один класс вместо россыпи классов, насколько я вижу, приведут как минимум к потере пункта 3.
А зачем вообще пихать структуры или классы в этот мультимап? Можно хранить только индексы и ссылку на объект.
Идея создавать несколько типизированных представлений очень ничго. В дотнете создание пары лишних экземпляров никому поемшать не могут. Более того это настоящая фобия многих плюсовиков — боязнь составных классов (т.е. класса ссылкающегося на кучу подобъектов). Те же коллекции всегда делаются отдельным подобъектом. И что?
А объем кода можно сократить введя перегруженный дженерик-метод (и соотвествющие перегруженные обобщенные представления) который возмет на себя все сложности. Как-то так:
MultiIndex<Item> map = new MultiIndex<Item>;
View<stryng> yView = map.CreateView<stryng>("Y"); // динамическое создание делегата для свойства
// перегруженный вариант с двумя параметрами
View<int, string> XYView = map.CreateView<int, string>(
delegate(A a) { return a.X; },
delegate(A a) { return a.Y; });
yView["Test 2"].X...
XYView[new A(2, "Test 2")].X...
XYView[2, "Test 2"].X...
Собственно, полная типобезопасность, довольно простой и удобный интерфейс.
А как обойти ограничение связанное с невозможностью сослаться на член класса, ты и сам придумал. Делегаты действительно очень часто выручают когда речь идет о гибкости.
Как еще один вариант, вместо делегатов можно воспользоваться стандарной техникой оповещения о изменениях свойств, но этот способ к сожалению требует внесения кода в хранимые классы.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Вот это и была для eao197 "новая дорожка": он с Boost раньше, как уже сказал, не работал.
Я с DataView тоже. Форумы то он читал? Буст, хотя бы на уровне документации изучал?
ПК>Предикат, задающий порядок.
Способ сотрировки?
ПК>ЧТД.
>> Попробуй, например, дописать код сериализации содержимого в ХМЛ или бинарный формат.
ПК>http://boost.org/libs/multi_index/doc/advanced_topics.html#serialization При этом, в отличие от интрузивной сериализации .Net, поддерживается возможность реализации форматов, не предусмотренных авторами классов.
Ну, кое что доступно. Но зачем это нужно? Если захочется ХСЛТ всегда доступен.
>> отфильтровать строки по некоторому критерию (опять же 1-2 строки).
ПК>На C++ для этого обычно используются более общие средства, работающие не только с конкретным классом.
Во оно как? Крутой язык... Жать, что на фиг не упали более общие средства. Фильтровать то нужно тоже по иднексу. Иначе какой вообще смысл от этого мультимапа? Можно и перебором искать.
ПК>Попробуй сделать на C# интерфейс коллекции (т.е. один класс), обеспечивающий проверки времени компиляции, перечисленные в этом
Я тебе там ответил. Могу только еще раз предложить перестать превозносить плюсы. Нет ничего что можно сдалть на них и нельзя на других языках. Вопрос только в подходах.
ПК>Ну, напиши пример объявления коллекции, аналогичного в плане проверок времени компиляции этому
Уже писал. Кода получается меньше.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Странный аргумент. EC>А .NET Framework не нужно устанавливать? Или быть может он весит меньше boost'а и быстрее выкачивается и устанавливается?
Фэймворк ставится один раз вместе со студией (при этом можно просто на Next жать и все). Далле чтобы создать проект и исползовать в нем тот или иной класс нужно нажать пару кнопок. Буст же нужно устанавливать отдельно. Используют его даеко не все. Да и буст — это не одна библиотека подкючаемая одной строкой, а куча для каждой из которых унжно потрахаться, чтобы ее использовать.
Так что странный не мой аргумент, а та упертость с котрой поклонники С++ не признают самых очевидных вещей.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>> Если то, что бустовский мультииндекс лучше, то это тоже не так, у DataView есть масса функционала, которого там нет. Прикинь, к примеру, во что обойдется реализация для него DataView.RowFilter.
ПК>В сравнительно тривиальный адаптер. У нас подобные используются с произвольными диапазонами (заданных парой итераторов).
Адаптеры не смогут испоьзовть индексы.
К тому же это не единственная возможность DataTable/DataSet. Они еще позволяют сливать разыне DataTable/DataSet-ы, получать описание отредактированных данных (причем в разных формах, одна из которых Diff XML), создавать набор связанных DataTable-ов (в DataSet-е) и отображать их на один сложный ХМЛ. И еще черт знает что. В общем, мощьный и слоный класс с очень неплохой производительностью.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В сравнительно тривиальный адаптер. У нас подобные используются с произвольными диапазонами (заданных парой итераторов).
Ну это вряд ли. Видишь ли, там собственный язык запросов, который позволяет вводить фильтры пользователю или хранить их в конфигурации.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Такой стиль у практически всего GPLного опен-сорсного софта. Q>>Да ладно.
MSS>Особо рекомендую GNU grep и SCSI стек из линукса. Песня. Кнут отдыхает.
А USB драйвер, например, написан очень неплохо
Все зависит все-таки от того, кто писал, а нет open source'ности.
Некоторые вещи, к тому же, были написаны очень давно (тот же grep, наверняка), когда вопрос о понятности кода не стоял так остро и не было выработано каких-то рекомендаций по этому поводу. Чем современне программа, тем она лучше написана, как правило. + стиль С-шных программ очень портит требование переносимости. Если программа должна работать на 10-ках различных платформ, она будет выглядеть плохо.
