гарантирует порядок по мапу, но гарантирует по слайсу?
Почитайте за unordered map,она по дефолту в го, если вам нужна упорядоченная мапа то смотрите в сторону ordered map
в го специально сделано так что бы порядок элементов в мап был рандомен слайс никакого отношения к мап не имеет, но да он сохраняется сортировку
Неспециально, а исходя из реализации
Зря ожидал. У мапы под капотом range лежит рандомизатор перебора ключей. Специальная фича от производителя.. ;)
шиза производителя скорее
не, не шиза, в go мапы реализованы с использованием хэш таблиц и в связи с этим порядок всегда будет разным. Сделано в угоду быстрой производительности операций INSERT и GET
Да уже все равно, баг, фича или шиза.. оно так есть. Если надо упорядоченно доставать из мапы, то рядом соберите слайс ключей, по нему и итерируйтесь в порядке сборки или сортировки. По ключам достаете из мапы чего надо было..
если тебе нужно unordered_map - используй unordered_map. нормальное std должно поддерживать несколько типов хотя бы самых базовых map под юзкейсы и быть расширяемым,композитным, иметь компораторы и redefine хеш-функции всего такого. почему я должен мутить костыли с векторами и соответственно ударом по памяти, если мне нужна обычная упорядоченная мапа? кстати, у меня к тебе такой вопросик. O(1) у хешмапы всегда быстрее logN у красно-черного или сета скажем?
Вот это первый раз слышу
Там запилен рандом по ключам. Специально.
а какой верный ответ на последний вопрос?
конечно же нет
в каких случаях нет?
у хешмапы лучше комплексити, но это ниче не говорит о его эвристике и на малом количестве дерево c logN будет значительно быстрее + у него нет никаких колизий, там стабильное время выполнения, никакого перехеширования, а у красно-черных элементы балансируются. если нужно что-то искать по критериям, диапазонам, вхождениям, порядку элементов то хешмапы совсем проигрывают
Обсуждают сегодня