Библиотека задач по Go | тесты, код, задания
Ir al canal en Telegram
Задачи и тесты по Go для тренировки и обучения. Учиться у нас: clc.to/4o0_XA По рекламе: @tproger_sales_bot Для обратной связи: @proglibrary_feeedback_bot Наши каналы: https://t.me/proglibrary/9197
Mostrar más6 674
Suscriptores
Sin datos24 horas
-147 días
-6530 días
Archivo de publicaciones
Repost from Библиотека Go-разработчика | Golang
💡Стек или куча?
🤔 Живет ли переменная на стеке вызовов, или она динамически выделена в куче?
В большинстве случаев вам не стоит беспокоиться об этом. Go собирает мусор и автоматически очищает неиспользуемые переменные.
Однако сборка мусора имеет свою цену, поэтому чем меньше выделений делает ваш код, тем быстрее он может работать.
📌 Как узнать, выделяется ли переменная в куче?
Некоторые операции по умолчанию вызывают выделение памяти в куче и поэтому легко обнаруживаются и исправляются. Вот несколько примеров:
🔸Строковые переменные неизменяемы. Конкатенация двух строк приводит к новой аллокации и сборке мусора. В качестве альтернативы можно использовать
strings.Builder.
🔸Срезы, которые растут за пределы своей емкости, реаллоцируются. Решение: предварительно выделить срез с помощью make().
🔸Когда функция создает локальную переменную и возвращает указатель на эту переменную, переменная должна быть выделена в куче.
📌 Однако есть ситуации, когда выделения в куче неочевидны. Подумайте об указателях, скрытых внутри других типов данных, таких как срезы или мапы. Или рассмотрите массивы. Если массив слишком большой, чтобы жить на стеке, он выделяется в куче.
📌 Как найти эти случаи выделения в куче?
Запустите или скомпилируйте свой код с флагом сборки мусора "-m", и команда Go выведет заметку каждый раз, когда переменная перемещается или уходит со стека в кучу:
go run -gcflags "-m"
или
go tools compile -m
#tipRepost from Библиотека Go-разработчика | Golang
💡Стек или куча?
🤔 Живет ли переменная на стеке вызовов, или она динамически выделена в куче?
В большинстве случаев вам не стоит беспокоиться об этом. Go собирает мусор и автоматически очищает неиспользуемые переменные.
Однако сборка мусора имеет свою цену, поэтому чем меньше выделений делает ваш код, тем быстрее он может работать.
📌 Как узнать, выделяется ли переменная в куче?
Некоторые операции по умолчанию вызывают выделение памяти в куче и поэтому легко обнаруживаются и исправляются. Вот несколько примеров:
🔸Строковые переменные неизменяемы. Конкатенация двух строк приводит к новой аллокации и сборке мусора. В качестве альтернативы можно использовать
strings.Builder.
🔸Срезы, которые растут за пределы своей емкости, реаллоцируются. Решение: предварительно выделить срез с помощью make().
🔸Когда функция создает локальную переменную и возвращает указатель на эту переменную, переменная должна быть выделена в куче.
📌 Однако есть ситуации, когда выделения в куче неочевидны. Подумайте об указателях, скрытых внутри других типов данных, таких как срезы или мапы. Или рассмотрите массивы. Если массив слишком большой, чтобы жить на стеке, он выделяется в куче.
📌 Как найти эти случаи выделения в куче?
Запустите или скомпилируйте свой код с флагом сборки мусора "-m", и команда Go выведет заметку каждый раз, когда переменная перемещается или уходит со стека в кучу:
go run -gcflags "-m"
или
go tools compile -m
#tipЕсть буферизованный канал с определенной емкостью и горутина, которая читает из него данные. Что произойдет, если канал закроется, хотя в нем еще остались данные?
Repost from Библиотека Go-разработчика | Golang
💡Как тривиально проверить значения интерфейса на nil?
В Go новички часто сталкиваются с проблемой интерфейсных переменных, которым присваивае
тся nil указатель. В таком случае, хотя значение в интерфейсе является nil, сама переменная интерфейса не равна nil.
Пример: создаем переменную x как указатель на int, который по умолчанию nil, и переменную y как пустой интерфейс, который тоже nil по умолчанию. После присваивания x переменной y, интерфейс y уже не является nil, хотя x все еще nil.
var x *int
var y any
y = x
📌 Что вернет y == nil?
Вернет false. Это потому, что интерфейс не просто представляет значение, которое ему присвоено, а действует как контейнер для этого значения.
Для проверки, является ли значение в интерфейсе nil, нужно использовать утверждение типа. Например, для проверки y на nil, используем:
y.(*int) == nil
Это показывает, что интерфейс y не nil, но содержащееся в нем значение — nil. Полный пример здесь.
#tipУ Тинькофф открылась стипендиальная программа для студентов на 2024 год!
В отборе могут участвовать студенты бакалавриата, специалитета и магистратуры (кроме выпускного курса) из всех городов и ВУЗов.
Стипендия выдаётся на один учебный год и составляет 25 000 ₽ в месяц. Кроме этого:
🖋️ доступ к лекциям;
🖋️ общение с менторами;
🖋️ отложенный оффер на стажировку или работу в Тинькофф
Более подробная информация и форма подачи заявки 👉 по ссылке
Переходите и подавайте заявку на одну из крупнейших в стране частных стипендий для студентов!
Реклама АО «Тинькофф Банк» ИНН 7710140679
Что такое starvation (голодание) в контексте конкурентности в Go?
🧑💻 Статьи для IT: как объяснять и распространять значимые идеи
Напоминаем, что у нас есть бесплатный курс для всех, кто хочет научиться интересно писать — о программировании и в целом.
Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.
Для кого: для авторов, копирайтеров и просто программистов, которые хотят научиться интересно рассказывать о своих проектах.
👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.
