ну, когда точно знаешь, сколько тебе надо, преаллоцируешь руками, и норм

да я понимаю, просто с го толко осваиваюсь, немного не понял момент, в статье про слайсы тоже не увидел

откуда в го пришел?

перл

жесть

а так с улицы )

да я понимаю, просто с го толко осваиваюсь, немного не понял момент, в статье про слайсы тоже не увидел

такое поведение же везде, просто оно скрыто. Какий-нибудь arrayList работает подобным образом

хм, ну там блоки памяти, насколько я помню, тоже не по 1ому выделяются

просто ты про cap в перле и не знаешь, пока в профиль не залезешь

ну там внутри-то и не массив ведь по факту

какой-нибудь односвязный список, я точно не помню

Нене, доступ же за о1

просто это оптимальней, чем при каждом добавлении элемента реалоцировать память

иначе ты и память засрешь быстрее маленькими объектами

а поговорить?

обсудим алокацию массива в памяти?) или уже все обсудили?

а вам есть, что добавить или исправить? я не прочь новых знаний набраться

обсудим алокацию массива в памяти?) или уже все обсудили?

А там разве не просто выделяется область нужного размера?)

нет

А как?

сам массив указателей то неприрывая структура

объекты могут в хипе где угодно валяться, для них выделяется столько, сколько нужно

а вот массив указатель должен лежать монолитов

А мы про массив указателей говорим, или просто про массив? Массив да, монолитом, я про это и говорил.

И по нему поэтому легко брать нужное, знаешь его начало, и знаешь, на сколько умножить индекс, чтоб в памяти сдвинуться...

не, ну если взять обычный моссив объектов, объектам не обязательно лежать именно "в самом массиве"

И по нему поэтому легко брать нужное, знаешь его начало, и знаешь, на сколько умножить индекс, чтоб в памяти сдвинуться...

Поскольку размер ячеек одинаковый:)

я думал, что все массивы должены нефрагментированно и последовательно храниться, чтобы можно смещаться по памяти

т.е. не надо в памяти хранить длинную змею объектов

не, ну если взять обычный моссив объектов, объектам не обязательно лежать именно "в самом массиве"

Это в случае указателей так. А если объекты по значению в него - то надо змею. Разве нет?

главное, чтобы указатели на эти объекты были по порядку

не, не надо

type A struct {} x := [3]A{a1, a2, a3} - змея же будет. Тут без указателей.

нужна змея адресов этих объектов

на уровне языка не будет

а в памяти оно как угодно может быть

type A struct {} x := [3]A{a1, a2, a3} - змея же будет. Тут без указателей.

+

А если x := [3]*A{&a1, &a2, &a3} то тут уже только указатели внутри массива, а объекты хз где.

в смысле есть у тебя arr (length == 10). Это значит, что у тебя должно быть в памяти пространство на 10 адресов

а объекты сами хер знает где в хипе

а объекты сами хер знает где в хипе

Не верю. Если массив объектов - одно, если массив указателей - другое.

ок

давай посмотрем на это с другой стороны

массив может хранить объекты рахного размера?

разного типа

массив может хранить объекты рахного размера?

Не-а (ну мы про го говорим)

[]interface{}

но это ссылка же

[]interface{}

Это будет слайс объектов типа интерфейс{} :) В доке про рефлексию про это вроде говорится.

суть типа в массиве - это возможность перемещаться, сдвигаясь на размер типа по массиву?

коллеги, как бы вы поэлегантнее из одного оффсета перевели в другой? именно оффсет now := time.Now() // тут московская зона +0300 newOffset := "+0730"

суть типа в массиве - это возможность перемещаться, сдвигаясь на размер типа по массиву?

Ну, да. И знать, что можно с элементом сделать.

а как понять, сколько interface{} занимает?

Не-а (ну мы про го говорим)

ну, в го может быть. В целом же сами объекты могут быть где угодно. Динамические массивы так чаще всего и делаются - массив адресов отдельно, объекты отдельно

тогда нет нужды выделять один длинный кусок памяти

ну, в го может быть. В целом же сами объекты могут быть где угодно. Динамические массивы так чаще всего и делаются - массив адресов отдельно, объекты отдельно

Тут согласен.

а как понять, сколько interface{} занимает?

unsafe.Sizeof ;) https://play.golang.org/p/PrNJAlafjA

