RP
мапы ж вообще порядок не гарантируют
Size: a a a
2020 February 27
ŹR
тогда перекачивай через list видимо
Тогда можно сразу брать реализацию на "Кумир"
YZ
ЧЗНХ? Как почнинить?
To list, sort, to map. Но чинить это не надо :)
СИ
Yuri Zhloba
To list, sort, to map. Но чинить это не надо :)
а ему не поможет же, только кодировать из list
SP
https://erlang.org/doc/man/erl_nif.html#enif_map_iterator_create
> The key-value pairs of a map have no defined iteration order. The only guarantee is that the iteration order of a single map instance is preserved during the lifetime of the environment that the map belongs to.
> The key-value pairs of a map have no defined iteration order. The only guarantee is that the iteration order of a single map instance is preserved during the lifetime of the environment that the map belongs to.
ŹR
а ему не поможет же, только кодировать из list
Если в map не возвращать - сработает
YZ
To orddict :)
PG
Yuri Zhloba
To list, sort, to map. Но чинить это не надо :)
удваиваю 🌚
ŹR
https://erlang.org/doc/man/erl_nif.html#enif_map_iterator_create
> The key-value pairs of a map have no defined iteration order. The only guarantee is that the iteration order of a single map instance is preserved during the lifetime of the environment that the map belongs to.
> The key-value pairs of a map have no defined iteration order. The only guarantee is that the iteration order of a single map instance is preserved during the lifetime of the environment that the map belongs to.
Честно говоря, оно всегда упорядывачивает ключи
SP
думаю зависит от размера map
ŹR
Хз что там с гарантиями, но у меня ни разу не было чтобы было по другому
YZ
Кстати, можно, наверное, подхачить pretty print, который форматирует терм при выводе на консоль.
ŹR
iex(1)> Jason.encode(%{a: 1, b: 2})
{:ok, "{\"a\":1,\"b\":2}"}
iex(2)> Jason.encode(%{b: 1, a: 2})
{:ok, "{\"a\":2,\"b\":1}"}
iex(3)> Jason.encode(%{b: 1, a: 2, c: 3})
{:ok, "{\"a\":2,\"b\":1,\"c\":3}"}SP
там же в зависимости от размера map его внутреннее представленгие меняется с массива на tree динамически
ŹR
там же в зависимости от размера map его внутреннее представленгие меняется с массива на tree динамически
Ща проверим. Сколько надо размер?
SP
вроде 64
SP
A
Я не спец в библиотеках. Пишу просто от имени здравого смысла. Ведь структура map и tree имеют схожий интерфей работы с контейнером. Только tree имеет еще и возможность сравнения элементов. Тогда в теории выглядит так что надо сделать tree подходящим контейнером и пользоваться его процедурой обхода элементов. Канонично, но покодить придется... 8)
A
Возможно, что уже все реализовано и надо просто грепать tree в документации 8)