телефонный справочник

[_Bers]

Сообщение от rrrFer

несколько раз прочитал первый пост, не нашел там ничего про однофамильцев. Сам придумал?

Зато нашел это:

Распечатка в алфавитном порядке абонентов из заданного диапазона номеров или фамилий; например, для номеров диапазон может быть: 222222 - 333333, а для фамилий: Иванаускас - Иванов (то есть Иванова в диапазон не входит).

Прочитай ещё раз внимательно.

Обрати внимание на это:
Распечатка в алфавитном порядке абонентов из заданного диапазона номеров или фамилий; например, для номеров диапазон может быть: 222222 - 333333, а для фамилий: Иванаускас - Иванов (то есть Иванова в диапазон не входит).

Сообщение от rrrFer

словарь нужен - но то
map<string, int>, то map<int, string>

Ну поэтому я и написал выше: в реальной задачи потребуются мапы для каждого столбца:

имя_столбца -- запись.

Для задачи, где нужно выбирать по фамилиям и номера получается:

фамилия - запись
номер - запись

Это два multimap связанные через значение "запись".

Сообщение от rrrFer

в структуре можно перегрузить операторы сравнения типа lessByName и lessByNumber, например.

Смысл? Как это тебе вообще поможет?
Тебе в любом случае понадобится делать карту на каждый столбец, по которому ты захочешь выбирать.
Карта по дефолту замечательно умеет сортировать и символьные и числовые ключи.

Зачем создавать ещё какую то непонятную структуру, да ещё перегружая операторы сравнения?

Сообщение от rrrFer

ну и я бы multiset тут использовал (там есть параметр шаблона, в который я передал бы этот lessByName).

ООП головного мозга: городить ненужные классы, со всякими перегруженными операторами сравнения, и глобальной friend впридачу.

Осталось только продемонстрировать на деле выборку: по фамилиям и диапазону номеров

[rrrFer]

ООП головного мозга: городить ненужные классы, со всякими перегруженными операторами сравнения, и глобальной friend впридачу.

операторы сравнение в абоненте должны спасти меня от лямбд в справочнике

Распечатка в алфавитном порядке абонентов из заданного диапазона номеров или фамилий; например, для номеров диапазон может быть: 222222 - 333333, а для фамилий: Иванаускас - Иванов (то есть Иванова в диапазон не входит).

Прочитай ещё раз внимательно.

Обрати внимание на это:
Распечатка в алфавитном порядке абонентов из заданного диапазона номеров или фамилий; например, для номеров диапазон может быть: 222222 - 333333, а для фамилий: Иванаускас - Иванов (то есть Иванова в диапазон не входит).

прочитал очень внимательно, нашел слово ИЛИ (это значит что потребуется лишь одна мапа.

Осталось только продемонстрировать на деле выборку: по фамилиям и диапазону номеров

ИЛИ по фамилиям ИЛИ по номерам. Мапа нужна одна - set, перегрузка операторов и абонент не нужны (если абонент не будет изменяться), но если у абонента гипотетически может появиться еще одно поле по которому нужно делать выборку - то без класса абонента таки не обойтись (но это гипотетически)

[_Bers]

Сообщение от rrrFer

операторы сравнение в абоненте должны спасти меня от лямбд в справочнике

Ой ой ой... не то, что бы я против лямбд, но нафига они тут нужны то???

Сообщение от rrrFer

прочитал очень внимательно, нашел слово ИЛИ (это значит что потребуется лишь одна мапа.

ИЛИ по фамилиям ИЛИ по номерам.

Ну в принципе да: можно трактовать как "или" (без и).
но даже если трактовать как "или", все равно потребуется две мультимапы: одна на фамилии, другая на номера.

Единственное упрощение для фамилий здесь заключается только в том, что вместо поиска ключей содержащих подстроку, можно просто сразу же запросить всех однофамильцев по ключу мультимапа:

http://www.cplusplus.com/reference/m...p/equal_range/

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

Сообщение от rrrFer

но если у абонента гипотетически может появиться еще одно поле по которому нужно делать выборку - то без класса абонента таки не обойтись (но это гипотетически)

В реальном серьёзном проекте, где действительно требуется гибкость, используют специализированные механизмы, которые либо являются fronted для баз данных аля sql, либо имитируют работу таковых (БД полностью в оперативной памяти).


Например, я у себя на работе сделал вот такой fronted:

Есть механизм Table. Который реализует бизнес-логику работы с таблицей. Такую как добавление столбцов, добавление записей, выборки и тп.

От него наследуется конкретная таблица, которая создает конкретные столбцы, заполняет их некоторыми первичными данными (это нужно для юнит тестов).

Можно и не наследоваться, а использовать Table напрямую, но если всяких разных таблиц паредполагается множество - то наследование улучшает читабельность и структуру кода.

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

namespace DB
    {
        TableTransaction::TableTransaction(const eMODE mode)
            :Table(mode)
        {
            TableName("transaction")

                [ TYPES ][ AUTO_ID ][   INT   ][     DATE     ][     TIME     ][      INT      ]
                [ NAMES ][  "id"   ][ "value" ][   "tr_date"  ][   "tr_time"  ][ "contr_agent" ]
                    <<      NONE   << DEFAULT << CURRENT_DATA << CURRENT_TIME <<    DEFAULT  
                    <<      NONE   << DEFAULT << CURRENT_DATA << CURRENT_TIME <<    DEFAULT    ;

        }
    }

Таблица умеет работать в режиме "офф-лайн": таблица целиком существует в оперативной памяти. В этом случае выборки из таблицы осуществляются средствами самой таблицы.

Либо в режиме "он-лайн": таблица на самом деле связана с реальной базой данных. В моем случае это postgres, и всякого рода выборки из этой реальной базы осуществляется на самом деле средствами самого postgres, а сама таблица на самом деле лишь конвертирует sql-подобный синтаксис собственный в sql с которым работает postgres.

Можно создавать любые таблицы аля "телефонная книга". Добавлять/удалять/делать выборку. С любым количеством столбцов или строк.

[rrrFer]

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

Мне тоже как-то раз понадобилось что-то типа Pattern matching, я пытался сделать на мапах - не получилось (если у тебя нужна выборка по 1 полю - нужна 1 мапа, по двум - 2, трем - 3...у меня их было 4 и требовалось часто удалять и добавлять данные - это надо делать одновременно во все мапы. Все осложнялось еще и тем, что требовались выборки одновременно по 1 и 2 мапе, скажем - вобщем был нужен нормальный pattern matching, а не такая залипуха)

В реальном серьёзном проекте, где действительно требуется гибкость, используют специализированные механизмы, которые либо являются fronted для баз данных аля sql, либо имитируют работу таковых (БД полностью в оперативной памяти).

либо берут более подходящий язык ))

Ой ой ой... не то, что бы я против лямбд, но нафига они тут нужны то???

вобще, думал будут нужны для выборок. Но да, стандартные типы сравнятся сами.

но даже если трактовать как "или", все равно потребуется две мультимапы: одна на фамилии, другая на номера.

да хватит одной мапы. Я это ИЛИ понимаю так, что от студента хотят, чтобы он хоть что-нибудь сделал (или первой или второе)

и глобальной friend впридачу.

а friend зачем? )