стоит ли запилить тему по с++

HoShiMin, сишечка почему в дровах приросла.. пч имеет мин оверхед в сравнение с чистым асмом, а плюсы из-за классов ещё тормознутей. ежли ж к расту вернуться, то он должен показать превосходство в скорости /цене отладки (иначе ж грош ему цена). но даже в этом случае основная часть публики будет ждать карбона в надежде бесшовно перейти на нечто новое

--- Сообщение объединено, 4 мар 2023 ---

есть протоколы тестов и наиболее вероятные ошибки являют себя практически сразу, а вынет душу али нет - это уже больше к Вопросу психической тренировки: в реале деньгу получают больше не те (кто лучше программирует жестянки), а те (кто лучше программирует окружающих)

 

Ладно, давай покажу кое-какую магию: https://godbolt.org/z/z87vj1d1q

 

:lol:

 

Ну вот о чем тут можно еще разговаривать? Спецы - такие спецы...

 

Код (Text):

1. #include <stdint.h>
2. #include <stddef.h>
3.  
4. int sum(const int nums[])
5. {
6.     int result = 0;
7.     for (int i = 1; i < nums[0]; i++)
8.     {
9.         result += nums[i];
10.     }
11.     return result;
12. }
13.  
14. int main()
15. {
16.     const int arr[6] = {6, 1, 2, 3, 4, 5 };
17.     return sum(arr);
18. }

--- Сообщение объединено, 4 мар 2023 ---

те же яйца, только в профиль

 

У спецов есть даже специальный термин для кодинга драйверов на бэйсике - снижение размерности т.е. преобразование данных, состоящее в уменьшении числа переменных путём получения главных(не всратых) переменных %)

 

А разница? Ассемблерного кода меньше не стало.
К сведению, раст тоже прошёл тест на адекватность: https://godbolt.org/z/aEYd4Yd9W

 

Об этом надо разговаривать только с теми, кто сами прошли тесты на адекватность))

Ну я не думаю, что ФриБасик является рассово-верным. Вроде эта штука пошла из линуксов изначально, хотя, может, и путаю что-то.

 

Я не спец по фрибейсику, но многие говорят что это тот же С только с бейсиковским синтаксисом.

 

Rust безусловно интересная штука. Я сам в нём ни бум-бум, но читал много обсуждений и как я понял всё прикольно, но чудовищный синтаксис и мозголомное программирование накидывающее +100 к сложности написания сложных программ.
Но оно оправданно.
Мне лично сразу же вспоминается идиома так сказать программирования с которой я сам на плюсах очень давно столкнулся - это банальная модификация контейнера.
Суть в том, что допустим в игре есть контейнер монстров и они каждый кадр проявляют какое то поведение - в том числе, например, определяют врага и нацеливаются на него и потом атакуют. И вот это вот запоминание это ссылка в монстре на другого монстра.
И вот тот монстр которого атакуют умирает и мы его из контейнера удаляем - но блин, если в том монстре который атаковал зависнет указатель на убитый объект, то о печаль и мрак - при попытке обратиться будет краш.
Как это порешать? Самый простой способ который я выработал - это флаг "сейчас будет удалён" в монстрах и целый проход по контейнеру монстров метода "проверь не собрался ли тот на кого ты ссылаешься умереть и если так, то обнули указатель".
Работает? Да. Источник трудноотлаживаемых проблем в реальном софте? Абсолютно.

Так вот - что делает Раст? Как я понял он просто на этапе компиляции принципиально пресекает попытки "наивной реализации" когда монстр удаляется из списка в тот же момент когда умирает (что и порождает вышеобозначенную проблему).
С этими всеми владениями и ссылочностями ты просто изначально вынужден писать код в подобной манере - сперва запомнить кого надо удалить, а потом удалять в корне игрового цикла где есть тот самый владетель списка монстров и уже нет никого кто на них ссылается временно.
Это с одной стороны ограничивает и бесит и превращает код в мишуру из всяких mut let & * ^, но сразу бьёт по пальцам школьной линейкой когда шаг влево-вправо может породить проблемы в коде типа плюснутого.

