AP
2.0 у вас не float64. я ж предложил поменять на 2.1<<2
Size: a a a
2020 April 24
VM
А как тут читатель становиться в очередь?
Проверяешь мапу на наличие очереди, если нет - создаешь, затем добавляешь в нее читателя
VM
Как только книга освобождается, проверяем есть ли очередь, отдаем первому из нее и соотв удаляем из очереди
Если никого - возвращаем в библиотеку
Если никого - возвращаем в библиотеку
AE
если оно не float64 то почему %T определяет его как float?
c
c
2.1 : constant 2.1 truncated to integer но без поллитра не разберешьAP
если оно не float64 то почему %T определяет его как float?
c
c
2.1 : constant 2.1 truncated to integer но без поллитра не разберешьAE
теперь ошибка о том, что на флоат не опредён сдвиг
AP
а потом в строке #9 замените b := a << 2 на b := 2.0 << 2
AE
какой же вывод мы можем сделать?
AP
Что 2.0 в вашем примере - это константа, как сказали выше, а не переменная типа float64
AP
2.0 и 2.0 << 2 - разные штуки в итоге
AE
то что она константа - воросов не вызывало)
AE
вопрос почему мы видим такие типы - флоат и инт
AP
вопрос почему мы видим такие типы - флоат и инт
Числовые константы не имеют типа, пока он не будет присвоен явным приведением.
AP
AP
То есть, использование оператора битового сдвига, приводит число 2.0 к типу int
AE
да уж! вот это интересно
VI
а вы знали про проблемы с GC и мапами?
вот ишьи: https://github.com/golang/go/issues/16070
https://github.com/golang/go/issues/20135
только я не понял, в чем причина. у меня есть большая мапа, которая утекает (нет, не говнокод, мапа используется в простой библиотечке go-cache, создатель ссылается на эти же ишьи), но может кто-нибудь сказать, в чем дело?
в смысле? если часто удалять/добавлять в мапу, она утекает?
вот ишьи: https://github.com/golang/go/issues/16070
https://github.com/golang/go/issues/20135
только я не понял, в чем причина. у меня есть большая мапа, которая утекает (нет, не говнокод, мапа используется в простой библиотечке go-cache, создатель ссылается на эти же ишьи), но может кто-нибудь сказать, в чем дело?
Maps that shrink and grow repeatedly used to also cause leaks.
в смысле? если часто удалять/добавлять в мапу, она утекает?
AS
а вы знали про проблемы с GC и мапами?
вот ишьи: https://github.com/golang/go/issues/16070
https://github.com/golang/go/issues/20135
только я не понял, в чем причина. у меня есть большая мапа, которая утекает (нет, не говнокод, мапа используется в простой библиотечке go-cache, создатель ссылается на эти же ишьи), но может кто-нибудь сказать, в чем дело?
в смысле? если часто удалять/добавлять в мапу, она утекает?
вот ишьи: https://github.com/golang/go/issues/16070
https://github.com/golang/go/issues/20135
только я не понял, в чем причина. у меня есть большая мапа, которая утекает (нет, не говнокод, мапа используется в простой библиотечке go-cache, создатель ссылается на эти же ишьи), но может кто-нибудь сказать, в чем дело?
Maps that shrink and grow repeatedly used to also cause leaks.
в смысле? если часто удалять/добавлять в мапу, она утекает?
я бы рекомендовал для долгоживущего кэша использовать более специализированные решения, которые работают вне gc, типа https://github.com/coocood/freecache
AS
заодно можно более явно контролировать потребление памяти
OK
я бы рекомендовал для долгоживущего кэша использовать более специализированные решения, которые работают вне gc, типа https://github.com/coocood/freecache
тут можно вспомнить и allego/bigcache и VictoriaMetrics/fastcache оба проекта чуть более живы, но! имеют и свои ограничения