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

Плюсы востребованы не сами по себе, а как язык, который де-факто является стандартом для разработки нативного софта.
Его учат в университетах, он всем знаком, он у всех на слуху, именно для плюсов написаны лучшие оптимизирующие компиляторы и огромное количество библиотек.
Кроме того, плюсы - язык широкого профиля. На нём одинаково можно писать как операционные системы, так и сервера или десктопный софт с UI.

Настолько широкопрофильный язык надо ещё поискать.
Однако, если сужать область применения, всегда найдётся узкоспециализированный язык, который подходит лучше. Например, Android -> Java, веб-сервера -> Go, железячный кодинг -> Rust и т.д.

 

на цппкон 2019 куча докладов про модули, неужели их наконец-то завезут в плюсы в стандарте 20ого года...

 

там всегда так было, - другое дело что в одном месте и дети и системные кодеры-реверсеры итд. вроде как тематика - гамесы, вроде несерьёзно, но зато какое исполнение - в своё время там можно было почерпнуть инфы поболее чем например тут.
с другой стороны - не исключаю что там какраз отчасти местные и релизили всякое. но давно.

 

так а шо по теме? пилиться будет или не?

 

да пейшу потихоньку, но это какбэ сказать - human-like (не для страуструпов, которые эти ++ пишут) трактование материалов cppreference, поскольку если чтото гдето непонятно, а там такого для неокрепшего ума немало, то порой разбираться надо именно с асм листингами, ну и вообщем весь этот матан (что где как когда) в разобраном виде объясняю.
пруф. вообщем всё это ещё и компилировать надо и с моего английского на нормальный английский переводить, да и писать еще много. а исправлять уже написанное - так примерно столько тоже.

 

Таки шо? Куда нажать, чтобы посмотреть сей труд?

 

Ежегодное явление снега народу еще не состоялось, наберись терпения.

 

самое забавное, что раст ФАКтически в разряде крипто с/с++, пч расово-чистых раст прожектов няма: все пользуют легаси либы/апи, то бишь надобно писать растой небезопасный код

 

Обычно первым делом пишут безопасные обёртки, а дальше поднимаются из ансейфа в безопасный код.
Или пишут на расте всё, как в RedoxOS, чтобы не тащить сишные библиотеки.

 

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

вечная альфа

 

Насчёт мёртвых ссылок - не уверен.
Например, положил в вектор объект, взял на него итератор, затем сделал clear() и обратился к итератору. Все плюсовые компиляторы такое съедят, раст - нет. PVS, может, и поймает такую ошибку, но хотелось бы ловить подобное в самом компиляторе.
Или несинхронизированный доступ к данным, разделённым между потоками: раст такое не скомпилит, в отличие от плюсов.

А от логических ошибок, ошибок железа и ошибок в ансейф коде и коде на других языках, про корректность которого раст не знает - да, раст не защитит. Ну что теперь, на расте из-за этого не писать? Хоть в каком-то месте у тебя будет больше гарантий, а это уже лучше, чем отсутствие гарантий везде.

 

а как раста узнает что у меня цель - МП код а не однопоточный?
зачем етот оверхед если цель именно 1 поток?

 

Если работаешь с std::thread - раст знает семантику этих функций и понимает, что это создание потока, и не даст внутри потока работать с данными без синхронизации или без передачи владения потоку.
А если будешь отдавать указатели напрямую в CreateThread - не узнает.

Хм, какой оверхед? Для однопоточных синхронизировать ничего и не надо: компилятор видит, что ты работаешь в одном потоке и гонок нет.

 

ОК, раста не знаю посему стало интересно на базе какого критерия он добавляет синхру
спс

 

такую возможность можно добавить в компиль любого яп-а.

синхру высчитывать в статике бесполезно == мало-мальски развитые коды используют динамические объекты. к примеру, проблема взаимной блокировки потоков является не менее животрепещущей, чем их забеги + доступ к одному и тому же объекту может происходить по разным ссылкам и механизм синхры такие обращения пропускает + нарушение доступа может получаться из-за хардварной ошибки (другими словами, система управления зачастую требует предельной гибкости). короче, для масштабируемых решений 99+% ошибок идут сугубо рантаймом.

что значит "отсутствие гарантий везде"??? все такие дураки и вот пришло ОНО, ржавое ведёрко - наш спаситель, аминь в том же хухле рвут на своих грудях халатик, молДе раста прям круть и дальше некуда, но (когда разговор переходит в бренные плоскости, про деньги) то весь оптимизм куда-то девается. не секрет, что раста прожекты ФАКтически все даже не за еду работают, а просто на уровне хобби (камлания о раста обёртках исключаем из числа сего).

 

Возьми и добавь это в компиль с++.

Авторитетное мнение человека, не имеющего никакого отношения к расту, подъехало...

 

кстати, а раста умеет из коробки решать проблема dead lock, white lock issues?

 

Пока ты работаешь в safe-парадигме, не работая с сырыми указателями, раст поймёт, что ты ссылаешься на один и тот же объект. В ансейфе тоже поймёт в большинстве случаев, но его можно обмануть (например, кастом "указатель -> число -> указатель").

Почему тогда мы не рассматриваем хардварные ошибки в применении к другим языкам? Как часто ты с ними сталкиваешься, что для тебя это проблема?
Так можно зайти далеко: тут у нас пролетел гамма-квант и переключил состояние мьютекса, там пролетело реликтовое излучение и 2 + 2 стало 5.
С таким подходом можно вообще софт не писать - всё равно корректно работать не будет

Вот вам и хобби-проект)

Из коробки не умеет. Но можно использовать сторонние крейты: NO_DEADLOCKS — Rust concurrency library // Lib.rs

 

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

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

ну, давай глянем..
ржавоё ведёрко, аууууу говоря по-простому, раст - это продукт хайпонавтики: сейчас публика рвёт у себя на грудях халатик за раст - завтра за хряст итд-итп..
https://www.analyticsinsight.net/go...hat-rust-cant-outperforming-c-in-programming/
экие редиски - пинают ржавое ведёрко, но с карбоном своя смеХАтура имеет место быть

 

Хм, а чем здесь должен помочь раст? Снова поднять сеть?

В расте тоже нет оверхеда, ты не платишь производительностью за безопасность, она даётся бесплатно.

А на что здесь смотреть? На то, что раст делит 0.01% рынка, си - 0.02, а плюсы - 0.16? При том, что раст в 6 раз моложе си и плюсов - это превосходный результат. Пройти за 8 лет путь от рождения до включения в ядро Linux - это уникальный случай.
Как бы тебе ни хотелось защищать свой любимый си, сообщество решило иначе. Больше не осталось ни одной причины начинать писать новый проект на си, когда его можно написать на чём угодно другом.
Единственное, что ещё держит этот язык на плаву - огромные горы старого кода, который необходимо поддерживать.