обычно это просто увеличивает энтропию в мире… а к тому же зачастую мешает менять и совершенствовать код в этих проектах.
Делать реально нормальный опенсорс это труд причем не малый. Зачастую стоит пожалеть нервы и время людей которые вдруг используют ваш код. Т.к. саппорт или даже ответ на свой вопрос они врят-ли получат
эм, как бы есть встроенный vet много чего может подсказать по коду, понятно что в go нет pointer арифметики, а за память у него gc отвечает, но это не значит что в какой ни буть printf программист передал все аргументы да ещё и правильных типов и т.п.
чет не видел такого, альфа и сбер — пропускают только если карта самого банка, не знаю проверяет ли она состояние карты но то что чужую не пускает точно
как минимум она убила тех инжинеров которые спускались в зону аварии на разветку (из-за не возможности работы роботов) и получали дозы не совместимые с жизнь
ну size то меняется между ними поэтому тут одной никак
по поводу аллока — это то что выделяется в куче, то что выделяется на стеке там не показывается (ибо быстро и так легко не отследишь)
кстати это на 1.9 были результаты ради интереса проверил на 1.8: BenchmarkFib10-8 5000000 247 ns/op 32 B/op 5 allocs/op
BenchmarkFib10-8 10000000 181 ns/op 16 B/op 4 allocs/op
получается неплохо так доработали компилятор в 1.9 — как миниму он сумел все вызовы strconv.Itoa на стеке разместить
func formatPAXRecord(k, v string) (string, error) {
const padding = 3 // Extra padding for ' ', '=', and '\n'
size := len(k) + len(v) + padding
sizeLen := len(strconv.Itoa(size))
size += sizeLen
sizeStr := strconv.Itoa(size)
if len(sizeStr) != sizeLen {
sizeStr = strconv.Itoa(size + len(sizeStr) - sizeLen)
}
record := sizeStr + " " + k + "=" + v + "\n"
return record, nil
}
не знаю насколько читаем этот вариант, но для начального кода: BenchmarkFib10-8 10000000 163 ns/op 32 B/op 2 allocs/op
для этого BenchmarkFib10-8 20000000 94.9 ns/op 16 B/op 1 allocs/op
тоже чтоли пул риквест сделать
судя по тому, что расположено по вашей ссылке это ограничения на установку куки. т.е. грубо говоря защита от того, что кто-то на поддомене инжектнет в браузер куку на основной домен. https://tools.ietf.org/html/draft-west-cookie-prefixes-05 в Introduction об этом написано, как бы это не пересекающийся кейс с csrf
ну у вас чет все также не математично из формулы x + y сделать x / y…
55% то не от жителей азии, а от 100% установок вируса (куда и 7% и 12% тоже входят)
Делать реально нормальный опенсорс это труд причем не малый. Зачастую стоит пожалеть нервы и время людей которые вдруг используют ваш код. Т.к. саппорт или даже ответ на свой вопрос они врят-ли получат
{code}123{code}работаетпо поводу аллока — это то что выделяется в куче, то что выделяется на стеке там не показывается (ибо быстро и так легко не отследишь)
кстати это на 1.9 были результаты ради интереса проверил на 1.8:
BenchmarkFib10-8 5000000 247 ns/op 32 B/op 5 allocs/opBenchmarkFib10-8 10000000 181 ns/op 16 B/op 4 allocs/op
получается неплохо так доработали компилятор в 1.9 — как миниму он сумел все вызовы strconv.Itoa на стеке разместить
ну
не знаю насколько читаем этот вариант, но для начального кода:
BenchmarkFib10-8 10000000 163 ns/op 32 B/op 2 allocs/opдля этого
BenchmarkFib10-8 20000000 94.9 ns/op 16 B/op 1 allocs/opтоже чтоли пул риквест сделать
55% то не от жителей азии, а от 100% установок вируса (куда и 7% и 12% тоже входят)