Насколько я понял, проблемы две: «недостоверные источники» и «пользователь не указал работодателя». Вопрос: зачем спорить про то, заплатит ли работодатель за статью на Wikipedia, если можно просто добавить страничку http://en.wikipedia.org/wiki/User:PaulEremeeff с требуемой информацией и спорить уже только про источники?
У меня в firefox forEach медленнее в ≈30 раз, в Chromium — >60 раз. Подозреваю, что если forEach будут активно использовать, то браузеры начнут агрессивно встраивать код на основании предположений о типе this, а до тех пор придётся терпеть.
Думаю, что этот момент можно несколько приблизить, написав популярный(!) benchmark, проверяющий скорость выполнения ES6‐конструкций.
Как я понял, метод nextесть. Но не у массива, а у его итератора и вам нужно переписать код, чтобы он сначала получал итератор, а потом уже использовал next, чтобы получить код, эквивалентный for of. То, что есть, не является эквивалентным кодом.
Насколько я понимаю, CMake нормально переваривает любую систему сборки. Во всяком случае, в neovim (единственный проект, который я знаю, который не считает, что зависимости должны устанавливаться пакетным менеджером) как‐то с этим нормально справляются.
make install делать не рекомендуется, если только вы ставите не в каталог, который потом будете подключать через LD_LIBRARY_PATH и который содержит либо только одну конкретную зависимость, либо только зависимости для одного конкретного проекта (соответственно, в обоих случаях его можно снести, зная, что именно при этом поломается и что именно вы сносите) — make uninstall далеко не всегда есть. Тот же CMake не генерирует его по‐умолчанию.
Я говорю не про «лёгкость». Я говорю про то, предусмотрена такая ситуация производителем или нет. У Apple не предусмотрен такой сценарий, как «вытаскивание памяти, форматирование, …», а производители жёстких дисков против использования их продукции без ФС ничего против не имеют. Именно поэтому у Apple нет 16 ГБ, а в жёстких дисках есть 1 ТБ. А не потому, что у жёстких дисков такой возможностью воспользоваться легко, а в продукции Apple нет.
При чём «не предусмотрен» здесь — это вариант с лишением гарантии в первую очередь. Во вторую — «мы даже и не думали, что так можно сделать».
Нет, это совершенно другое дело. Во‐первых, драйвера, как вы сказали, Apple не раздаёт. Я не зря сказал «если производитель будет предоставлять возможность» — она не предоставляется. Я даже не уверен, что, если вы будете распространять описание «определённого протокола» и «соответствующие драйверы», то не получите иск от Apple.
Во‐вторых, вы можете задействовать всё место на жёстком диске, не превращая компьютер в бесполезный ящик.
В‐третьих, использование жёсткого диска «как есть» — не такая уж редкость. Любой RAID будет работать с нижележащим железом без каких‐либо ФС (они будут уровнем выше, но это уже не проблемы жёсткого диска), кроме того иногда жёсткий диск задействуется без ФС для вещей вроде баз данных.
Вы вполне можете получить 0,6666666666666666 после деления в IPython, если возьмёте третью версию Python, либо напишете во второй from __future__ import division. Но вот получить рациональную дробь так не получится, нужно что‐то более сложное. Возможно, можно создать (или даже уже есть) дополнение для IPython, которое это делает. Впрочем, взять уже готовое из Sage проще, чем возиться с доделкой IPython.
А ещё есть минимальный размер файла… Тут такое дело: если вам нужно, вы можете занять терабайт, сделав tar c /some/path|gzip > /dev/sdn. Занять целиком, без расходов на журнал ФС и прочие служебные вещи, без интересных особенностей вида «файл не может быть меньше N КиБ» и т.п.
Но вы никак не можете повлиять на наличие служебных секторов. Вот если производитель будет предоставлять возможность (скажем, обновлением прошивки или с использованием специального протокола и соответствующих драйверов) занимать эти служебные секции, то это будет честно. Неприятно, неудобно, но в моём понимании честно.
Спокойно. В рекламе всегда пишут «ТБ». В реальности тоже будут «ТБ». То, что некоторые ОС пишут «ТБ», а имеют ввиду «ТиБ» — это их личные проблемы. Если и подавать иск из‐за того, что на 1 ТБ диске умещается 0,9 «ТБ», то его должны подавать производители дисков к авторам ОС, потому что приставка «Т» имеет чётко определённое значение, и это не 2⁴⁰.
Вот если в рекламе напишут «ТиБ», а будут иметь ввиду «ТБ», тогда да. Только вы ещё найдите дурака, который так себя подставит: по поводу «ТиБ» разночтений просто не бывает, да и «Ти» считается неизвестной простому обывателю приставкой.
В стандарте C99 есть offsetof (из заголовочного файла stddef.h). Лучше всего использовать именно его, а не __builtin_offsetof или ещё что‐то, и только при использовании компиляторов не поддерживающих C99 использовать #define.
Кстати, из имеющихся у меня компиляторов gcc и clang используют __builtin_offsetof, pcc и tcc используют ((size_t)&((t*)0)->m) (только используют всё же более приличные имена параметров), ekopath использует и то, и то (я недостаточно знаком с этим компилятором, чтобы сказать, когда реально используется: __builtin_offsetof из /opt/ekopath/lib/5.0.1/include/stddef.h, а когда другой вариант из /opt/ekopath/include/5.0.1/stl/ansi/_cstddef.h, но pathcc -E на простейшую програмку выводит __builtin_offsetof).
Короче подключайте stddef.h и используйте offsetof. Разработчики компиляторов лучше знают, как это надо реализовать. __builtin_offsetof в стандарте нет.
Кстати, никто не хочет попытаться обойтись без подчёркиваний? Или без подчёркиваний и без fork? Я знаю, что это возможно и как это сделать, но процедура ещё более муторная. Второе без генератора я бы писать не стал.
Если никто не напишет вариант до середины следующего дня (или даже несколько позже), то я обновлю статью.
Вообще‐то предполагается, что у вас уже юникодная локаль (любая, не обязательно ru_RU). Да и, как я показал выше, засунуть туда этот параметр запуска можно, можно даже засунуть туда код, который собирает UTF-8 по байтам (именно он там и есть). Просто это уже тривиально по сравнению с основной задачей.
Второе легко, но как‐то не хочется: это ведь увеличение кода без каких‐либо качественных изменений. Лучше попробовать LANG=C: при этом (#) будет работать с байтами, а для UTF-8 придётся либо писать свою функцию, либо увеличивать число «символов».
PATH= не нужно вообще, это присваивание здесь просто для контроля выполнения первого условия (я бы его не писал вообще, если бы не strace: про NULLCMD я помнил, но как‐то теоретически и считал, что конкретно к <<< оно не относится).
let я что‐то нигде не видел, а относительно $() есть объективные соображения: попробуйте вставить `` внутрь ``. Это возможно с экранированием, но очень неудобно.
Думаю, что этот момент можно несколько приблизить, написав популярный(!) benchmark, проверяющий скорость выполнения ES6‐конструкций.
nextесть. Но не у массива, а у его итератора и вам нужно переписать код, чтобы он сначала получал итератор, а потом уже использовалnext, чтобы получить код, эквивалентныйfor of. То, что есть, не является эквивалентным кодом.make installделать не рекомендуется, если только вы ставите не в каталог, который потом будете подключать черезLD_LIBRARY_PATHи который содержит либо только одну конкретную зависимость, либо только зависимости для одного конкретного проекта (соответственно, в обоих случаях его можно снести, зная, что именно при этом поломается и что именно вы сносите) —make uninstallдалеко не всегда есть. Тот же CMake не генерирует его по‐умолчанию.При чём «не предусмотрен» здесь — это вариант с лишением гарантии в первую очередь. Во вторую — «мы даже и не думали, что так можно сделать».
Во‐вторых, вы можете задействовать всё место на жёстком диске, не превращая компьютер в бесполезный ящик.
В‐третьих, использование жёсткого диска «как есть» — не такая уж редкость. Любой RAID будет работать с нижележащим железом без каких‐либо ФС (они будут уровнем выше, но это уже не проблемы жёсткого диска), кроме того иногда жёсткий диск задействуется без ФС для вещей вроде баз данных.
from __future__ import division. Но вот получить рациональную дробь так не получится, нужно что‐то более сложное. Возможно, можно создать (или даже уже есть) дополнение для IPython, которое это делает. Впрочем, взять уже готовое из Sage проще, чем возиться с доделкой IPython.tar c /some/path|gzip > /dev/sdn. Занять целиком, без расходов на журнал ФС и прочие служебные вещи, без интересных особенностей вида «файл не может быть меньше N КиБ» и т.п.Но вы никак не можете повлиять на наличие служебных секторов. Вот если производитель будет предоставлять возможность (скажем, обновлением прошивки или с использованием специального протокола и соответствующих драйверов) занимать эти служебные секции, то это будет честно. Неприятно, неудобно, но в моём понимании честно.
forkи подчёркиваний получилось как‐то неинтересно.Вот если в рекламе напишут «ТиБ», а будут иметь ввиду «ТБ», тогда да. Только вы ещё найдите дурака, который так себя подставит: по поводу «ТиБ» разночтений просто не бывает, да и «Ти» считается неизвестной простому обывателю приставкой.
offsetof(из заголовочного файлаstddef.h). Лучше всего использовать именно его, а не__builtin_offsetofили ещё что‐то, и только при использовании компиляторов не поддерживающих C99 использовать#define.Кстати, из имеющихся у меня компиляторов gcc и clang используют
__builtin_offsetof, pcc и tcc используют((size_t)&((t*)0)->m)(только используют всё же более приличные имена параметров), ekopath использует и то, и то (я недостаточно знаком с этим компилятором, чтобы сказать, когда реально используется:__builtin_offsetofиз /opt/ekopath/lib/5.0.1/include/stddef.h, а когда другой вариант из /opt/ekopath/include/5.0.1/stl/ansi/_cstddef.h, ноpathcc -Eна простейшую програмку выводит __builtin_offsetof).Короче подключайте
stddef.hи используйтеoffsetof. Разработчики компиляторов лучше знают, как это надо реализовать.__builtin_offsetofв стандарте нет.Если никто не напишет вариант до середины следующего дня (или даже несколько позже), то я обновлю статью.
ru_RU). Да и, как я показал выше, засунуть туда этот параметр запуска можно, можно даже засунуть туда код, который собирает UTF-8 по байтам (именно он там и есть). Просто это уже тривиально по сравнению с основной задачей.LANG=C:.(#)будет работать с байтами, а для UTF-8 придётся либо писать свою функцию, либо увеличивать число «символов».PATH=не нужно вообще, это присваивание здесь просто для контроля выполнения первого условия (я бы его не писал вообще, если бы неstrace: проNULLCMDя помнил, но как‐то теоретически и считал, что конкретно к<<<оно не относится).letя что‐то нигде не видел, а относительно$()есть объективные соображения: попробуйте вставить``внутрь``. Это возможно с экранированием, но очень неудобно.? Я в первую очередь об этом подумал.
Кстати говоря,
$(( ))и$[ ]— одно и то же. Но почему‐то все используют двойные скобки.