Да в принципе даже и map[key] = value;

+1

http://en.cppreference.com/w/cpp/container/map/operator_at

Да в принципе даже и map[key] = value;

можно придраться из-за одного лишнего вызова конструктора по умолчанию

это то, с чем я пытаюсь бороться. Стандартная либа должна быть удобной, а не минималистичной

Вот именно - удобной и достаточно логичной, чтобы не лезть каждый раз в документацию. Почему, скажем, чтобы получить индекс мин. элемента нужно использовать не только min_element, но ещё и distance?

Вот именно - удобной и достаточно логичной, чтобы не лезть каждый раз в документацию. Почему, скажем, чтобы получить индекс мин. элемента нужно использовать не только min_element, но ещё и distance?

индекс элемента где?

индекс элемента где?

В последовательности, в vector, например.

можно придраться из-за одного лишнего вызова конструктора по умолчанию

Поэтому я и написал "даже") так-то emplace, конечно, лучше. И не только для мапы.

Вот именно - удобной и достаточно логичной, чтобы не лезть каждый раз в документацию. Почему, скажем, чтобы получить индекс мин. элемента нужно использовать не только min_element, но ещё и distance?

А если это не vector?

А если это не vector?

А что есть distance для "не вектор"?

В последовательности, в vector, например.

ну есть такое дело, да. Нет у нас index_of

А что есть distance для "не вектор"?

расстояние между итераторами

А что есть distance для "не вектор"?

distance возвращает дистанцию между итераторами и это не обязательно random access iterator

то есть там просто будет либо разность, если РА итераторы, или ++/— для двунаправ. и так далее

расстояние между итераторами

Вот это выносит мозг, ну реально же. Мне нужен просто argmin, нафиг мне думать о расстоянии между итераторами?

А что есть distance для "не вектор"?

Я к тому, что min_element должен возвращать iterator, а не что-то еще

Если поиск идет не по вектору, а по списку, то это критично.

Вот это выносит мозг, ну реально же. Мне нужен просто argmin, нафиг мне думать о расстоянии между итераторами?

ну так ты заюзал min_element, он тебе его нашёл

Я к тому, что min_element должен возвращать iterator, а не что-то еще

Я понимаю, в этом суть итераторов как универсального инструмента

сам элемент, а не индекс какой-то

сам элемент, а не индекс какой-то

Ага, но сам элемент без индекса чаще всего бесполезен, само мин. значение

Ага, но сам элемент без индекса чаще всего бесполезен, само мин. значение

оооочень интересное заявление. Не согласен

Ага, но сам элемент без индекса чаще всего бесполезен, само мин. значение

это сектанство :)

оооочень интересное заявление. Не согласен

Зависит от задачи, конечно. :)

Да там какие-то итераторы сплошные, методы в целом не очень удобные. Например, как добавить в map пару ключ-значение? Нужно создать std::pair, а только потом его пихнуть в map.

map[key] = value, не?

map[key] = value, не?

тссс, он осознал уже)

map[key] = value, не?

ну я привык к qt-шному insert(const Key &key, const T &value) и не увидев такого в std огорчился ?

Надо пропоузнуть

ну я привык к qt-шному insert(const Key &key, const T &value) и не увидев такого в std огорчился ?

зачем, если есть даже проще. В Qt тоже своих приветов хватает

Надо пропоузнуть

наифг не нужно

А итератор в map только по парам. То есть для обхода значений без ключей, всегда нужно писать .second. И Это в коде иногда запутывает, что за second - хрен его знает с первого взгляда.

А кмк норм. Пара "ключ-значение"

А итератор в map только по парам. То есть для обхода значений без ключей, всегда нужно писать .second. И Это в коде иногда запутывает, что за second - хрен его знает с первого взгляда.

боже, ты придираешься к таким мелочам.......

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

боже, ты придираешься к таким мелочам.......

Из всех этих мелочей всё и состоит

Из всех этих мелочей всё и состоит

Это совсем мелочи

Нормальные люди уже давно for (auto&& [key, value] : mymap) { ... } пользуются!

Это совсем мелочи

Ладно, но вот шаблонный ад с typedef-ами читать вам нравится?

можно придраться из-за одного лишнего вызова конструктора по умолчанию

а хотя не факт. оно же может мувнуть, а не повторно вызывать.

Почему у какого-нибудь map нет простого метода has_key? Почему надо проверять это через итераторы?

find

или я ошибаюсь?

Нормальные люди уже давно for (auto&& [key, value] : mymap) { ... } пользуются!

Давно?

а хотя не факт. оно же может мувнуть, а не повторно вызывать.

a[key] - приводит к вызову конструктора по умолчанию

Ладно, но вот шаблонный ад с typedef-ами читать вам нравится?

а при чём здесь typedef? Если ты про SFINAE, то да, он ужасне

Давно?

Ну это частично сарказм был.

Ладно, но вот шаблонный ад с typedef-ами читать вам нравится?

Надо его вычищать поганой метлой и юзать using

find

Что find? Я же говорю: почему это надо делать через итераторы и сравнивать что вернул find с end?

