А что если пустое пространство обладает отрицательной массой? Совсем маленькой, и поэтому ее нельзя измерить локально, но по мере расширения вселенной количество пустого пространства растет, и отрицательная масса увеличивается, из-за этого растет и скорость расширения вселенной. Чему будет противоречить такая картина и как ее можно сфальсифицировать?
Если под "из контекста" вы подразумеваете "если что-то изменяется, то это не const"
Нет, конечно. Я имею ввиду, что, возможно, есть способ понять или договориться, где const стоит, а где его нет. Два кандидата на такой способ:
берем базу программ побольше. Сносим все const (и во всех библиотеках тоже, конечно). Учим нейросетку их восстанавливать. Хорошо бы при этом как-то запретить ей смотреть, изменяется что-то, или нет. Обрезать весь код, например. Если ей это хорошо удается - значит, это и есть способ. А где не восстановились - может, там они и не нужны были?
(дальше буду утрировать до полного бреда, зато будет, надеюсь, понятна идея, а в реальности такое надо делать намного аккуратнее) просто договариваемся, что все глобальные переменные отныне const, все static члены - не const, первый и третий аргументы в функции всегда const, а второй и остальные - не const. В паре ключ - const. Ну, и так далее... Синтаксис языка сохраняется. Семантика - перекурочивается. const больше нет, но все знают, как сделать константу. Сделать такое (фактически, новый язык) почти наверняка можно, но можно ли это сделать удобным? Вряд ли, но - а вдруг?
Я далек от мысли защищать пациентов. И даже не лезу в дискуссию о стандарте со стариковским брюзжанием, что раньше всё было лучше (хотя очень хочется: современный подход к UB меня бесит, но вроде начали, наконец, хоть где-то что-то исправлять, так что призываю этот текст в скобочках не замечать :) ). Но вот в идее пояснить или даже просто выделить как-то ошибку в приведенном ошибочном примере, раз уж он приведен... Что-то в этой идее есть, согласитесь.
Кстати, только вот на днях беседовал с начинающим программистом C++, который вообще не понимает, зачем нужен const. И, знаете, это заразно: сижу теперь, думаю... Вдруг, и вправду, можно сформировать семантику языка так, чтобы было из контекста понятно, какие элементы изменяемые, а какие - нет? Причем без изменения привычного синтаксиса? Хотя, все-таки, больше похоже на тяжелый бред.
Перечисленные претензии, действительно, кажутся странными. Однако пояснить, что дело именно в const, из-за которого и возникает временный объект, мне кажется, все же стоит: статьи читают не только суперпрофи в C++, но и новички, школьники и студенты, и им будет сложно разобраться в проблеме (где именно проблема возникает, какая и почему) без подсказки. А из нынешнего текста статьи даже не вполне очевидно, что проблема там вообще есть.
В том-то и дело, что эту картинку не надо удерживать в голове, это только для объяснения приходится длинно все расписывать. Глядишь на условие, и сразу видишь симметрию вокруг 12. И понимаешь, что всё сокращается. Поэтому сначала считаешь (глядя на условие) 2*4+2*1=10, которые добавятся к 12*12*5 (долго считал, кстати - пятница ,вечер). Потом считаешь 12*12*5, причем сначала пытаешься 144 (квадраты чисел до 16 просто в памяти есть) умножить на 5, понимаешь, что это сложно, и вместо этого считаешь 12*5*6*2=60*6*2=36*10*2=360*2. А дальше не считаешь: уже видно, что 10 - это 5*2, и к каждым 360 добавится по 5 и будет 2*365. А значит, результат - 2. Вот, а про всё остальное разложение вообще не думаешь: увидел, что сократится, и даже не пытаешься думать, чему там эти члены равны.
Полностью согласен. Более того, из статьи следует, что дело как раз в удачном стечении обстоятельств.
Но вот, возникает ощущение, что для непрофессионального программиста обстоятельства будут чаще складываться удачно именно при использовании Python (а не Pascal или, тем более, С++) — у него песочница лучше.
И, когда оглядываюсь вокруг, это ощущение усиливается.
Я собственно, не так уж давно это осознал. Потому и статья зацепила.
Так валидный код 20-летней давности без библиотек скомпилируется и сейчас
Лет 10 назад компилировался. Потом не проверял.
Мне-то проще, чем другим, без сторонних библиотек код писать — у меня все свои :) Когда-то и TCP/IP стек делал, и беспроводные протоколы, и Fat32 на карточках, и ОС свою, и в ядре Линукса много ковырялся… И еще кучу всего.
Не надо из плюсов делать JS или Python, для этого уже есть JS или Python. Лучше всё-таки специализированными инструментами пользоваться, и для научных вычислений таковые есть получше, чем Python.
С одной стороны, это так. С другой — чем больше людей поддерживают какую-то технологию, и (это, наверное, даже важнее) чем больше приходит новых людей, тем лучше и быстрее она развивается. Специализированные инструменты знают (по сравнению с Python) немногие. Поэтому они медленнее развиваются. И не становятся достаточно универсальными для научных задач (а они часто достаточно разнородны — сегодня надо систему дифуров решать, а завтра — картинку фильтрами обрабатывать). И поэтому многие мои знакомые из науки уже тоже перешли на Python.
С плюсами — та же проблема. Из-за их сложности многие учат JS или Python. И плюсы вообще остаются сбоку. Из-за чего хиреют и умирают. До конца, конечно, еще далеко. Но процесс, кажется, уже пошел — новых программистов на плюсах, по моим ощущениям, все меньше. Вот и я уже дочек учу писать на JS и Python…
Мне кажется, какая-то библиотека, позволяющая писать код в стиле интерпретируемых языков без типизации, достаточно мощная (чтобы код мог быть универсальным), обеспечивающая песочницу для кода, и в то же время позволяющая при необходимости (или при желании) добавлять в программу элементы «настоящего» С++ (прямо в текст 10-строчной программы в стиле JS, без большого порога, опять же) позволила бы увеличить популярность плюсов и обеспечить их развитие.
Хотя, по моим ощущениям, поезд уже ушел. И таймер тикает.
В общем, в данном контексте получились ключевыми слова «сейчас» и «или очень сложно» — все же ядро Linux не самая новая разработка, да и компилятор я писал лет 20 назад.
Я совсем не призываю обходиться без сторонних библиотек (хотя это и остается моим любимым занятием — но мир меняется, да и таких мамонтов, как я, мало осталось). Но нужны удобные языки, удобные среды исполнения, удобные библиотеки — чтобы снижался порог вхождения, чтобы все удобно читалось и легко писалось.
Думаю, что выскажу крамольную мысль — но возможно, идеальная стандартная библиотека для С++ должна делать из него что-то, подобное JS. Ну, или Python. Возможности языка это вполне позволяют.
Вот тогда и новые программисты будут в сообщество приходить, и ученым станет удобно языком пользоваться… А потом уже кто-то из них заглянет внутрь и постепенно начнет использовать остальные возможности языка.
Мне показалось, что автор как раз весьма подробно рассказал и о том, как выглядела проблема (программа забирала себе все ресурсы, до которых могла дотянуться, выделяла себе памяти раз так в 10 больше физической RAM в системе, и из-за этого все начинало тормозить так, что оставалось только вырубить компьютер, если он еще раньше не падал сам оттого, что не мог вовремя обработать какую-нибудь срочную задачу — не знаю, получится ли устроить такое на свежих ОС, а раньше получалось легко и на ура), и о том, в чем она на самом деле состояла (в некоторой области значений программе не хватало ни float, ни double, ни какой другой арифметики с заранее заданной шириной — а язык — без сторонних библиотек, из коробки — не умеет работать с числами с динамически расширяемой разрядностью, из-за этого программа проскакивала область экстремума и уходила в область, где метод расходился — а среда выполнения при этом не обеспечивала — из коробки и общеизвестного, опять же — автоостанова по превышению предела использования памяти). В общем, наверное, в С++ все решалось бы наличием общеизвестной или хотя бы достаточно популярной (так, чтобы ее не надо было искать, а достаточно было вспомнить главу из учебника, например) библиотеки, работающей с такими числами. И общепринятой практикой ограничивать ресурсы, запуская программу. Но в итоге оказалось проще выбрать интерпретатор, который делает это за пользователя, а не искать способы реализации первого на С++ и настройки второго в Windows XP.
Выглядит разумным подходом для пользователя, которому нужно получить однократный результат, а завтра заняться чем-то совсем другим.
Конечно, если подобные вычисления надо проводить постоянно, то выигрыш в скорости в конце концов окупит время на поиск библиотеки и изучение администрирования Windows. Но при разнородных задачах проще выбирать вариант, где большинство граблей уже убрано. Или и не появлялось никогда.
Я, кстати, в последнее время тоже предпочитаю в начале работы с какой-нибудь новой микросхемой подергать ее с помощью Embedded JS или MicroPython. А уже потом писать нормальную программу на С или С++. Так выходит быстрее — система не падает, интерпретатор выдает вменяемые сообщения об ошибках, и в любой момент можно что-то вызвать вручную. А уже потом, когда понятно, как оно работает и чего от него ждать, можно писать полноценную программу.
Например, на С. И на С++. Периодически этим занимаюсь на работе, когда микроконтроллеры программирую. Да, в общем, много где можно. Когда-то в прошлом веке принимал участие в разработке компилятора С++ — так его тоже, в общем, почти без библиотек делали (ну, то есть, вызовы read и write, конечно, брали готовые — хотя, в принципе, ничто не мешало сделать прямой системный вызов и избавиться от библиотек вообще). Что ядро Линукса, что загрузчики всякие тоже не особо стандартые библиотеки используют. А программы, в общем, вполне нормальные.
Это только мне кажется, что программисты на С++ смешивают знание синтаксиса языка и знание библиотек? Мне всегда казалось, что это довольно далекие понятия. И именно тот факт, что на С++ сейчас нельзя (ну, или очень сложно) писать нормальные программы без использования хотя бы стандартной библиотеки, а в ней сплошь и рядом совершенно неудобочитаемые названия, приводит к высокому порогу вхождения в программирование на С++. Автор же явно указал, что тот, кто писал программу, знал синтаксис языка, а не библиотеки.
Вообще, я думаю, что развитие С++ пошло куда-то не туда: на заре язык был мощным и удобным в использовании, программы получались короткими и читаемыми. А потом все (в первую очередь те, кто делает библиотеки) забыли об удобстве пользователей. И вместо простого цикла (int i — что может быть короче?) или выделения памяти (s* sp=new s, опять же, коротко и ясно) появились монструозные (хотя и безопасные в использовании) конструкции. Возможно, их стоило бы сразу же спрятать (причем очень хорошо спрятать — чтобы они не вылезали ни в сообщениях об ошибках компилятора, ни в консольных отладчиках) — и это бы само по себе облегчило новичкам изучение языка. А так — имеем то, что имеем.
А что если пустое пространство обладает отрицательной массой? Совсем маленькой, и поэтому ее нельзя измерить локально, но по мере расширения вселенной количество пустого пространства растет, и отрицательная масса увеличивается, из-за этого растет и скорость расширения вселенной. Чему будет противоречить такая картина и как ее можно сфальсифицировать?
Нет, конечно. Я имею ввиду, что, возможно, есть способ понять или договориться, где const стоит, а где его нет. Два кандидата на такой способ:
берем базу программ побольше. Сносим все const (и во всех библиотеках тоже, конечно). Учим нейросетку их восстанавливать. Хорошо бы при этом как-то запретить ей смотреть, изменяется что-то, или нет. Обрезать весь код, например. Если ей это хорошо удается - значит, это и есть способ. А где не восстановились - может, там они и не нужны были?
(дальше буду утрировать до полного бреда, зато будет, надеюсь, понятна идея, а в реальности такое надо делать намного аккуратнее) просто договариваемся, что все глобальные переменные отныне const, все static члены - не const, первый и третий аргументы в функции всегда const, а второй и остальные - не const. В паре ключ - const. Ну, и так далее... Синтаксис языка сохраняется. Семантика - перекурочивается. const больше нет, но все знают, как сделать константу. Сделать такое (фактически, новый язык) почти наверняка можно, но можно ли это сделать удобным? Вряд ли, но - а вдруг?
Я далек от мысли защищать пациентов. И даже не лезу в дискуссию о стандарте со стариковским брюзжанием, что раньше всё было лучше (хотя очень хочется: современный подход к UB меня бесит, но вроде начали, наконец, хоть где-то что-то исправлять, так что призываю этот текст в скобочках не замечать :) ). Но вот в идее пояснить или даже просто выделить как-то ошибку в приведенном ошибочном примере, раз уж он приведен... Что-то в этой идее есть, согласитесь.
Кстати, только вот на днях беседовал с начинающим программистом C++, который вообще не понимает, зачем нужен const. И, знаете, это заразно: сижу теперь, думаю... Вдруг, и вправду, можно сформировать семантику языка так, чтобы было из контекста понятно, какие элементы изменяемые, а какие - нет? Причем без изменения привычного синтаксиса? Хотя, все-таки, больше похоже на тяжелый бред.
Перечисленные претензии, действительно, кажутся странными. Однако пояснить, что дело именно в const, из-за которого и возникает временный объект, мне кажется, все же стоит: статьи читают не только суперпрофи в C++, но и новички, школьники и студенты, и им будет сложно разобраться в проблеме (где именно проблема возникает, какая и почему) без подсказки. А из нынешнего текста статьи даже не вполне очевидно, что проблема там вообще есть.
В том-то и дело, что эту картинку не надо удерживать в голове, это только для объяснения приходится длинно все расписывать. Глядишь на условие, и сразу видишь симметрию вокруг 12. И понимаешь, что всё сокращается. Поэтому сначала считаешь (глядя на условие) 2*4+2*1=10, которые добавятся к 12*12*5 (долго считал, кстати - пятница ,вечер). Потом считаешь 12*12*5, причем сначала пытаешься 144 (квадраты чисел до 16 просто в памяти есть) умножить на 5, понимаешь, что это сложно, и вместо этого считаешь 12*5*6*2=60*6*2=36*10*2=360*2. А дальше не считаешь: уже видно, что 10 - это 5*2, и к каждым 360 добавится по 5 и будет 2*365. А значит, результат - 2. Вот, а про всё остальное разложение вообще не думаешь: увидел, что сократится, и даже не пытаешься думать, чему там эти члены равны.
Но вот, возникает ощущение, что для непрофессионального программиста обстоятельства будут чаще складываться удачно именно при использовании Python (а не Pascal или, тем более, С++) — у него песочница лучше.
И, когда оглядываюсь вокруг, это ощущение усиливается.
Я собственно, не так уж давно это осознал. Потому и статья зацепила.
Лет 10 назад компилировался. Потом не проверял.
Мне-то проще, чем другим, без сторонних библиотек код писать — у меня все свои :) Когда-то и TCP/IP стек делал, и беспроводные протоколы, и Fat32 на карточках, и ОС свою, и в ядре Линукса много ковырялся… И еще кучу всего.
С одной стороны, это так. С другой — чем больше людей поддерживают какую-то технологию, и (это, наверное, даже важнее) чем больше приходит новых людей, тем лучше и быстрее она развивается. Специализированные инструменты знают (по сравнению с Python) немногие. Поэтому они медленнее развиваются. И не становятся достаточно универсальными для научных задач (а они часто достаточно разнородны — сегодня надо систему дифуров решать, а завтра — картинку фильтрами обрабатывать). И поэтому многие мои знакомые из науки уже тоже перешли на Python.
С плюсами — та же проблема. Из-за их сложности многие учат JS или Python. И плюсы вообще остаются сбоку. Из-за чего хиреют и умирают. До конца, конечно, еще далеко. Но процесс, кажется, уже пошел — новых программистов на плюсах, по моим ощущениям, все меньше. Вот и я уже дочек учу писать на JS и Python…
Мне кажется, какая-то библиотека, позволяющая писать код в стиле интерпретируемых языков без типизации, достаточно мощная (чтобы код мог быть универсальным), обеспечивающая песочницу для кода, и в то же время позволяющая при необходимости (или при желании) добавлять в программу элементы «настоящего» С++ (прямо в текст 10-строчной программы в стиле JS, без большого порога, опять же) позволила бы увеличить популярность плюсов и обеспечить их развитие.
Хотя, по моим ощущениям, поезд уже ушел. И таймер тикает.
Спасибо.
В общем, в данном контексте получились ключевыми слова «сейчас» и «или очень сложно» — все же ядро Linux не самая новая разработка, да и компилятор я писал лет 20 назад.
Я совсем не призываю обходиться без сторонних библиотек (хотя это и остается моим любимым занятием — но мир меняется, да и таких мамонтов, как я, мало осталось). Но нужны удобные языки, удобные среды исполнения, удобные библиотеки — чтобы снижался порог вхождения, чтобы все удобно читалось и легко писалось.
Думаю, что выскажу крамольную мысль — но возможно, идеальная стандартная библиотека для С++ должна делать из него что-то, подобное JS. Ну, или Python. Возможности языка это вполне позволяют.
Вот тогда и новые программисты будут в сообщество приходить, и ученым станет удобно языком пользоваться… А потом уже кто-то из них заглянет внутрь и постепенно начнет использовать остальные возможности языка.
Выглядит разумным подходом для пользователя, которому нужно получить однократный результат, а завтра заняться чем-то совсем другим.
Конечно, если подобные вычисления надо проводить постоянно, то выигрыш в скорости в конце концов окупит время на поиск библиотеки и изучение администрирования Windows. Но при разнородных задачах проще выбирать вариант, где большинство граблей уже убрано. Или и не появлялось никогда.
Я, кстати, в последнее время тоже предпочитаю в начале работы с какой-нибудь новой микросхемой подергать ее с помощью Embedded JS или MicroPython. А уже потом писать нормальную программу на С или С++. Так выходит быстрее — система не падает, интерпретатор выдает вменяемые сообщения об ошибках, и в любой момент можно что-то вызвать вручную. А уже потом, когда понятно, как оно работает и чего от него ждать, можно писать полноценную программу.
Вообще, я думаю, что развитие С++ пошло куда-то не туда: на заре язык был мощным и удобным в использовании, программы получались короткими и читаемыми. А потом все (в первую очередь те, кто делает библиотеки) забыли об удобстве пользователей. И вместо простого цикла (int i — что может быть короче?) или выделения памяти (s* sp=new s, опять же, коротко и ясно) появились монструозные (хотя и безопасные в использовании) конструкции. Возможно, их стоило бы сразу же спрятать (причем очень хорошо спрятать — чтобы они не вылезали ни в сообщениях об ошибках компилятора, ни в консольных отладчиках) — и это бы само по себе облегчило новичкам изучение языка. А так — имеем то, что имеем.