И даже так: https://play.golang.org/p/gZkDkmkVCa

коллеги, как бы вы поэлегантнее из одного оффсета перевели в другой? именно оффсет now := time.Now() // тут московская зона +0300 newOffset := "+0730"

https://golang.org/pkg/time/#Time.In ?

https://golang.org/pkg/time/#Time.In ?

0730 - это что за Location?

эмм, направишваются 2 вопроса - 1. и правда, что за оффсет? 2. есть fixedzone в том же пакете

у москвы же вроде изменилась таймзона

оупс )? фейл небольшой

когда перестали переводить

эмм, направишваются 2 вопроса - 1. и правда, что за оффсет? 2. есть fixedzone в том же пакете

1. Обычный оффсет - 7:30 от UTC выставлен клиентом. 2. Да, FixedZone нашел, но надо парсить оффсет в секунды. Вот спрашиваю, может что поэлегантнее можно придумать

вообще, хранить время по Москве - не самая дальновидная идея :) сама по себе

вообще, хранить время по Москве - не самая дальновидная идея :) сама по себе

очень плохая вообще)

ERROR: S client not available

хранишь по гринвичу и норм

у москвы же вроде изменилась таймзона

в моем мире зона у москвы осталась та же Europe/Moscow

вообще, хранить время по Москве - не самая дальновидная идея :) сама по себе

речь не идет о хранении, если внимательно присмотреться к вопросу

речь не идет о хранении, если внимательно присмотреться к вопросу

ктож всматривается?

"поинтеры создают доп нагрузку на GC"

кто-то пояснит мне за эту цитату?

Лолшто?

читаю статью на хабре

могу скинуть линк

давай

https://m.habrahabr.ru/post/325468/

1. Обычный оффсет - 7:30 от UTC выставлен клиентом. 2. Да, FixedZone нашел, но надо парсить оффсет в секунды. Вот спрашиваю, может что поэлегантнее можно придумать

поэлегантнее, валидировать offset через TZ какой-нибудь (получать список и хранить в памяти), получить Name по оффсету, и делать In

https://m.habrahabr.ru/post/325468/

используя указатели, шанс улететь на хип выше, чем без оного, в статье написано некорректно и без объяснений, тк если переменная локальная, и не покидает скоупа, она все равно будет на стэке

"поинтеры создают доп нагрузку на GC"

может имеется ввиду что увеличивает на шаг действие гц на этапе маркировки объектов? хз, но помоему увеличение этапа gc когда stw возможно только если резко возрастает частотность создание неважно чего поинтеров или значений

https://m.habrahabr.ru/post/325468/

см http://www.agardner.me/golang/garbage/collection/gc/escape/analysis/2015/10/18/go-escape-analysis.html и разбирайся :) там много весёлого и странного

см http://www.agardner.me/golang/garbage/collection/gc/escape/analysis/2015/10/18/go-escape-analysis.html и разбирайся :) там много весёлого и странного

поступил к чтению, спасибо

используя указатели, шанс улететь на хип выше, чем без оного, в статье написано некорректно и без объяснений, тк если переменная локальная, и не покидает скоупа, она все равно будет на стэке

не знаю, как в ГО, но в целом может быть иначе. Опять же, в стек может класться просто ссылка на объект, а объект класться в хип

и вам советую почитать про escape analysis и про gc в Go, тогда будете знать как в ГО

https://segment.com/blog/allocation-efficiency-in-high-performance-go-services/ тоже на эту тему

Здесь можно задать вопрос: Новый проект на чем лучше фронтенд начинать на React.js или Vue.js ? (сайт средних размеров - создание турнирных сеток)

бек на го, естественно

Здесь можно задать вопрос: Новый проект на чем лучше фронтенд начинать на React.js или Vue.js ? (сайт средних размеров - создание турнирных сеток)

да ты охренел?

извини, пошутил

есть чат по жс

да ты охренел?

изучаю общественное мнение

есть чат по жс

я знаю

но там неадекваты, каждый свое болото хвалит

после твоего вопроса вдруг стало интересно сколько Гоистов пишет фронтенд

не пописывает, а именно пишет)

если ты имеешь ввиду жс-фреймворки, по-моему - каждый второй

ну не знаю

ни одной строчки фронта за полтора года на Go не написал