Бьёрн Страуструп (Bjarne Stroustrup), создатель языка C++, опубликовал возражения против выводов, сделанных в отчёте АНБ, в котором организациям было рекомендовано отойти от использования языков программирования, таких как Си и Си++, перекладывающих управление памятью на разработчика, в пользу языков, таких как C#, Go, Java, Ruby, Rust и Swift, обеспечивающих автоматическое управление памятью или выполняющих проверки безопасной работы с памятью во время компиляции...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58527
Что этот профессор себе позволяет? Решил пойти против корпораций?
а мы где?
> Решил пойти против корпораций?
> большинство рекомендаций Core Guidelines уже реализованы в статическом анализаторе и профиле безопасной работы с памятью из состава Microsoft Visual Studio.А профессор точно воюет в ту сторону?
А кого его мнение теперь вообще интересует? Я имею ввиду кормящихся с ойти?
Ten "safe C" commandments to remember...1. Restrict to simple control flow constructs. Do not use goto statements, setjmp, longjmp, or recursion.
2. Give all loops a fixed upper-bound.
3. Do not use dynamic memory allocation after initialization.
4. Limit functions to no more than 60 lines of text.
5. Use minimally 2 assertions for every function of more than 10 lines.
6. Declare data objects at the smallest possible level of scope.
7. Check the return value of all non-void functions, and check the validity of all function parameters.
8. Limit the use of the preprocessor to file inclusion and simple macros.
9. Limit the use of pointers. Use no more than 1 level of dereferencing per expression.
10. Compile with all warnings enabled, in pedantic mode, and use one or more modern static source code analyzers.
Ага, щас, разбежалися!
> Ага, щас, разбежалися!Гуд, вторым шагом надо найти стену покрепче.
Если бы не детище страуструпа, не было бы такого дерьма как сраст.С++ целиком никто не сможет освоить, настолько он пытается уметь все.но работаетхотябы. Ближайшие лет 50монстру ничего не грозит. А раст.. Еще более переусложненнй, изначально мертворожденный дегенерат.
50 лет, как вы далеко смотрите. Через 50 лет вообще пк не понадобится
Долб. Ам он и сейчас не нужен. Смартфон не замена пк и не будет им никогда. И нейроинтерфейсы никаким боком тут.
>Смартфон не замена пк и не будет им никогдаСмартфон, вообще-то, и есть ПК+телефон+камера. Так, к слову.
Нет конечно. Пк+теелефон+камера существовал до смартфона.
Ещё раз. Смартфон = ПК + средство связи + видеокамера. Именно поэтому смартфон уже заменил многим людям ПК.
Так ПК = систембный блок + средство связи + видеокамера + ...
Точно лох... Ты еще не понял что "системный блок" теперь у тебя в ладони и в кармане брюк помещается? "ПК" - это персональный компьютер, а не какая-то определенная коробка определенной формы с какими-то придуманными тобою определенными размерами (уточняю, потому что судя по всему ты не в курсе). А ты не видел как к смартфонам подключают обычные клавиатуры, мониторы, мышки и используют их "как ПК"? Повторю, что тебе говорили выше -чтобы быть ПК эта "коробка неопределенного размера и формы" должна вмещать в себя вычислительное устройство универсального назначения, память (желательно разных типов), кучку софта, заставляющего это всё работать и решающая необходимые отдельному индивидууму задачи. Даже средство связи и видеокамера не обязательны для того, чтобы ПК назывался ПК. Сколько дискет было мною попилено в дисководах ПК 1980-90х годов на компах, которые не были подключены ни к какой "связи".
Смартфон все таки не ПК. Различается целями и задачами. Смартфон удобен для потребления информации. А ПК для её создания. Попробуйте ка покреативить на смартфоне. Это как сексом в противогазе в ластах заниматься.))) Программы писать на смарте, видео редактировать, 3d создавать.)))
Установи на смартфон Windows, подключи док станцию с монитором и остальным и пользуйся на здоровье как обычным компьютером.Только есть нюанс производители не очень любят когда их трояны выпиливают из устройств и запрещают это делать всеми правдами и не правдами. За исключением некоторых не самых популярных.
> Установи на смартфон Windows, подключи док станцию с монитором и остальным и
> пользуйся на здоровье как обычным компьютером.Да вон есть полтора полу-недо-нечто на атомах. Даже сразу в виндой вроде. Правда, в результате вы получаете паршивый телефон (впрочем, скорее, планшет - с телефонной батарейкой х86 с виндой помирает слишком быстро) и паршивый компьютер, но это уже ваши проблемы.
>Именно поэтому смартфон уже заменил многим людям ПК.И мозг
Ну ты вот на ПК, а та же проблема.
> Смартфон, вообще-то, и есть ПК+телефон+камера. Так, к слову.Минус нормальные средства ввода и отображения. Что сильно нагибает эффективность именно созидательных работ. Смотреть фишкинет и покупать хнюшки на алишке можно и на этом конечно.
Смартфон создан для потребления информации, создавать на нем её затруднительно и неудобно. В отличии от ПК.
На нем столько написано, что быстрее наверно не разгрести. А на раст переписывать.. Ну еще примерно??
Rust появился не из-за Плюсов. А потому что Плюсы перестали справляться со сложностью современного программного обеспечения. Слишком дорого обходятся конечным пользователям ошибки программистов.Также Rust намного проще Плюсов. На его освоение достаточно полугода обычно в отличие от Плюсов.
Раст не проще плюсов… они примерно одинаковы по сложности.Но! Раст разгружает голову разработчика от необходимости вручную отслеживать корректность кода (с тчк зрения самого языка). Т.е. пишешь на расте - думаешь о задаче, пишешь на плюсах - надо думать и о задаче, и о том чтобы не выстрелить себе в ногу забыв об очередной "особенности" языка.
>Раст не проще плюсовКонечно, проще. Примерно на порядок. На освоение Плюсов - 5 лет. На освоение Раста - 6 месяцев.
Странно, что не двадцать один день.
Погодь, просто ещё не успели книжек по Rust для тинейджеров настрочить.
Плюс, если прочитал "для тинейджеров настрочить" прочитал как "для тинейджеров на*\Д*рочить"
>>пишешь на расте - думаешь о задачепишешь на расте - думаешь о тонне закорючек, которые тебе надо поставить, что код скомпилировался. А потом, требования немного меняются и ... начинается либо "полное" переписывание закорючек, либо unsafe. Такое себе "безопасное" программирование.
Э... может ты просто не умеешь писать, раз тебе нужно о таком думать?
Когда ты пишешь на расте, ты думаешь о том, что именно должен делать код, о представлении в памяти, о том кто и чем владеет, о потоках данных и о том, как информация шарится напр. между потоками. А не о каких-то закорючках.
А потом просто используешь простой синтаксис чтобы это отразить в коде.
Неужели сишники не осилили пару закорючек?
Открою секрет. Если думать о том же, разрабатывая на плюсах, то память утекать не будет.
> ты думаешь о том, что именно должен делать код, о представлении в памяти, о том кто и чем владеет, о потоках данных и о том, как информация шарится напр. между потоками.Чё правда? А выше чел уверяет, что надо думать только о задаче, а не о том, что ты перечислил. Вы там уж договоритесь, о чём надо думать в расте, а потом нам несчастным расскажите. :-) И да, то что ты перечислил (т.е. на самом деле о где и какие закорючки применить), мало отличается от "дум" в с++, да и в любом другом зрелом языке.
так думать о представлении абстракций в памяти, в каких структурах будешь хранить данные и о потоках данных внутри программы это и есть думать о задаче, в дополнение к думам о самой предметной области. Ты, похоже, никогда о таком и не думал, потому рассказываю, тебе, несчастному. И да, это мало отличается от любых других зрелых языков, но в некоторых из этих зрелых языках приходится думать и о много другом, чтобы, как тебе сказали "не выстрелить себе в ногу". Думать в дополнение (!) к проблемам задачи. Как тебе и пыталются объяснить, но тебе это не нужно.
Всё правильно говоришь, молодец! Когда опыта нет, знаний нет, но хочется кому-то чего-то доказать, то ты всё правильно пишешь - опускай оппонента, пиши глупость и на том "победишь" в споре. НО! когда через пару тройку лет, вылезешь из кодинга и станешь очень небольшим, но спецом, то ты внезапно узнаешь, что такое "задача" и что никого отношения к "памяти", потокам данным и т.п. бреду она не имеет это всё ВНЕЗАПНО частные (очень частные) детали _реализации_ задачи. И что думы о потоках данным ни чем не отличаются от дум про память и т.п. бреду. Но ты не переживай - подрастёшь узнаешь!
> мало отличается от "дум" в с++... но есть нюанс. Если ты не будешь об этом думать в с++, то ничего страшного не произойдет.
Ну прод упадет, или кто-то рут получит, бывает, дело-то житейское.А в расте злой компилятор начнет возмущаться и отказываться компилить твой код! Возмутительно))
Так что или ты делаешь все правильно сам, или тебя заставят об этом думать.> А выше чел уверяет, что надо думать только о задаче, а не о том, что ты перечислил.
Возможно у нас разное понимание что значит "только о задаче". Так что не вижу противоречий.
>> А выше чел уверяет, что надо думать только о задаче, а не о том, что ты перечислил.
> Возможно у нас разное понимание что значит "только о задаче". Так что
> не вижу противоречий.Вот когда узнаете, что такое "задача" - подходите, а то пока ваши фантазии читать немного смешно.
Скажу вам даже больше: все ЯП _общего назначения_ примерно одинаковы по сложности. Какие-то из них имеют более высокий порог вхождения, какие-то менее, но уже мидл+ особого профита от выбора "легкого в изучении языка" не ощущает от слова "совсем". А любые спекуляции на тему "легких в изучении ЯП" так и остаются не более чем спекуляциями.
вероятно ошибки непрофессионалов с раздутым чсв или дебилов - считающих себя программистами после просмотра роликов на ютубе - вот чьи ошибки дорого обходятся
Там полно роликов вида выучить язык за 4 часа
сам язык учится за полчаса. много времени уходит на изучение либ
> Слишком дорого обходятся конечным пользователям ошибки программистовИздержки конечных пользователей вообще никого не волнуют. Но и раньше не волновали.
Разве что в плане вероятности судебных разборок, но и там попробуй доказать и конкретные цифры обосновать.Это почти как писать на кого-то жалобу, что гадит посреди улицы, прикладывая фотографию где стоит тип в штанах, а рядом посреди дороги здоровенная куча навалена. Вроде бы всё очевидно, а ты попробуй доказать. В итоге, следующая куча у стукача под дверью, а тип обошёлся даже без штрафа ведь на фото не изображено нежелательных действий, нет даже даты. Но это для общего развития
> В итоге, следующая куча у стукача под дверьюочень маловероятно.
> нежелательных действий,
административных правонарушений.
ps: изучал КоАП по протоколам ГИБДД.
> Плюсы перестали справляться со сложностью современного программного обеспеченияЭто не "плюсы перестали справляться", а "мамкины" программисты перестали справляться с управлением памятью в
программах на плюсах. Глобальное "неосиляторство". Кроме того, использование "безопасных" языков сильно ускоряест и упрощает, а значит и удешевляет разработку ПО. А, как известно, "дешево" и "качественно", совсем не синонимичные понятия. Скорее даже наоборот.А Страуструп прав: плюсы всё умеют, в том числе и "безопасность". Но не все ппрограмисты "умеют" в "безопасность" плюсах. А там где "безопасность" там, как правило, всегда "тормоза". Безопасность в ущерб производительности...
какая классная история, жаль что ...Как может "в безопастность" уметь язык где в стандарте UB больше чем блох на бродячей собаке?
> не все ппрограмисты "умеют" в "безопасность"
так покажи мне тех кто умеет! классические дырки и фигня с памятью находятся в куче проектов, причем некоторым лет по 15 и больше
на пеньке новости "CVE в с/с++" можно вообще в отдельный раздел выносить
А кто мешает не писать код, который будет содержать UB? Кроме того, как показывают здешние новости, мамкины программисты найдут что сломать и в Rust.
Ты, блять, 4 байта из файла прочитай и сделай reinterpret_cast<int32_t*> — это уже UB будет.
А на фига это делать ?! Специально по граблять прыгать
И как ты из бинарного файла читать будешь?
> а "мамкины" программисты перестали справляться с управлением памятью в программах на плюсах. Глобальное "неосиляторство".Это же как раз довод в пользу раста и т.п.: представим, что рождается всё больше и больше трёхпалых людей, а количество пятипалых постоянно сокращается. Есть ли в таких условиях смысл шить пятипалые перчатки?
В общем, зачем нужен карбюратор (и умение его регулировать), когда есть впрыск с электронным управлением?
Нет, не довод. Rust тоже не серебряная пуля. Не сломает память, сломает что-нибудь ещё.
правильно, давайте ломать память!
ведь если не будем ломать - то что-то другое сломают програмисты раста
Этот профессор, во-первых, сам работает (работал) в одной из корпораций. Во-вторых, существует исключительно благодаря корпорациям, а точнее их баблу.
> Решил пойти против корпораций?Мало того против корпорации - ПРОТИВ А Н Б ! ! !
Ну ничо, рыцари плаща и кинжала разъяснят его ошибку ]:>
Профессор этот в своё время протолкнул всю эту С++ мерзость и дурацкую систему типов которую стали путать с ООП.
Ну его, этого Страуссупа.
> Что этот профессор себе позволяет? Решил пойти против корпораций?Нет, просто Бьёрн мыслит как вменяемый адекватный инженер, и судит с позиции логичного подхода когда все программисты также разумные люди, понимающие что они делают. Но сейчас в индустрии далеко не так, даже Линус очень аккуратно намекнул, что возможно и стоит, т.к. времена уже не те, он бы может в присущей себе манере высказался покрепче, но даже он начал фильтровать базар, шибко взялись, видать. Бьёр всё правильно пишет, только он проспал наплыв макакокодеров в индустрию, которые дешевле и их легко заменить на другую партию макак.
А все эти модные веяния по защите от выстрелов себе в ноги расчитаны на тех, кто и в голову себе выстрелит не особо напрягаясь. Времена такие, хипстоязычки для макакокодиров с более низким порогов вхождения для войтишников в ойти, которые наперегонки готовы рвать себе глотки и дупы доказывая что:
"Си сотоварищи нибезапасин, там сишные дыры и можно отсрелить себе всякое в памяти, азаза!!!!1111"
На самом деле просто пытаясь замаскировать свою бездарность и неосиляторство как в интеллектуальном плане, так и в плане усидчивости и аккуратности. Сейчас же как, хочется поскорей, войти в ойти, поймать за хвост успешный успех и макакокодить на маках где-нить удалённо с тёплых стран методом х**ак-х**к и в продакшон.
Но говно всё равно Си сотоварищи, да!
> Бьёрн мыслит как вменяемый адекватный инженер, и судит с позиции логичного подхода когда все программисты также разумные люди, понимающие что они делаютЭто позиция полного неадеквата, живущего в мире розовых поней.
Сейчас острая проблема нехватки программистов во всем мире. Даже за очень большие деньги очень сложно найти хорошего специалиста.
Это проблема не языков программирования, а всей глобальной системы образования.
Классическое образование отупляет людей, делает узкими специалистами не способными соединить абстрактные вещи между собой.
Потому что такими людьми легко управлять, легко держать стадо под контролем и давать немного на про питание.Чем дальше тем более очевидно это будет. Возможно через лет 100 будет революция этой системы, но пока будут пытаться менять инструменты, внедрять ИИ, снижать пороги входа.
Но ИТ идёт другим путём, оно требует все более и более качественного образования иначе все равно возникнет дефицит, что разогнаный до уровня ассемблера и кастрированный питон для более лёгкого понимания и супер современный советник из ИИ который делает за программиста 99.9% работы будут очень - очень сложными.
В будущем нас ждёт либо полный мир высокообразованных и умных людей, либо анархия из за огромного количества бесконтрольно живущих программ которые никто не в состоянии менять.
>Сейчас острая проблема нехватки программистов во всем миреТо то новости читаеш -в США корпорации уже выкидывают под полмиллиона программистов.В Европе где то 150.000 сокращают.Рынок был раздут,сейчас такое кол-во нахрен не нужно будет
Ну так кем рынок был раздут? Инженерами или макаками-в-ойти-ноджыэс-пистон?
> Ну так кем рынок был раздут? Инженерами или макаками-в-ойти-ноджыэс-пистон?Я не знаю,предполагаю что эффективными менеджерами.
Надо было просто сказать, что C++ Core Guidelines станут обязательными для реализации в компиляторах C++26.
и все будут сидеть на С++22 ?
так же как сейчас до сих пор попадаются проекты на 99м стандарте
C++22 это что такое?
Это с++23, которые на самом деле должен был выйти в 22м, но комитет как всегда просрачил все сроки и пришлось переносить на год.
Не должен был. Они ещё в при 14-ом декларировали выход стандарта раз в 3 года из того, что будет готово на тот момент.
После С99 ничего хорошего не придумали. Вообще-то, он содержит всё самое необходимое и ничего избыточного. Ни больше ни меньше.
Да здравствуют С++ амиши !
Оберон лучше
Только почему то это лучшее никто не использует. Парадокс)))
Гадость с GC не нужна, или жабы мало?Язык должен быть либо низкоуровневым и близким к системе как Си - и тогда в нем недопустимы GC, исключения и т.д. - либо высокоуровневым как Haskell - и тогда непонятно, зачем вообще делать его императивным, а не функциональным (т.е. понятным для машины и сложным для человека). Фон-неймовская архитектура на виртуальной машине - полный маразм.
Oberon, Go, Java, C# - это морально устаревшие, костыльные недоязыки. А конкретно в Oberon'е еще и нет параметрического полиморфизма (template в C++ или generic в Java/C#), т.е. на нем никак не написать обобщенные коллекции.
> ничего избыточногоА как же VLA?
> А как же VLA?-Wvla -Werror, ну вот так вот, если странные неконтролируемые йопсы софта не нравятся.
> После С99 ничего хорошего не придумали. Вообще-то, он содержит всё самое необходимое
> и ничего избыточного. Ни больше ни меньше.Ну да, действительно, зачем нам static_assert() из C11 :). О багах в программе прикольнее узнавать когда бортовой компьютер сделает волшебный фигакс на полпути к назначению.
Но, конечно, вы можете сколхозить аналог этого 20 разными способами. Только нестандартно и чаще всего без нормального сообщения об ошибке.
С++ 98 же. Хотя, если честно, мне надоело вместо лямбд писать фуказатели.
На самом деле С++ плохой потому, что там нет менеджера дополенений. Уже 2023 год а там до сих пор нельзя скачивать библиотеки и автоматически их компилировать с бинаркмиком.
Главный плюс плюсов это как раз таки то что язык не подвязан к сетевым сервисам, надо что-то просто скачай отдельно и сохрани. А вот в случае rust, go, python и прочих с пакетами, если там приляжет сервачек то тебе как разрабу останется только жалостно ждать пока восстановят работу серверов. А может быть и так что его не восстановят и все хана.
>если там приляжет сервачекИ кто ж тебе мешает сделать свой внутренний сервачок, кроме отсутствия знаний, что так можно?
>И кто ж тебе мешает сделать свой внутренний сервачок, кроме отсутствия знаний, что так можно?Тебе же сказали менеджер пакетов в Си плюс-плюс не нужен.
А новую версию программы в отдельную папочку "Версия 3.4.5".Хорошо что вас к Rust не подпускают, да и вы не в состоянии его осилить. Копашитесь в своём болоте.
Хорошо бы еще норко... Растонечисть к низкоуровневуму программированию не подпускали.
Хорошо что все эти годы с++ не пускали в ядро. И уже не пустят.
А то даже страшно подумать что за монстр был бы рожден...
Согласен. Но скатились, оступились и подорвались на раст.
Но с Rust ядро может в мегамостра перерасти.
Ядро и на одном си может перерасти в мегамостра.
Нужно подождать еще годик-два и пару десятков лямов строк кода.
Это скорее попытка хоть как-то его усмирить или хотя бы сдержать на время.
> Но с Rust ядро может в мегамостра перерасти.Да вообще мегамонстра и из сей можно вырастить. Как будто в сях абстракций нельзя навернуть. Особо ушлые господа делают на сях по сути ООП. А чего, гибкость и низкоуровневый доступ еще и не такое позволяют.
Ну вон например корутины на сях. А чо, так то прикольно. В каком-нибудь lwan.ws даже к месту смотрится. Но если вас вот так наобум подобным кодом огорошить в не очень продуманном проекте, ваши шансы въехать в происходящее...
>А то даже страшно подумать что за монстр был бы рожден...Это все зависит от квалификации программистов и менеджера проекта.
Be-be монстр ? А Syllable (правда там ++ кода очень мало) ? А ещё читал про проект обработки сетей 5g ,так ребята писали что без ++ не один язык не справлялся,нужен реалтейм,так ядро обработчика у них вышло 12 мгб.При этом от stc им пришлось отказаться,т.к оказался медленный для ихних задач.
> ядро обработчика у них вышло 12 мгб.Намекает что они профакапились где-то в сильно другом месте, раз это весит как целый линукскернел, у которого уровень сложности при этом так то сильно более другой.
> Намекает что они профакапились где-то в сильно другом месте, раз это веситОни были вынуждены держать в памяти заранее вычесленные таблицы преобразование Фурье и куча других данных. При этом ещё возможность распределить обработку,распораллеривать ее и следить за энергоэффективностью.Ядру Линукс в плане энергии не доверили т.к с DSP у него в этом плане плохо,он экономит энергию только при незначительной нагрузке.
> Главный плюс плюсов это как раз таки то что язык не подвязан к сетевым сервисам
> надо что-то просто скачай отдельно и сохрани
> А вот в случае rust, go, python и прочих с пакетами...Знаешь, в Rust, Go, Python, Ocaml, Racket, Debian, Ubuntu, RHEL -- тоже можно без пакетов.
Надо что-то -- просто скачай отдельно и сохрани.
> Знаешь, в Rust, Go, Python, Ocaml, Racket, Debian, Ubuntu, RHEL -- тоже
> можно без пакетов.
> Надо что-то -- просто скачай отдельно и сохрани.Однако куча софта на этом подразумевает что надо именно скачать левые полуварезок "от васяна" из мутных репок. И другие варианты не очень то и предусмотрены. Зачастую еще сделав curl | sh в процессе.
>Главный плюс плюсов это как раз таки то что язык не подвязан к сетевым сервисам, надо что-то просто скачай отдельно и сохрани. А вот в случае rust, go, python и прочихНа сколько я знаю, go это один бинарный вайл. Там тоже скачал, закинул куда надо и все.
> надо что-то просто скачай отдельно и сохрани.есть мнение что настоящий программист пишет СВОЙ код (а не скачивает чужой).
Я знаю единственный "язык", где управление внешними пакетами встроено прямо в него -- Deno. В нем можно прямо в исходнках написать путь к гитовскому репозиторию и во время исполнения скрипта Deno сходит на этот сервер скачает git репозиторий и скомпилирует его.Во всех остальных языках пакеты устанавливаются либо отдельной тулзой или отдельным командой для тулчейна языка. И этот процесс является опциональным. Можно руками разруливать все зависимости и хранить их где угодно. Можно ими вообще не пользоваться.
А так, чем плюсы с их Conan отличаются от той же ноды с npm? Только тем, что конан переусложнен и не идет из коробки и неосиляторы по прежнему предпочитают копипастить сторонние либы в свой гит репозиторий и больше никогда в жизни не обновлять?
А потом что то случается с git репозиторием и все сосут лапу.
В Go тоже можно
Насчёт питона не совсем точно. Я иногда люблю выкачивать всё, чего нет в чистом Python и класть в папку с моим кодом. Качаю обычно с офф сайта. А питонил ещё до этих virtualenv и pip.
Вы не поняли сарказм. Человеку-то как раз и не надо, но АНБ рекомендует...
Кто-то уже делает, правда пока содержит только библы Boost: https://github.com/poacpm/poac
vcpkg, conan, xmake и пакетный менеджер дистрибутива
А лучше всё сразу, т.к мало кто публикует свои пакеты везде.cargo в отличии от пакетного менеджера дистрибутива позволяет лочить версии пакетов, не допуская поломку кода при обновлении системы, и позволяет обеспечить воспроизводимость (Т.к в локфайле явно прописано какой хеш имела каждая зависимость, с которой разработчик всё разрабатывал), а не "а у меня на компуктере фсё работает"
Что вам мешает лочить вкрсии пакетов в зависимостях?
Depends: libc6 (= 2.36-8)
Nix/docker/... в отличии от Cargo позволяют лочить не только версии библиотек, но и остального окружения. А ещё можно распространять программы в образах виртуальных машин. Или программно-аппаратные комплексы в виде железных ящиков, чтобы обеспечить воспроизводимость - сходил в магазин и купил ещё один точно такой же ящик, а не "а у меня на компуктере фсё работает"
cargo vendor -- не благодари
> Nix/docker/... в отличии от Cargo позволяют лочить не только версии библиотек, но
> и остального окружения. А ещё можно распространять программы в образах виртуальных
> машин. Или программно-аппаратные комплексы в виде железных ящиков, чтобы обеспечить воспроизводимость
> - сходил в магазин и купил ещё один точно такой же
> ящик, а не "а у меня на компуктере фсё работает"У докера другая проблема - для запуска приложений на клиентских машинах он не особо то и подходит
Nix ближе, т.к позволяет упаковать готовое приложение в AppImage/docker/добавить в nixpkgs/прочее, я сам им пользуюсь везде где только можно. Однако у него другая проблема - он далёк от майнстрима, особенно пока в нём не закончили делать flakes, и в результате его сейчас удобно использовать только для конечного продукта, а в опенсорсе он и вовсе пользователей скорее отпугнёт.
Ты описал преимущество. Хотелось бы услышать о недостатках.Толстовато.
Полагаться на скачать на автомате и как нибудь накомпилировать могут только не отвечающие за конечный продукт.
Фраза " Отказ от гаррантий.." глаза не нарезала?А есть и серъёзные проекты, где производитель отвечает за ПО, и работу в целом. В том числе финансово, а не только поддержкой "для посылания, и обещаний исправить в новых версиях".
Конечно, готовые комполенты используются, и даже часто из тех же источников. Но всё тестируется, как по отдельности, так и на совместимость разных венсий компонентов между собой.
Ты чё, у них любая задача сложнее четырех секунд решения это необходимость копипастить, либо ставить пакеты. Поколение постоянно неудовлетворённых от изобилия, гребут все пакеты и библиотеки.
Лучший раб тот, который не понимает, что он раб.
Это как раз плюс. Не нужно никаких сетевых сервисов, они совершенно лишние
интересно, как ты соберешь свое недоприложение без интернета ? на c/c++ - легко
а не думал что то может быть и плюсом?
чует кошка, чьё мясо съела
>чует кошка, чьё мясо съелаПоясни, кто кошка? И обоснуй.
Пускай АНБ и пользуется своими советами. А я чую, оно поест ООМов.
>При этом разработчикам, которым не требуются подобные строгие гарантии безопасности, оставляется возможность продолжения использования старых методов разработкиПроблема в том, что большинство разработчиков так считают априори. И начинают шевелиться только после того, как подобный подход оборачивается огромными убытками для пользователей продуктов.
Современные ойтишники считают пользователей чем-то вроде дрозжевых бактерий. Кому их мнение вообще интересно среди тусовочки?
И правильно считают. Только кто-то себе так говорит "надо максимально писать качественно по стандартам и со всеми необходимыми проверками", а кто-то считает что "и так сойдёт". Опеннет тому пример, когда эксперты заявляют "нам ваши статические анализаторы не нужны, мы и так УМНЫЕ", становится страшно вообще компьютер включать.
Обмазаться тоннами вырвиглазных стандартов и бесполезных проверок, прилепленных просто чтобы были( попробуй-ка навесить адекватные проверки на кроссплатформенные интерфейсы, чтобы ничего никуда не съезжало и смотрелось годно ), чтобы поддержка стала максимально сложной и трудоёмкой и кроме одного-двух васянов, сидящих на проекте с самого его начала вообще никто ничего разгрести не мог быОуу есс. Ынтепрайес наше всьйо
> становится страшно вообще компьютер включать
А компьютеры вообще регулярно включать не надо. Раз включил сразу после покупки и сборки - и работает
> А компьютеры вообще регулярно включать не надо. Раз включил сразу после покупки и сборки - и работаетОт кода уровня "эксперт опеннета" компьютер приходится регулярно перезагружать. Раз включил и навсегда можно было 50 лет назад, когда экспертов сишки ещё не было.
так и .. какие есть стандарты и тесты, чтобы проверить, чтобы обильное приложение норм работало на рзных яблочных осях и устройствах( +поворотах на бок ) и то же самое с андройдом ?
Ну так, чтобы МАСТЕРА сотню раз не отвлекать ерундовыми вопросами..
> Раз включил и навсегда можно было 50 лет назад, когда экспертов сишки ещё не было.Простите, а что тогда было? Алгол? Shell+Awk? Лампы? (без шуток)
Fortran, PL/I
> ойтишники считают пользователей чем-то вроде дрозжевых бактерий
> И правильно считаютГлавное, что нужно о вас знать
А потом при очередном кризисе ноют, оказавшись на улице. А все почему, потому, что пользователь это тот, кто платит всем этим олухам деньги
> А потом при очередном кризисе ноют, оказавшись на улице. А все почему,
> потому, что пользователь это тот, кто платит всем этим олухам деньгиТипичные свиньи под дубом. Так не только в айти
то есть ты идеальный пользователь
Вот прям багтрекер растоманов описал, где они не боятся показать корпам, кто тут главный, и чьи проблемы обратной совместимости от версии к версии. Прям бунтари нашего времени.
>Проблема в том, что большинство разработчиков так считают априори. И начинают шевелиться только после того, как подобный подход оборачивается огромными убытками для пользователей продуктов.Но ведь это не повод чтобы переходить на Раст, не так ли?
Если Rust сократит убытки, ещё какой повод.
А если не сократит? А если увеличит?
> А если не сократит? А если увеличит?Почему ы будущем времени? Потому и сокращают.
Всякое возможно в теории. Но практика говорит, что Раст сокращает убытки, а не умножает их.
Мозилья-то?
о, может расскажешь про экономику альт линкса, интересно было услышать гуру менеджмента
До бизнес модели епла им точно, где отображение дырень в фряхе сюрьективно дыреням соевого макинтоша, но хоть что-то.
Плюмодеб, плес.>хоть что-то
Сто пятьдесят восьмая это что-то, другого почему-то нет, а что есть, то можно разглядеть лишь в мелкоскоп.
>соевого макинтоша
Спросили плюмодеба, а он знает четыре слова: кринж, база, соевый и чад. А потом выясняется, что руста на маке почему-то нет, есть свои разработки и, внезапно, не мертворождённый проц. Но всё равно соя - это эпол, а не кедогном с js в опплетиках, потому что так хозяин сказал.
Какая практика? Практика 3,5 проектов?
Причём из первого их уже уволили.
Покажи эту практику.
Откуда у растаманов практика?
У растаманов пока один манямирок. Пока нет стандартов типа MIL-STD и misra, они могут блеять что угодно, их фактически нет в по-настоящему ответственных применениях (ведро линукса это даже не близко). Пока под них прогибается Lynx Software под соусом привлекать хипсторов и пытается втащить в это AdaCore (у них на сайте одной строкой ссыль на Lynx Software), но AdaCore слишком дофига инвестировали в Ada, для которой стандарт уже давно и апдейт вот-вот. А раст в мишон-критикал -- это все пока "высокорисковое вложение" (и для Lynx Software тоже) и хайп от обезьян, которые ничего подобного никогда не кодили.
У AdaCore есть SPARK с ним им никакой Растишка не нужен.
> Если Rust сократит убытки, ещё какой повод.От вас убытки.и вассокращают. Туда и дорога
А вы-то чего так распереживались? 😀
> А вы-то чего так распереживались? 😀Радуюсь! От избытка чувств эмоции! Наконец ненужно делают ненужным в мировом масштабе!
> А вы-то чего так распереживались? 😀Что тут не понятного? У соседа корова сдохла, вау! И черт с ним что у самого хата горит, праздник и танцы.
> шевелиться только после того, как подобный подход оборачивается огромными убытками для пользователей продуктовПример приведи, или балабол.
Там всего пара абзацев ни о чём. Но есть примечательный момент: при перечислении предлагаемых языков на замену Страуструп опустил Rust. Вряд ли это случайность, но смысл этого скрытого послания неясен и может быть расшифрован диаметрально противоположными способами.
Видимо Rust на больную мозоль наступил, вот и обиделся дедуля.
Я думаю, что он понимает, что раст обоср.ть так же как всё остальное, что он перечислил, не получится. С мнением АНБ насчет раста он согласен.
У него обидка, что раст взяли туда, куда с++ зась.
Хаха, кто-то забеспокоился что теперь знание 100500 способов инициализации объекта (c++_init_forest.gif) или умение предвидеть все UB в коде вдруг станет не нужным?
Лучше бы придумал как на его же языке не делать ошибки с памятью.
Он уже придумал. Называется shared_ptr и unique_ptr
То есть вместо того, чтобы писать как в нормальных языках
let p = D::new()
нужно писать в 5 раз больше символов?
std::unique_ptr<D> p = std::make_unique<D>();
Неудивительно, что плюсовики такие злые и так кидаются на раст - завидуют, что в нормальном языке это предусмотрено из коробки.
auto уже существует.
> То есть вместо того, чтобы писать как в нормальных языках
>
> let p = D::new()
>
> нужно писать в 5 раз больше символов?
>
> std::unique_ptr<D> p = std::make_unique<D>();
>
> Неудивительно, что плюсовики такие злые и так кидаются на раст - завидуют,
> что в нормальном языке это предусмотрено из коробки.Нормальных языков многои ржавого средних нет.
Примеры: C,D,Ada, PPascal,perl5, Luann, tcl.
Идеальный: Forth!
Понимаешь, нормальность языка зависит от интеллектуальных способностей разработчика. Вот если он мозговит, ему нормальными кажутся одни языки. Если туповат -- другие. И тут ничего не поделаешь.А бизнес делает простую вещь: он пытается найти золотую середину между высокоуровневыми, выразительными и безопасными языками, которые не могут осилить туповатые разработчики, и низкоуровневыми , невыразительными небесопасными языками, для которых на рынке полно народу.
Суть-то не в технических качествах языков. Суть в деньгах.
Как показала практика последних лет, надо делать сразу нормально, а не искать середину.
А то суть в деньках сводится уже к тому, что неэффективных людей надо отправлять в биореактор.
> Как показала практика последних лет, надо делать сразу нормально, а не искать середину.Увы, практика в течение всей истории человечества показывала прямо противоположное.
> неэффективных людей надо отправлять в биореактор
Очевидно, что в биореактор придётся отправить 95% населения. Кто будет выбирать? Вы уверены, что попадёте в заветные 5%? А вот ещё соображение: они конечно выполняют свою работу неэффективно, но они её выполняют. Если они исчезнут, всё то, что они делают, придётся делать оставшимся 5%. Даже если Вы попадёте в оставшиеся 5%, хотите ли Вы впахивать в 20 раз больше, чем сейчас? Ну ладно, с учётом их неэффективности, что там в 20, хотя бы в 5 больше работать? Хотите? А сумеете? Вот в том-то и дело.
А вообще могу устроить и небольшой исторический экскурс. Был уже в середине прошлого века человек, который именно так и решил сделать, да только из сего начинания ничего хорошего не вышло. Дело кончилось тем, что славяне его своими трупами закидали, аж 20 миллионов человек положили, но до гадёныша добрались. Сейчас весь мир вспоминает его как очень нехорошего человека, погубившего 6 миллионов ни в чём не повинных евреев.
В общем, мир -- место весёлое, годное. Ни разу не справедливое, но очень интересное. Рекомендую погулять / осмотреться.
Это залёт. Примеры не сопоставимы, правильно будет let p = Box<D>::new(...).
Ваш код не работает. Но это не залет, а просто забыли :: добавить. Box::<D>::new(...).
Не надо усложнять на ровном месте, с Box будет так:let p = Box::new(D::new());
> Не надо усложнять на ровном месте, с Box будет так:let p =
> Box::new(D::new());Раст как обычно радует читаемым, лаконичным, интуитивным кодом...
Это сарказм? Разве код выше нечитаемый? Вы пишите конкретно, что именно прочитать не можете. А то тот, кто знает Rust и прекрасно его читает, вас не поймет.
Знаешь про автоматическое выведение типов в С++? Называется auto
В Пять раз больше символов?!!! Отвратительно! Нужно срочно выучить новый язык программирования, прочитать новые стандарты и книги... Я вообще не умею читать, а тут в Пять раз!!!
Ты уже знаешь (ха-ха, самоуверенно!) "старый язык". Похвально. А есть те, кто не знает ни "старого" ни "нового" и стоят перед выбором. И что бы ты не утверждал, вход в "новый" легче. Но тебе ведь положить на тех, кто не знает ни того ни другого, важен только ты.
Ну давай тогда на расте полный вариант:let mut p: Box<D> = Box<D>::new();
и на С++ короткий:
auto p = std::make_unique<D>();
> плюсовики такие злые и так кидаются на раст - завидуют, что в нормальном языке это предусмотрено из коробки.
Вообще-то наоборот растоманы кидаются на всех. Вот не понятно, что ты подразумеваешь под "предусмотрено из коробки"? Вывод типов шаблона конструктора появился в С++17.
auto D_uptr = std::make_unique<D>();Оп-па. Что на это скажете, педеRustы?
let D_uptr: Box<D> = Default::default();Четыре символа разницы
Ну std:: втыкать везде это не комильфо, если это не хедер. В большинстве случаев будет
auto ptr = make_unique<D>();
Великая школа using namespace std подкатила?
> нужно писать в 5 раз больше символовв 5 раз?! Растаманы ещё и правильно считать символы не умеют...
Вариант на расте не эквивалентен варианту на плюсах.На плюсах ты создаешь объект в хипе, тогда как на расте на стеке. Ну и не пользуешься автоматическим выводом типов и сокращением неймспейсов.
Эквивалентный вариант на расте:
let mut d: std::boxed::Box<D> = std::boxed::Box::<D>::new(D::new());Но, с учетом того, что на плюсах ты используешь конструктор по умолчанию и наиболее близкий растовский вариант -- имплементация трейта Default, можно немного сократить:
let mut d: std::boxed::Box<D> = std::boxed::Box::<D>::default();против плюсового
std::unique_ptr<D> p = std::make_unique<D>();
Box по-умолчанию в prelude, так что не нужно указывать полный путь:let mut p: Box<D> = Default::default();
Никто этого не боится. На С++ написано несколько миллирдов софтов, библ, сервисов и т.д. Он нужен везде и всегда. И у плюсовиков и у сишников всегда будет работа на годы вперед, это 100%.А на вашем расте не написано ничего.
Раньше был нужен. Теперь уже нет, не нужен. Ну разве что для поддержания той огромной кучи кода, которую успели наплодить за несколько десятков лет.
Жаль разработчики UE5 вас не послушали и написали движок на C++.
Когда софт для реальной жизни (авионику, транспорт, медицинское оборудование), а не для игрушечного ойти начнут писать на расте, тогда и будет видно про "нужен-не нужен". А пока хайптрейн по кругу катается, "ядро линукса, у-у-у-у!", т.к. стандартов на раст для ответственных применений (да и вообще стандартов, что-то с буковками ISO) в природе не имеется.
Сторонники Кобола тоже так думали - теперь их считанные единицы.
ты на их зарплаты посмотри.
В целом может я конечно плохо искал, но в целом знаю на плюсах может быть всего пару тройку библиотек Qt, Boost и так по мелочи там плагины к KDE всякие хотя используем и часто работаю с продуктами более 10-15 лет, а вот с Rust знаком последние несколько лет даже на пороге входа в язык есть удобный учебник, реестр cargo с библиотеками, а еще уйма разработчиков на GitHUB, а главное подключай и используй без боли любую разработку, т.е. нет уймы возни с настройкой проекта и системы сборки. Вспомниаю почему-то времена Visual Studio 5.0 когда делал ActiveX и собирал там как-то уомпоненты эти совершенно несовместимые бинарные файлы проектов между версиями. Какая-то канувшая в лету библиотека MFC.Я думаю, что C/C++ сейчас страдает от отсутствия штатных инструментов сборки, какой-то эталонной реализации (под каждую платформу свои какие-то линковщики, там тебе такие флаги тут вообще совсем дургой транслятор) и почти нет уже сообщества (там остались люди за 50+, а молодые люди конечно смотрят в сторону проще/быстрее/дороже). Да и заказов на проекты с C++ сегодня редкость большая, так по мелочи только где-то используют, а большая часть действительно проектов на C#, Java, Python, Golang-ах всяких.
"Если между свободой и безопасностью народ выбирает безопасность, в конечном итоге он теряет и то и другое."
Бенджамин Франклин
Блин, нашел, это жесть: https://randomnetcat.github.io/cpp_initialization/initializa...
https://google.github.io/styleguide/cppguide.html#Variable_a...
https://abseil.io/tips/88Этого хватит для понимания. А то, что в стандарте сложные правила, дык это везде так.
С ним сложно не согласиться, особенно учитывая что у того же rust вся безопасность работы с памятью сидит в анализаторе кода компилятора. У go же вообще сборка мусора которая сказывается на общей производительности приложения и его предсказуемости, но не обеспечивает безопасной работы с памятью.
а в С++ нет ни анализатора в компиляторе, ни предсказуемости приложения...
Поведение плюсов намного более предсказуемо, так как нет самодеятельности. Код будет вести себя ровно так как его написали.
>Поведение плюсов намного более предсказуемоUB? Не, не слышал.
это не предсказуемость, а косяк аппаратуры и если ты о нем знаешь то будешь избегать. Ну и особенности компилятора тоже обычно изучать следует прежде чем его использовать.
> косяк аппаратуры
> особенности компилятора
> если ты о нем знаешьВ этом и проблема, что нужно знать всё, вплоть до точки росы в конкретный день, чтобы быть уверенным что программа у заказчика соберётся, шаблон развернётся, в новых 100500 страниц стандарта ничего не изменили и никакой козёл ничего не перегрузил.
Ну так это суть низкоуровневых языков таких как c++ которые сразу на аппаратуре работают и хочешь не хочешь в них придется учитывать все особенности аппаратуры и компилятора.
Ну и зачем оно такое надо? Мне вот надо код писать, чтобы выполнить поставленную задачу, а не предугадывать где компилятор может подкинуть шершавого из-за ущербности стандарта
Си - низкоуровневый. C++ - нет. И нет, это не суть языка, а неспособность (невозможность) прийти на уровне стандарта к единому мнению.
Си никакой не низкоуровневый.
По сравнению с плюсами? Конечно, он более низкоуровневый. Но до асемблера ему далеко, да.
На с++ можно писать на голом железе и не жужжать, в том числе в объектной парадигме.
А на статических классах можно и вовсе получить быстрее и компактнее, чем на Си.
> А на статических классах можно и вовсе получить быстрее и компактнее, чем на СиДа ладно, может и быстрее ассемблера?
>> А на статических классах можно и вовсе получить быстрее и компактнее, чем на Си
> Да ладно, может и быстрее ассемблера?Я про ассемблер не говорил, а вот оптимизированный код на статических классах не редко бывает эффектифнее чем си.
А быстрее ассемблера, ну очевидно же, никто не может.Выше фраза промелькнула, что С++ недостаточно низкоуровневый. Независимо от парадигмы программирования, на С++ можно писать проект под голое железо ровно с тем же количеством ассемблерных вставок, как и на Си, то есть таблица векторов прерываний и несколько макросов на спецфические инструкции процессора. То есть, язык достаточно низкоуровневый.
Вот и получилась из языка военно-морская свинка (aka ни рыба, ни мясо). Для низкоуровневого языка сильно переусложнён и для этого вполне хватает Си, для высокоуровневого опять же переусложнён и имеет очень много неопределённостей.> хочешь не хочешь в них придется учитывать все особенности аппаратуры и компилятора
В том и дело, что человек - это не робот. Он в любом случае не может учесть все неопределённости в программе даже среднего размера. Поэтому появляются всякие статик-анализаторы, фаззеры и прочие валгринды. И те, что видно по CVE, далеко не всегда справляются. Вариант решать проблему - языки на принципиальном уровне отсекающие хотя-бы некоторые классы проблем. Но Страус обидится и ещё 20 стандартов о том как надо обходить грабли его творения напишет.
Хомячки тогда будут активно использовать те проблемы, которые не отсекли. Ждать следующего супер инновационного языка?
Если лезешь в такие места, где нужно знать точку росы в конкретный день, то всё просто: накорявил архитектуру.
> вплоть до точки росы в конкретный деньНу это не правда. Там вполне разумные компромиссы, сделанные в первую очередь для скорости.
мвахахахаа!
ты это серьезно? тогда я буду смеяться еще громче!! (с)особенно крутое решение для библиотек "угадай на каком железе оно налажает"
>это не предсказуемостьТы бы не позорился, а? Undefined behavior как раз и обозначает неопределённое поведение. Это не особенность железа, это неопределённость в стандарте, как должен вести себя компилятор в тех или иных случаях. Если ты ведёшь кроссплатформенную разработку, это реальная большая проблема, решение которой занимает очень много времени и сил, и стоит в итоге очень дорого.
Особенно весело когда gcc, clang и студия дают разное поведение и результаты для одного и того же кода.
Прекрасный язык, продуманный, надежный, безошибочный))
go и gccgo не дают разного результата?
Не знаю, на го не писал, с таким не сталкивался.
> UB? Не, не слышал.В расте тоже есть UB. А еще для С++ есть UBSan. Не, не слышал?
Который а) ничего не гарантирует и покрывает только некоторые виды ub и б) добавляет в рантайм оверхед и из-за этого если и используют, то только в прогоне юнит тестов, в продакшене на реальных данных его не запускают.
> Который а) ничего не гарантирует и покрывает только некоторые виды ubникакой инструмент не гарантирует 100% отсутствие ошибок, но это не означает, что его не нужно использовать.
> б) добавляет в рантайм оверхед
Они все его добавляют и asan, и tsan. Но он намного меньше в отличие от valgrind'а, который любят приводить в пример местные растоманы.
> то только в прогоне юнит тестов, в продакшене на реальных данных
> его не запускают.Можно увеличить данные для тестов. Сделать prestable с реальными данными. Вон тот же google по отчетам находит много ошибок с помощью них.
> Но он намного меньше в отличие от valgrind'а, который любят приводить в пример местные растоманы.Причем тут вообще раст и варлинг?
> никакой инструмент не гарантирует 100% отсутствие ошибок
Как раз таки большинство других языков (java, js, python и даже perl) не имеют проблем с ub. По крайней мере, в своих обычных режимах работы, если к ним не подключать плюсовые библиотеки.
Тот же безопасный раст дает 100% от отсутствия ub. Да, есть некоторые нюансы, вроде того же переполнения, но проверки можно оставить и в релизной сборке. Возможны дедлоки в многопоточности, но от них нет 100% защиты даже теоретически. И возможны утечки памяти при циклических ссылках у объектах с rc. Но от этого тоже невозможно защититься без полноценного gc.
Но две последние проблемы — это проблемы именно в текущей реализации стандартной библиотеки, которая внутри себя использует unsafe. Без использования unsafe невозможно реализовать ни rc, ни работу с тредами. Так что в чисто безопасном теоретическом расте это воспроизвести невозможно.
Так что инструменты дающие 100% работающие программы без ub есть.
в зависимости от версии компилятора, целевой платформы (привет платформозависимые UB), настроек оптимизации, фазы луны и тдофиегнно надежный язык, прям как швейцарские часы!
что мы и видим по россыпи CVE %(
В c++ работа кода напрямую зависит от кодера. Если кодер рукожоп то и код будет работать через жепу.
>Если кодер рукожопПокажи хоть одного вменяемого. За несколько десятков лет существования Плюсов так и не нашлось такого почему-то.
Любой эксперт с опеннета может переписать ядро линукса с си на си++ без единого UB. Не могут лишь потому что их мама от компьютера отгоняет слишком рано
> Любой эксперт с опеннета может переписать ядро линукса с си на Расте. Не могут лишь потому что их мама от компьютера отгоняет слишком раноFixed.
да, да если программер лажает - то это "не настоящий с/с++'ник" и вообще его нам подбросили в проект.
вот что-то диды за 30+ лет так и не научились не выходить out-of-bounds и не делать use-after-free
причем самые=самые диды - те которые ядро линкса пишутможет пора признать, что это не реально из-за кривого-косого языка и использовать другие подходы?
Конечно Rust надёжнее. Как может быть не нажёжным тот язык, на котором ничего не написано?
> у того же rust вся безопасность работы с памятью сидит в анализаторе кода компилятораКонечно, это не так на самом деле. Вся безопасность работы с памятью у Rust заложена в фундаментальных принципах языка программирования, которые компилятор поддерживает.
Нет, rust прежде чем собраться анализируется и если там нет нарушений правил то код собирается, но вот если выкинуть эту проверку то в rust вообще что угодно можно творить с памятью.
Эта проверка только потому существует, что такой принцип заложен в самом языке.
Это проверка компилятора, но могут написать и другой компилятор rust который уже позволит нарушать это правило.
>но могут написать и другой компилятор rustНа могут! Это уже будет не компилятор для языка Rust, а компилятор для какого-то другого языка.
Это часть языка. Оно описано в rfcs. https://rust-lang.github.io/rfcs
И любой другой компилятор должен их выполнять, иначе это будет компилятор чего угодно, но не раста.
Такая схема разработки была выбрана как раз по результатам наблюдений за высокоэффективной работой комитетов с++)))
То что в gcc добавили на данный момент не проводит проверки. Но компилятором языка rust является. Только реализация не полная. Вопрос, что мешает так и оставить и собирать из доступных исходиков?
Вы поймите, эти люди из Си++ комитета до сих пор не стандартизовали создание форматированных строк по месту, они не смогли стандартизовать аннотации в комментариях, вместо это они уже три года спорят о том как будет называться функция, назначение которой понятно только им самим. На самом деле Страус прав, Си++ хороший язык, но он был хороший 20 лет назад. Сейчас задачи поменялись, требования к синтаксису возросли, и то что смотрелось круто в 80-е сейчас вызывает кривую улыбку.
Чем дольше стандартизируешь, чем дольше получаешь зп и прочие плюшки. На конференции всякие ездишь и т.д.Вообще ощущение что раст, свифт и другие новые языки дали больший пинок для развития плюсов чем все эти комитеты.
Вон наконец-то добавили концепты и модули.
Не прошло и 10 лет. Хотя нет, прошло.
Прекрасно жили без всех этих монад, концептов, модулей и прочих извращений.
А так же без самолётов, медицинской техники и персональных автомобилей.
Ну хорошо, если С++ раньше был главным ООП ЯП, то какой сейчас его заменил?
Зависит от конкретной сферы. В бизнесе - java. В вебе - javascript. В системном программировании - Rust. И так далее.
> В системном программировании - Rust. И так далее.во влажных фантазиях растоманов.
Можешь опровергнуть, показав где этот раст в системном программировании. Про неработающий ре-сдох я в курсе, там ничего не работает, ОС не юзабельная.
> Можешь опровергнуть, показав где этот раст в системном программировании. Про неработающий
> ре-сдох я в курсе, там ничего не работает, ОС не юзабельная.Можешь прекратить пускать метан в лужу:
https://slowtec.com/referenzen.html
https://slowtec.com/referenzen/automatisierung-iot-parabolri...
> real-time systems in Rust and measurement, control and regulation technology (MSR)https://calyptech.com/
> Used for high performance embedded system components as an alternative to C.
Дык ты код покажи. А так NASA использует С, так что уймись.
Кого волнует что там использует НАСА?
Только не Javascript, а Typescript. На голом JS невозможно поддерживать реально огромные проекты: проверено на 2-х многолетних проектах из продакшена.
какой дурак делает крупные проекты на javascript/typescript
google, хотя у них closure compiler с аннотациями типов был задолго до TypeScript.
В геймдеве? Ой, всё?
Что там со стандартами на раст? В "системном программировании", которое мишон-критикал, кроме понтов про безопасность, нужно еще пруфать годность ("формально верифицировать") и сертификацию проходить.
Смешно конечно. Системное программирование это как минимум - понимание того как работает та или иная библиотека и знания/навыки реализации аналогичной функциональности если вдруг что-то не понравилось. Поэтому кто может/умеет в системное программирование опускаться до раста явно не будет, так как типичная реализация более менее сложных алгоритмов/библиотек на языках типа раст - это боль. И мы все еще посмеемся над результатами полученными на раст. Недаром многие производители OS заняли выжидательную позицию. Оценивая выплывет ли ржавый пингвин или потонет.
Питон. Там где не хватает скорости - Си.
>С++ раньше был главным ООП ЯПНо каким боком сюда Rust?
D разумеется! Абсолютно легальный и мощный преемник.
> создание форматированных строк по месту, они не смогли стандартизовать аннотации в комментарияхЭто прямо киллер-фичи, по-вашему? И как же я жил без аннотаций в комментариях, ужас просто. Такое ощущение, что человек, который о C++ только читал докапывается до микроскопических мелочей.
А правда в том, что на текущий момент в современном C++ есть практически всё что нужно, все старые "болячки" исправлены. В последующих стандартах нужно не добавлять, а вычищать весь старый мусор (всё что связано с C). Все вот эти str-функции, malloc'и, memcopy и прочий ковбойский трешак.
> все старые "болячки" исправленыДа-да, главное, не забудь добавить virtual к деструктору, если когда-нибудь от этого класса кто-нибудь будет наследоваться. Или не ошибись с типами шаблонов, иначе тебя может ошибка с описанием на несколько экранов, причем ничего вразумительного не говорящая о причинах.
Язык развивается странным образом -- все старые проблемы просто игнорируются и основная деятельность направлена лишь на добавление фич ради фич.
> Да-да, главное, не забудь добавить virtual к деструктору, если когда-нибудь от этого класса кто-нибудь будет наследоваться.А не надо использовать абстрактные классы налево и направо. Используй компоненты и мозг, а не анти-паттерны ООП, когда каждая сущность распилена на интерфейсы вплоть до атомов.
> Или не ошибись с типами шаблонов, иначе тебя может ошибка с описанием на несколько экранов, причем ничего вразумительного не говорящая о причинах.
Опять же, не зная броду - не лезь в воду. Не разобравшись в шаблонах, не стоит туда лезть. Лично я предпочту иметь сколь угодно сложную ошибку компиляции, чем любимое сишное UB во время исполнения.
Эти фишки не являются частью языка, чтобы их "вычищать".
> mallocСкажи мне крутой плюсовик-затейник, ты видел как реализован неперегруженный operator new?
> Сейчас задачи поменялись, требования к синтаксису возросли,чьи требования? у кого выросли?
> Вы поймите, эти люди из Си++ комитета до сих пор не стандартизовали создание форматированных строк по местуНе гони, он включен в C++23. А типобезопасное форматирование не так просто как может показаться, посмотри, например на код absl::StrFormat().
> ... они не смогли стандартизовать аннотации в комментарияхИ правильно делают, аннотации в коментариях это зло и всем, кто пробует нагрузить комментарии вспомогательной технической функциональностью, нужно открывать руки
>> ... они не смогли стандартизовать аннотации в комментариях
> И правильно делают, аннотации в коментариях это зло и всем, кто пробует
> нагрузить комментарии вспомогательной технической функциональностью, нужно открывать
> рукиЭто единственный безопасный способ свободно расширять язык не ломая совместимость.
Так у большинства известных мне языков.
Кроме perl'а, там создатель языка предусмотрел такую возможность.
Стандартная библиотека С++ вызывает лишь матерные эмоции. Элиптические функции есть, а вот работа с сетью отсутствует. Что чаще нужно программистам в работе ? Эти люди из Си++ комитета больше для себя лоббируют, плюя на простых прикладных программистов. Все новые стандарты С++ вносят какую то дичь, нужную лишь разработчикам стандартной библиотеки. Развитие языка пошло куда то не туда после С++ 11 и 14. До сих пор не удосужились сделать нормальные многомерные динамические массивы. Чтобы без извращений с одним индексом
Нормальные многомерные массивы - это одна из тех задач которые преподают на прикладном программировании. Если недопрограммист говорит - дайте мне "НОРМАЛЬНЫЕ" многомерные массивы - этот недопрограммист должен идти в армию очки драить, а затем дворы мести.
>Страуструп считает, что хороший статический анализатор, соответствующий рекомендациям C++ Core Guidelines, может обеспечить необходимые гарантии безопасности C++ кода, требуя значительно меньше затрат, чем переход на новые безопасные языки программирования.Это если им пользоваться на постоянной основе. Но из-за лени или сжатых сроков мало кто будет. Так что общие затраты в итоге всё-таки будут гораздо выше, особенно для пользователей.
А ещё такой анализатор должен существовать в природе.
И желательно бесплатный.
> При этом разработчикам, которым не требуются подобные строгие гарантии безопасности, оставляется возможность продолжения использования старых методов разработки.Возможно, люди не хотят, чтобы возможность усиленного ногострела существовала.
// А вообще, лучше б на D переходили.
D не допилен, там много ошибок в реализации, но по факту он превосходит плюсы по синтаксису и лаконичности.
Именно. Это то, как было надо, но ниасилили.
А есть язык где нет ошибок и который «допилен»?
Да, это Модула-2.
А компилятор современный умней есть ?))
Да, скоро в gcc включат. Без шуток.
Букв много -- если писали все эти IMPLEMENTATION MODULE, то должны бы помнить.
Ничего страшного, больше будет времени на раздумья.
твои слова да в уши паскалефобам, у которых истерика от begin-end
Современные IDE умеют дополнять слова.
А какой смысл, если они ВСЁ РАВНО В ЛИСТИНГЕ?! (и загромождают код) Даже с подсветкой это многословие выбешивает. Там, где ты пытаешься углубиться в алгоритм, тебе приходится читать ещё и эти бегин енд. Мне что, заняться больше нечем??
Это время уже пора измерять в годах.
Иногда полезно отвлечься на написание кода от присваивания исключительных прав на достояние общественности. Больше буковок - больше труда рукам и килобайтов в исходнике, можете начать килобайтами меряться.
Чушь не городи! Что именно там "недопилено"? Или тебе васян 5 лет назад это сказал и ты как туnой попугай повторяешь?У Ди ядро языка давно уже стабилизировано. Пока что весь сыр-бор с библиотеками - их надо обновлять под новую "идеологию Range", что-то придётся писать заново и т.п. Но для этого и нужно опенсорсное сообщество! У каждого найдётся что-то допилить.
Такие люди пусть обстена.
D оказался отстоем, скорость низкая, файлы большие.
смотря как писать
в целом Ди может иметь скорость Си, иногда быстрее.
Чушь непомерная. Для Ди есть прекрасный фронтэнд с LLVM-бэкендом. На выходе "почти" Си-шная производительность. Размер неважен, сейчас всё большое.
"Надо просто программировать без багов!"- Автор C++. Самого худшего языка после PHP.
Ну ведь раст гораздо хуже. И пхп и даже питон.
Раст приняли в ядро линукса, что-то не видел такие новости про питон и пхп.
Да и про с++ что-то такого не слышал. А, точнее с++ упоминался в тредах про раст на lkml. Как пример как не нужно делать.Ну и парочка любимых цитат
"C++ is a terrible language"
"C++ ended up with a bunch of terrible, unmaintainable garbage"
"C++ can't solve the problem of the C language at all, it will only make things worse. This is a really bad language."Думаю сами догадываетесь чьи они))
Аж в швятое ведро! Да ладно!
А чего, он еще в авторитете? ;-)
Кому как, но сравнивая его и болтуна-теоретика Бьерна... Выбор очевиден!
> Раст приняли в ядро линукса,в ядро, которое написано на C. По твоей же логике получается, что C лучше.
Даже интересно как ты пришел к этому выводу...
Если бы раста был хуже си, то раст бы просто в ядро не добавляли.
Это вроде бы более чем логично. Ибо какой смысл?Торвальдс (да и не только он) писал, что раст может решить часть проблем (с тему же memory issues) и хочет дать ему шанс.
Именно чтобы сделать ядро лучше. А с++ туда не приняли и не собирались.
=> (для ядра в частности и системного программирования в целом) раст лучше чем с++.
> А, точнее с++ упоминался в тредах про раст на lkml.Именно поэтому Google использует C++ в фучсии?
Раст гораздо лучше. Он намного проще, у него стандартная развитая инфраструктура. Он по умолчанию не даёт рукожопить с памятью в большинстве случаев.
> стандартная развитая инфраструктураКак нетрудно догадаться, рукожопство перетекло в том числе и сюда. Да-да, вендоринг во все поля и проклятья со стороны занимающихся воспроизводимой сборкой (верещащие про безопасТность и не заморачивающиеся такой ерундой -- обычно помогают себе хвостом при перемещении по бранчам).
Про вендоринг говоришь... как так продвигается добавление поддержки e2k в gcc?
В любой непонятной ситуации переходи к обсуждению "Эльбрусов" (С).
Так а кто распушил хвост на Эльбрусах и вступил одновременно в картельный сговор?
Может заодно возродить Itanium, который с такой помпой продвигали неосиляторы Intel корпорации потратившей овердофига денег и обосравшись при этом?
Ты малыш не видел как это продвигалось с отдельной новой улучшенной версией Windows.
А GCC это проект GNU, который пытается примазаться ко всему Linux когда он уже далеко не 100% распространения имеет и пишется самостоятельно. То есть никто не обязан им выдавать нечто. GCC создавали в противовес платным компиляторам.
А в e2k компилятор часть платформы. Осилишь написать компилятор - вперед. Не осилит GNU написать компилятор - их проблемы. Никто им не обязан и тебе тем более открывать код платформы.
cargo vendor сохранит все необходимые исходники для сборки в отдельный каталог. Можешь хранить их потом как угодно и из него собирать офлайново.
О, пчёлы против мёда воюют, смотрите! Вендорлокнутый-то в итоге, это хорошо или плохо?Ничего вендорлокнутого в карго нет. Хочешь, тяни пакеты из гита, хочешь, откуда угодно из сети, хочешь, со своего собственного диска Ц. Большинство не будут страдать фигнёй и притянут всё, что нужно с crates.io.
> Большинство не будут страдать фигнёй и притянут всё, что нужно с crates.io.Поэтому такие языки и не любят. Должны быть средства пробежаться по списку установленных в систему пакетов и использовать их, или предложить установить новые. Но никак не тянуть хз чего.
> у него стандартная развитая инфраструктура.У амого языка нет стандарта, на этом можно закончить про то, что раст лучше С++
> У амого языка нет стандартагазанул в озеро, аж осушил до дна. Вон ссылку давали, на RFC языка
https://rust-lang.github.io/rfcs/
Или тебе какие стандарты, прям чтобы именно "ГОСТ 12345"? Ну тогда ой...
Мне чтоб ISO или ANSI
Вот и выросло поколение, которое считает набор rfc стандартом.
https://www.ietf.org/rfc/rfc1945.txt
> Вот и выросло поколение, которое считает набор rfc стандартом.Вот и подросла школота, считающая стандартом только выс^Hхлоп многомиллиардных корпораций ...
> https://www.ietf.org/rfc/rfc1945.txt
>> Вот и выросло поколение, которое считает набор rfc стандартом.
> Вот и подросла школота, считающая стандартом только выс^Hхлоп многомиллиардных корпораций
> ...Быстро переобулся. Возможно ли реализовать по приведенным тобой rfc компилятор раста? Нет, там даже грамматика языка не описана. Более того в расте даже модель памяти до сих пор не описана.
Конечно она там не описана.
Потому что она описана тут https://github.com/rust-lang/wg-grammar/tree/master/grammar
> Конечно она там не описана.
> Потому что она описана тут https://github.com/rust-lang/wg-grammar/tree/master/grammarСлушай, сначала ты говорил, что набор rfc - это по твоему мнению стандарт. Теперь еще какие-то репозитории. Может все карты сразу откроешь?
>>> Вот и выросло поколение, которое считает набор rfc стандартом.
>> <классический пример>
> Быстро переобулся. Возможно ли реализовать по приведенным тобой rfcБыстро ты начал вилять задом.
Приколись: стандартизация плюсов была аж в 98-ом, да и сишка была стандартизована в 89-ом, а GCC с их поддержкой - еще в 87-ом (помимо кучи других - Watcom, Turbo, MS, Lattice, Datalight)
Ну вот и приходи через столько же лет, когда раст стандартизируют.
А мне что до раста? Я говорю что Си++ один из худших ЯП. Посади стеднтов 3 курса разрабатывать язык, скажи им можно пихать туда всё что угодно, любую идею, вот и получится поделие примерно одного уровня.
"Вы зачем код с багами пишете? Пишите код без багов!"
— Бьорн Страуструп, автор 14 разных методов инициализации в C++
Вот именно!
Что конкретно?
> Страуструп считает, что хороший статический анализатор, соответствующий рекомендациям C++ Core Guidelines, может обеспечить необходимые гарантии безопасности C++ кода, требуя значительно меньше затрат, чем переход на новые безопасные языки программирования.В каком-то смысле Страуструп даже прав: если кому-то "переход на новые безопасные языки программирования" - это затратно, то значит не так уж для них и важна безопасность. А так аксиома Эскобара в чистом виде.
> Объектом критики также стало акцентирование отчёта АНБ только на проблемах работы с памятью, оставляя без внимания многие другие проблемы языков программирования, влияющие на безопасность и надёжность.Акцентируют, потому что по статистике проблемы работы с памятью являются причиной более 70% уязвимостей в коммерческих проектах, написанных на C/С++.
Решение? Продолжать писать на С/C++! Спасибо, Бьёрн!
чем больше фиксить баги - тем дольше ты будешь работать
сидеть "на поддержке" древнючего проекта и фиксить баги (а в процессе новых добавлять), возможно не очень интересно, но довольно выгодноособенно если "это" написано на стандарте 99 года и половина специалистов уже померла от старости, и ты остался незаменимым (читай неувольняемым)
А можно раздельную статистику по С и С++? В современном С++ прямого доступа к памяти через указатели стараются избегать. Больше используют умные указатели, контейнеры, да объекты, которые автоматически диапазоны проверяют.
У Гугл подавляющая часть кода на С++, Си исчезающе мало. Я это к тому, что у Гугл +- та же статистика. То же самое с Мозиллой.
Всё ещё не спилили кобол, фортран, перл и просто си. Плюсы спилить невозможно по похожей причине, т.е. уже есть куча живого кода родом из далёкого прошлого которую невозможно за разумные сроки перенести на радикально другой ЯП. Например, PostgreSQL. Тем более настолько же функциональной альтернативы всё ещё нет. Бьёрн предлагает итеративное развитие языка и вслед за ним адаптацию кода по мере необходимости. Здесь он полностью прав.
> Страуструп считает, что хороший статический анализатор, соответствующий рекомендациям C++ Core Guidelines, может обеспечить необходимые гарантии безопасности C++ кодаТак в Расте этот статический анализатор сделали обязательным, и он выдаёт не ворнинги, а ошибки. Всё.
Проблема C/C++ в том, что погромисты ленивые жопы, и мало кто применяет статические анализаторы. Да и какого фига их так много? Вот в Расте он один, в компиляторе. А кроме него можно линтеров накатить.
Нормальные программисты настраивают CI/CD, который компилирует проект под каждую платформу после каждого коммита, ну и заодно статический анализатор запускает
В новости написано :
> выполняющих проверки безопасной работы с памятью во время компиляции.и
> Страуструп считает, что хороший статический анализатор,В чем разница ?
Разница в том, что использование анализатора необязательно. Кроме того, анализатор может не учитывать какие-то сложные случаи. А вот компилятор обязан.
> А вот компилятор обязан.Совсем нет. Если из исходников соберётся бинарник. Компилятор будет рабочим, хотя из без реализации проверок.
Разница в том, что в расте хайп вокруг статического анализатора... а про формальную верификацию молчок.
Я понимаю что вызову кучу хейта, видосик где объясняют как rust работает с памятью, выводы делайте сами нужен он вам или нет.
https://youtu.be/rDoqT-a6UFg
Так, и че дальше то? Помотал, просто рассказывают про кучу в контексте раста и структуру его типов в памяти
Дальше можно оценить мантру про безопасность работы с памятью и её необходимость.
> Дальше можно оценить мантру про безопасность работы с памятью и её необходимость.И какое ваше мнение?
В его языке даже базовые арифметические операции вызывают неопределенное проведение, может быть это как-то исправить наконец?
В java и kotlin используется семантика заворачивания, при переполнении
В rust паника в отладочной сборке и семантика заворачивания в релизной.
В С++ неопределенное поведение.Проблема же не только в автоматическом управлении памятью
В расте переполнение так же является ub. Так уж устроены современные процессоры. Но его легче отлавливать на отладочных сборках.+ можно и релизные сборки собирать с проверкой на переполнение, но это сильно бьет по производительности и поэтому так никто не делает.
>переполнение так же является ub. Так уж устроены современные процессоры.Уточните, что это за современные процессоры такие в котором переполнение в простейших целочисленных арифметических операциях вызывает неопределенное поведение?
> В расте переполнение так же является ub.Уточните, где именно здесь неопределенное поведение?
https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...
По той ссылке, что Вы привели, в Rust результат переполнения при сложении зависит от ключей компилятора. Если задан ключ --debug, то одно, а если нет, то другое.
Из новости узнал, две вещи.
1). Страуструп не знает о существовании языка Раст. Это хорошо.
2). Страуструп вендузятник. Он же работал в Bell Labs, видел живых Кена Томпсона и Денниса Ритчи. Позор!Приличный человек не должен знать таких слов, как "Microsoft Visual Studio".
Другими словами, ты вообще ничего не узнал (не понял). Надеюсь, ты не программист?
Что бы ругать Visual Studio, с ней надо сперва поработать, и поработать с мучениями, иначе с чего её ругать.
Конечно, найдут что поругать и её любители, но не с такой же яростной реакцией.Потом универсальных инструментоа не бывает, как бы их не позиционировали. И в Вашей любимой среде разработки, тоже явно не со всякой задачей продуктивно работать.
У нас на работе куча программ на разных языках понаписано и нигде статического анализатора нет.
Даже встроенный в android studio инспектор и тот отключили.В организации занимающейся аутсорсом тоже ни в одной программе не было статического анализатора.
Если его нет прямо в компиляторе, его не включают. Если компилятор просто печатает предупреждения, их игнорируют
Программисту Андроид программ отвечать ни за что не надо, достаточно не делать откровенно забагованное ПО. Если б меня перевели на разработку Андроид ПО, я б тоже сократил у программистов "лишние" операции по тестированиям, если что исправят в обновлении. ;)
> Если его нет прямо в компиляторе, его не включают. Если компилятор просто
> печатает предупреждения, их игнорируютДоля правды в этом есть. Просто нужен кто-то, кто все настроит. Остальные будут идти за ним https://s5o.ru/storage/simple/ru/ugc/23/90/c4/11/ruu788faf18...
> Если компилятор просто печатает предупреждения, их игнорируютВ go именно поэтому не дает собрать код с неиспользуемыми переменными. Даже в деве.
>В организации занимающейся аутсорсом тоже ни в одной программе не было статического анализатора.Потому что он в отдельной программе в пайплайне CI/CD. А варнинги не игнорируют, а трактуют как ошибки. Достаточно чтоб гайдлайны проекта и пайплайн этого требовали. Еще страшных историй?
>Если его нет прямо в компиляторе, его не включают.
Надо спросить где у растаманов формальная верификация происходит. В ихнем конпеляторе ее нет. "Если его нет прямо в компиляторе, его не включают" (с) Бггг.
Дед выдал базу, зумерки порвались. Навязывание анализаторов и линтеров путем встраивания их в компилятор - зло. C++ живет по сей день, потому что он гибкий и дает свободу разработчикам.
У деда начальная стадия болезни Альцгеймера. Он застрял в 80-х годах прошлого века (как и большинство тутошних престарелых "экспертов") .>потому что он гибкий и дает свободу разработчикам
А на пользователей и их проблемы из-за такой вот "свободы" плевать. Да?
> У деда начальная стадия болезни Альцгеймера.За базар пояснишь? Открой список фичей из С++20 и С++23 и скажи, что там застряло в 80-x?
Лучше бы всех этих фичей не было бы. Язык окончательно превратился в помойку после С++ 14
> Лучше бы всех этих фичей не было бы. Язык окончательно превратился в
> помойку после С++ 14Давай примеры где помойка после с++ 14
> А на пользователей и их проблемы из-за такой вот "свободы" плевать. Да?Тебе же ответили в статье или ты не осилил? Используй анализаторы.
А в Раст можно просто писать код и не сношаться с анализаторами, дебаггерами и линтерами. Прикольно, да?)
> А в Раст можно просто писать код и не сношаться с анализаторами,
> дебаггерами и линтерами. Прикольно, да?)Это вранье.
Тебе бы такого Альцгеймера к 80 .. если вообще доживёшь
Да, он гибкий.
Позволяет гoвнoкодить десятками изощренных способов, отстреливая ноги себе и своим пользователям.
Ну говнокодь только одним способом. Кто тебе мешает? Будто от наличия только одногоспособа твой код сразу выпрямится.
Ещё один Юрий Лоза.
1) Просто не нужно быдлокодить. Я лично смотрел в сурцы некоторым опенсурц проектам. И да, необходимость держать код открытым и разработка в стиле "Чем больше глаз, тем меньше шанс пропустить ошибку" вовсе не защищают от ужасного качества кода. Правила то простые. Делайте все явно. Главный источник ошибок - это различного рода неявные вещи. Например объект должен уничтожаться явно в каком то одном месте по явно установленными правилам. Если он у вас будет уничтожаться в 100500-х местах по овер9к if-ам, то 100501м месте вы его уничтожить забудете. 2) Пользуйтесь нормальными языками с нормальными инструментами разработки. В Делфях уже 100500 лет как существует FastMM, который в Full debug mode автоматически ищет любые ошибки доступа к памяти. А то ребята, так радеющие за православный C/C++, до сих пор перезагружают оконный менеджер Cinnamon по таймеру, чтобы избавится от утечки памяти.
>Просто не нужно быдлокодить"Не виновата я, он сам ко мне пришёл".
Нет, это непросто. Это очень непросто, что и демонстрирует огромная куча литературы на тему хороших стилей программирования, а также на мене обширная база данных уязвимостей.
на мене -> не менее
> Просто не нужно быдлокодить.Золотые слова. Но легко сказать, трудно добиться. Бизнес-то с тобой полностью согласен. Он не просто так развивает все эти новые языки: это ведь именно что способ принудить разработчиков не быдлокодить.
> Просто не нужно быдлокодитьНадо просто запретить людям делать плохо, и все сразу станет хорошо. Почему до сих пор не сделали?
> В Делфях:D
Сразу видно настоящего программиста, который больше ничего не видел.
Ну так если вы ратеете за плюсы, ответьте по факту, почему в плюсах за 40 лет ничего нет даже близко по функиональности FastMM? чтобы показать все проблемы с памятью сразу?
Если в Делфях еще нужно писать ReportMemoryLeaksOnShutdown := True, то в Lazarus это просто включается по умолчанию в Debug режиме. И вы при каждом завершении программы будете видеть, была у вас утечка памяти или нет. Очень помогает. Full debug mode еще круче. Он ищет обращения к уже освобожденной памяти. Ну кстати бывает полезно скомпилить прогу под разные платформы. Что прокатывает на 32х битах, то падает на 64х.
Он просто не знает, что как только начинаешь писать на расте, все баги сами себя фиксят и волосы становятся шелковистыми.
Так вот к чему приводит кодинг на с++!
Вот ему и обидно, что его волосы уже не станут шелковистыми даже если он начнет писать на расте((
Открываю секрет ни у кого волосы не станет шелковистыми от писания на расте. И баги сами себя фиксить не будут.
От Раста последние волосы повыпадают.
Сам их повыдираешь после часа работы с растаманскими указателями. :))))
> все баги сами себя фиксятстандартная мантра растохейтеров про якобы заявления растоманов. За "все баги" только вы, сишники, заявляете. А растоманы заявляют за отсутствие в растовских прогах 70% типичных сишных ошибок, которые (во какая оказия и несправедливость, не иначе, саботаж!) допускают "ненастоящие" си-программисты. Наверное в стек между ушами у сишников не помещаются все эти рекомендуемые Бьёрном Guidelines, выход за границы буфера происходит.
> и волосы становятся шелковистымиУточните на какой части тела?
эх я то думал он серьезный дядька, повелся на заявления какой-то там мутной конторы, комментировать даже не буду.
Вообще его "письмо" крайне прикольное. Чего только стоит:
"To the best of my knowledge, no experts from the ISO C++ standards committee were consulted."Т.е. он не реальных щах считает, что к членам с++ комитета должны были придти аннбшники и спросить "а не багованое ли ваше поделие?"
И они такие "нет конечно, у нас самый лучшый язык в мире!"
А анбешники "а, ну раз вы так говорите, то вычеркиваем"
теперь внезапно выяснится, что мистер Страуструп уже лет 150 неистово донатит фанатикам-поборникам традиционных семей и достоин всяческого осуждения?
И ему запретят программировать на расте? Так он только рад этому.
Хоть один нормальный человек среди всей это кодлы. Бьёрн всегда был нормальным человеком.
Он придумал ЭТО. Как он мог быть нормальным?
Придумал единственное нормальное? Так поэтому и придумал что нормальный, а тебе бы голову полечить не помешало бы.
А как может быть нормальным Грейдон Хор, придумавший (Это)^2 ?
> Он придумал ЭТО. Как он мог быть нормальным?На ЭТОм написан твой браузер, из которого ты комментишь. Как ты вообще можешь быть нормальным?
И куча дыр в нем именно из за этого.
> И куча дыр в нем именно из за этого.Ну напиши на расте и без дыр. 17 лет прошло с момента создания языка. В чем же проблема? Почему, зачем, во имя чего вы упорствуете, Мистер Андерсон?
Есди выбирать между дурявым и быстрым софтом, я выберу быстрый.
Только выбор всегда идет между: "дрявый и медленный", "быстрый и дрявый", дрьявый как ваш покорный слуга
Выбор идёт между софтом, который есть и софтом которого нет. В таком случае выбирают тот софт, который есть.
Не все программисты могут осилить надёжный стиль на Си подобных языках.
У кого то быстрый код вовсе не взлетит.
А на медленном безопасном задача коть как то будет решена.Ещё тормоза в управляемых языках в значительной степени связаны с парадигмой программировпния. В том же С# если всё заеихать в статики, и писать как на самом деревянном диалекте Си, догадаетесь какое будет быстродействие? Крайне высокое. Только не всякая задача вменяемо решается таким образом.
> догадаетесь какое будет быстродействие? Крайне высокое.Да-да. А еще если отключить сборщик мусора, то и обгонит... Говорят в каком-то софте для биржи на джаве так делают.
С виртуальной машиной в виде. Net он никогда не будет быстрым что ни делай с ним
> Net он никогда не будет быстрым что ни делай с нимНу вот даже в движке Unity свой форк .net и c#, а игры все равно тормозят и жрут ресурсы.
Игры на Юнити тормозят по той причине, что их делают в большинстве своём вчерашние студенты, которые не задумываются о простейших оптимизациях ассетов.
> Игры на Юнити тормозят по той причине, что их делают в большинстве
> своём вчерашние студенты, которые не задумываются о простейших оптимизациях ассетов.Какая игра на Юнити не тормозит и не жрет ресурсы? Можно ссылку?
Полностью оптимизированных нет таких игр. Я их сотню перепробовал. Вот несколько примеров: игры серии pathfinder в момент релиза кушали 100% gpu для отрисовки главного меню, игра last epoch 11 Гб ОЗУ после загрузки пары локация, одиннадцать гигабайт Карл!! причем благодаря венде и ее сжатию давно не активных страниц памяти реально сжимается 6гб из 11.Есть игры серии sabnautica в которых реально матёрые программисты реально старались сделать все реально хорошо на unity (или же они просто купили коммерческую оптимизацию игры, авторы unity за этот счёт и зарабатывают) правда кроме ассетов, там половина пластилин.
Unity для игроделов это как электрон для писателей десктоп софта. Тебе не нужно думать ни об потребляемой ОЗУ, а самое главное ни о потребляемой памяти видеокарты. На встроенных графических чипах можно забить оно там будет как томогочик, а так дискретные требуются современные, я бы сказал сейчас идёт мейнстримный нацел на то что 8гб vram карты это стандарт, хотя на 4 ещё нормально.Так вот по своей сути юнити это не игровой движок, это player игрового кода игры, именно так, они не позволяют улучшать его внутренности и не дают к ним доступа. Все игры на юнити страдают одними и теми же проблемами, кроме общеизвестных связанных с производительностью это ещё: загрузка игрового кода в один поток на одном ядре, у всех игр на юнити процесс thread рендеринга картинки зависает в момент загрузки, стандартный код поиска коллизий между двумя и более объектами в игре "буксует", выглядит это как игровой персонаж пытается лбом таранить "врага" и плавно скользит в сторону, во всех arpg что я пробовал.
Если сравнить unity с ue4 на играх от первого лица шутер там или выживание то unity выглядит ужасающе.
>> догадаетесь какое будет быстродействие? Крайне высокое.
> Да-да. А еще если отключить сборщик мусора, то и обгонит... Говорят в
> каком-то софте для биржи на джаве так делают.Сборщик мусора статическому коду и объектам не мешает, а отключить надо лишние проверки в критичных местах, в релизе.
Но это скорее полу спорт, чем практическая задача. Формально программа типа на c#, но кучей плюшек не пользуется, и не сокращает ни фремя разработки, ни добавляет фич.
Лично я в таком стиле только эмулятор 386 писал, именно со спортивным интересом.
Мда... А кошка слушает, да ест. У всех значимых корпораций: Майкрософт, Оракл, Гугл, Эпл есть собственные языки программирования. А у некоторых даже два. Да, они участвуют в развитии стандарта С++, в конференциях, но по факту каждый спешно ищет пути соскочить.
> каждый спешно ищет пути соскочить.Только все никак не получается.
Потому что довлеет наследие десятилетий. Не выкинешь же сразу старое г.вно, когда другого еще не нас.рал. А старого на миллион авгиевых конюшен навалено, гераклов на всех не хватает. Ну и плюс старое пока продолжает приносить деньги, а качество у конкурентов такое же, ибо такое же старое.
> Не выкинешь же сразуНу 17 лет прошло, можно было уже начать?
Скорее, что имела место быть эволюция.Начинали делать инженеры для себя, как для людей. И вышло может и с косяками, и не всё сразу придумали, но результат закономерно оказался хорош.
Коммерсы посмотрели. И попробовали развить... Тот же Ведроид, современный Веб. И вышло безмозглое в конце ненужно. При всей продуманности, эффективности, окупаемости оно часто больше не даёт такого, без чего в жизни не было бы ох и ой.
Да все проще. Все кто что-то может в программировании не видят смысла в маргинализации своих продуктов.
Потому что каждый пилит свое, а нужно объеденить силы в одном направлении.
Большая часть разработчиков просто мартышки, как и большая часть людей вообще. Так что язык просто не должен позволять стрелять себе в ногу и все. Если позволяет и его надо обмазывать анализаторами и настройками с гайдами, это приводило и будет приводить к проблемам. Для идеального программтста гайды рулят, для реального...эта критика от автора языка, который уходит в легаси не катит для реальных условий.
Язык не должен говорить что тебе делать. Подумай об это когда научишься думать.
Страуструп окончательно окочурился с своей лбратной совместимостью т превращению языка в помойку.
> превращению языка в помойку.Вообще-то последние нововведения очень хороши: std::format, expected, концепты, корутины, модули. А обратная совместимость она важна. Растоманам не понять.
Вот даже не начинайте. За нарушение обратной совместимости надо просто незамедлительно уничтожать. В Аду есть особая печь для тех, кто нарушают.
не, нужно тащить за собой тонны старого кода, поддерживать копролитические платформы и все ражи 2-3 калек которые сидят на железе 30 летней давности!
офигенный план
Дед высказал своё мнение, в котором он недоволен молодёжью. Не хотят молодые суп вилкой хлебать, хоть ты бей их.
А молодые вообще ничего не хотят - только чтобы им всё разжевали и в рот положили, да "дедов" пообсирать, которые всё современное IT создали.
К сожалению, это не только в IT.
о, начинается старческое нытье в стиле "раньше было лучше", "молодеж совсем от рук отбилась", "деды кал жрали ложкой, а эти не хотят"...к счастью этому уже больше 1к лет, вот еще Сократ писал «Нынешняя молодежь привыкла к роскоши, она отличается дурными манерами, презирает авторитеты, не уважает старших, дети спорят со взрослыми, жадно глотают пищу, изводят учителей».
> к счастью этому уже больше 1к лет, вот еще Сократ писал «Нынешняя
> молодежь привыкла к роскоши, она отличается дурными манерами, презирает авторитеты, не
> уважает старших, дети спорят со взрослыми, жадно глотают пищу, изводят учителей».Сократ жил в Афинах во время Пелепонесской войны. В которой Афины потерпели поражение. Он был прав.
Создали бы без косяков то можно было бы возмущаться, а так так себе аргумент.
Сейчас даже фрукты и овощи не принято резать и всё такое. Их принято есть в виде смузи. Смузи это когда все положили в блендер и измельчили. Даже не ты, а специально обученный человек.
А что плохого в смузи? Под твоё описание подходит обыкновенный банановый молочный коктейль. Ты не любишь банановые коктейли?
Но а как же безопасность!?
Безопасность с безопасТностью рознь.
> Но а как же безопасность!?Безобразность синтаксиса? Это к расту.
Си и Си++ дают свободу мысли и творчества. А вы и дальше программируйте на своих душных псевдобезопасных языках и обязательно слушайте, что говорит АНБ!
Филологам в IT не место. Программа -- это не школьное сочинение на тему "как я провёл лето", в ней не должно быть места отсебятине, а значит и таким халтурным языкам как C и C++.
Свобода мысли и творчества, вот только большинство тупо гуглят готовый код.
https://upload.wikimedia.org/wikipedia/commons/thumb/d/da/Bj... - вот настоящий плюсовик, альфач.А теперь, ратоманы, ваш ход.
Сейчас он выглядит вот так, но смысл тот же (может себе позволить)
https://i.imgur.com/rJUB4oq.png
Я написал язык Си и слегка з̶а̶.̶.̶.̶ в шоке от этого https://upload.wikimedia.org/wikipedia/commons/thumb/2/23/De...
24" 1080p панели - он настолько нищий?
> 24" 1080p панели - он настолько нищий?Какая разница какой монитор? Ты еще спроси почему он вертикально не повернут, чтобы больше кода влазило.
И прическа не из барбершопа, и волосы не фиолетовые, и штанишки не узкие, и сникеры не модные, и бицепсы не выпирают...
Фу, ненастоящий какой-то программист.
А вот rust-сообщества:
https://foundation.rust-lang.org/img/headshot/jane.jpg
https://twitter.com/yaahc_/photo
Старпёр, хвастающийся своими ЭЛТ мониторами.
Какая там у него стадия? Отрицания?
> Какая там у него стадия?реализм.
Торг
“ Создатель C++ раскритиковал навязывание безопасных языков программирования” - сами языки программирования это хорошо. А навязывание конечно плохо.
Комментаторы раст-хейтеры с батхёртом от того что не хотят / не могут осилить ничего нового.Майкрософт говорил что 80% всех уязвимостей за 2020 (или какой там) год - это мемори сейфти, поэтому Раст отлично заходит. (Ищите сами ссылку на это если нужно).
Не понимаю как профессионал может говорить что один язык лучше или хуже. Это как бензопила лучше чем перфоратор. Или я работаю молотком (С/С++) последние 20 лет и все нормально, значит отвёртки и все другие инструменты не нужны.
> Не понимаю как профессионал может говорить что один язык лучше или хуже.
> поэтому Раст отлично заходит
Товарищи майоры оставили бекдоры, и теперь, чтобы замять "это грязное дело" нужно объявить, что вина тому только безопасная работа с памятью, а не их многочисленные закладки. А здорово вы это придумали, я сразу и не догадался!!!
На мотив "Мурки",Товарищи майоры
Оставили бекдоры
И решили дело то замять.Сишку обвинили
Чтоб все её забыли
И пошли на Расте все писать.
а) Дипстейт продвигает безопасные(но при этом централизованные или уже закрепощенные) решения что бы иметь меньше головной боли
б) Дипстейт предвидит волну отхода от безопасных языков и намеренно создает собой антирекламу(скорее всего нет)Судя по описанию слов деда в статье, дед опять пыхтит и оправдывается.
P.S C++ в нынешнем виде и наследием обратной совместимости выглядит как треш. Rust имел все шансы, но превращается в ахтунг, и сектанство вокруг него какое-то нездоровое.
Не холивара ради.Я до сих пор не понимаю тех, кто пишет на плюсах. Если вам нужны указатели и непосредственное взаимодействие с железом - вам чистый Си. Если безопасность, ООП, функциональщина и прочие концепции - пишите на любом относительно современно ЯП: Java и её производных, D, C#, Ruby, Python, да хоть на JS! Плюсы-то вам зачем? Зачем мучаться? Туда же все эти потуги с Rust, Go, что там ещё из новоязов? Для чего? А главное на серьёзных щщах пытаться переубеждать людей, что Rust лучше Java, например. Или Python. В конце концов, если человек не привязан к какому-то стеку технологий, то вообще может выбирать между диалектами LISP и Haskell. Вот где раздолье для самореализации! Мне вот лично гораздо больше Python нравится чем Ruby. Но при этом я понимаю и принимаю, что де-факто именно Python стал lingua franco. Лучше уж Python чем C++ или Java. Потому что меньше геморроя тащить вместе с языком. За один день можно разобраться как базовые операции делать и начать писать код для своих прикладных задач, а не месяцами изучать стандартную библиотеку.
P.S. единственная сфера, где нужен C++ - это HFT. Куда Страус и свалил. Всё. По сути он больше никому не нужен. Оттуда и пассаж про "скорость над безопасностью". Весь остальной банкинг вращается или на C# или Java. Потому что архитектура, ООП, безопаность и прочее.
Я хотел написать, что Ruby нравится гораздо больше чем Python. Поправка.
> Rust ... Для чего?1. Может быть ты специалист/компания широкого профиля и хочешь использовать один и тот же язык для бек-энда, тулинга, встраиваемых компонентов, кусков фронта (WebAssembly), графики. И чтобы быстро, без фризов, и безопасно!
2. У тебя огромная кодовая база и без развитой системы типов и кучи проверок компилятора ты просто утонешь в багах при рефакторинге/доработках.
3. Ты стремишься максимально переиспользовать свой код (или брать готовое), а для этого нужны хорошая система модулей и мощные инструменты управления зависимостями и процессом сборки.
4. У тебя многопотоков, и без вот этих автопроверок на Send и Sync, а также без защиты от гонок, твоя жизнь тихонечко превращается в ад.
5. Тебе надоело писать шаблонный код и ты хочешь красиво его генерировать макросами.
> Не холивара ради.
> Я до сих пор не понимаю тех, кто пишет на плюсах. Если
> вам нужны указатели и непосредственное взаимодействие с железом - вам чистый
> Си. Если безопасность, ООП, функциональщина и прочие концепции - пишите на
> любом относительно современно ЯП: Java и её производных, D, C#, Ruby,
> Python, да хоть на JS! Плюсы-то вам зачем? Зачем мучаться?Они дают все эти концепции и получаешь такой же быстрый код как на С.
> P.S. единственная сфера, где нужен C++ - это HFT. Куда Страус и
> свалил. Всё. По сути он больше никому не нужен. Оттуда и
> пассаж про "скорость над безопасностью".Для С++ есть куча других реалтаймовых задач.
> Весь остальной банкинг вращается или на C# или Java. Потому что архитектура, ООП, безопаность и прочее.
В современном банкинге, в том числе и связанном с биржей, используется go, например.
> В современном банкинге, в том числе и связанном с биржей, используется go, например.Есть. В Ozon, например, все вакансии на Go. Что говорит лишь о том, что там собрались смузихлёбы.
Я не понимаю зачем усложнять себе жизнь и тащить плюсы в задачи, где требуется быстродействие. Пишите на C и не выпендривайтесь! Либо учите и разбирайтесь до бесконечности в плюсах и страдайте. Все остальные, кому не требуется писать RTOS, критические секции ОС, хардкорные реализации алгоритмов для роутеров или ещё какие-то специфические задачи уже давно перешли на Java или любой другой ЯП. И в ус не дуют.
P.S. не переубедите вы меня, что С++ в принципе нужен. С++ - это попытка натянуть всё то развитие в области прграммирования на язык С, просто потому что это удобно и не ломало код на первых порах. Гораздо проще и правильнее было сразу в Java вкатываться. Когда она появилась и развилась само собою.
Ну вот мне нужна работа на десктопе на разных платформах. Гуи с кучей сложных виджетов и MVC. Работа с мультимедиа (как ffmpeg, так и медиа API осей напрямую). Возможность работать с API графами и всякие рисовашки на сцене. При этом все это добро должно достаточно быстро и сносно работать. Желательно интеграция со всякими CI/CD и тестовыми фреймворками.
Попадает под список требований только C#, Java, C++.
К сожалению, работа с гуём на C++ организована на порядки лучше благодаря Qt, поэтому C# и Java отваливаются. Когда будут стабильные рабочие биндинги для Qt под Rust - смело перейду на него. А пока да, С++ адекватной замены нет. Пытаться сидеть на вот этих Java/D/Ruby это как раз таки "жрать кактус" вместо решения бизнес-задач.
> К сожалению, работа с гуём на C++ организована на порядки лучше благодаря QtВсе верно Qt слили немного денег на реализацию GUI вот и путь(цена) до результата поближе чем на всяких языках второго порядка (через биндинги).
Все эти крики по сути просто разговор о техническом долге разработчиков ОС общего назнаечени, которые к 2022 году не имеют до сих пор нормального C ABI для создания GUI. Так что речь тут не о фреймворках, а о том, что создатели X11, Windows или macOS не предоставляют единого стандарта я уж ен помню что там были за инициативы у них у всех OpenMotif вроде бы последнее что я помню пытались стандартизировать...
Так что проблема тут не в языка и их биндингах, а в целом в том что вам 30 лет продают Windows с недокомплектом (хотя ладно там вроде бы есть какой-то CreateWidnowsEx), так что вам дают X11 с набором примитив рисовашки окна, картинки и что там еще по стандарту X11 можно рисовать. Что вам дают в Carbon/Cococa только Objective-C интерфейс к компонентам. Это все просто маркетинг, который сегодня привел к лидерству Electron прилоежния дающий общий API для рисования HTML в окошке для всех систем.
Давайте лушче вместо срача что там биндинга нет петицию на восстановление OpenMotif писать к всем манстримным системам...
Писать десктопное приложение, дёргающее API ОС для отрисовывания это конечно не абстрактный конь в вакууме. Каждый день все этим занимаются. Требуется примерно 0,00001% разработчиков. Про бизнес-логику поржал, да. Java для того и сделали, чтобы бизнес-логику по сути писать, не заморачиваясь переносимостью.Я не буду спорить, что Qt очень много сделал для плюсов. Но мы говорим вообще-то про энтерпрайз код, а там альтернативы Java по сути нет и не было.
P.S. Ruby on Rails как был, так и есть лучшим веб-фреймворком. Только JS макаки в него не могут никак. Что ни в коей мере не мешает использовать Ruby примерно в любой прикладной задаче.
> Ну вот мне нужна работа на десктопе на разных платформахКто тебе сказал, что тебе нужны "разные платформы"? Ты сам это выдумал из ****опы и ставишь в требования. Просто посиди, подумай - так ли оно тебе надо и внезапно окажется, что в пень не упёрлось.
> JavaМедленнее C++, жрёт больше.
> DПрикольный язык, писал на нём. Но он не особо популярен и мало библиотек.
> C#Слишком много Microsoft.
> Ruby, Python, да хоть на JS!Медленные скриптовые языки.
Была модная концепция, что плюсцы заменят собой чистый си, и заодно станут языком для всего. Тогда еще не было мобайла и зоопарка архитектур - безраздельно царил х86, на ПК стояла винда, линукс был экзотикой и выпендрежем, на серверах чаще встречались BSD. В этих условиях можно было поверить в замену си плюсами.Но вместо этого случился бум веба и скриптовых языков. Новое поколение программистов не нуждалось в сложных компилируемых языках. Вместо десктопных приложений на плюсах, люди стали писать веб-приложения. С другой стороны, системные программисты не перешли на плюсы из-за его очевидных недостатков по сравнению с чистым си (и отсутствия явной потребности в нем). К середине 10-х годов были созданы инструменты, комбинирующие лучшие стороны скриптовых языков и типизированных компилируемых. Сейчас они уже зрелые. Теперь у плюсов нет даже гипотетической возможности увеличить долю. Новые программисты в него могут попасть только из российских вузов с устаревшей на 30-40 лет программой.
Наивная позиция про статический анализ. Если инженерам позволить быстрее сдать задачу (а еще KPI криво написать), то конечно все это будут игнорировать понаставят флагов "-Wno-*" и будут спокойно халтурить.Язык же исключающий в принципе возможность написания кода халтурно (кстати Rust позволяет халтурить в своем unsafe подмножестве), так что этим активно можно пользоваться.
Что касается плюсов в возможности свободы в использовании там где нужно небезопастного подхода это не работает в современных подходах кодом зачастую владеет не один человек а команда и разбираться почему там какой-то Васян решил сэкономить слишком затратно, так что создают некоторые практики говорящие надо писать код безопастно, но Васян конечно не успевал в сроки и продалбал и вообще так проще, так что потом переиспользовав это в потоке другой Петя и все ... все довольны проект сдан, а Васян и Петя осчастливлены премиями за успехом и сдачей в срок, но вот только спустя год найдут проблему в самом неожиданном месте. Если позволить человеку халутрить он будет халтурить....
Относительно языков с защитой дело это очень хорошее перекладывать ответственность на бездушную программу которой пофиг на сроки и прочие обстоятельства, но вот только тот же Rust все эти гарантии дает обойти и создает илюзию защиты, так все эти механизмы снимают unsafe блоками или внешними выходами в C/C++ код. А так же не забываем про уймы runtime внешних библиотек и вот мы решили только часть проблемы.
С++ плохой язык, но остальные еще хуже. Нет в жизни счастья.
C++ (и его подмножество C) - единственный язык. Других не существует.
Толсто. Си - это отдельный язык. Он к Си плюс-плюс никакого отношения не имеет.
счасть есть, его не может не быть! увольняешься из гугла и вот оно
Остальные хуже исключительно из-за вашей ограниченности и излишней специализации в одной технологии.
Вместо того, чтобы мудохаться с вашими наркоманскими тулкитами и зоопарком компиляторов и билд-системам (это помимо той наркомании, что в самом языке), люди и корпорации пошли по пути создания и использования более простых и отвечающих потребностям инструментов. И вспять этот процесс уже не повернуть.
Под винду еще какое-то время попишете на своих плюсцах. А потом всё.
> развиваемые последние годы базовые рекомендации по использованию C++ (C++ Core Guidelines)С учебником (любым) пробовали ознакомиться?
C++ действительно не позволяет писать надёжный код.
С проблемой утечки памяти в браузерах, пользователи сталкиваются каждый день. Но есть и вторая сторона медали - это переносимость кода. Так что если нужно обеспечить переносимость,то выбора в общем-то и нет. На больших объёмах кода утечка памяти гарантируется.
> C++ действительно не позволяет писать надёжный код.Да неужели?
> Но есть и вторая сторона медали - это переносимость кода.И она изумительная у С++.
> На больших объёмах кода утечка памяти гарантируется.Нет.
У Вас что в дипломе написано? У меня в специализации "Разработчик С++".
Это где такие дипломы, в Зимбабве чтоли? :D
Диплом это здорово, конечно, ваш диплом может помочь решить проблему с утечками памяти в отрасли?
Видимо, корпорации Google, Microsoft и пр. так и не смогли вас нанять вовремя, и теперь обречены на страдания с багами.
Если заглянуть в новости они на оборот по увольняли, нецросети будут работать за место этих всех бездарей.
Жертвовать безопасности ради эффективности? Ну такое себе. И лучше раньше думать о безопасности, чем потом гайдлайны прикручивать к хромой собаке.
> И лучше раньше ..., чем потомПотом это, очевидно, будет делать другой разработчик. В таком случае лучше переписать весь код заново.
Мнение этого человека чётко и по делу. Каков он сам и есть.
А просто в АНБ принято лгать и под видом чего-то такого на самом деле ваяется какая-нибудь опасная хреновина задействующая распределенные вычисления и искуственный интеллект и чтобы всем и каждому не объяснять ничего, а тем более не заниматься переподготовкой кадров надо обмазаться безопасностью типа. А он такой наивный думает что политики и спецслужбы коллективного запада, и сэшэопии в особенности такие честные и неполживые братья по разуму с точно такими же как у программистов рациональными мозгами и целями, которые все и определяют. Во-первых обществу нужны кривые мозги, а от компа требуется безопасность и пока макаки пишут убогий код, который процессор оптимизирует для более-менее быстродействия можно говорить о безопасности в ущерб скорости.
Вон в интернете скрипты такие убогие, что топовый смартфон уже не вывозит и производителям пришлось ускорить средние модели до уровня топов прошлых лет, чего в их планы не входило вовсе.
> А просто в АНБ принято лгатьУ Страуструпа мнение по Расту отличается по АНБ, поэтому АНБ лжет?
> чтобы всем и каждому не объяснять ничего
Тут в pdf вообще-то на 6 страниц объяснено.
> а тем более не заниматься переподготовкой кадров
Как устроена работа у них внутри, и даже количество работников неизвестно, поэтому тем более не можем знать, как у них там с переподготовкой.
> обществу нужны кривые мозги
Подхожу к пешеходу, и спрашиваю «хотите, чтобы у вас мозг был кривым»? Бред же. Никто не хочет, чтобы были глупые как папуасы, ибо $$$ меньше. Даже КНР кучу денег дарит китайцам, чтобы учились в дорогих иностранных университетах (но с последующиим возвращаением в КНР).
>Даже КНР кучу денег дарит китайцам, чтобы учились в дорогих иностранных университетах (но с последующиим возвращаением в КНР).Так вот зачем КНР столько своих полицейских участков по всему миру! И понятно почему им помогают власти и полиция европейских государств - нет полицейских участков - нет оплаты со стороны КНР университетов в том государстве - нет дополнительного притока денег в экономику (ведь местные жители в большинстве своём дебилы с IQ < 115, что делает нерентабельным их обучение в ВУЗах, а китайцев много, на всю страну наберётся достаточно китайцев с достаточным IQ, чтобы насытить ими зарубежные вузы).
C++ действительно небезопасен. Элементарно передать в функцию ссылку на объект на стеке вызывающей функции - и вот вам use-after-free. Смарт-указатели от этого не спасут - они держат данные на куче, а куча - это медленно, никто не будет хранить каждую переменную на куче. Rust решает эту проблему - данные хранятся по-умолчанию на стеке, как в обычном C++, можно передавать ссылки, но borrow checker следит за тем, чтобы use-after-free не было. Я не знаю, как мы C++ и C без этого живём, наверное в нашем коде use-after-free на use-after-free.
> Элементарно передать в функцию ссылку на объект на стеке вызывающей функции - и вот вам use-after-free.И где там free, фантазёр?
>This temporary space is automatically freed when the function that called alloca() returns to its caller.
>Do not attempt to free(3) space allocated by alloca()!Читать умеешь?
пиши нормально, нормально прочтем
> Элементарно передать в функцию ссылку на объект на стеке вызывающей функцииПока мы внутри вызываемой функции, стек вызывающей все еще жив и никто его удалять не собирается. Так что твой пример надо дополнять, а то сейчас и thiscall как use-after-free
Если у тебя проблема - показывай свой недоисходник.
Только ты забыл написать что раст не решает проблему, а создаёт.
>Carbon Language is currently an experimental project. There is no working compiler or toolchain.
>Most of Carbon's design discussions occur on Discord.Смузихлёбы detected.
Там не только смузи, там ещё гендерная херня головного мозга креди команды разработчиков. Зашёл как то раз, посмотрел "бейджи" у цветных профилей, проблевался и вышел.
У раста также. Более того там такие в команде языка сидят.
Не нужно. Ждём релиза carbon и забываем про Си и с++.
Яп больше не нужны, нейронки будут сразу машинные коды писать
А зачем ваш карбон, если уже есть раст стабильный?
Чтобы было еще больше безопастности.
А давайте отменим python. С памятью у него, конечно, проблем нет. Но сколько же угроз безопасности создаёт eval как предпочтительный метод чтения конфигурационных файлов.
> Страуструп считает, что хороший статический анализатор, соответствующий рекомендациям C++ Core Guidelines, может обеспечить необходимые гарантии безопасности C++ кодаЭти языки и есть этот самый статический анализатор. Всяк кулик своё болото хвалит...
