Почему нет метода front() на std:: map (и других ассоциативных контейнерах из STL)?

ссылка STL, по-видимому, создает концептуальную разницу между:

"Контейнеры последовательности" (список векторов переадресации массива), с одной стороны
"Ассоциативные контейнеры" (с другой стороны, множество мультимножеств multimap unordered_set unordered_multiset unordered_map unordered_multimap).

Кроме того, похоже, что у нас есть:

все контейнеры, реализующие метод begin(), возвращают итератор, указывающий на первый элемент в контейнере.
только контейнеры последовательности, имеющие метод front(), возвращающий ссылку на первый элемент в контейнере.

Я понимаю, что метод front() можно легко определить в терминах метода begin() путем разыменования его возвращаемого значения.

Таким образом, мой вопрос: почему метод front() не определен для всех объектов, определяющих метод begin()? (который должен быть каждый контейнер действительно)

(я предполагаю, что с семантической точки зрения он не имеет особого смысла, чтобы получить первый элемент из карты, как это делается для первого элемента из вектора, но мне было интересно, было ли более допустимым объяснение).

Ответ 1

Вам действительно нужно спросить комитет по стандартам этого (comp.lang.С++. std), но я предполагаю, что да, это просто не имеет особого смысла. Дальше там не так много ясности, что бы это значило. Вы хотите, чтобы корень, предварительный заказ сначала, после заказа сначала, сначала вы вставили...? С последовательностями это совершенно ясно: фронт - одна сторона, другая. Карты - это деревья.

Ответ 2

Фронт() означает упорядочение; "первый в строке".

Begin() подразумевает, что можно начать где-нибудь, где бы ни было.

Ответ 3

Я предполагаю, что:

front() и back() не существовало бы в Sequence, если бы не тот факт, что интерфейс изначально был разработан с изменяемыми последовательностями. front() имеет смысл, когда вы думаете о том, как использовать его в комбинации с push_front() и pop_front(). Для неизменяемых последовательностей (из которых новичок array является единственным примером в стандарте, если вы не считаете const vector), front() является сокращением для *begin(), о котором просто не стоит волноваться.
Поскольку у контейнеров, не упорядоченных по порядку, нет push_front(), не считалось, что стоит их front(). Вы можете добавить записи в map, но вы не можете указать, где в порядке их добавления, так как это ключ. В этом разница между последовательностью и упорядоченной коллекцией.
"Держитесь", вы говорите: "vector имеет front(), но не push_front()". Я подозреваю, что это связано с тем, что vector имеет back() - если вы используете back(), то снова "приятно" использовать front() для его соответствия.

Это просто предположение, основанное на том, что я знаю о разработке полезных/удовлетворяющих API-интерфейсов, и моем наблюдении за API-интерфейсами контейнеров. Я не знаю, как Степанов думал по этому поводу или какой-либо отчет о его обсуждении в стандартном комитете.

Ответ 4

Вы правы, его можно было бы реализовать довольно легко. Но дело в том, что эти контейнеры предназначены для конкретных применений. Наличие члена front() означает, что цель контейнера - иметь явный порядок. Разумеется, значения map упорядочены, но это вопрос о производительности. И, конечно, что бы ни была внутренняя структура, чтобы начать где-то (предоставить begin()), но иногда нет смысла предоставлять front() или back().

Итераторы предназначены для перемещения данных, члены front() предназначены для доступа к первому элементу явно упорядоченной коллекции. Доступ к первому члену карты не имеет смысла, потому что он ассоциативен.

Ответ 5

STL предназначен для прохождения через итераторы. Поэтому я думаю, что front() имеет смысл только для контейнеров, таких как list и deque.