Надо его вычищать поганой метлой и юзать using

Плюс один. Бесят сишные алиасы, особенно когда про указатели на функции заходит речь

тоесь это уж слишком неудобно?

a[key] - приводит к вызову конструктора по умолчанию

а, да, увидел)

Что find? Я же говорю: почему это надо делать через итераторы и сравнивать что вернул find с end?

Вообще можно юзать m.count(key) > 0 или даже без > 0

Что find? Я же говорю: почему это надо делать через итераторы и сравнивать что вернул find с end?

ranges должны лечить такие проблемы по идее.

тоесь это уж слишком неудобно?

Да if (m.find("aaa") != m.end()) против if (m.has_key("aaa"))

а что насчёт m.count(key) ?

а что насчёт m.count(key) ?

Да, знаю :)

Ладно, но вот шаблонный ад с typedef-ами читать вам нравится?

Это как раз неизбежная часть синтаксиса меты, так что нравится/не нравится — спи, моя красавица

Да, знаю :)

ну тогда в чём вопрос?

И вообще. Обычно после проверки существования обращаются к элементу. А find как раз даст его

ну тогда в чём вопрос?

Хочу удобных высокоуровневых методов. :)

Хочу удобных высокоуровневых методов. :)

это именно он

делает ровно то, что ты хочешь

Да if (m.find("aaa") != m.end()) против if (m.has_key("aaa"))

ну если приходится так уж часто это проверять - есть макросы.

это именно он

У map count не может вернуть что-то больше 1. Где логика названия "count"? count - подсчитывать.

У map count не может вернуть что-то больше 1. Где логика названия "count"? count - подсчитывать.

ору, просто ору

что насчёт multi_map?

ору, просто ору

:))

ERROR: S client not available

что насчёт multi_map?

Обобщение? Ну да

Обобщение? Ну да

Так проще шаблоны писать.

Так проще шаблоны писать.

В этом и суть stl: шаблоны и итераторы. Мощно, гибко, но низкоуровнево.

ну если приходится так уж часто это проверять - есть макросы.

Не надо макросов в плюсах

Они нужны крайне редко, чтобы их использовать в таких задачах :)

Не надо макросов в плюсах

Геттеры, сеттеры макросами делать удобно. Есть такая библиотека даже, где так сделано. Без них кода было бы в 2 раза больше.

В этом и суть stl: шаблоны и итераторы. Мощно, гибко, но низкоуровнево.

ещё раз - что тебе неудобно делать?))

про мапу и has_key мы поняли уже. Что ещё?) мб мы знаем решение

/stat@combot

combot.org/chat/-1001031904034

ещё раз - что тебе неудобно делать?))

Если честно, то всё :) Я просто жру кактус каждый день и плачу, но выхода нет. Написал для себя разные обёртки, но это костыль и велосипед.

Геттеры, сеттеры макросами делать удобно. Есть такая библиотека даже, где так сделано. Без них кода было бы в 2 раза больше.

Лучше это в виде пропозала оформить, чтобы были нормальные проперти)

Кстати, кто в курсе что такое stl2.0 и как с ним обстоят дела?

Лучше это в виде пропозала оформить, чтобы были нормальные проперти)

Согласен

Оно вроде и abi не сломает

Кстати, кто в курсе что такое stl2.0 и как с ним обстоят дела?

я в курсе. Не забивай себе в этим голову пока что. Всё с ним туманно

это просто перепроектировка текущего stl и исправление былых ошибок

это просто перепроектировка текущего stl и исправление былых ошибок

А каких ошибок?

Лучше это в виде пропозала оформить, чтобы были нормальные проперти)

пропертей не будет. Каст @antoshkka

я в курсе. Не забивай себе в этим голову пока что. Всё с ним туманно

Я помню, что это было нужно как раз чтобы ranges нормальные сделать.

А каких ошибок?

в подробности не вдавался. Я тогда другим был занят

пропертей не будет. Каст @antoshkka

Печально. Ну да ладно

Я помню, что это было нужно как раз чтобы ranges нормальные сделать.

Поддержку ranges и так вроде добавить можно. Но я с ренджами сильно не занком, просто использую на базовом уровне

Кстати на счёт буста, реально вот это туда добавить? https://github.com/CastXML/CastXML/issues/36

Кстати на счёт буста, реально вот это туда добавить? https://github.com/CastXML/CastXML/issues/36

а что это за либа?

CastXML?

CastXML?

ага, не слышал про такое раньше

Это Kitware сделали форк gccxml (вроде) с поддержкой msvc и clang. Генерит abstract syntax tree в xml-формате. Используется в том числе для создания привязок на других языках к C++

The earliest known versions of Dennis Ritchie's first C compiler (Score: 100+) Link: http://j.mp/2tFViPn

/

Property tree has been tested (regressions successfully compiled and run) with the following compilers: Visual C++ 8.0 gcc 3.4.2 (MinGW) gcc 3.3.5 (Linux) gcc 3.4.4 (Linux) gcc 4.3.3 (Linux) Intel C++ 9.0 (Linux)

что нужно знать о свежести документации Property_tree