P.S.
(как правильно реализовать вышеописанную "идиому" на Rust я честно говоря даже не знаю, но читая обсуждения понял, что решение есть и оно для плюсов кособокое, но зато работает в расте)

 

Ну обычно такие проблемы решаются через счетчик ссылок (к примеру в COM), но и у него есть недостатки типа циклических ссылок (разруливается через слабые ссылки к примеру). С растом не сталкивался, но думаю у него решена эта проблема на уровне компилятора.

 

В последнее время вакантные места программистов захватывает мафия бывших студентов кулинарных техникумов со знанием турбопаскаля( импортозамещение во все поля !)

На Delphi и CBuilder написана целая российская SCADA-система и система программирования логических контроллеров, это вам не палец обоссать, и не ОВНОм воспользоваться.

В Интернетах уже стойко закрепилась ситуация, когда постоянно, буквально уже на третьем или четвертом посте в форумах (да и вообще где бы то ни было) какое нибудь юнное дарование нет-нет да и обязательно вставит свои пять копеек про то, что: на Delphi нет приличных вакансий в РФ, а то, что есть — платят гроши и заставляют допиливать старые задачи, сидя на коробках из-под мониторов перед ЭЛТ-мониторами в госучреждениях на Delphi никто не открывает новых проектов Delphi давно продан непонятно кому, и уже не развивается (ну… версии 2006, 2007, 2009, 2010, XE, XE2, XE3, XE4, XE5, XE6, XE7, XE8 уже не торты, само собой) вся команда из Borland ушла в Microsoft на Delphi можно только программировать мышкой, и ничего сложнее двух кнопок и поля ввода написать нельзя и тысячи, тысячи подобной ерунды.

И на самом деле юное дарование на 100% право, делфи — это удел старых пердунов с бородкой, которые сидят на сладком месте с какого нибудь 94-го в фирмочке и обслуживают свою супер-нетленку на каих нибудь делфи 3 + Интербэйс. А айти знаете ли за это время некисло так шагнул вперед и программисты должны решать совсем другие задачи, где делфи ВООБЩЕ нет места.

Lazarus для Free Pascal на деле оказывается далеко не кроссплатформенным (вы пробовали запускать и компилировать что-то на нем под маки? )

 

Я не спец по Басикам вообще и не могу судить. Я только собрал FreeBasic в 4кб экзешник без стандартных библиотек (конечно, многие команды, которые зависят от стандартных библиотек работать откажутся, но на чистом православном WinAPI писать как-то можно). Вопрос в том, что живых и развивающихся Басиков очень мало, а те, что есть уже настолько нишевые проекты (FreeBasic, PureBasic, Xojo, Gambas), что даже как-то обидно за них.

То, что ты описываешь, это - ECS (entity component system), насколько я понял, и да, в этой концепции многие игроделы ржавого критиковали, тк в эту концепцию borrow checker так себе вписывается, и многие даже пытаются читерить, вот например, в принципе вполне адекватная критика:

Проблема циклических ссылок толком ничем кроме GC не решить. Вопрос в том, когда и как сборщик мусора запускать. Например, касательно видео игр, некоторые господа вполне себе умудрялись запускать GC между кадрами, чтобы избежать каких-то неявных проблем с производительностью с ним связанных. Если такое решение возможно (вписать GC в архитектуру приложения), то ничего особо страшного в нем нет.

Ну у меня есть некое расстройство с тем, что Паскаль не особо развивается, как язык. Взять туже Аду как пример, которая прекрасно живет в своей нище из safety-critical приложений, хоть как-то развивается, стандарты новые собираются выпускать (последний был в 2012 году, скоро должен новый выйти по идее, если уже не вышел). Но Паскалисты почему-то прекрасно сидят на жопе ровно и их все устраивает. Я смотрел FreePascal, на первый взгляд неплохой компилятор, но в 2023 году как-то уже зашкварно писать на языке, который застрял далеко в прошлом, меня лично не устроили бесконечные begin-end'ы и точки с запятой в языке по поводу и без повода. Понятно, что во времена, когда Паскаль появился, парсеры языков программирования не были такими, как сейчас, и в этом была необходимость, но сейчас то зачем так страдать?))

