Сходу, быть может, и нет. Я ж не имел ввиду, что можно просто сесть и начать на любом языке писать. К тому в комментарии и было слово "примерно", ещё и курсивом выделенное.
Неужто Вы будете отрицать, что любой программист, знакомый с C-подобным синтаксисом, не сможет писать на JS? Безусловно, не сходу, а затратив, быть может, может пару часов на изучение, но все же сможет, и довольно быстро. Я лишь хотел сказать, что выбор JS в этом плане не так уж и плох.
"Если следовать описанным в статье путём, то можно вообще всё переопределить в планковских единицах, умноженных на некие вычисленные коэффициенты."
Это ж вы написали? Я, возможно, несколько резко высказался, поэтому прошу прощения — я ни в коем случае не хотел никого обидеть. Когда я работал в институте в своё время, эта проблема порою вставала боком, поэтому я порою веду себя дурно :( Но дело не в этом.
Я переформулирую то, что хотел сказать. Проблема измерений физики до недавнего времени заключалась в том, что общепринятые единицы измерения были основаны на неких эталонах, которые мало того что сами по себе непостоянны, в каких условиях бы они не хранились, так ещё и не имели весьма расплывчатый смысл — можно придумать сотни экспериментов, зафиксировать в них все известные условия и сказать — вот эталон, так и будем мерить. И хоть это и намного проще для понимания, все условия соблюсти сложно, дорого, да и не факт, что при создании эталона было учтено все, что можно учесть. Верно?
Поэтому СИ и отходит от этого, и пытается предложить более гибкую формулировку, которая зависит лишь от фундаментальных постоянных и не привязывает измерения к какому-то конкретному эксперименту. По сути, уточнять значение той же постоянной Планка в этом случае не имеет никакого смысла — ни до 100-го знака, ни до первого, поскольку она фундаментальна, а все остальные единицы измерения — её производные.
Если текущая физическая теория хоть сколько-нибудь верна, проблема того, что постоянная Планка (в СИ) известна лишь до определенного знака, проблема лишь системы измерения, но никак не постоянной Планка — к сожалению, на тот момент, когда различные народы выдумывали системы измерения, об этой постоянной они ничего не знали, иначе бы они все в Планках и мерили.
Что же касается выражения, например, килограмма через эту постоянную: сие выражение не с потолка взято — существует опыт, который позволяет явным образом связать ее с массой, а подобная формулировка, типа "постоянная Планка * магическая константа", является лишь упрощением.
Это я все к тому, что не нужно осуждать людей за решение проблем, о которых вы ни черта не смыслите.
К слову, там же объясняется причина появления defect report, который изменил поведение auto в случае direct-initialization (что мы тут и обсуждаем, собственно).
For background information see N3681, "Auto and braced-init-lists", by Voutilainen, and N3912, "Auto and braced-init-lists, continued", also by Voutilainen.
При этом в N3912, хоть и без лишних подробностей, объясняется почему и как было принято именно такое решение. Основная причина, я так понимаю, в том, чтобы не сломать range-based for в случае, когда в качестве range expression используется braced-init-list.
Да, будет работать, теперь вижу. К сожалению, из всех нововведений я в курсе лишь о тех, что случайно бросились в глаза на том же cppreference, например, потому спасибо за разъяснения.
Ммм, не уверен. Даже открыл драфт N4296, но там требования на implicit move constructor не изменились — он все так же не объявляется, если есть user-declared copy constructor (explicit Foo(const Foo&) в данном случае).
Кстати, возможно, я Вас неправильно понял, но copy initialization не будет работать, если конструктор deleted. И неважно, возможно там copy elision или нет.
По-моему, это один из очень редких случаев, когда здравый смысл временно покинул авторов языка.
Честно, я не припомню ни одного случая, когда здравый смысл бы их покинул.
Попробуйте скомпилировать вот этот абстрактный пример (прошу обратить внимание на конструкторы):
struct Foo {
Foo() {
// unpredictable logic
}
Foo(std::initializer_list<int>) {
// more unpredictable logic
}
explicit Foo(const Foo&) {
// even more unpredictable logic
}
};
void main() {
auto foo(Foo());
std::cout << typeid(foo).name() << std::endl;
}
Подсказка: он не скомпилируется. Почему? Да-да, тот самый most vexing parse, поэтому мы получим совсем не то, что хотели. Решение? Давайте подумаем.
Написать так?
auto foo = Foo()
Нельзя, потому что конструктор копирования explicit.
Написать так?
auto foo(Foo{})
Нельзя, потому что мы хотим вызвать именно конструктор по умолчанию.
Очевидно! Написать так:
auto foo{Foo()}
А теперь представьте, что бы вышло без того патча: Вы бы вообще не смогли скопировать Foo в такую переменную никаким образом — пытались-пытались бы, и внезапно получили бы std::initializer_list. А точнее, Вы получили бы еще одну ошибку компиляции, потому что неявное копирование Foo запрещено.
PS:
Пример, конечно, совершенно бесполезный, но подобная ситуация не является чем-то невероятным.
Я не знаю, почему ни в одном источнике он не используется, но это прекрасно работает — я лично использовал этот метод для генерации атласов с SDF-шрифтами, и результат был отличный.
Возможно, Вам следует обратить внимание на работу господина Арнольда Мейстера, который предложил алгоритм точного (если мне, конечно, память не изменяет) расчета подобных полей за линейное время. Причем там неважно, какое преобразование Вы хотите сделать — Евклидово, или какое поинтересней. Расчет выполняется, как и у Вас, в два прохода, причем выполняется построчно, что в целом предполагает прекрасный потенциал для распараллеливания.
Почитать можно вот тут.
Если электронная почта и социальные сети все время будут в поле моего внимания, я постоянно буду на них отвлекаться.
Внимание, вопрос: разве это проблема монитора? Притом здесь это единственный аргумент против.
Возможно, автор делает исключительно консольные приложения, ну или мобильные без эмулятора, или для embedded систем каких-нибудь — что-нибудь в таком духе, когда достаточно единственного окна IDE. В противном случае я осмелюсь предположить, что раз ему лучше без дополнительных мониторов, то он либо не дебажит свой код, либо вовсе его не запускает.
Скоро и от AIR ничего не останется, по-моему — начиная с версий 23+ там столько багов в рантайме, что с ним работать невозможно, в частности со Stage3D. И чем дальше, тем только хуже становится.
так что-то похожее вроде ж из коробки можно, не?
Сходу, быть может, и нет. Я ж не имел ввиду, что можно просто сесть и начать на любом языке писать. К тому в комментарии и было слово "примерно", ещё и курсивом выделенное.
Неужто Вы будете отрицать, что любой программист, знакомый с C-подобным синтаксисом, не сможет писать на JS? Безусловно, не сходу, а затратив, быть может, может пару часов на изучение, но все же сможет, и довольно быстро. Я лишь хотел сказать, что выбор JS в этом плане не так уж и плох.
Всегда считал, что нормальному программисту примерно без разницы, на каком языке писать
"Если следовать описанным в статье путём, то можно вообще всё переопределить в планковских единицах, умноженных на некие вычисленные коэффициенты."
Это ж вы написали? Я, возможно, несколько резко высказался, поэтому прошу прощения — я ни в коем случае не хотел никого обидеть. Когда я работал в институте в своё время, эта проблема порою вставала боком, поэтому я порою веду себя дурно :( Но дело не в этом.
Я переформулирую то, что хотел сказать. Проблема измерений физики до недавнего времени заключалась в том, что общепринятые единицы измерения были основаны на неких эталонах, которые мало того что сами по себе непостоянны, в каких условиях бы они не хранились, так ещё и не имели весьма расплывчатый смысл — можно придумать сотни экспериментов, зафиксировать в них все известные условия и сказать — вот эталон, так и будем мерить. И хоть это и намного проще для понимания, все условия соблюсти сложно, дорого, да и не факт, что при создании эталона было учтено все, что можно учесть. Верно?
Поэтому СИ и отходит от этого, и пытается предложить более гибкую формулировку, которая зависит лишь от фундаментальных постоянных и не привязывает измерения к какому-то конкретному эксперименту. По сути, уточнять значение той же постоянной Планка в этом случае не имеет никакого смысла — ни до 100-го знака, ни до первого, поскольку она фундаментальна, а все остальные единицы измерения — её производные.
Если текущая физическая теория хоть сколько-нибудь верна, проблема того, что постоянная Планка (в СИ) известна лишь до определенного знака, проблема лишь системы измерения, но никак не постоянной Планка — к сожалению, на тот момент, когда различные народы выдумывали системы измерения, об этой постоянной они ничего не знали, иначе бы они все в Планках и мерили.
Что же касается выражения, например, килограмма через эту постоянную: сие выражение не с потолка взято — существует опыт, который позволяет явным образом связать ее с массой, а подобная формулировка, типа "постоянная Планка * магическая константа", является лишь упрощением.
Это я все к тому, что не нужно осуждать людей за решение проблем, о которых вы ни черта не смыслите.
К слову, там же объясняется причина появления defect report, который изменил поведение auto в случае direct-initialization (что мы тут и обсуждаем, собственно).
В N3922 есть следующая отсылка:
При этом в N3912, хоть и без лишних подробностей, объясняется почему и как было принято именно такое решение. Основная причина, я так понимаю, в том, чтобы не сломать range-based for в случае, когда в качестве range expression используется braced-init-list.
Да, будет работать, теперь вижу. К сожалению, из всех нововведений я в курсе лишь о тех, что случайно бросились в глаза на том же cppreference, например, потому спасибо за разъяснения.
Ммм, не уверен. Даже открыл драфт N4296, но там требования на implicit move constructor не изменились — он все так же не объявляется, если есть user-declared copy constructor (
explicit Foo(const Foo&)в данном случае).Честно, я не припомню ни одного случая, когда здравый смысл бы их покинул.
Попробуйте скомпилировать вот этот абстрактный пример (прошу обратить внимание на конструкторы):
Подсказка: он не скомпилируется. Почему? Да-да, тот самый most vexing parse, поэтому мы получим совсем не то, что хотели. Решение? Давайте подумаем.
Написать так? Нельзя, потому что конструктор копирования explicit.
Написать так? Нельзя, потому что мы хотим вызвать именно конструктор по умолчанию.
Очевидно! Написать так:
А теперь представьте, что бы вышло без того патча: Вы бы вообще не смогли скопировать Foo в такую переменную никаким образом — пытались-пытались бы, и внезапно получили бы std::initializer_list. А точнее, Вы получили бы еще одну ошибку компиляции, потому что неявное копирование Foo запрещено.
PS:
Пример, конечно, совершенно бесполезный, но подобная ситуация не является чем-то невероятным.
Почитать можно вот тут.
Внимание, вопрос: разве это проблема монитора? Притом здесь это единственный аргумент против.
Возможно, автор делает исключительно консольные приложения, ну или мобильные без эмулятора, или для embedded систем каких-нибудь — что-нибудь в таком духе, когда достаточно единственного окна IDE. В противном случае я осмелюсь предположить, что раз ему лучше без дополнительных мониторов, то он либо не дебажит свой код, либо вовсе его не запускает.
Скоро и от AIR ничего не останется, по-моему — начиная с версий 23+ там столько багов в рантайме, что с ним работать невозможно, в частности со Stage3D. И чем дальше, тем только хуже становится.