Ишь ты, молодцы, всё правильно сделали.

нет исключений, хотя если сильно припрёт, то аналог на панике можно изобразить ... наследование ... Наверняка, рано или поздно в каком-то виде оно будет ... В любом случае, это не «непродуманность», а осознанное решение.

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

... а не так, чтобы добавляли разные костыли для разных частных случаев

Вообще то наследование, хотя бы на уровне расширения структур, очень распространённый полезный паттерн b это не какая-то фича на обочине языка чтобы её продумывание c реализацией откладывать на потом.

Я этого наелся вдоволь: на каждом (плюсовом) проекте своя ... «система сборки» (причём даже если это «почти стандартный» Cmake, то всё равно вокруг наверчено всякого проекто-специфичного) ...

Теперь осталось проанализировать свою жратву и подумать почему именно так всё происходит - т.е. действительно ли в мире не хватает 17-го стандарта инфраструктуры насаждаемого языком и действительно ли все предыдущие 16 не завоевали мир из-за отсутствия лобби со стороны комитетов стандартизации c/c++. Ещё можно пофантазировать на счёт развития этой инфраструктуры если учесть, что новые стандарты стабильных языков выходят на шкалах в десятки лет в отличие от компонент инфраструктуры.

Там нет однозначной «красной тряпки» на которую будут бросаться. Есть, конечно, очевидные вещи, но далеко не всё можно так выделить.

Подавляющее большинство проблемных мест выделить можно и уж точно можно залечить самые распространённые и эксплуатируемые ошибки связанные с переполнением буферов. А в таком виде около unsafe {} места становятся наравне с остальными классами ошибок по частотности.

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

Ты не понял вопроса. Впрочем, это само по себе является ответом.

Ты же себя опять ведёшь как баба. Неужели бабский паттерн поведения в тебя настолько въелся, что не получается с него просто соскочить даже когда он становится негативно заметен?

Ты же себя опять ведёшь как баба

Как скажешь, милый.

P.S. Отвечать не нужно, мы и так в оффтопике.

Чтобы беззаботно разрабатывать обычные приложения этого достаточно

Угу. Зачем бежать быстрее медведя, когда достаточно бежать быстрее конкурента.

Не важно что наше ПО ломают, главное чтобы его ломали не сильно чаще, чем у конкурента. В результате имеем то что имеем.

стилей разработки
наследование, исключения

Это не стили - это парадигмы. В С тоже нет наследования, и ничего, живут.

С++ мультипарадигмальный, да, но хорошо это, или плохо - большой вопрос.

В Rust радует то, что с самого начала прививают определенный стиль написания кода и форматирования, из-за чего все сорцы/api выглядят одинаково.

сам делает Box Rc Arc Mutex

auto auto(auto auto) { auto; }

то есть: загрузчик + ядро + все дрова + все системные библиотеки + весь прикладной код.

Ну это же ерунда. Да, уязвимость может быть на любом уровне, но так мы хотя бы за свой будем (более) спокойны.

Но это же и есть непродуманность (результат)