--- Сообщение объединено, 4 мар 2023 ---

Пользуясь случаем, знает кто хороший кросс компилятор с венды на линуксы и маки? Я пробовал zig cc, кросскомпилировал цэ/плюсы и языки, которые в них компилируются (ним), вроде работает, но выглядит недоработаным. Вроде CodeTyphon (FreePascal) должен это уметь, но опять же я - паренек модненький: на паскалях писать не хочу. Какие еще варианты есть?

 

Смысл изучать что-то новое, когда тебе уже 35+ и ты не программер и не элитный спец, а нужно решить несложную задачу. Ставишь Delphi 6 или C++ Builder 5 или Visual Basic 6 на выбор. И за короткий срок решаешь задачу. Или обязательно надо ставить последнюю Visual Studio многогигабайтную и учить последний стандарт? Кстати, просьба к Rel написать короткий список того, что не надо учить в C++ старого стандарта, для человека, который пользуется C++ Builder 5 и только начинает изучать язык.

 

Так, это сложно. Мое мнение, что сейчас учить С++ не нужно. На практике большинство задач можно решить более простым языком. Тот С# или Петухон. Если прям нужен натив, то Раст, Ним, Дэ в зависимости от предпочтений и задач.

Если прям хочешь учить именно С++, то я бы советовал почитать https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines для начала, а потом еще https://github.com/Nekrolm/ubbook - в С++ можно относительно нормально жить, если вся команда понимает и следует ряду правил. Ну и да, если хочешь связать свою карьеру с С++, то искренне желаю тебе попасть на разработку новых проектов, а не поддержку легаси кода.

 

Кстати не видел TwinBasic? Позиционирует себя как полноценная замена Visual Basic 6 (COM ориентированность и т.п.), 64 бит компилятор. Даже мой драйвер на шестерке уже портировали под него.

Ну хз, мне на практике встречались случаи которые решались банальными слабыми ссылками. В том же COM, когда компонент имеет коллекцию суб-объектов, которые в свою очередь должны иметь свойство Parent. В суб-объекте храним слабую ссылку на родителя. Если родитель умирает в деструкторе пробегаемся по суб-объектам и обнуляем ссылку на родителя.

 

Не видел, выглядит интересно, но в 2023 году, когда весь мир использует бесплатные ЯП, писать такое как то зашкварно (боюсь, что как минимум из-за этого он будет популярен, как PureBasic):

Ну по сути GC так и работает, если не считать дополнительные фичи, типа "поколений".

 

Пурик хорош кросплатформенной библиотекой, но не могу привыкнуть к его синтаксису + с ООП там также "весело" как и в С.

 

вот именно!
баша за глаза на 90% хватает

 

То что я описал - это классическое программирование и я описал почему там возникают проблемы.
А ECS это как раз то к чему Rust просто принуждает потому что иначе невозможно. Ибо владелец контейнера монстров может кому то дать им попользоваться читая или даже записывая, но так чтобы к концу этого действа любые ссылки исчезли и теперь владелец контейнера может пройтись по списку и удалить лишнее. И не скомпилируется если куда то в коде уйдёт любая ссылка и не завершит своё существование к этому моменту. Очень всё жёстко и программу сразу с нулевых позиций надо планировать так чтобы эти требования соблюдать.

P.S.
А за Джонатана Блоу лайк сразу же. Имхо ярчайший гик.
P.P.S.
Он, кстати, в этом видео именно про это говорит - мол Раст просто заставляет тебя делать вещи так а не иначе, ибо иначе код не скомилируется, толкает в паттерны типа ECS, но его мысль как раз в том - верно ли это для всех случаев жизни и программирования?