Сорри, случайно в минус ткнул. Коммент выше релевантен: это не тот goto, о котором писал Дейкстра. Ранний выход из функции не нарушает структуры. Проблема с "goto в конец" состоит в том, что никто не запретит сделать вам "не в конец", а вот с return такое не пройдёт.
Да, согласен. Но я думаю что в мире felix-gcc разницы нет: если я запустил свой код, и он выдал на выходе, скажем, нуль, то теперь нуль должен быть всегда, при любых обновлениях компилятора, и неважно, UB там или UC.
Так проблема в том, что непонятно, с чем совмещать. Юзер пишет, и говорит, что в ревизии x.5 работало так, а в x.6 работает эдак. Мы чешем репу и выясняем, что действительно так, хотя мы даже об этом не подозревали. Окей, поправили. А потом находится другой юзер, который сообщает, что в ревизии x.4 было вообще иначе, и что теперь делать?
С моей колокольни тут нет никакого "де-юре" и "де-факто", потому что... гм, ну вот представьте себе ситуацию. Вы пишете инструмент и даёте какие-то гарантии, и при этом вы решительно и никак не хотите ничего обещать сверх того, потому что нынешняя реализация -- она просто вот такой получилась. Вы же не можете всё предусмотреть и на каждом углу тыкать assert(), если вход некорректен. А так получается, что у меня нет никакого способа защитить себя от юзеров, которые всегда сочту, что вот если оно случайно сейчас работает так, то теперь оно должно быть так отныне и вовеки веков.
Мне кажется, в некотором смысле это игра в терминологию, потому что выше уже в комментариях приводили ссылку на статью "C is not a low-level language" с подзаголовком "Your computer is not a fast PDP-11". Нюанс в том, что ассемблер вашего компьютера совершенно не совпадает к логикой конструкций языка C, в котором, например, существуют отдельные операции A++ и ++A, имеющие смысл именно в контексте того ассемблера. Даже какое-нибудь тривиальное действие вида int a = 5; in b = 15; можно (и нужно?) выполнять тем способом, который можно считать родным для компьютера сейчас, а не в семидесятых годах. И даже в семидесятых компилятор понимал, что если в формуле с делением выгоднее сперва посчитать знаменатель, это и надо сделать. (Что-то помню подобное, но неточно). А отсюда уже один шаг до dead code elimination и прочих вещей, которые мы так любим. Я бы сказал, в текущей статье ещё очень малоагрессивные виды оптимизаций обсуждают.
Теоретически этот аргумент понятен, но решительно неясно, что это означает на практике. Есть алгоритм, который работает известным образом на указанном наборе входных данных. За пределами этого набора он по сути не тестировался и работает бог весь как -- в зависимости от оборудования и фазы Луны.
Felix-gcc прикопался к конкретному виду UB, но на практике ведь UB везде, начиная с хрестоматийных f(++x, ++x), и я не удивлюсь, если даже сами авторы компилятора не знают, как именно выполняется f(++x, ++x) на текущей версии, ибо зачем им это знать? То есть в мире felix-gcc мы должны сначала прогнать миллион тестов на миллионе видов UB, потом закрепить это всё в тысячестраничном документе и следить, чтобы не дай бог новая версия компилятора ничего не сломала.
Кобол -- это немного другое. Кобол был изначально создан как нишевый язык для бизнес-приложений, и вам надо было днём с фонарём искать людей, которым он нравился даже тогда. Соответственно, в наши дни предприняты большие усилия по продвижению .NET/Java в качестве "дефолтного" языка для таких случаев.
То есть имелась ясно очерченная проблема (предметная область без приличного языка) и были сделаны хорошо подготовленные усилия для её преодоления.
Сейчас мы наблюдаем совершенно иной процесс: "маленький и приятный" язык, который изначально создавался в пику чему-то монструозному тоже превращается в монструозность, см. Python. А если не превращается, то остаётся нишевым. Можно посмотреть, как растёт с годами объём документации.
При этом распухание языка -- это ни разу не про распухание кода. Это про (а) реализацию модных фишек, потому что вот в языке X есть лямбды и дженерики, я в своём тоже такое хочу и (б) как раз про эффективность кода как по объёму, так и по скорости.
Заметьте, мы тут обсуждаем оптимизации gcc, которые все как раз направлены на рост производительности итогового приложения. Расширения стандарта C++ (move semantics, в частности) тоже про более эффективный код. Так что мы видим попытки сделать софт не толще и медленее, а ровно наоборот. Нередко скорость достигается ценой разбухания, но это отдельный вопрос.
Ну если честно, все эти рассуждения выглядят как попытка всерьёз изложить тезисы известного баяна "Настоящие программисты не используют Паскаль". Ничего нового. Как говорил Страуструп, языки делятся на те, которые не любят, и те, на которых не пишут.
А что такое "вручную"? Забудем о шаблонах. В C есть простые обычные макросы. Вы в макрос запихнули несколько инструкций. Потом этот макрос оказался внутри другого макроса, а другой -- внутри третьего. И в итоге когда это всё развернётся, у вас окажется, например, фрагмент вида
a = 5;
a = 15;
a = 7;
И теперь по вашей логике нельзя выбросить первые две строки? Ведь программист написал, значит, знал, что делает.
Так ведут себя все современные компиляторы C++ точно, и подозреваю, что C тоже. Сильно сомневаюсь, что комментатор выше прав, но его теория выглядит рационально.
Статья интересная, спору нет, но с тоном и отдельными колкостями категорически не согласен. Вы не просто описываете объективно существующую проблему и приводите примеры и мнения (что нормально), вы намеренно давите на эмоции и пользуетесь чернушными риторическими приёмами. "Видимо, Торвальдс плохо изучил Си", "Кармак плохо изучил Си" -- это что вообще такое? Кармаку не было интересно запускать свой код на пятнадцати платформах и десяти компиляторах -- он убедился, что его хак работает на конкретной интересующей его комбинации, и всё. Вероятно, он не хуже нас знает, что такой метод стоит на шатком фундаменте.
Аналогично, человек, кладущий в память два int-значения, и вытаскивающий обратно float, зачем-то это делает. Вероятно, у него есть на то хорошая причина, но нельзя же не понимать, что ты суёшься ну в очень уж тёмный угол, в котором законы зыбки. В этом отношении юзер felix-gcc из диалога ни разу не прав: у него есть легальный способ получить нужное ему поведение, но он из принципа делать этого не хочет. Он хочет, чтобы его Ариан упал, а виноваты были разработчики компилятора.
Язык C страдает от массы болезней, порождённых особенностями его развития. Некоторые вещи нельзя получить легальными способами, и на то должны быть официальные compiler-specific пути, за которые отвечают разработчики компиляторов. Некоторые беды, по всей видимости, неискоренимы, но опять-таки, люди, выбирающие Си из массы вариантов, чем-то же руководствуются. Ну а так, да, пусть будет "более лучший язык". Например, Ада специально спроектирована, чтобы подобные ошибки предотвращать. На ней, кстати, код "Ариана" написан.
Ситуация в целом довольно странная, и вот эти прекрасные маглевы её только ухудшают. В принципе, доходы в Японии по всей страны более-менее ровно распределены. Если выкинуть пару outlier'ов, то жить везде можно. В Токио доходы явно выше, но и расходы (на жильё, в первую очередь) взлетают. При этом в городах поменьше и с местом попроще, и нельзя сказать, что по деньгам всё плохо.
Проблема в том, что работа в столице, всякая культура-мультура тоже. В Европе в городе на 200-300 тыс. населения будут концерты, театры, бизнес и прочее. В Японии не будет ничего, только спальная застройка и работа по типу заводов, которые ещё не переехали в Китай. Получается своего рода система с положительной обратной связью -- люди едут где работа, а фирмы открываются там, где есть люди.
И вот это высасывание страны синкансеном мне совершенно не нравится. Но, что поделаешь. Может, и вправду zoom и корона -- светлое будущее всего человечества.
Ну, в моём городке мне до ближайшего банка минут 15 на машине ехать, так что не так уж и много. А так автор же верно пишет, "так сложилось исторически". Были деревни, в каждой деревне свой банк и своя почта. Я затрудняюсь ответить, зачем люди в банк ходят. Сам бываю там раз в год, допустим. Но всегда там люди, всегда очередь, кому-то надо, значит.
По-моему, вполне объективно написано, где там восторженные оценки? Что почта и банк на каждом углу - ну это просто фактология, а про тротуары и архитектуру ничего не сказано.
Я даже не знаю, с какой стороны правильнее подойти к этому вопросу.
Периодически случаются такого сорта "выбросы". Конкретно эти ребята собрали деньги на кикстартере, и могли вообще не заморачиваться на тему результата -- даже если бы продаж было ноль, что с того? Проехали, занимаемся чем-нибудь другим. Ну и аудитория уже была достаточно подогрета, если вы набрали денег у публики, я бы не назвал это "отсутствием помпы". Вот я на свой проект вряд ли даже $10 тыс. подниму.
Основная беда в том, что это, что называется, не sustainable. Они начали проект где-то там в 2014, верно? В 2017 выпустили, и с тех пор тишина. Одна игра за семь лет, конечно, команду из трёх человек прокормит, но это же чистой воды аматёрство, хотя и качественное, а не бизнес.
Это не просто хорошая игра, это игра на широкую аудиторию. Тут же работает воронка: 100 человек услышало, 10 заинтересовалось, один купил / один спиратил. И за счёт общего объёма количество купивших достаточно, чтобы окупить проект.
А если игра с меньшей помпой и бюджетом делалась и на более нишевую аудиторию, то вся эта воронка изначально гораздо уже, и "хвоста" на выходе уже может не хватить. К качеству всё это имеет опосредованное отношение. Ну и как во всём, хорошо, бы, чтобы в жанре было хотя бы 2-3 хороших представителя, а не "ведьмак и пустота".
Ну это же не совсем так - в общественное достояние будут переходить конкретные старые мультфильмы, а Микки как персонаж является маркой вроде логотипа. Такие штуки защищены вечно (вы же не ожидаете разрешения лепить куда угодно эмблему Mercedes, например).
Наше время есть за что ругать, но обращаться к писателям прошлого за "философией будущего" довольно забавно. Ведь за пределами понятного во все времена желания улучшить жизнь человека начиналась обыкновенная экспансионистская концепция времён Колумба и Кортеса. Достичь, открыть, завоевать. Не, я даже не хочу критиковать -- романтика всей этой движухи совершенно понятна и не нуждается в обосновании. Но называть её "ориентиром будущего" или, не знаю, прогрессом в мышлении я не готов. Так что, если хочется, можно поностальгировать о том, как интересно и радостно нам жилось на заре колониальных империй, но "философию будущего" я бы искал где-то в другом месте. Скажем, идея познания и переустройства своего физического тела вполне заслуживает внимания -- не как конечная цель, а как этап, который хорошо бы пройти, прежде чем начинать мыслить в космическом масштабе.
Вот такая у меня идея для произведения. Но, боюсь, она слишком мрачная и нереалистичная, и читатели её не воспримут...
Да не в этом дело, как мне кажется. Этих антиутопий уже как собак нерезаных, и многие авторы тоже опираются на актуальную повестку (на что же ещё опираться). Ну и в итоге начинаешь воспринимать весь этот каталог просто как медицинскую энциклопедию: окей, +1 шиздецома, которая может поджидать человечество. Когда сценариев апокалипсиса так много, относишься к каждому из них как к маловероятному, да и вообще весь этот список меньше трогает.
Слово "философы" в данном контексте я читаю с негативной коннотацией. Если прав, то вынужден к нему присоединиться: проблема не в круге вопросов, а в уровне дискуссии.
В данном случае это чистой воды диванные разговоры, потому что модели бессмысленно обсуждать без формул, например. Ну и пинать предыдущие модели бездоказательно -- тоже как-то несимпатично.
Если ограничиться вот прямо первым абзацем, я не думаю, что классическая экономика не может объяснить "растущее неравенство", ведь ровно это и происходило при развитии капитализма, например. Ничего нового. Ну а уж если сравнить с каменным веком, где, видимо, почти все равны были, то и подавно.
Опыт показывает, что автора интересуют деньги в этом году, а не тонким слоем в течение ближайших 40 лет. Что, впрочем, не отменяет того факта, что денег (по крайней мере, в русскоязычном сегменте этого рынка) здесь нет вообще, и оригинальные книги пишутся исключительно из любви к искусству / ради опыта / эксперимента / резюме и т.п.
Сорри, случайно в минус ткнул. Коммент выше релевантен: это не тот goto, о котором писал Дейкстра. Ранний выход из функции не нарушает структуры. Проблема с "goto в конец" состоит в том, что никто не запретит сделать вам "не в конец", а вот с return такое не пройдёт.
Да, согласен. Но я думаю что в мире felix-gcc разницы нет: если я запустил свой код, и он выдал на выходе, скажем, нуль, то теперь нуль должен быть всегда, при любых обновлениях компилятора, и неважно, UB там или UC.
Так проблема в том, что непонятно, с чем совмещать. Юзер пишет, и говорит, что в ревизии x.5 работало так, а в x.6 работает эдак. Мы чешем репу и выясняем, что действительно так, хотя мы даже об этом не подозревали. Окей, поправили. А потом находится другой юзер, который сообщает, что в ревизии x.4 было вообще иначе, и что теперь делать?
С моей колокольни тут нет никакого "де-юре" и "де-факто", потому что... гм, ну вот представьте себе ситуацию. Вы пишете инструмент и даёте какие-то гарантии, и при этом вы решительно и никак не хотите ничего обещать сверх того, потому что нынешняя реализация -- она просто вот такой получилась. Вы же не можете всё предусмотреть и на каждом углу тыкать
assert(), если вход некорректен. А так получается, что у меня нет никакого способа защитить себя от юзеров, которые всегда сочту, что вот если оно случайно сейчас работает так, то теперь оно должно быть так отныне и вовеки веков.Мне кажется, в некотором смысле это игра в терминологию, потому что выше уже в комментариях приводили ссылку на статью "C is not a low-level language" с подзаголовком "Your computer is not a fast PDP-11". Нюанс в том, что ассемблер вашего компьютера совершенно не совпадает к логикой конструкций языка C, в котором, например, существуют отдельные операции A++ и ++A, имеющие смысл именно в контексте того ассемблера. Даже какое-нибудь тривиальное действие вида int
a = 5; in b = 15;можно (и нужно?) выполнять тем способом, который можно считать родным для компьютера сейчас, а не в семидесятых годах. И даже в семидесятых компилятор понимал, что если в формуле с делением выгоднее сперва посчитать знаменатель, это и надо сделать. (Что-то помню подобное, но неточно). А отсюда уже один шаг до dead code elimination и прочих вещей, которые мы так любим. Я бы сказал, в текущей статье ещё очень малоагрессивные виды оптимизаций обсуждают.Теоретически этот аргумент понятен, но решительно неясно, что это означает на практике. Есть алгоритм, который работает известным образом на указанном наборе входных данных. За пределами этого набора он по сути не тестировался и работает бог весь как -- в зависимости от оборудования и фазы Луны.
Felix-gcc прикопался к конкретному виду UB, но на практике ведь UB везде, начиная с хрестоматийных
f(++x, ++x), и я не удивлюсь, если даже сами авторы компилятора не знают, как именно выполняетсяf(++x, ++x)на текущей версии, ибо зачем им это знать? То есть в мире felix-gcc мы должны сначала прогнать миллион тестов на миллионе видов UB, потом закрепить это всё в тысячестраничном документе и следить, чтобы не дай бог новая версия компилятора ничего не сломала.Кобол -- это немного другое. Кобол был изначально создан как нишевый язык для бизнес-приложений, и вам надо было днём с фонарём искать людей, которым он нравился даже тогда. Соответственно, в наши дни предприняты большие усилия по продвижению .NET/Java в качестве "дефолтного" языка для таких случаев.
То есть имелась ясно очерченная проблема (предметная область без приличного языка) и были сделаны хорошо подготовленные усилия для её преодоления.
Сейчас мы наблюдаем совершенно иной процесс: "маленький и приятный" язык, который изначально создавался в пику чему-то монструозному тоже превращается в монструозность, см. Python. А если не превращается, то остаётся нишевым. Можно посмотреть, как растёт с годами объём документации.
При этом распухание языка -- это ни разу не про распухание кода. Это про (а) реализацию модных фишек, потому что вот в языке X есть лямбды и дженерики, я в своём тоже такое хочу и (б) как раз про эффективность кода как по объёму, так и по скорости.
Заметьте, мы тут обсуждаем оптимизации gcc, которые все как раз направлены на рост производительности итогового приложения. Расширения стандарта C++ (move semantics, в частности) тоже про более эффективный код. Так что мы видим попытки сделать софт не толще и медленее, а ровно наоборот. Нередко скорость достигается ценой разбухания, но это отдельный вопрос.
Ну если честно, все эти рассуждения выглядят как попытка всерьёз изложить тезисы известного баяна "Настоящие программисты не используют Паскаль". Ничего нового. Как говорил Страуструп, языки делятся на те, которые не любят, и те, на которых не пишут.
А что такое "вручную"? Забудем о шаблонах. В C есть простые обычные макросы. Вы в макрос запихнули несколько инструкций. Потом этот макрос оказался внутри другого макроса, а другой -- внутри третьего. И в итоге когда это всё развернётся, у вас окажется, например, фрагмент вида
И теперь по вашей логике нельзя выбросить первые две строки? Ведь программист написал, значит, знал, что делает.
Так ведут себя все современные компиляторы C++ точно, и подозреваю, что C тоже. Сильно сомневаюсь, что комментатор выше прав, но его теория выглядит рационально.
Статья интересная, спору нет, но с тоном и отдельными колкостями категорически не согласен. Вы не просто описываете объективно существующую проблему и приводите примеры и мнения (что нормально), вы намеренно давите на эмоции и пользуетесь чернушными риторическими приёмами. "Видимо, Торвальдс плохо изучил Си", "Кармак плохо изучил Си" -- это что вообще такое? Кармаку не было интересно запускать свой код на пятнадцати платформах и десяти компиляторах -- он убедился, что его хак работает на конкретной интересующей его комбинации, и всё. Вероятно, он не хуже нас знает, что такой метод стоит на шатком фундаменте.
Аналогично, человек, кладущий в память два int-значения, и вытаскивающий обратно float, зачем-то это делает. Вероятно, у него есть на то хорошая причина, но нельзя же не понимать, что ты суёшься ну в очень уж тёмный угол, в котором законы зыбки. В этом отношении юзер felix-gcc из диалога ни разу не прав: у него есть легальный способ получить нужное ему поведение, но он из принципа делать этого не хочет. Он хочет, чтобы его Ариан упал, а виноваты были разработчики компилятора.
Язык C страдает от массы болезней, порождённых особенностями его развития. Некоторые вещи нельзя получить легальными способами, и на то должны быть официальные compiler-specific пути, за которые отвечают разработчики компиляторов. Некоторые беды, по всей видимости, неискоренимы, но опять-таки, люди, выбирающие Си из массы вариантов, чем-то же руководствуются. Ну а так, да, пусть будет "более лучший язык". Например, Ада специально спроектирована, чтобы подобные ошибки предотвращать. На ней, кстати, код "Ариана" написан.
Ситуация в целом довольно странная, и вот эти прекрасные маглевы её только ухудшают. В принципе, доходы в Японии по всей страны более-менее ровно распределены. Если выкинуть пару outlier'ов, то жить везде можно. В Токио доходы явно выше, но и расходы (на жильё, в первую очередь) взлетают. При этом в городах поменьше и с местом попроще, и нельзя сказать, что по деньгам всё плохо.
Проблема в том, что работа в столице, всякая культура-мультура тоже. В Европе в городе на 200-300 тыс. населения будут концерты, театры, бизнес и прочее. В Японии не будет ничего, только спальная застройка и работа по типу заводов, которые ещё не переехали в Китай. Получается своего рода система с положительной обратной связью -- люди едут где работа, а фирмы открываются там, где есть люди.
И вот это высасывание страны синкансеном мне совершенно не нравится. Но, что поделаешь. Может, и вправду zoom и корона -- светлое будущее всего человечества.
Ну, в моём городке мне до ближайшего банка минут 15 на машине ехать, так что не так уж и много. А так автор же верно пишет, "так сложилось исторически". Были деревни, в каждой деревне свой банк и своя почта. Я затрудняюсь ответить, зачем люди в банк ходят. Сам бываю там раз в год, допустим. Но всегда там люди, всегда очередь, кому-то надо, значит.
По-моему, вполне объективно написано, где там восторженные оценки? Что почта и банк на каждом углу - ну это просто фактология, а про тротуары и архитектуру ничего не сказано.
Я даже не знаю, с какой стороны правильнее подойти к этому вопросу.
Периодически случаются такого сорта "выбросы". Конкретно эти ребята собрали деньги на кикстартере, и могли вообще не заморачиваться на тему результата -- даже если бы продаж было ноль, что с того? Проехали, занимаемся чем-нибудь другим. Ну и аудитория уже была достаточно подогрета, если вы набрали денег у публики, я бы не назвал это "отсутствием помпы". Вот я на свой проект вряд ли даже $10 тыс. подниму.
Основная беда в том, что это, что называется, не sustainable. Они начали проект где-то там в 2014, верно? В 2017 выпустили, и с тех пор тишина. Одна игра за семь лет, конечно, команду из трёх человек прокормит, но это же чистой воды аматёрство, хотя и качественное, а не бизнес.
Это не просто хорошая игра, это игра на широкую аудиторию. Тут же работает воронка: 100 человек услышало, 10 заинтересовалось, один купил / один спиратил. И за счёт общего объёма количество купивших достаточно, чтобы окупить проект.
А если игра с меньшей помпой и бюджетом делалась и на более нишевую аудиторию, то вся эта воронка изначально гораздо уже, и "хвоста" на выходе уже может не хватить. К качеству всё это имеет опосредованное отношение. Ну и как во всём, хорошо, бы, чтобы в жанре было хотя бы 2-3 хороших представителя, а не "ведьмак и пустота".
Ну это же не совсем так - в общественное достояние будут переходить конкретные старые мультфильмы, а Микки как персонаж является маркой вроде логотипа. Такие штуки защищены вечно (вы же не ожидаете разрешения лепить куда угодно эмблему Mercedes, например).
Наше время есть за что ругать, но обращаться к писателям прошлого за "философией будущего" довольно забавно. Ведь за пределами понятного во все времена желания улучшить жизнь человека начиналась обыкновенная экспансионистская концепция времён Колумба и Кортеса. Достичь, открыть, завоевать. Не, я даже не хочу критиковать -- романтика всей этой движухи совершенно понятна и не нуждается в обосновании. Но называть её "ориентиром будущего" или, не знаю, прогрессом в мышлении я не готов. Так что, если хочется, можно поностальгировать о том, как интересно и радостно нам жилось на заре колониальных империй, но "философию будущего" я бы искал где-то в другом месте. Скажем, идея познания и переустройства своего физического тела вполне заслуживает внимания -- не как конечная цель, а как этап, который хорошо бы пройти, прежде чем начинать мыслить в космическом масштабе.
Да не в этом дело, как мне кажется. Этих антиутопий уже как собак нерезаных, и многие авторы тоже опираются на актуальную повестку (на что же ещё опираться). Ну и в итоге начинаешь воспринимать весь этот каталог просто как медицинскую энциклопедию: окей, +1 шиздецома, которая может поджидать человечество. Когда сценариев апокалипсиса так много, относишься к каждому из них как к маловероятному, да и вообще весь этот список меньше трогает.
Слово "философы" в данном контексте я читаю с негативной коннотацией. Если прав, то вынужден к нему присоединиться: проблема не в круге вопросов, а в уровне дискуссии.
В данном случае это чистой воды диванные разговоры, потому что модели бессмысленно обсуждать без формул, например. Ну и пинать предыдущие модели бездоказательно -- тоже как-то несимпатично.
Если ограничиться вот прямо первым абзацем, я не думаю, что классическая экономика не может объяснить "растущее неравенство", ведь ровно это и происходило при развитии капитализма, например. Ничего нового. Ну а уж если сравнить с каменным веком, где, видимо, почти все равны были, то и подавно.
Опыт показывает, что автора интересуют деньги в этом году, а не тонким слоем в течение ближайших 40 лет. Что, впрочем, не отменяет того факта, что денег (по крайней мере, в русскоязычном сегменте этого рынка) здесь нет вообще, и оригинальные книги пишутся исключительно из любви к искусству / ради опыта / эксперимента / резюме и т.п.