Нет, это эволюция и развитие. (:

Ну и я готов спорить, что «полноценных исключений из коробки» всё-таки не будет.

Вообще то наследование, хотя бы на уровне расширения структур, очень распространённый полезный паттерн

Не уверен. Как по мне, в расте вполне хватило бы чего-то типа alias this из D. Городить полноценное множественное наследование нафиг не надо. Ну и если по твоему это очень просто, то можешь изложить «в двух словах» как бы ты сделал. С учётом того как в расте трейты работают.

Теперь осталось проанализировать свою жратву

Выводы давно сделаны и выше я их озвучил. Странно, что это приходится повторять.

новые стандарты стабильных языков выходят на шкалах в десятки лет

Ну если за «языки» брать одну только нерасторопную джаву или делать акцент на банальное отсутствие развития в плюсах некоторое время назад, то да. Других примеров тоже хватает.

Так что фантазировать и остаётся.

Подавляющее большинство проблемных мест выделить можно

Как?

С++ мультипарадигмальный

Так ведь раст тоже. И как по мне, то это однозначно хорошо.

Не важно что ... главное чтобы ...

Не важно какую инфантильную галиматью писать на форумах, интернет всё стерпит, главное обозначить своё существование.

Это не стили - это парадигмы.

Исключения это не парадигдма, как и наследование структур по сравнению с композицией.

В Rust радует то, что с самого начала прививают определенный стиль...

Очень радостно, когда ЦА языка это кучка овощей которых нужно регулярно окучивать.

Нет, это не ерунда.

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

Без трастед компьютинг бэйс ценность раста примерно равна ценности вижуал бейсика.

Нет, авто это целых 4 лишних буквы.

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

То есть в эталонном случае лишних буков быть не должно, а если в коде появляется Mutex<T> или гипотетический SpinLock<T>, то это должно быть продиктовано необходимостью оптимизации кода, а не необходимостью его написания с целью удовлетворения хотелок создателей компилятора.

Rust - FOSS. Разрабы с радостью ждут ваших патчей.

Ну и если по твоему это очень просто, то можешь изложить «в двух словах» как бы ты сделал. С учётом того как в расте трейты работают.

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

Выводы давно сделаны и выше я их озвучил. Странно, что это приходится повторять.

Эти выводы больше похоже на первичную эмоцинальную реакцию, по типу как чиновники решают проблемы запретами проблемных явлений. Если анализ и был, то его результаты в этих выводах не прослеживаются.

Ну если за «языки» брать одну только нерасторопную джаву...

Причём тут ява, речь же о близких конкурентах, это плюсы и си. Да и с остальными языками дела обстоят схоже.

Трастед компьютинг недостаточно из-за возможности использования rowhammer attack. Только air gap и обыск на входе и выходе.

Как?

Заворачиванием в библиотеку или прослойку. Это что касается работы с памятью и синхронизации, в плюсах эффективно нельзя побороться разве что с UB в выражениях типа «i = ++i + i++» без помощи компилятора.

Инструмент разработки должен предоставлять программисту средства, а не заставлять писать тонны лишних буковок и кракозябр, которые компилятор в принципе может генерировать сам, [...].

Толсто (или глупо). Статический анализ не предназначен для чудесного вытаскивания замысла программиста из неаннотированного кода.

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

http://stackoverflow.com/questions/3970279/what-is-the-point-of-a-private-pur...

Статический анализ не предназначен для чудесного вытаскивания замысла программиста из неаннотированного кода.

Статический анализ, в данном случае, выявляет нарушение элементарных правил разработки.

У тебя компилятор требует завернуть структуру в мьютекс, если ссылка не нее попала в spawn?

А что, в таком случае, помешало компилятору просто поставить напротив этой структуры «флажок» Mutex?

Или у тебя есть офигительный замысел, который позволяет обойти необходимость в Mutex<T>?

Есть, конечно. Я мог хотеть переместить переменную в замыкание. Или на самом деле я хотел использовать scoped thread, в котором можно использовать ссылки. Или я хотел использовать Arc<Mutex<T>>. Или я хотел написать impl Sync for T {}.

Ну, думаю, понятно.

Я мог хотеть переместить переменную в замыкание.

Rust-специфичная фигня

Или на самом деле я хотел использовать scoped thread

Аналогично.

Или я хотел написать impl Sync for T {}.

Такая вещь должна анализироваться применительно с каждому вызову этой имплементации.

Кто мне тут вещал про полиморфизм, static/dynamic dispatch и про то, что Rust делает специализацию на каждый чих?

Или я хотел использовать Arc<Mutex<T>>

Arc должен приделывать компилятор, в случае если Rc используется в более чем одном треде.

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

Ага, конечно. И джава (например) не нужна - ведь там «глубоко под капотом» можно нативные части найти. А значит и ГЦ и «безопасность» ничего не стоят. Если увеличить градус бреда, то можно про закладки в железе порассуждать и прийти к выводy, что всё надо делать самому.

Ты, конечно, можешь доводить до абсурда и дальше, но это именно ерунда и получается.

из-за чего пришлось засунуть композицию во все щели

И чем это плохо?

Ну и с трейтами, как по мне, отлично получилось.

Если анализ и был, то его результаты в этих выводах не прослеживаются.

Скорее похоже, что кое-кто недостаточно по граблям находился, потому и брызжет максимализмом. Ну да ладно, это всё субъективно. Ты главное скажи чем тебе мешают тесты из коробки, если всё равно можно их игнорировать? Оверхеда тебе лично это никак не даст. Тогда в чём проблема? Просто побрюзжать?

Причём тут ява, речь же о близких конкурентах, это плюсы и си.

С - это такое дело, он вообще не особо развивается. А что плюсы? С тех пор как комитет из комы вышел успели два стандарта родить и ещё один на подходе.

Да и с остальными языками дела обстоят схоже.

Это с какими? С# - версии каждые 2-3 года выходят.

Заворачиванием в библиотеку или прослойку.

А... в этом плане.

Значит мы о разном говорим. Мой аргумент был о том, что если видим unsafe, то к коду стоит присмотреться повнимательнее. А в плюсах такого нет, ну или наоборот - слишком много.

Разумеется, написать библиотеку с безопасным интерфейсом можно. Но если кодовая база развивается активно, то могут быть нюансы. Скажем, у нас пошли на некоторые сомнительные компромиссы ради удобства иметь формальные проверки. А ещё некоторое время назад выяснилось, что самопальный скрипт контролирующий разные соглашения местами работал неправильно и естественно оказалось, что они нарушались. И через ревью это успешно прошло...

Да, раст от этого всего не спасёт, но польза от гарантированных проверок мне очевидна.

Rust-специфичная фигня

Почему? В плюсах тоже можно в лямбду перемещать.

Аналогично.

Нет. Плюсовый аналог: создать thread и позвать для него join.

Такая вещь должна анализироваться применительно с каждому вызову этой имплементации.

Как это? А если вызов единственный?

Arc должен приделывать компилятор, в случае если Rc используется в более чем одном треде.

А если это библиотека, например? Или если решение об использовании потоков происходит в рантайме?

Пожалуй, я даже соглашусь с тем, что раст местами более многословный чем мог бы быть и выигрышем является исключительно «явность», которая почему-то так мила многим. С другой стороны, про «неявность» тоже многие ноют и в общем случае непонятно что лучше.

Почему? В плюсах тоже можно в лямбду перемещать.

Очень может быть, хотя кресты тоже не нужны.

Нет. Плюсовый аналог: создать thread и позвать для него join.

Прямого то нет. Немедленно? Зачем?

Как это? А если вызов единственный?

Погоди...

Я правильно понимаю, что типаж Sync пустой, то есть это тупо способ сказать компилятору, что ссылку на нечто можно безопасно передавать между тредами?

Ну тогда это особый случай, и его надо обозначить явно, правда зачем так многословно?

А если это библиотека, например?

Если статическая, то хранить ее в промежуточном представлении, и делать специализации...

Если динамическая... Это уже интересней... Можно в «заголовке» экзешника указывать, какие специализации нужны, и JIT-ить библиотеку в соответствии с этой информацией из промежуточного представления, например (вот это я дотнетчик, однако).

Или если решение об использовании потоков происходит в рантайме?

Если есть вызов spawn - заворачивать в мьютекс/другой механизм синхронизации и не волнует (да это не всегда оптимально).

Ещё можно явно требовать какие типы нужны для работы с динамической библиотекой.

тонны лишних буковок и кракозябр, которые компилятор в принципе может генерировать сам

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

начал писать.. и слижком уж много написал впечатлений, не удалять же )

