fshp: А так Вы правы. Даже, немного по-другому взглянув на задачу, понимаю, что даже существуй такой контейнер, он бы не облегчил задачу, а привел бы к новым трудностям, нехарактерным для подхода, основанного на network'ах.
В общем, boost::graph мне в руки, строить network, выяснять элементы многомерного массива. А для хранения идеально подойдет предложенный Вами контейнер - ведь он больше ориентирован не на работу в динамике, а на хранение и дальнейший анализ.
fshp: Строго говоря, не дерево нужно, а network со связями вдоль ребер. Видимо, самое разумное сначала все собрать, а многомерный массив использовать лишь для компактного хранения и представления результата.
Смотрите. Проблема не в геометрической форме, не том, что это "гиперпараллилепипед" получится. Именно он и нужен.
Проблема в том, что ему во все стороны расти нужно, то есть перед нулевыми индексами вставлять, а не только после последних добавлять, причем эффективно. В одномерном случае std:vector не очень хорош для решения таких задач. std::list хорошо вставляет и в начало, ему, конечно, все равно куда вставлять. Равно как и некоторые другие контейнеры эффективно работали бы в одномерном случае.
Но boost::multy_array, похоже, пока недостаточно обобщен для того, чтобы использовать другой способ организации. Будь у него возможность задавать тип базового одномерного контейнера в качестве параметра, он не был бы аналогом только std::vector.
Интересно что и функционал развит у него в другом направлении. Очень похоже на гиперкуб из OLAP - можно слайсить. Очень интересный контейнер, хотя и для другой задачи.
rell_nx: В плане РСУБД напрашивается же следующее. Всю ту кучу возможных колонок надо разбить на две группы. Те принципиальные, по которым Вы собираетесь искать (делать запросы) и те, которые нужны Вам только для информации.
Пример - частота процессора. Она, очевидно, может быть как у процессора, так и у компьютера, планшета или смартфона. То, что по ней будут проводить поиск, весьма вероятно. В самом простом случае этот параметр заслуживает отдельной колонки в общей таблице. И пусть поле будет пустым для вещей, у которых процессора нет, это хорошо и удобно.
Другой случай - это габариты в упаковке, например. Ну не будет никто выбирать телефон по габаритам и весу его коробки. Такие запросы не понадобятся. Но сама информация может быть нужна. Ее можно смело сериализовать с другой такой же описательной информацией и всю кучу класть в одно поле. И доставать оттуда когда понадобится. Туда вообще можно писать что угодно - хоть температуру на Марсе. Главное, для удобства загонять туда эти данные в виде пары ключ-значение.
Например:
Температура на Марсе: 300K
Засунули пары, вытащили пары - а потом вывели где надо. До тех пор, пока значение не разлучается с ключем и не используется каких-нибудь неявных предположений о том, что в каком порядке там лежит, все вообще замечательно.
Разве это неясно? Разве есть причины насиловать таблицы или использовать какие-то извращенные базы данных с уже вместо Вас изнасилованными таблицами?
Ужас, если задуматься :) Получается, что свободное владение C++ или CSharp - это своего рода заклинание :))) Никто не знает, что это такое, а нужно просто сделать умный вид и ударить пяткой в грудь :) Кто убедительнее ударит - тот и молодец :)
rell_nx: Предпочел бы сначала научиться чему-нибудь, а потом делать. Вы простую концепцию освоить не можете, а говорите о более сложных. При этом читать не желаете :)))
И поймите простую вещь. Реляционная база данных и ее таблицы - это не то, что Вы там себе вообразили - куда хочу туда ворочу. Таблицы, связи между ними, ограничения, которые Вы накладываете на поля незыблемы. Эта структура не подлежит изменениям до тех пор, пока Вы не соберетесь полностью изменить дизайн. Они неприкосновенны. Табу. Если Вы хотите хранить в них какую-то ерунду, которая меняется раз от разу - храните, никто не мешает. Надо Вам туда засунуть пары значений - параметр/значение - суйте, и обрабатывайте по месту.
Вы, вот, когда в трамвае прокатиться собираетесь - как все люди входите, или, может быть, в окно лезете, или вентиляционный люк, а может, просторную дыру в его обшивке себе пробиваете?
MiiNiPaa: Собственно то, что для контейнеров STL проверяется не равенство, а эквивалентность и является их неотъемлемым концептуальным свойством. В силу своего предназначения, set при помощи less проверит не возникает ли ситуации, когда в контейнере уже есть значение, которое не меньше добавляемого и одновременно добавляемое не меньше его (эквивалент) и добавит только если такое значение отсутствует. Если программист неверно определил операцию сравнения, не понимая такой работы контейнера, его ждут сюрпризы вплоть до момента полнейшего просветления :)
bogolt: Думаю, книга Effective STL здесь была бы более полезна. Внимание человека, возможно, приковано больше к умному указателю, чем к тому, для чего он в данном случае используется и куда включается. А ведь очевидность и красота того, о чем Вы говорите, следуют из свойств set и способа сравнения, по которому контейнеры устанавливают идентичность !(a
И последний кирпичик, о котором совсем забыл. Реляционные базы данных. До сегодняшнего дня сам удивлялся, почему некоторые задачи, над которыми пришлось бы долго думать в С++, а потом мучительно отлаживать, легко, быстро и безошибочно решались внутри базы данных. Причем выбор этого инструмента во всех случаях был неосознанным и случайным - просто результат мне был нужен в виде базы данных, оттого и делал внутри. А сегодня неожиданно получил ответ.
Здесь автор книги раскрывает основное отличие декларативного языка SQL от тех языков, которые нам привычны и рассказывает об основных ошибках восприятия новичков и пришельцев из других языков и стилей: az-design.ru/index.shtml?Support&DataBase&SQL/Celk...
SQL изначально ориентирован на работу с множествами. А следовательно, и задачи, ориентированные на работу со множествами, решаются им легко и быстро. Те задачи, которые меня удивляли, относятся как раз к таким.
Так что реляционные базы данных тоже очень неплохо бы добавить в список для самообразования :)
Так в том то и дело, что, получается, нигде :) А ведь стоило бы :) И легко бы было новичкам и интересно - интересно, потому что увидели бы сразу глубину профессионала :) А легко, потому что не пришлось бы им Ваши правила учить методом погружения, а узнали бы они их от учителя :)
Десять - пятнадцать простых правил какими средствами Вы решаете проблемы. И пяток строжайших запретов :) Например, за generic programming - на кол :)))
bogolt: То, что стандартов полно, это, конечно. Но Ваши подходы гораздо уже общих стандартов. А Ваши соображения, которыми руководствуетесь и, может быть, случайный неудачный опыт с какими-то из средств, который заставил Вас раз и навсегда их исключить, тоже уникальны для Вашей группы. Если задуматься, то внутри огромного пространства возможностей С++ длинные своды выделяют ограниченные, но значительные области. Которые гораздо шире того, назовем так, диалекта, который Вы создали для себя и используете. Едва ли Ваш диалект слишком уж широк. Скорее всего, Вы ограничиваетесь небольшим, но проверенным и засевшим в подкорках набором средств. И этот Ваш диалект, конечно, непонятен тем, кто говорит на другом диалекте. И длинные своды тут бессильны - Ваш диалект - надстройка над ними. Опиши Вы Ваш подход в виде короткого списка, дай простые и увлекательные примеры - Ваш код, который нравится лично Вам, потратьте пару дней на новичков, увлеките новичков своим видением - и, глядишь, веселее бы пошло обучение Вашему диалекту :) А так, жуть, жуть - казнить нельзя помиловать - ужос :) Не брать новичков Вы не можете, а брать морока :) Очень Вам сочувствую :)
Глупо, конечно, энтузиасту-любителю, давать советы профессионалу, но может быть Вам для новичков стоит краткий свод используемых Вами концепций и приемов создать? А еще вспомнить пару привлекательнейших вещиц, которые Вы никогда не используете, потому что они Вашу концепцию рушат или багам способствуют? Они бы, может, и быстрее в суть дела вникали и портили бы меньше :) Ведь путей много, но как только Вы требуете от человека, чтобы он работал с Вами, становится важным только Ваш путь? :)
В общем, boost::graph мне в руки, строить network, выяснять элементы многомерного массива. А для хранения идеально подойдет предложенный Вами контейнер - ведь он больше ориентирован не на работу в динамике, а на хранение и дальнейший анализ.