> Передача "по ссылке" ни как не выделяется на стороне вызывающего.
Зачем её выделять?
Затем, что когда читаешь код, хочется знать, что происходит: может у тебя под ногами переменная поменяться, или всё-таки нет.
> Если "ссылки" задумывались как "не NULL" поинтеры, то лучше было сохранить взятие адреса при передаче параметра.
Ссылки задумывались, чтобы можно было написать a + b независимо от того, являются ли эти термы интами, комплексными числами или вообще векторами в N-мерном пространстве с указателем на аллоцируемую в рантайме память под капотом.
В данном примере явно прослеживается применение const ссылок. Ок, согласен, что передачу const ссылок можно было бы сделать без взятия адреса, а передачу мутабельных - с взятием. Меня бы такое устроило.
Сохранение "совместимости с C" в плане преобразования типов: сделать шаблон, надёжно различающий int, bool и поинтер - задача не тривиальная.
Передача "по ссылке" ни как не выделяется на стороне вызывающего. Если "ссылки" задумывались как "не NULL" поинтеры, то лучше было сохранить взятие адреса при передаче параметра.
Я встречал пример с построением графика. Система с поддержкой -0.0 рисовала правильный график, а без поддержки - с артефактами. И как раз из-за подобного деления на переменную, стремящуюся к нулю (и в какой-то момент становящейся +0 или -0), где-то внутри формулы.
Нет. Cassandra (ScyllaDB) и HBase реализуют одинаковую идеалогию двух-уровневого key-value: partition key + clustering key. Отличие: в Cassandra partition key распределяется в distributed hash table, а в HBase он тоже "сортирован".
Каждый ((pk, ck), value) - это отдельная запись в сторадже с временем вставки и возможным маркером удаления. В HBase даже можно использовать время вставки как третий ключ, и получать историю изменения одного value.
Колоночными их назвали по ошибке, потому что в английском они использовали понятие wide column : в одной Row (которая есть value для partition key) может быть огромное множество полей (field) с не фиксированными именами.
Так же можно считать "колоночными базами" различные Hadoop/BigData движки запросов (Presto, Hive, Spark) поверх специальных форматов файлов (Parquet, ORC).
Вот блин: на захвате переменной цикла споткнулся. И вроде ж известная грабля, сам при написании уже на автомате отслеживаю. А при чтении чужого кода не заметил :-(
Извините, но ваш вариант читается хуже, имхо.
Код нужно не только писать, но и читать. Иногда chaining выглядит красивее, иногда делает кашу там где не нужно.
Вот в этом примере, чейнинг делает всё только хуже и медленнее. Особенно учитывая, что matches может быть составным условием на две строчки, а do_job_with и no_matches_found могут быть по три-десять строчек каждый. Выписывать в lambda или в отдельностоящие функции в питоне будет… disgusting.
Но, безусловно, в каком нибудь другом языке это будет выглядеть привычнее.
Хотя вместо do().else() я пять раз из шести предпочёл бы сохранить результат array.filter() в переменную и проверить обычным if.
matched = array.filter{|el| matches}
if !matched.empty?
matched.each{|v| do_job_with(v)}
else
no_matched_found()
end
Расскажу из жизни маркетплейса: все маркетплейсы друг-друга выкачивают, чтобы мониторить ассортимент и цены конкурента. При этом, если не душить того, кто к тебе приходит с фул-сканом, он с удовольствием выжрет все твои ресурсы (а что, ещё и лёгкий DoS).
Так что, на то, чтобы конкуренту было не удобно тебя выкачивать «по-быстрому», прилагается не тривиальный объём усилий.
А потом ещё веб-краулеры заявляются, и тоже хотят тебя проиндексировать. Если в коде веб-приложения затесался тяжёлый запрос, краулер с радостью тебя приложит.
емнип, в базовой работе, на которой основывались эти "уязвимости" позже была найдена ошибка. И потому крипкостойкость этих алгоритмов всё ещё не опровергнута. Сомнения имеются, но доказанных уязвимостей пока в публичном доступе нет.
Про Гугл не знаю, но в авиастроении есть правило «менять не более 10% за раз»: новая конструкция должна отличаться от предыдущей не более чем на 10%.
А причём тут решарпер и С++ ? Вы имели в виду Clion?
А когда diff просматриваете в GitHub/GitLab, вам решарпер поможет?
Затем, что когда читаешь код, хочется знать, что происходит: может у тебя под ногами переменная поменяться, или всё-таки нет.
В данном примере явно прослеживается применение const ссылок. Ок, согласен, что передачу const ссылок можно было бы сделать без взятия адреса, а передачу мутабельных - с взятием. Меня бы такое устроило.
У меня две претензии к языку:
Сохранение "совместимости с C" в плане преобразования типов: сделать шаблон, надёжно различающий int, bool и поинтер - задача не тривиальная.
Передача "по ссылке" ни как не выделяется на стороне вызывающего. Если "ссылки" задумывались как "не NULL" поинтеры, то лучше было сохранить взятие адреса при передаче параметра.
На первых пентиумах ещё отдельно распаивался на материнке. В картриджах для Slot-1/Slot-A тоже отдельными микросхемами был.
правда, вариантов перепаять вроде не было.
На некоторых старых интелах с «крутой» встройкой был L3 128МБ, работающий преимущественно как видео-память.
Всегда думал: проц с таким количеством памяти на борту вполне мог бы работать без внешней памяти.
Я встречал пример с построением графика. Система с поддержкой -0.0 рисовала правильный график, а без поддержки - с артефактами. И как раз из-за подобного деления на переменную, стремящуюся к нулю (и в какой-то момент становящейся +0 или -0), где-то внутри формулы.
К сожалению, давно это было, ссылку не отыщу.
Нет. Cassandra (ScyllaDB) и HBase реализуют одинаковую идеалогию двух-уровневого key-value: partition key + clustering key. Отличие: в Cassandra partition key распределяется в distributed hash table, а в HBase он тоже "сортирован".
Каждый ((pk, ck), value) - это отдельная запись в сторадже с временем вставки и возможным маркером удаления. В HBase даже можно использовать время вставки как третий ключ, и получать историю изменения одного value.
Колоночными их назвали по ошибке, потому что в английском они использовали понятие wide column : в одной Row (которая есть value для partition key) может быть огромное множество полей (field) с не фиксированными именами.
https://en.wikipedia.org/wiki/Wide-column_store
Вот ClickHouse - истинно колоночная база данных. А также Amazon RedShift, Greenplum, Sybase IQ (SAP IQ), KDB и другие
https://en.wikipedia.org/wiki/List_of_column-oriented_DBMSes
Так же можно считать "колоночными базами" различные Hadoop/BigData движки запросов (Presto, Hive, Spark) поверх специальных форматов файлов (Parquet, ORC).
Вот блин: на захвате переменной цикла споткнулся. И вроде ж известная грабля, сам при написании уже на автомате отслеживаю. А при чтении чужого кода не заметил :-(
А ты знаешь цену этого Loongson? Или ты о российском опыте?
Середнячка (или всё-таки топа) 2011 года хватает для всех офисных задач. Лишь бы памяти под Chrome хватало.
Так что, пересадить поголовно чиновников на компы с этим процессором получится относительно легко. (А кто не захочет, может пересесть в другое место).
Тебе пришлось так развёрнуто объяснять, что делают четыре строчки кода, и ты их продолжаешь называть «читаемыми»?
ну-ну.
Извините, но ваш вариант читается хуже, имхо.
Код нужно не только писать, но и читать. Иногда chaining выглядит красивее, иногда делает кашу там где не нужно.
Вот в этом примере, чейнинг делает всё только хуже и медленнее. Особенно учитывая, что matches может быть составным условием на две строчки, а do_job_with и no_matches_found могут быть по три-десять строчек каждый. Выписывать в lambda или в отдельностоящие функции в питоне будет… disgusting.
Но, безусловно, в каком нибудь другом языке это будет выглядеть привычнее.
Хотя вместо do().else() я пять раз из шести предпочёл бы сохранить результат array.filter() в переменную и проверить обычным if.
Да, длиннее. Но понятнее.
Кстати, у while тоже есть else.
Так что, на то, чтобы конкуренту было не удобно тебя выкачивать «по-быстрому», прилагается не тривиальный объём усилий.
А потом ещё веб-краулеры заявляются, и тоже хотят тебя проиндексировать. Если в коде веб-приложения затесался тяжёлый запрос, краулер с радостью тебя приложит.
емнип, в базовой работе, на которой основывались эти "уязвимости" позже была найдена ошибка. И потому крипкостойкость этих алгоритмов всё ещё не опровергнута. Сомнения имеются, но доказанных уязвимостей пока в публичном доступе нет.
В долгосрочной перспективе с большой вероятностью выгодное. Неадекваты, даже высокопрофессиональные, в конечном итоге разлагающе действуют.
Наберут адекватных, получится более сплоченный и сосредоточенный на достижение цели коллектив.
Блин, промахнулся :-( хотел плюс поставить
Всех в Юту! В Solt Lake City!
Написал бы прямо «отклонения» вместо «девиации».