Если книга хорошая - то, имхо, можно и сразу с ++ начинать, ибо обычно стандартом в таких книжках идёт полный ввод в Си. А потом уже в Си++. Могу порекомендовать Подбельскую для начала - очень академичный стиль изложения.. такой точный, научный, но в книге очень много ошибок, но это даже, т.к. ошибки не фундаментальные - а скорее более похожие на опечатки, ну или ляпы.

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

А вот книжку Страуструпа я сначала не мог осилить т.к. мало опыта было, а теперь осилить могу но уж больно скучна по сравнению с Мейерсом тем же, хотя иногда может быть хорошим справочником, но кстати и весьма не полным, т.к. язык то развивается..

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

Ну и самое забавное, до начала изучения ++ я занимался Си. Промышленно. Обожал этот язык.. (кстати позволял себе ругать ++ совершенно их не зная, а просто прочитав в одной книжке «исскуство программирования для Unix» - то что Си++ избыточен, некомпактен и за это его критикуют - ну и тоже стал критиковать ) - кстати советую эту книжку, она кстати филосовская а не программисткая - но очень полезная кстати.. правда я отрывами её читал, но в будущем планирую полностью...

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

Иными словами открываем код ядра линукса - да там есть куча математики, да там есть много чего. Но блин как же это скучно.. А вот берем http://ru.cppreference.com/w/ или любую программу именно на Си++ - это просто кайф читать этот язык (изучать)

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

