Skip to content

Latest commit

 

History

History
44 lines (34 loc) · 4.24 KB

lesson003_report.md

File metadata and controls

44 lines (34 loc) · 4.24 KB
Raw

Занятие 003 2021-05-17

Выполнение заданий по Stepic 1.12 Плюс чтение материалов

Тайминг

  1. (01:00)(01:00) Выполнение степика с просмотром доп примеров из стековерфлоу
  2. (00:08)(01:08) Читал статью https://blog.golang.org/slices-intro
  3. (00:27)(01:35) Читал статью и делал немного заданий из https://blog.golang.org/slices
  4. (00:13)(01:48) Просмотрел "трики" https://github.com/golang/go/wiki/SliceTricks
  5. (00:12)(02:00) Читал https://habr.com/ru/post/525940/ и смотрел в https://play.golang.org/ про ссылки и прямое указание срезов

Замечания

  1. Есть синтаксис с многоточием для автоматического присвоения размера массиву x := [...]int{1,2,3}
  2. Есть синтаксис присвоения отдельных элементов x:=[5]int{2: 3, 3: 17}
  3. (+) Как и все переменные для простых типов массив инициализируется значениями по умолчанию, а не нуллами
  4. (+) Можно как в питоне свапнуть значения переменных, включая элементы массивов x[0],x[1]=x[1],x[0]
  5. (-?) То что срезы то на одном массиве работают (и меняют его) и тут же если переполняются стряпают новый - выглядит хотя и оптимизировано по хранению, но источником багов. Я бы предпочел явный какой-то механизм.
  6. (!) Надо помнить, что слайсы идут по ссылке, а массивы по значению при передаче в функциий, ПРИЧЕМ на самом деле и срезы по значению, но внутри там ссылки на хранилища
  7. (?) https://blog.golang.org/slices - всюу до этого структура слайса описывалась как (*[]T, size, cap) а тут дается иная картинка, с хидером и указателем на первый элемент
  8. (-) https://github.com/golang/go/wiki/SliceTricks - необходимость при удалениях еще и явно подчищать остатки если там что-то ссылочное
  9. (-) https://github.com/golang/go/wiki/SliceTricks - кажется достаточно резонным вопрос, почему эффективные варианты операций не сделаны в основной библиотеке golang а должны как тайное знание такими сниппеты передаваться

В целом понятно. Но не очень нравится, что слайс это одновременно и вьюха над готовым массивом и динамический массив одновременно. Понятно в принципе как устроено, но при чтении кода, особенно если явно не известна длина среза - сложно понять - будет или нет подмена хранилища под срезом или нет и т.д. Корче в сочетании с необходимостью ставить nil для ссылочных типах при изменении, мне кажется что срезы - эта такая точка в которой много очень скрытых ошибок формируется.

Результаты

По степику все сведено в директории, особенно ничего особенного в заданиях нет.

По второй статье делал некоторые задания, например

  1. типа сложное для указателе и UTF