как у вас частное перестало быть подмножеством общего?
потому что я не согласен с вашим утверждением. Да, собственно, это уже давно общее место, что железо дешевле софта, и соответственно, труда программистов
как раз там линейная зависимость стоимости аренды от потребляемых ресурсов. В зависимости от дистанции и масштабов проекта эта стоимость может дорастать до весьма существенной.
Может, и что? Дешевле и быстрее заплатить за железо, чем за дополнительную разработку
вы просто не поняли обоснование того, как GC даже теоретически не способен экономить ресурсы по сравнению с автоматическим освобождением
смотря что понимать под ресурсами если говорить только о железе, то да Если комплексно о разработке, то сильно экономит ресурсы; человеческие, в первую очередь
По факту совсем не париться о производительности обычно могут позволить себе только фронтендеры (потому что за железо платит пользователь) и ML специалисты
ну-ну наша контора продает, например, десктопный софт, который стоит (в полном сборе) 40000 баксов за 1 (одно) рабочее место. Даже супермощный десктопный комп будет стоить сильно меньше
Если же речь об онлайне, там еще проще, там амазоновское облако, например, которое отлично скейлится за очень небольшие деньги
и кажется вы из этого обсуждения ничего не вынесли
мне кажется, это вы должны были что-то вынести, т.к. совсем себе не представляли, как работает выделение/освобождение памяти в хотя бы дотнете
ну в качестве примера аналоги auto и лямбд появились в java позже с++, хотя казалось бы...
а потом мощности компьютеров стали позволять писать даже на языках с GC
Да, как вариант; я сразу сказал, что труд погромиста сильно дороже железа
Во-первых, с++ сильно производительнее большинства из этой массы современных языков.
по размеру памяти - возможно. Чисто как числодробилка - где как, и совсем не "сильно" производительнее; да и скорость выделения в managed/unmanaged heap мы уже обсуждали
Мой посыл как раз в том, что с годами он стал сильно удобнее и дал больше средств для обеспечения надежности
другие-то тоже на месте не стояли:)
вопщем, с моего имха я б не замыкался в рамках одного языка
я потому и предлагаю смотреть на 10-15 летние тренды. То, что сейчас поднялся - ну ок, но до уровня его массовости в начале 2000х, например, куда как далеко
ну и в вашей ссылке речь о С :)
Я, вопщем, к тому, что не зацикливайтесь вы на одном с++ - это прекрасный язык, чтоб сломать себе голову и выстрелить в ногу, или устроить бурное обсуждение на хабре, курощая старпера который его уже почти забыл Но имхо, язык программирования должен быть средством, упрощающим выражение бизнес логики, а не препятствием которое надо бороть. И масса современных языков делает это лучше
в большинстве упомянутых мною сфер плюсы по-прежнему лидируют и даже понемногу проникают в смежные.
Ну вы посмотрите на тренд за последние лет 10-15
Использование плюсов неуклонно снижается. Да, в ембеддед они рулят и педалят, но это ж узкая область. Я, как дев, туда бы ни за что не пошел - есличо, работу будешь полгода-год искать (ну, у нас)
Вы теоретизируете о чем-то что где-то услышали
Я всего лишь читаю данную дискуссию
Вы, должно быть, хотели блеснуть остроумием, но я вас расстрою - движок Unity написан на C++, шарп там используется только для вытаскивания апишек движка наружу.
только?:) Т.е., то, что основной интерфейс для работы с юнити это с#, это только?
То что кроме плюсов есть языки более дружелюбные к программисту и позволяющие меньше напрягать мозг?
Меньше напрягать мозг на особенности языка. И эти высвободившиеся мощности можно вполне пустить на бизнес-логику. Это, на мой взгляд, эффективнее - все таки программы на работе мы пишем не для себя, a для пользователей, а им пофиг на язык
То что плюсы с годами и новыми стандартами не становятся лучше и приятнее? Я с ними работаю каждый день и вижу своими глазами обратное. Очень даже становятся.
из того, что я вижу в обсуждении - они становятся все сложнее и с б0льшим UB
То что все остальные должны срочно перестать писать на плюсах?
Так оно само так случится, очень уж высокий порог входа и дорогая поддержка
на жаве/котлине не писал, а вот на питоне довелось, и там надо держать в голове больше, чем в плюсах. Как минимум - типы переменных/аргументов.
Зачем?
а если я бекенд разрабатываю, то кто есть пользователь?
как только у вас появляется хотя бы пару тысяч пользователей, все становится интересно. Потому что то, что они могут учудить, ни одному QA в голову не придет Так что ошибки/баги есть всегда; рассуждения о том, что надо писать без них - идеалистические
Допустим, в обоих случаях у нас есть внятная стратегия обработки ошибок
И возникает ситуация, описанная выше по треду
В одном случае программа упадет с ошибкой (в силу особенностей языка), во втором нет (опять же, в силу особенностей языка) - продолжит работать, но уже некорректно.
Т.е., есть во втором случае есть у вас обработка ошибок, нет ее - совершенно никак вам не поможет
Использование unique_ptr защищает об большинства ошибок по невнимательности, но не защитит, если вы упорно намеренно и осознанно пытаетесь выстрелить себе в голову.
или использую его неправильно, от чего язык не защищает никак
Я, собственно, об этом в основном. Т.е., язык практически не изменился, просто оброс некими обертками, кои можно использовать правильно, можно неправильно, а можно и вообще не использовать. Это мне напоминает одну контору в конце 90х, в которой было запрещено использовать арифметические операции с указателями - чтоб, зчачить, не попортить чего
а если не торговый бот, а условная АЭС, то варианты 2 и 3 абсолютно иррелевантны - после катастрофы задача "не допустить сбой" провалена.
почему? Если у меня нормальная стратегия обработки ексепшенов, я при вылете оного спокойненько аварийно заглушу станцию
А если ошибка есть, но никак себя не проявила - станция подвзорвется, даже при наличии стратегии обработки ошибок - потому что обрабатывать и реагировать не на что
Суть моих филиппик очень простая - сам по себе язык и окружение не гарантируют ни от чего; как и 20 лет назад, надо самому за всем внимательно следить.
А само наличие new совершенно очевидно указывает на проблемное место, и ни один плюсовик, знакомый с хорошими практиками, такую ошибку никогда не допустит, и через кодревью не пропустит.
ну т.е. в языке есть задокументированная в стандарте конструкция, пользоваться которой нельзя:) Понятно:)
Скорее всего вы имели в виду
да я уже посмотрел внутрь make_unique, вижу, что он указатель на переданное value создает А как быть с созданием картинок, например, в цикле? Создал-обработал-автоудалил? Мне штож, в стеке их создавать?
В C++ есть множество способов выстрелить себе в ногу, но не надо приплетать к ним случаи, возможные только в искуственных примерах.
как-то, говорю ж, с 98 года не сильно все изменилось
потому что я не согласен с вашим утверждением. Да, собственно, это уже давно общее место, что железо дешевле софта, и соответственно, труда программистов
Может, и что? Дешевле и быстрее заплатить за железо, чем за дополнительную разработку
смотря что понимать под ресурсами
если говорить только о железе, то да
Если комплексно о разработке, то сильно экономит ресурсы; человеческие, в первую очередь
наоборот
В общем случае железо дешевле
ну-ну
наша контора продает, например, десктопный софт, который стоит (в полном сборе) 40000 баксов за 1 (одно) рабочее место. Даже супермощный десктопный комп будет стоить сильно меньше
Если же речь об онлайне, там еще проще, там амазоновское облако, например, которое отлично скейлится за очень небольшие деньги
мне кажется, это вы должны были что-то вынести, т.к. совсем себе не представляли, как работает выделение/освобождение памяти в хотя бы дотнете
а в дотнете они появились 14 лет назад
смотрите, потом поздно будет
Да, как вариант; я сразу сказал, что труд погромиста сильно дороже железа
по размеру памяти - возможно. Чисто как числодробилка - где как, и совсем не "сильно" производительнее; да и скорость выделения в managed/unmanaged heap мы уже обсуждали
другие-то тоже на месте не стояли:)
вопщем, с моего имха я б не замыкался в рамках одного языка
я потому и предлагаю смотреть на 10-15 летние тренды. То, что сейчас поднялся - ну ок, но до уровня его массовости в начале 2000х, например, куда как далеко
ну и в вашей ссылке речь о С :)
Я, вопщем, к тому, что не зацикливайтесь вы на одном с++ - это прекрасный язык, чтоб сломать себе голову и выстрелить в ногу, или устроить бурное обсуждение на хабре, курощая старпера который его уже почти забыл
Но имхо, язык программирования должен быть средством, упрощающим выражение бизнес логики, а не препятствием которое надо бороть.
И масса современных языков делает это лучше
Ок, ок, ошибся
Core у него на плюсах, все остальное - на сишарпе
скрипты пишутся на lua:)
А игра, т.е. взаимодействие логики отображения и взаимодействия - на с#; движок просто рисует меши, грубо говоря
Ну вы посмотрите на тренд за последние лет 10-15
Использование плюсов неуклонно снижается. Да, в ембеддед они рулят и педалят, но это ж узкая область. Я, как дев, туда бы ни за что не пошел - есличо, работу будешь полгода-год искать (ну, у нас)
Я всего лишь читаю данную дискуссию
только?:) Т.е., то, что основной интерфейс для работы с юнити это с#, это только?
и на плюсах, и на с#
но вся разработка с ним - на c#
Если с++ так чудесен, почему бы не сделать его с++ only, как тот же unreal?
Меньше напрягать мозг на особенности языка. И эти высвободившиеся мощности можно вполне пустить на бизнес-логику. Это, на мой взгляд, эффективнее - все таки программы на работе мы пишем не для себя, a для пользователей, а им пофиг на язык
из того, что я вижу в обсуждении - они становятся все сложнее и с б0льшим UB
Так оно само так случится, очень уж высокий порог входа и дорогая поддержка
Например, Unity:))
Зачем?
как только у вас появляется хотя бы пару тысяч пользователей, все становится интересно. Потому что то, что они могут учудить, ни одному QA в голову не придет
Так что ошибки/баги есть всегда; рассуждения о том, что надо писать без них - идеалистические
так я последний раз пару лет назад писал, как раз с использованием разного - unique_ptr и прочего
Мне не понравилось, слишком много надо держать в голове в сравнении с другими языками, типа с#, жава, котлин, питон.
А у вас, судя по всему, подобного опыта нет. Как там было, "узкий специалист подобен флюсу - полнота его одностороння"(ц)
ыы
вы, наверное, не очень давно работаете, извините
непредвиденные отказы есть всегда, как только программа попадает в б-м массовые руки пользователей
так как вы можете судить об ошибках, если ни на чем, кроме плюсов не пишете?
Ну давайте сначала
Допустим, в обоих случаях у нас есть внятная стратегия обработки ошибок
И возникает ситуация, описанная выше по треду
В одном случае программа упадет с ошибкой (в силу особенностей языка), во втором нет (опять же, в силу особенностей языка) - продолжит работать, но уже некорректно.
Т.е., есть во втором случае есть у вас обработка ошибок, нет ее - совершенно никак вам не поможет
если судить по исходной статье и обсуждению, такого знающего просто на работу не возьмут:))
вопрос, что мне передавать в пареметр make_unique? Картинку (например, в полгига), созданную на стеке?
эт не язык изменился, это стандартная библиотека изменилась
вопрос-то в том, что во втором случае пофигу, есть она у меня или нет
я после 8 лет на плюсах начал писать еще на c# 1.1
Радовался как дитя
А когда 2й вышел, так и вообще стало казаться, что больше уже ничего не надо
А когда вышел 3й, стало ну совершено понятно, что с++ это забытое прошлое:)
или использую его неправильно, от чего язык не защищает никак
Я, собственно, об этом в основном. Т.е., язык практически не изменился, просто оброс некими обертками, кои можно использовать правильно, можно неправильно, а можно и вообще не использовать.
Это мне напоминает одну контору в конце 90х, в которой было запрещено использовать арифметические операции с указателями - чтоб, зчачить, не попортить чего
я просто не понял, что вы имели в виду
почему? Если у меня нормальная стратегия обработки ексепшенов, я при вылете оного спокойненько аварийно заглушу станцию
А если ошибка есть, но никак себя не проявила - станция подвзорвется, даже при наличии стратегии обработки ошибок - потому что обрабатывать и реагировать не на что
угу, вижу
Суть моих филиппик очень простая - сам по себе язык и окружение не гарантируют ни от чего; как и 20 лет назад, надо самому за всем внимательно следить.
ну т.е. в языке есть задокументированная в стандарте конструкция, пользоваться которой нельзя:) Понятно:)
да я уже посмотрел внутрь make_unique, вижу, что он указатель на переданное value создает
А как быть с созданием картинок, например, в цикле? Создал-обработал-автоудалил? Мне штож, в стеке их создавать?
как-то, говорю ж, с 98 года не сильно все изменилось