Интересно то что Си++ строился с «обратной совместимостью с Си» - но именно это и послужило тому что язык с одним из самых долгих временем входа в него, и более того не всякий даже мегагуру знает Си++ полностью..

Более того Си++ преподносит самим его разработчикам неожиданные сюрпризы (положительные) о которых по началу они даже не подозревали. Например шаблоны - изначально служили простой цели - отделить алгоритм от типов, а потом разработчики «открыли» именно открыли а не создали намеренно ныне очень активно развивающуюся концепцию вычислений во время компилирования - об этом хорошо у Мейерса в 48-м совете его 3-й книги )

А самый кайф когда открываешь исходники gcc и смотришь как это всё реализовано, смотришь тот же оператор new delete - видишь что они работают на старом добром сишном malloc. free

В общем это крайне интересно - и вот еще для затравки ) http://www.drdobbs.com/cpp/microbenchmarking-c-c-and-java/184401976 - вообще не понимаю людей которые выбирают шарп и джаву ( возможно за простоту вхождения, но мне как-то душевно стремно было бы выбрать легкий путь и потом кичится надежностью сборщика мусора, зато курить в сторонке по быстродействию кода, к тому же концепция RAII и владения ресурсами умных указателей- просто убивает(имхо) всю их сборку мусора.

В общем, имхо, можно начинать с любой хорошей книге по азам Си++ - ибо там обязательно охватится и Си.. Хотя это лишь моё предположение - т.к. кроме Подбельской я не читал книг для новичков. Далее уже можно читать книги для продвинутого уровня (или среднего наверное правильнее сказать) - это Мейерс. Еще Лафорте рекомендуют - не смотрел пока.

Начинать обучение надо с правильных языков, как Pascal или Java. А то приучишься говнокодить, и все.

Очень может быть, хотя кресты тоже не нужны.

Но тем не менее, это не специфичнo именно для раста.

Прямого то нет.

Как сказать. Есть scoped_thread в бусте, например.

правда зачем так многословно?

И как же надо?

и JIT-ить библиотеку в соответствии с этой информацией из промежуточного представления

Можно. Но не в расте. Аналогично с «не всегда оптимально и не волнует». Мне хоть «борьба за явность» не всегда по вкусу, но в таких случаях предпочту чтобы компилятор указал на проблемы, а правильный способ решения уже сам выберу в зависимости от обстоятельств.