используется? подозреваю, что какая-то приемлемая. и с каждым релизом становящаяся всё лучше и лучше
про функцию на собесах иногда спрашиваю я, и, по-моему, только я и узнать я хочу, на самом деле, заглядывал ли человек в исходники map и важно мне это потому, что map - общая структура на все, практически, языки, и, соответственно, уровень любопытства к ней ясно показывает вообще уровень любопытства к инструментам, ежедневно используемым. это важный параметр для некоторых позиций
кококо бизнесу это не надо, бизнесу надо код)
А есть ли задачи, где знание внутреннего устройства map как-то поможет?
я удовлетворился прочтением блога и статей. надо заглянуть? я, кстати, случайно знал, но забыл
не знаю 🙂 но там прям явлены блеск и нищета go. когда у generic-типа в коде присутствуют ad-hoc оптимизации под конкретные типы - это сильно.
ладно, ты прав. потому что у меня появился вопрос (любопытство), а без заглядывания я не пойму ответ.
А должен это компилятор делать
а кто это делает сейчас?
Программист(в случае мап - авторы go).
Так. Хорошо. Давай заглянем в исходники map. В современных исходниках, как я понимаю, он выбирает между fast32, fast64, faststr (всё ассемблерные реализации) и построенным компилятором замыканием (там вообще везде вызывается t.hasher(..)) Возможно, в каком-то месте этот hasher() ничего не делает, но я не могу найти это место
https://github.com/golang/go/blob/68ecdc2c70544c303aa923139a5f16caf107d955/src/cmd/compile/internal/reflectdata/alg.go#L78 это же?
Ладно. Хорошо. Поправьте меня. Golang в текущей реализации всегда делает хэширование ключа. Никакие целочисленные ключи он впрямую не использует, хотя и имеет специальные функции для 32-битных и 64-битных ключей
Обсуждают сегодня