Re: С++ всё? Rust навсегда?
От: Мирный герцог Ниоткуда  
Дата: 15.06.20 10:14
Оценка: 8 (3) +12
Здравствуйте, varenikAA, Вы писали:

AA>Тут правда сразу подумал, а как там с вебом? rocket

AA>Глаз задергался от необходимости так детализировать логику веба.

это уже нцатая серебряная пуля на моей памяти, необходимо один раз и навсегда понять, что качество софта в гораздо (порядок/порядки) большей степени зависит от квалификации инженеров и менеджеров, нежели от инструмента. Профессионалы высокого класса могут и на Си (без классов) написать стабильный и безопасный код, обложившись линтерами, тестами, код-ревью и в целом обладая культурой разработки, а если дуракам дать половой орган стеклянный, вы сами знаете что произойдёт. Буквально месяц назад один крупный банк искал (а может всё ещё ищет) разработчиков на C++ чтобы переписать (подчёркиваю — переписать) то глючное и тормозное угрёбище, которое наворотили до этого нанятые хипстеры на расте. О чём это говорит? О том что раст — говно? Нет, это говорит о том что хочешь качество — плати нормальные бабки и нанимай нормальных разработчиков. Нормально делай — нормально будет.
нормально делай — нормально будет
Re: С++ всё? Rust навсегда?
От: SomeOne_TT  
Дата: 15.06.20 13:37
Оценка: +1 -3 :))
Здравствуйте, varenikAA, Вы писали:

AA>Собственно вопрос в теме. Навеяло предыдущими обсуждениями.

AA>Кто-то сбросил недавно ссылку Microsoft: Rust является 'лучшим шансом' в отрасли программирования безопасных систем

Плюсы нравятся, но они кошмарны. Чем раньше их закопают, тем лучше будет для всех. Жаль, только, никто их не закопает, как и фортран.
Re: С++ всё? Rust навсегда?
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.06.20 14:20
Оценка: +3 -3
Здравствуйте, varenikAA, Вы писали:

AA>Собственно вопрос в теме. Навеяло предыдущими обсуждениями.

AA>Кто-то сбросил недавно ссылку Microsoft: Rust является 'лучшим шансом' в отрасли программирования безопасных систем

Я уже два десятилетия вижу такой аргумент.

«C++ не является безопасным для памяти языком и никто не притворялся бы, что это не так»


Во-первых, C/C++ буквально созданы чтобы управлять памятью. Во-вторых, этот аргумент уже настолько надоел, что не могут придумать абсолютно ничего нового. Что думаете посадите своих программистов на Rust или C#, который рекламировали точно так же, и всё у вас будет в шоколаде.

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

Один из подходов, который давно используется, состоит в том, чтобы больше обучать программистов написанию более безопасного кода. Но «нет никаких доказательств того, что комплексное обучение разработчиков на C и C++ действительно решит эту проблему любым существенным способом»


Очень наивно, я могу на любом языке программирования написать отвратительную программу с кучей глюков. "Нет никаких доказательств того, что один и тот же программист налажав на C/C++ не налажает на других языках программирования".

Когда Бьерн Страуструп рекламировал C++ он говорил, что одно из его основных достоинств прямое управление памятью. И тут я, например, спрашиваю, какое преимущество у Rust? А мне в ответ C++ небезопасен, потому что позволяет управлять памятью. Нет, постойте ка, какое преимущества у Rust, я не хочу слышать про C++, говорите про Rust. Что там нельзя управлять памятью и это преимущество?

Ну, вы знаете, наши программисты пишут лажовый код, мы хотим попробовать Rust в надежде на то, что они перестанут писать лажовый код. А Microsoft известна своими программистами. Они может поэтому и переписывают свой .NET каждый раз, потому что проще переписать с нуля, чем поддерживать и развивать старую версию.
Re[2]: С++ всё? Rust навсегда?
От: smeeld  
Дата: 15.06.20 15:15
Оценка: -5
Здравствуйте, velkin, Вы писали:

V>Во-первых, C/C++ буквально созданы чтобы управлять памятью.


Чистый Cи и Cи c классами созданы чтоб управлять памятью. В новомодном раскошерном C++ это пытаются запретить и исключить, взамен навязывая какие-то кошмарные костыли.
Re: С++ всё? Rust навсегда?
От: vsb Казахстан  
Дата: 17.06.20 08:40
Оценка: +1 :)))
Думаю да, у Rust есть все шансы стать последним ЯП, сложно придумать что-то лучше.
Re[5]: С++ всё? Rust навсегда?
От: alex_public  
Дата: 20.06.20 00:41
Оценка: +2 :))
Здравствуйте, Lexey, Вы писали:

V>>Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования.

L>Увы, нет.

Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективные (там где в C++ будет просто сравнение двух чисел, в языках без шаблонов будет вызов виртуальной функции (или его аналог) со всеми печальными последствиями).

Хотя первый вариант может иметь смысл в определённых специфических случаях (типа ассемблера в MKL), но обычно оно в итоге всё равно оформлено в виде C/C++ библиотеки. )))


V>>Но мы опять ушли с темы. Люди обычно не пытаются доказать, что C# или какой-нибудь Rust круты. Они всё время начинают с того чтобы обругать лидера. Это позиция слабого, к тому же аргументы ложны по своей сути. Именно об том и был мой комментарий выше.

L>Какого лидера? C++ уже давно не лидер, а весьма нишевый язык.


Любой язык нишевый. Нет ни одного языка, который претендовал был на лидерство в любой области. У каждого языка есть область, в которой его применение имеет смысл. Но при этом он может быть в ней лидером (как C/C++ в свой или Питон в своей или Жабка в своей), а может и не быть (например C# и Ruby не повезло иметь более сильных конкурентов в своей нише).

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


P.S. Давно не был на этом форуме. Вот сейчас решил вечерком заглянуть, проведать как тут дела... А тут практически ничего не изменилось. )))
С++ всё? Rust навсегда?
От: varenikAA  
Дата: 15.06.20 09:31
Оценка: +1 :))
Собственно вопрос в теме. Навеяло предыдущими обсуждениями.
Кто-то сбросил недавно ссылку Microsoft: Rust является 'лучшим шансом' в отрасли программирования безопасных систем

Тут правда сразу подумал, а как там с вебом? rocket
Глаз задергался от необходимости так детализировать логику веба.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[2]: С++ всё? Rust навсегда?
От: varenikAA  
Дата: 15.06.20 15:43
Оценка: +3
Здравствуйте, velkin, Вы писали:

V>Очень наивно, я могу на любом языке программирования написать отвратительную программу с кучей глюков. "Нет никаких доказательств того, что один и тот же программист налажав на C/C++ не налажает на других языках программирования".


Ну, на том же F#, если не использовать внешние dll, чистый код не сможет вызвать BSOD даже если вы второй день пишете на F#.
Да и на D такое сложно, ибо изначально проверка типов, особенно длины/границ массивов. Кажется в rust тоже проверка типов сильная.
Писали год назад один плагин для шифрования потока на плюсах, это конечно тихий ужас, настройка окружения одна чего стоит.
Зато сетевой поток сразу обрабатывается без лишних преобразований. Это с одной стороны круто. С другой, ушло много времени на отладку.
И все равно производительности для обработки видео с камеры 640x480 не хватало. Дефолтовый плагин шифровал через виндовый RSA, наш через CryptoPro.
У С++ слишком богатый синтаксис с неоднозначной семантикой. По моему скромному опыту.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[2]: С++ всё? Rust навсегда?
От: L.K. Марс  
Дата: 17.06.20 09:46
Оценка: +3
МГ>в гораздо (порядок/порядки) большей степени зависит от квалификации инженеров и менеджеров, нежели от инструмента. Профессионалы высокого класса могут и на Си (без классов) написать стабильный и безопасный код, обложившись линтерами, тестами

Тут дело такое. Армия стрельцов с ружьями непременно разгромит противостоящую ей армию профессиональных лучников. Даже при равной дальности эффективной стрельбы и при равной убойной силе стрелы и пули.

Потому что армию стрельцов (массовую армию) можно обучить за пару недель ("сыплешь туда порох, засовываешь пулю, поджигаешь фитиль, целишься"). А для стрельбы из лука нужна многолетняя каждодневная тренировка. Т.е. профессиональных лучников будет мало.
Re[6]: С++ всё? Rust навсегда?
От: lpd Черногория  
Дата: 20.06.20 09:34
Оценка: -3
Здравствуйте, alex_public, Вы писали:

_>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективны


Можно подумать у программистов других проблем нет, чем возиться с шаблонами ради 2% скорости программы. Тут по сети по десятки и сотни миллисекунд пакеты идут, а ты страдаешь из-за шаблонов. У нас не 1980 г. когда пытались все оптимизировать. Скоро в браузере будет все работать и требовать 128 ядер для чата, а ты все оптимизируешь универсальные алгоритмы.
Такая оптимизация — не более чем предпочтение определенного типа программистов, а не реальная необходимость. Не говоря уже о том, что способов оптимизировать каждую программу обычно много и без шаблонов.

_>(там где в C++ будет просто сравнение двух чисел, в языках без шаблонов будет вызов виртуальной функции (или его аналог) со всеми печальными последствиями).


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

L>>Какого лидера? C++ уже давно не лидер, а весьма нишевый язык.

_>Любой язык нишевый.
Такие тезисы нужно доказывать. А если это невозможно(так и есть), то не разбрасываться ими.
До Java, у С++ была гораздо более широкая область применения чем сейчас. И это разумно, т.к. никто не хочет возиться ни с delete, ни с weak_pointer<...>. Плюс инструменты для разработки на java проще, легче отлаживать.
Но вы будете до упора оптимизировать шаблоны С++, пока он не останется в нише языка для универсального сравнения интов и флоатов.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Отредактировано 20.06.2020 10:00 lpd . Предыдущая версия . Еще …
Отредактировано 20.06.2020 9:37 lpd . Предыдущая версия .
Отредактировано 20.06.2020 9:35 lpd . Предыдущая версия .
Отредактировано 20.06.2020 9:34 lpd . Предыдущая версия .
Re[2]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 15.06.20 10:40
Оценка: +2
Здравствуйте, Мирный герцог, Вы писали:

МГ>это уже нцатая серебряная пуля на моей памяти, необходимо один раз и навсегда понять, что качество софта в гораздо (порядок/порядки) большей степени зависит от квалификации инженеров и менеджеров, нежели от инструмента.


А я уже энцатый месяц трахаюсь с проектом, в котором надо постоянно проводить операции над графом, при этом не нарушая инварианты, некоторые из которых очень трудно сформулировать. И 99% возникающих ошибок у меня — логические, а вовсе не из-за нарушения логики владения чем-то там.
Re[2]: С++ всё? Rust навсегда?
От: reversecode google
Дата: 15.06.20 13:43
Оценка: +2
переменный ток опасен
если его запретят использовать, жить станет безопасней
Re[9]: С++ всё? Rust навсегда?
От: Мирный герцог Ниоткуда  
Дата: 18.06.20 11:34
Оценка: +2
Здравствуйте, L.K., Вы писали:

LK>Ну так физическое превосходство — у боксёра. Но хлюпик боксёра повалит — за счёт технического превосходства.


опять вас несёт в далёкие дали. Давайте вернёмся на исходную позицию. К чему вы начали разговор о лучниках, толпах и прочем, если это вообще (подчёркиваю — вообще) не применимо в контексте инженерной разработки? Вам не понятно что толпа бездарей принципиально не справится с тем, что сделает один квалифицированный человек? (и речь о профессиональной деятельности, а не о том кто кому лещей надаёт, если что). Если вам этот момент понятен (о принципиальной невозможности инженерной разработки чего угодно неквалифицированной толпой), то о чём мы вообще спорим?
нормально делай — нормально будет
Re: С++ всё? Rust навсегда?
От: dsorokin Россия  
Дата: 18.06.20 14:02
Оценка: +2
Rust — один из самых красивых языков программирования, и что удивительно, код получается эффективным при исполнении, причем никакой сборки мусора. Раньше даже не поверил бы в такое
Re[4]: С++ всё? Rust навсегда?
От: AlexRK  
Дата: 18.06.20 15:33
Оценка: -2
Здравствуйте, vsb, Вы писали:

vsb>>>Думаю да, у Rust есть все шансы стать последним ЯП, сложно придумать что-то лучше.

ARK>>Ой, да ладно. В Rust полно кривизны и костылей.
vsb>Было бы интересно увидеть перечисление.

Перечисления у меня нет, но язык при поверхностном изучении оставил смешанное впечатление. Навскидку можно назвать корявые массивы с захардкоженным синтаксисом и ограничением на 32 элемента, странный баланс unsafe-фич (ведущий к ложному чувству безопасности), кучу ссылок и указателей (&, &mut, Rc, Arc, Box, *, const *, etc.), переусложненную систему модулей, дополнительный макроязык внутри основного языка... долго все вспоминать. Очень много мусора. Даже базовые фичи работают непоследовательно. Например, вот это компилируется: "if {33} > 1", а вот это нет: "if {{33} > 1}".
Re[8]: С++ всё? Rust навсегда?
От: L.K. Марс  
Дата: 18.06.20 18:14
Оценка: -1 :)
P>Лучник пока учится, пусть 10 лет, в чем я сильно сомневаюсь, все равно же службу несет

Не несёт он никакую службу. Потому что это 10-летний подросток, сын мелкого феодала, которого отправили в школу лучников.

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

Соответственно, лучники — это военная элита, это мизерный процент армии, и увеличить этот процент нельзя (точнее, можно, но очень-очень дорого).
Re[9]: С++ всё? Rust навсегда?
От: prog123 Европа  
Дата: 18.06.20 21:38
Оценка: +2
Здравствуйте, L.K., Вы писали:

P>>Лучник пока учится, пусть 10 лет, в чем я сильно сомневаюсь, все равно же службу несет

LK>Не несёт он никакую службу. Потому что это 10-летний подросток, сын мелкого феодала, которого отправили в школу лучников.
LK>А типичный крестьянин не может отправить никуда детей. Это стоит денег, да и дети нужны рядом, для помощи в крестьянском хозяйстве.
LK>Соответственно, лучники — это военная элита, это мизерный процент армии, и увеличить этот процент нельзя (точнее, можно, но очень-очень дорого).

А что мешает с++-нику писать на расте и даже на гоу? Вот у растистов и гоуистов писать на с++ далеко не сразу получится, лет через 5. А наоборот без проблем.
Порог вхождения в с++ высокий и с каждым новым стандартом повышается. Помимо старых костылей нужно учить новые фичи. Следовательно те кто уже имеет хороший опыт в с++ имеют преимущество, так как из-за высокого порога вхождения желающих входить немного и конкуренция ниже. Так что и с++ и с с++никами в ближайшие лет 10-20 все будет хорошо.
Re[11]: С++ всё? Rust навсегда?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 19.06.20 09:13
Оценка: +1 -1
Здравствуйте, Рома Мик, Вы писали:

РМ>Здравствуйте, prog123, Вы писали:


P>>Порог вхождения в с++ высокий и с каждым новым стандартом повышается. Помимо старых костылей нужно учить новые фичи. Следовательно те кто уже имеет хороший опыт в с++ имеют преимущество, так как из-за высокого порога вхождения желающих входить немного и конкуренция ниже. Так что и с++ и с с++никами в ближайшие лет 10-20 все будет хорошо.

РМ>Вообще-то как раз если так и есть, то c++ников будет становиться меньше, и у них самих-то все будет хорошо, но для языка — это медленная смерть.

Думаю что нет. Сейчас требуется гора C++-ников и новый народ с радостью учит язык и развивается. На деле же, куча фич и навык борьбы с костылями нужен единицам, а подавляющее большинство, под присмотром этих единиц, отлично делает свою работу. Инструментарий языка достаточно развит уже для такого.
Re[2]: С++ всё? Rust навсегда?
От: Ночной Смотрящий Россия  
Дата: 19.06.20 17:15
Оценка: +2
Здравствуйте, vsb, Вы писали:

vsb>Думаю да, у Rust есть все шансы стать последним ЯП, сложно придумать что-то лучше.


Детский сад, штаны на лямках.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: С++ всё? Rust навсегда?
От: alex_public  
Дата: 22.06.20 19:25
Оценка: +2
Здравствуйте, lpd, Вы писали:

_>>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективны

lpd>Можно подумать у программистов других проблем нет, чем возиться с шаблонами ради 2% скорости программы. Тут по сети по десятки и сотни миллисекунд пакеты идут, а ты страдаешь из-за шаблонов. У нас не 1980 г. когда пытались все оптимизировать. Скоро в браузере будет все работать и требовать 128 ядер для чата, а ты все оптимизируешь универсальные алгоритмы.
lpd>Такая оптимизация — не более чем предпочтение определенного типа программистов, а не реальная необходимость. Не говоря уже о том, что способов оптимизировать каждую программу обычно много и без шаблонов.

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

L>>>Какого лидера? C++ уже давно не лидер, а весьма нишевый язык.

_>>Любой язык нишевый.
lpd>Такие тезисы нужно доказывать. А если это невозможно(так и есть), то не разбрасываться ими.

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

lpd>Но вы будете до упора оптимизировать шаблоны С++, пока он не останется в нише языка для универсального сравнения интов и флоатов.


У C++ ниша не языка для сравнения интов, а ниша языка для написания инфраструктурного ПО. Ты вот прямо сейчас читаешь этот текст из браузера написанного на C++. ))) Более того, рантаймы всех остальных современных мейнстрим языков написаны на C++: JVM, CLR, CPython, V8 и т.д. Поэтому даже смешно говорить о сужение ниши C++ — она будет вечной основой всего IT мира.

Единственный сценарий, в котором C/C++ может перестать играть свою важнейшую роль в IT мире, это если появится такой же системный язык (достаточно низкоуровневый и быстродействующий), только удобнее. И вот как раз Rust претендует на эту роль. Но пока до реальных успехов ещё крайне далеко.
Re[13]: С++ всё? Rust навсегда?
От: chaotic-kotik  
Дата: 23.06.20 08:24
Оценка: +2
Здравствуйте, lpd, Вы писали:

lpd>Это ты уже сам написал. Оптимизировать программу добавлением сложных шаблонов(а некоторые еще и мув-семантику для этого везде лепят) совсем тупо. Нужно оптимизировать узкие места, алгоритм, выбирать соответствующие быстрые инструменты и архитектуру.


Проблема только в том, что без шаблонов и прочих фич языка, у тебя получится сложнее, могу на примере пояснить — допустим у нас есть серверное приложение с пуллом потоков (довольно типичное серверное решение), ты передаешь в тред пулл функторы и они там исполняются, тоже довольно типичное решение.

Простой подход a-la С++03 — пишешь абстрактный класс Functor и наследуешь от него свои функторы, получается плоская иерархия из десятков классов, классы простые, т.к. реализуют метод — operator().

проблема 1 — тебе приходится создавать все в куче, т.к. виртуальные вызовы и прочая хурма, а значит управление памятью это проблема
проблема 2 — в свои реализации функтора ты передаешь параметры и они должны туда копироваться, а их много при этом, часто один функтор запускает следующий функтор, а тот запускает еще один и параметры передаются по цепочке (типичный паттерн в асинхронном программировании (в том же boost.asio), когда ты обрабатываешь прочитанные данные в первом коллбэке, отправляешь ответ и когда ответ отправлен запускается другой коллбэк, в котором ты делаешь что-нибудь и запускаешь чтение, по окончании которого снова вызывается первый коллбэк, примерно как здесь — https://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/example/cpp03/echo/async_tcp_echo_server.cpp, только в этом примере в коллбэки передается мало параметров, т.к. это эхо сервер, а в каком-нибудь более сложном приложении в коллбэки могут передаваться объекты потолще)
проблема 3 — внезапно тебе потребовалась поддержка cancellation и для этого тебе нужно добавить еще один метод в твой базовый класс и реализовать его в куче разных реализаций

Сложный подход — пишем шаблон — template <classs ... Args> class Functor; Используем type erasure для параметра конструктора, чтобы туда можно было передавать и указатели на ф-ии и лямбды и обычные функторы.

решение 1 — можно сделать оптимизацию для случая, когда параметры занимают мало места и размещать из не в динамической памяти, а в самом объекте Functor. Упрвление памятью не проблема, т.к. функтор реализует value семантику.
решение 2 — используем move семантику для параметров.
решение 3 — можно добавить реализацию cancel в одном месте.

Это конечно сложнее в реализации, но это IMO упрощает код. Подход Си с классами проще на первый взгляд, но это выливается в сложности в дальнейшем.
Отредактировано 23.06.2020 8:27 chaotic-kotik . Предыдущая версия .
Re[15]: С++ всё? Rust навсегда?
От: alex_public  
Дата: 23.06.20 22:19
Оценка: +2
Здравствуйте, lpd, Вы писали:

lpd>Использовать move-семантику для оптимизации, особенно везде — это вообще дно. Оптимизировать нужно только узкие места программы. Передача аргументов не играет решающей роли в быстродействии. ЕСЛИ у тебя большие объекты копируются в критичном коде при легковесной обработке их, можно легко сделать только для них метод MoveObject(), а не перегружать язык новыми типами &&(имеющими только академический интерес) с запутанным синтаксисом.


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

И да, сама по себе семантика перемещения нужна в языке в первую очередь не ради оптимизации, а для возможности реализации полноценного RAII и соответствующего управления ресурсами. Без неё просто физически невозможно написать соответствующие умные указатели и т.п. Однако побочно её использование частенько приводит и к существенному (например в случае использования в проекте различных контейнеров) увеличению быстродействия. И я не вижу ни единой причины, почему надо от него отказываться.

lpd>Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес только для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения.


Что такое "возможности общего назначения"? )

lpd>И на Java/C# уже давно пишется гораздо больше.


Ну во-первых только на Java (см. например здесь https://madnight.github.io/githut/#/pull_requests/2020/1), а во-вторых если следовать этой логике, то и Java давно пора выбросить на свалку, заменив везде на JS (см. на тот же график).
Re[17]: С++ всё? Rust навсегда?
От: alex_public  
Дата: 26.06.20 12:58
Оценка: +2
Здравствуйте, lpd, Вы писали:

_>>Т.е. в реальности никакого усложнения или увеличения прикладного кода от использования семантики перемещения нет. И использовать её повсеместно более чем правильно.

lpd>Насчет увеличения количества кода не буду судить, т.к. мув семанитку не использовал.
lpd>Но усложнение есть и большое, т.к. она добавляет лишней информации в код новыми типами. Так что в этом вопросе ты субъективен, т.к. тебе эта мув-семантика нравится. А увеличение эффективности почти всегда пренебрежимо малое, поэтому повмевместно ее использовать близко к абсурду.

Ещё раз повторюсь: если у тебя был какой-то сложный тип с нетривиальным поведением, которое надо прописывать кодом, то это значит что до семантики перемещения он у тебя имел сложный оператор копирования, а с переходом на семантику перемещения этот оператор будет ЗАМЕНЁН таким же сложным оператором перемещения. И где у тебя тут добавление лишней информации?

_>>И да, сама по себе семантика перемещения нужна в языке в первую очередь не ради оптимизации, а для возможности реализации полноценного RAII и соответствующего управления ресурсами.

lpd>Я уже писал про RAII, что считаю это хаком.

Уууу ну тогда всё понятно, почему тебе не подходит C++... Ведь RAII — это считай его первооснова (так же как и у Rust) и одновременно главное отличие от почти всех остальных языков. Можно программировать на C++ например вообще без классов (в таком функциональном стиле, на замыканиях), но нельзя без RAII. Ну точнее формально говоря можно (это осталось ради совместимости с C), но тогда в языке не остаётся вообще никакого смысла. Это как использовать Rust только в одном глобальном блоке unsafe с одними голыми указателями.

lpd>Файл — это абстракция ОС, с которой работают через хэндл. А переменная — это абстракция языка программирования, и у этих двух абстракций общего ничего нет. Просто пользуются тем, что переменная когда-то удалится, но это хак.


Переменная вообще говоря никогда не "удалится". Обычно это просто выделенное на стеке место, которое возможно будет перезаписано (а возможно и нет) при возврате на предыдущий уровень стека вызовов. А вот понятие "область видимости переменной" является вполне однозначным и чётко определено наверное во все языках программирования. И я не вижу ничего не естественного в том, что при выходе из области видимости переменной, хранящей "файл", он закрывается.

lpd>Аналогично с памятью и умными указателями. Некоторый смысл есть в том, что деструкторы вызовутся по выходу из функции, но это тоже притянуто за уши. GC пользоваться проще, а умные указатели — это редко нужная полумера, и реализованная длиннословно. unique_ptr<>, если он тебе так нужен, можно встроить в язык, и будет удобнее. Вообще в языке нужны и GC и умные указатели с возможностью выбирать.


Таких языков вроде как нет. И сомневаюсь, что они нужны.

lpd>>>Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес только для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения.

_>>Что такое "возможности общего назначения"? )
lpd>Нужно делать язык более удобным и простым в использовании для создания приложений со сложной логикой, какие пишут сейчас на Java, а не пытаться сделать монстра.

А зачем? Чтобы на C++ хреновенько, но писался вообще весь код в мире? Мне кажется это как раз тупиковый путь. Лучше уж C++ будет хорошо решать задачи в своей ниши, Java хорошо в своей и т.д. Компромиссный универсальный язык — это не нужное зло.
Re[18]: С++ всё? Rust навсегда?
От: dsorokin Россия  
Дата: 28.06.20 05:46
Оценка: +2
Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, lpd, Вы писали:


_>>>Т.е. в реальности никакого усложнения или увеличения прикладного кода от использования семантики перемещения нет. И использовать её повсеместно более чем правильно.

lpd>>Насчет увеличения количества кода не буду судить, т.к. мув семанитку не использовал.
lpd>>Но усложнение есть и большое, т.к. она добавляет лишней информации в код новыми типами. Так что в этом вопросе ты субъективен, т.к. тебе эта мув-семантика нравится. А увеличение эффективности почти всегда пренебрежимо малое, поэтому повмевместно ее использовать близко к абсурду.

В контексте C++ семантику перемещения использовать сложнее, чем семантику копирования. В Rust — ровно наоборот. Там даже часто не задумываешься, как работает перемещение. Все настолько естественно происходит, и что интересно, нет практически никакого синтаксического шума.

Написал

fn f(x: X) { .. }


Потом вызвал

f(x)


У тебя объект x передается через "перемещение". Будет ли там побитовое копирование или нет, зависит от обстоятельств, но сама идея передачи объекта через семантику перемещения кристально проста.

С копированием сложнее. Там нужно было бы явно реализовать трейт (класс типов) Clone для X.

impl Clone for X {
  fn clone(&self) -> Self { .. }
}


Потом в коде нужно было бы написать

f(x.clone())


Это выглядит разумно. Создаем явный барьер для более дорогой с точки зрения эффективности исполнения операции копирования. Операция перемещения в Rust крайне дешева.

На самом деле, к проектированию языка Rust подошли очень взвешено. Может быть, лет через 30 Rust будет тоже выглядеть нелепо для будущего времени, но для настоящего он по дизайну на мой личный субъективный взгляд выглядит просто превосходно!
Отредактировано 28.06.2020 5:48 dsorokin . Предыдущая версия .
Re[7]: С++ всё? Rust навсегда?
От: FR  
Дата: 23.06.20 05:13
Оценка: 1 (1)
Здравствуйте, Lexey, Вы писали:

L>ИМХО, он попадает в одну из ниш C++, но не во все. В тот же embedded он вряд ли серьезно зайдет в ближайшем будущем.


Чисто технически он лучше подходит для embedded чем С++. У С++ слишком жирный рантайм который
нельзя отключить не лишившись RTTI и\или исключений.
У rust все отключается проще и много библиотек поддерживают no_std.
Но все конечно решает инфраструктура, которая у rust пока слишком бедная для этой ниши.
Re[17]: С++ всё? Rust навсегда?
От: AeroSun  
Дата: 23.06.20 13:37
Оценка: 1 (1)
Здравствуйте, T4r4sB, Вы писали:

TB>Так вот, а кому вообще сдалась сложная С++-ная мув-семантика?


Это попытка исправить родовую травму с++ — копирование по умолчанию.
Вот только копирование в 99% не нужно — по умолчанию нужна передача по ссылке (константной). В общем аналогично, как это сделано в С#.
Достаточно было изменить дефолтное поведение + стандартизировать оптимизации при возврате/передаче и всё это обернуть в параметры компилятора для нового/старого с++ и это была бы бомба.
Но это бы сломало уже написанные программы + комитет до усрачки боится перемен (либо кто-то там сознательно старается "прикопать" с++).
Потому имеем что имеем.
Re[6]: С++ всё? Rust навсегда?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 07.07.20 08:09
Оценка: 1 (1)
Здравствуйте, Erop, Вы писали:

E>Я просто не в курсе. На Расте уже есть написанная ОС например?


На Rust пишут Hash &mdash; платформу будущего.
Re: С++ всё? Rust навсегда?
От: Zhendos  
Дата: 15.06.20 10:50
Оценка: +1
Здравствуйте, varenikAA, Вы писали:

AA>Собственно вопрос в теме. Навеяло предыдущими обсуждениями.

AA>Кто-то сбросил недавно ссылку Microsoft: Rust является 'лучшим шансом' в отрасли программирования безопасных систем

AA>Тут правда сразу подумал, а как там с вебом? rocket

AA>Глаз задергался от необходимости так детализировать логику веба.

А в чем детализация? Напоминает python/flask:

@app.route('/', methods=["GET"])
def index():
    pass


Но наличие flask ведь никак не мешает существованию других framework
для python/web ?
Re[3]: С++ всё? Rust навсегда?
От: Zhendos  
Дата: 15.06.20 15:58
Оценка: +1
Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, Zhendos, Вы писали:


AA>
AA>#![feature(proc_macro_hygiene, decl_macro)]

AA>#[macro_use] extern crate rocket;

AA>#[get("/")]
AA>fn index() -> &'static str {
AA>    "Hello, world!"
AA>}

AA>fn main() {
AA>    rocket::ignite().mount("/", routes![index]).launch();
AA>}
AA>


И что с этим кодом не так? Количество строчек плюс-минус
столько же сколько в flask, да выглядит код практически точно также,
функция из одной строчки, аннотация это функции и однастрочная
"запускалка". В общем все стандартно, может на python будет на пару строчек
больше, а на ruby/sinatra на пару строк меньше, но в чем отличие и минус Rust?
Re: С++ всё? Rust навсегда?
От: LuciferSaratov Россия  
Дата: 16.06.20 21:12
Оценка: +1
Здравствуйте, varenikAA, Вы писали:

раст, вроде бы, хорош, но нужен не один десяток лет, чтобы он стал реальной альтернативой C++/C.
на C++ и C, при всех недостатках этих языков, написано слишком много хорошего софта, который проще всего переиспользовать, разрабатывая новую систему на C++/C.

я пытался прикинуть, куда раст приткнуть в моей сфере — в игровой разработке.
его преимущества в играх были бы как нельзя кстати.
но получилось, что, в общем-то, пока никуда, а жаль.
Re[10]: С++ всё? Rust навсегда?
От: Слава  
Дата: 18.06.20 22:21
Оценка: +1
Здравствуйте, prog123, Вы писали:

P>А что мешает с++-нику писать на расте и даже на гоу? Вот у растистов и гоуистов писать на с++ далеко не сразу получится, лет через 5. А наоборот без проблем.


Ничто не мешает, кроме религии. И вот с религией-то сделать мало что возможно, как мы видим по этому треду.
Re[4]: С++ всё? Rust навсегда?
От: smeeld  
Дата: 19.06.20 14:37
Оценка: -1
Здравствуйте, AlexRK, Вы писали:

ARK>Любое можно же сделать, нет?


Подозреваю, что в понимании того товарища управление паматью-это не когда "любое можно сделать", а когда "ничего делать нельзя", кроме расставления xxx_ptr костылей, что и называется, видимо, управлением памятью.
Re[7]: С++ всё? Rust навсегда?
От: Ночной Смотрящий Россия  
Дата: 19.06.20 17:00
Оценка: +1
Здравствуйте, L.K., Вы писали:

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


Крайне важный в контексте программирования факт!
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: С++ всё? Rust навсегда?
От: vsb Казахстан  
Дата: 19.06.20 21:56
Оценка: :)
Здравствуйте, Lexey, Вы писали:

ARK>>Любое можно же сделать, нет?


L>Ну и как ты будешь тот же вектор на C делать (чтобы он автоматом память освобождал при выходе из скоупа)?


{
    struct myvector *v = NULL;
    ....
    v = myvector_allocate(...);
    if (v == NULL) {
        goto end;
    }
    ...
end:
    if (v != NULL) {
        myvector_deallocate(v);
    }
}


автоматизм достигается аккуратным программированием.
Отредактировано 19.06.2020 21:58 vsb . Предыдущая версия . Еще …
Отредактировано 19.06.2020 21:57 vsb . Предыдущая версия .
Отредактировано 19.06.2020 21:57 vsb . Предыдущая версия .
Re[5]: С++ всё? Rust навсегда?
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 19.06.20 22:30
Оценка: +1
Здравствуйте, Lexey, Вы писали:

V>>Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования.

L>Увы, нет.

И какой тогда язык программирования лидирует? Дело ведь не в том, что мне есть какое-то дело кто и на чём программирует. Просто все аргументы против я вижу как ложные. Например в C++ предыдущих стандартов не встроена работа с параллельными потоками исполнения, формально это правда, а по факту это ложь, так как эту проблему решает компилятор и сторонние библиотеки. Я могу сказать даже более, C++ стандарта ISO/IEC 14882:2003 более чем достаточно для самого изощрённого современного программирования.

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

Потому простой переход Rust не сделает из программиста профи. Нравится C#, ну так пожалуйста, я не против. Но вот так откровенно дурить головы людям, что C#, Rust или ещё что превосходят C/C++, да ещё и по библиотекам алгоритмов. Ну, ну. Особенно мне нравится бездоказательность этих утверждений.
Re[6]: С++ всё? Rust навсегда?
От: Lexey Россия  
Дата: 20.06.20 23:30
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>
vsb>{
vsb>    struct myvector *v = NULL;
vsb>    ....
vsb>    v = myvector_allocate(...);
vsb>    if (v == NULL) {
vsb>        goto end;
vsb>    }
vsb>    ...
vsb>end:
vsb>    if (v != NULL) {
vsb>        myvector_deallocate(v);
vsb>    }
vsb>}
vsb>


Не решает озвученную задачу.

vsb>автоматизм достигается аккуратным программированием.


Не достигается.
"Будь достоин победы" (c) 8th Wizard's rule.
Re[5]: С++ всё? Rust навсегда?
От: prog123 Европа  
Дата: 21.06.20 08:05
Оценка: +1
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, AlexRK, Вы писали:
ARK>>Любое можно же сделать, нет?
L>Ну и как ты будешь тот же вектор на C делать (чтобы он автоматом память освобождал при выходе из скоупа)?

#include <stdio.h>
#include <stdlib.h>

#define SCOPE(TYPE, NAME, ...) \
  {                            \
    ctor_##TYPE(NAME);         \
    __VA_ARGS__                \
    dtor_##TYPE(NAME);         \
  }                            \
  (void)0

typedef struct {
  int n;
} MyClass;

void ctor_MyClass(MyClass** this) {
  *this = malloc(sizeof(MyClass));
  printf("MyClass::ctor, (this-> %p)\n", (void*)*this);
}

void dtor_MyClass(MyClass** this) {
  printf("MyClass::dtor, (this-> %p)\n", (void*)*this);
  free(*this);
}

int main(int argc, char* argv[]) {
  MyClass* my_class_obj;

  SCOPE(MyClass, &my_class_obj, 
    (*my_class_obj).n = 16;
    printf("(*my_class_obj).p = %d\n", (*my_class_obj).n);
  );

  return 0;
}

MyClass::ctor, (this-> 0x7f0260)
(*my_class_obj).p = 16
MyClass::dtor, (this-> 0x7f0260)


Насколько я знаю, некоторые JVM написаны на С/С++, а следовательно GC также написаны на нем. Так что ничего удивительного, что даже на C можно написать менеджеры памяти разной степени автоматизации.
Re[6]: С++ всё? Rust навсегда?
От: Lexey Россия  
Дата: 21.06.20 23:46
Оценка: +1
Здравствуйте, prog123, Вы писали:

P> SCOPE(MyClass, &my_class_obj,

P> (*my_class_obj).n = 16;
P> printf("(*my_class_obj).p = %d\n", (*my_class_obj).n);
P> );

Это все замечательно, только вот, как насчет возможности делать return из произвольных мест кода, который в макрос засовывается?

P>Насколько я знаю, некоторые JVM написаны на С/С++, а следовательно GC также написаны на нем. Так что ничего удивительного, что даже на C можно написать менеджеры памяти разной степени автоматизации.


Эти менеджеры не доступны конечному пользователю в C/C++ (точнее, что-то доступно через тот же JNI, но это еще хуже, чем просто C).
"Будь достоин победы" (c) 8th Wizard's rule.
Re[7]: С++ всё? Rust навсегда?
От: Sheridan Россия  
Дата: 22.06.20 06:23
Оценка: +1
Здравствуйте, lpd, Вы писали:

lpd>Можно подумать у программистов других проблем нет, чем возиться с шаблонами ради 2% скорости программы. Тут по сети по десятки и сотни миллисекунд пакеты идут, а ты страдаешь из-за шаблонов. У нас не 1980 г. когда пытались все оптимизировать.


Надеюсь, в аду есть специальные котлы...
Matrix has you...
Re[8]: С++ всё? Rust навсегда?
От: pagid Россия  
Дата: 22.06.20 06:28
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

S>Надеюсь, в аду есть специальные котлы...

Для нежелающих ускорять программу на 2% за счет её усложнения? Вряд ли
Re[11]: С++ всё? Rust навсегда?
От: Sheridan Россия  
Дата: 22.06.20 14:05
Оценка: -1
Здравствуйте, pagid, Вы писали:

S>>И да, некоторым всегда сложно оптимизировать (странно, почему? )) ) и поэтому они называют этот процесс "усложнением".

P>Потому как предыдущий оратор говорил о использовании шаблонов, как усложнении, и задал именно эту оценку полезности — ускорение на 2%
Давай сразу уж не про шаблоны а про разработку проца и не про 2% а про 0.00002%
Ну чтобы даже тупому мне было понятно что овчинка не стоит выделки и вообще поэтому оптимизировать никогда не надо и вдобавок бизнес не платит.

P>И да, изначально, разговор насколько понял, не о том, использовать ли шаблоны и этим упростить и немного ускорить программу, а о том стоит ли усложнять язык (включая компилятор, библиотеки и проч.) ради этих 2%

Да, безусловно.
А дальше каждый сам за себя считает — будет ли ему сложно или нет.
Matrix has you...
Re[13]: С++ всё? Rust навсегда?
От: Sheridan Россия  
Дата: 22.06.20 14:28
Оценка: :)
Здравствуйте, lpd, Вы писали:

lpd>...шаблонов...

lpd>...шаблонов...
lpd>...шаблоны...

Ну не умеете в шаблоны — делайте по другому
Matrix has you...
Re[8]: С++ всё? Rust навсегда?
От: lpd Черногория  
Дата: 23.06.20 11:33
Оценка: :)
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, lpd, Вы писали:


lpd>>Можно подумать у программистов других проблем нет, чем возиться с шаблонами ради 2% скорости программы.


TB>Двух процентов, лол, правда?

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

А ты измерял, сравнивал? Я думаю в большинстве случаев меньше 2% будет в сумме, даже если ты все классы сделаешь шаблонными и rvalue.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Отредактировано 23.06.2020 11:34 lpd . Предыдущая версия .
Re[21]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 23.06.20 15:18
Оценка: :)
Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, T4r4sB, Вы писали:


TB>>Сложный. Вместо realloc приходится разбирать несколько случаев: у объектов есть ноексептнутый кастомный мув, у объектов запрещён кастомный мув, у объектов есть ексептнутый кастомный мув, итд.


CK>какая связь между realloc и move семантикой в Rust?


В Rust можно тупо вызвать realloc для вектора любый объектов, в C++ нельзя.
Re[27]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 23.06.20 20:52
Оценка: +1
Здравствуйте, chaotic-kotik, Вы писали:

CK>все, я понял что ты называешь realloc совсем не тоже самое что я, я думал про сишный realloc, который делает совсем другое


Я про сишный и говорю. Он может переместить буфер. Для С++-объекта это проблема. Для Раст-объекта — нет. В чём непонятки-то?

CK>вообще, по хорошему тебе ничего не нужно перегружать, если ты пишешь кастомные T(T&&) и operator = (T&&) то ты что-то делаешь не так скорее всего


Это всего лишь значит, что я пишу объект, управляющий ресурсом. В С++03 надо было перегрузить 4 хрени: T(), T(T&), =(T&), ~T(). В ++20 я боюсь их считать.
На деле из них большая часть лишние. Всего-то надо было добавить требование тривиальной реллоцируемости.
Re[28]: С++ всё? Rust навсегда?
От: alex_public  
Дата: 24.06.20 01:18
Оценка: +1
Здравствуйте, T4r4sB, Вы писали:

TB>Я про сишный и говорю. Он может переместить буфер. Для С++-объекта это проблема. Для Раст-объекта — нет. В чём непонятки-то?


Ну вообще говоря оба языка системные и соответственно оба позволяют что угодно. Это я в том смысле, что и в Rust'е ты можешь с помощью unsafe создать любые ссылки самого на себя и т.п. )

TB>Это всего лишь значит, что я пишу объект, управляющий ресурсом. В С++03 надо было перегрузить 4 хрени: T(), T(T&), =(T&), ~T(). В ++20 я боюсь их считать.

TB>На деле из них большая часть лишние. Всего-то надо было добавить требование тривиальной реллоцируемости.

Если мы говорим об объекте управляющем ресурсами, то при использование семантики перемещения тебе надо будет не добавить новый оператор, а заменить старый, т.к. оператор копирования скорее всего станет запрещённым.

Дополнительные перегрузки появляются в основном у всяких универсальных контейнеров (позволяющих грузить в себя данные множеством разных способов). Но такие вещи живут в первую очередь в базовых библиотеках, а не в прикладном коде.
Re[19]: С++ всё? Rust навсегда?
От: AeroSun  
Дата: 25.06.20 15:53
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>И как это позволит написать например unique_ptr? )


А у него много вариантов реализаций?
Не? Тогда просто добавить ключевой значок в язык
Re[5]: С++ всё? Rust навсегда?
От: Erop Россия  
Дата: 07.07.20 07:11
Оценка: +1
Здравствуйте, L.K., Вы писали:

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


Есть ОЧЕНЬ много задач, где язык не первая, не вторая и даже не десятая по сложности часть необходимой квалификации
Но есть, конечно и бесконечно больше задач, где главная проблема -- освоить инструмент. Для второй области С++/С не годится, для первой часто приемлем, а иногда и почти безальтернативен...

p. s.
Я просто не в курсе. На Расте уже есть написанная ОС например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: С++ всё? Rust навсегда?
От: Erop Россия  
Дата: 07.07.20 07:25
Оценка: +1
Здравствуйте, varenikAA, Вы писали:

AA>У С++ слишком богатый синтаксис с неоднозначной семантикой. По моему скромному опыту.

По моему опыту, судить о С++ по скромному опыту бессмысленно. Это примерно, как критиковать боб для бобслея или там космический корабль, по опыту вождения "Мерседеса"...
С++ -- чудовищно мощная штука, и применять её надо тока там, где менее мощные и более удобные почему-то не канают
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: С++ всё? Rust навсегда?
От: Erop Россия  
Дата: 07.07.20 11:29
Оценка: :)
Здравствуйте, Lexey, Вы писали:

L>Какое в C управление памятью, кроме стековых и статических переменных и убогих malloc/free (и их аналогов)? В плюсах, да, уже гораздо лучше.

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

L>Да уже давно придумана куча других аргументов. Например, убогая стандартная библиотека,

Да и фиг бы с ней. Лучше бы STL вообще не было
Крупные конторы любят свои фреймворки. А мелким и так С++ с высоким шибко порогом

L>отсутствие модулей (да, планируют завести, но еще хрен знает когда), отсутствие современных асинхронных примитивов (корутины в 20-м обещают, но только кастрированные), отсутствие рефлексии, ...

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

L>В этом плане язык лет на 10 отстал от того же C#.

Это просто другие задачи.
В С++ и так напихали кучу всего. Зачем из него ещё и эрланг делать?

L>Все не будет, но те же проезды по памяти в шарпе практически невозможны. И падения по NPE и прочим исключениям дебажатся в разы проще, чем в плюсах.

Проезды по памяти в современном С++ большая редкость и быстро ловятся.
Лично у меня крайний проезд случался год назад и на питоне + opencv, а не на С++

L>Нужно, конечно. Но в большинстве случаев хватает базовых знаний о том, как он работает.

В большинстве случаем всем просто наплевать на дикую по меркам С++ степень фрагментации.

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

Да не могут. Голые сишные указатели в современных плюсах употребляют крайне редко. Всё обкладывают шаблонами с отключаемыми проверками

L>По идее, там нельзя делать с памятью небезопасные вещи. И это, конечно, преимущество.

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


L>Э... когда это Microsoft переписывала .NET (кроме Core, который, очевидно, невозможно было сделать без частичного переписывания)?

Ну тогда и переписала
Твой оппонент немного утрирует, конечно, но в целом есть здравое зерно в его рассуждениях.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: С++ всё? Rust навсегда?
От: Lexey Россия  
Дата: 07.07.20 22:18
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Проезды по памяти в современном С++ большая редкость и быстро ловятся.


Проблема в том, что в реальной жизни у тебя будет процентов 20 кода на современном C++ и еще 80 на менее современном (а местами и просто на C с классами).

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

E>Да не могут. Голые сишные указатели в современных плюсах употребляют крайне редко. Всё обкладывают шаблонами с отключаемыми проверками

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

L>>По идее, там нельзя делать с памятью небезопасные вещи. И это, конечно, преимущество.

E>Обычно это самообман, а не преимущество. Ошибки вида "работа с невалидным указателем" давно научились ловить. Часто статическим анализом.

Вот только, они все равно вылезают в более-менее сложном коде.

E>И выработали практики, которые делают такие ошибки очень редкими.


Редкими — да, но не невозможными. Например, получить разадресацию пустого unique_ptr из-за какой-нибудь гонки в асинхронном коде более чем реально. И проявляться такая ошибка может крайне редко. При этом процесс может просто упасть и даже креш-дампа не оставить. И гадай после этого, почему оно упало.

E>Обычно такие проблемы начинаются при сложных каких-то взаимодействиях или при оптимизации.


Так никто и не говорил, что речь про простые вещи.
"Будь достоин победы" (c) 8th Wizard's rule.
Re[2]: С++ всё? Rust навсегда?
От: varenikAA  
Дата: 15.06.20 15:32
Оценка:
Здравствуйте, Zhendos, Вы писали:

Z>Здравствуйте, varenikAA, Вы писали:


AA>>Собственно вопрос в теме. Навеяло предыдущими обсуждениями.

AA>>Кто-то сбросил недавно ссылку Microsoft: Rust является 'лучшим шансом' в отрасли программирования безопасных систем

AA>>Тут правда сразу подумал, а как там с вебом? rocket

AA>>Глаз задергался от необходимости так детализировать логику веба.

Z>А в чем детализация? Напоминает python/flask:


Z>
Z>@app.route('/', methods=["GET"])
Z>def index():
Z>    pass
Z>


Z>Но наличие flask ведь никак не мешает существованию других framework

Z>для python/web ?


#![feature(proc_macro_hygiene, decl_macro)]

#[macro_use] extern crate rocket;

#[get("/")]
fn index() -> &'static str {
    "Hello, world!"
}

fn main() {
    rocket::ignite().mount("/", routes![index]).launch();
}
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[3]: С++ всё? Rust навсегда?
От: alexzzzz  
Дата: 16.06.20 11:48
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>Ну, на том же F#, если не использовать внешние dll, чистый код не сможет вызвать BSOD даже если вы второй день пишете на F#.


BSOD вообще трудно вызвать, если нет аппаратных проблем и ты не пишешь драйвер. Уронить процесс в Access Violation на C# без unsafe и DllImport, я думаю, что смогу. Если можно на C#, скорее всего, на F# тоже можно. Правда это будет не случайность, а целенаправленное действие, которое ещё надо знать как провернуть.
Re[3]: С++ всё? Rust навсегда?
От: vdimas Россия  
Дата: 16.06.20 20:49
Оценка:
Здравствуйте, T4r4sB, Вы писали:

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


Отбрасывай, сокращай, ограничивай.
Чем больше ограничений, тем проще система.
Re[2]: С++ всё? Rust навсегда?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 17.06.20 09:08
Оценка:
Здравствуйте, LuciferSaratov, Вы писали:

LS>я пытался прикинуть, куда раст приткнуть в моей сфере — в игровой разработке.

LS>его преимущества в играх были бы как нельзя кстати.

Ты видел какой они код пишут???

Когда я работал в Автодеске, в соседнем от нас здании сидел Ubisoft Singapore и их разработчики к нам часто приходили на собеседования. Такого кошмарного подхода к разработке как в играх вообще нигде нет, как мне кажется. Язык где надо очень много думать над структурой твоего кода и всячески ублажать borrow checker в коммерческих и успешных играх не взлетит. Там мало того, что надо по максимуму минимизировать фрагментацию памяти, пусть и в ущерб поддерживаемости решения, так еще и сделать все вчера, а лучше неделю назад.
Re[3]: С++ всё? Rust навсегда?
От: LuciferSaratov Россия  
Дата: 17.06.20 09:18
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Ты видел какой они код пишут???


в среднем по больнице, наверное, всё так и есть.
но я вижу также, что есть и ответственные люди в этой сфере и вполне уверен, что преимущества Rust были бы ценны.
в работе попадался совершенно разный код, есть и очень хорошие примеры, явно сделанные опытными людьми.
Re[3]: С++ всё? Rust навсегда?
От: Ops Россия  
Дата: 18.06.20 10:07
Оценка:
Здравствуйте, L.K., Вы писали:

LK>Потому что армию стрельцов (массовую армию) можно обучить за пару недель ("сыплешь туда порох, засовываешь пулю, поджигаешь фитиль, целишься"). А для стрельбы из лука нужна многолетняя каждодневная тренировка. Т.е. профессиональных лучников будет мало.


Так битва не насмерть. И когда лучники научатся, они начнут убивать стрельцов еще на этапе насыпания пороха.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[4]: С++ всё? Rust навсегда?
От: L.K. Марс  
Дата: 18.06.20 10:30
Оценка:
Ops>Так битва не насмерть. И когда лучники научатся, они начнут убивать стрельцов еще на этапе насыпания пороха.

Я же говорю: квалифицированных лучников будет мало. Это дорогой юнит.

А против неё будет толпа вчерашних крестьян, наскоро обученных стрелять из ружей. И эта толпа задавит лучников числом.
Re[5]: С++ всё? Rust навсегда?
От: Мирный герцог Ниоткуда  
Дата: 18.06.20 11:01
Оценка:
Здравствуйте, L.K., Вы писали:

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


к выбору аналогий надо подходить осторожно. Для меня очевидно, что никаким "числом" нельзя решить сложные инженерные задачи, т.к. когда речь идёт о качестве решения кумулятивный эффект не работает, рулит только интеллект и опыт. Моя встречная аналогия такова — какой бы великой не была армия идиотов, они принципиально не смогут сделать то, что сможет сделать один умный человек (изобрести, спроектировать). Совсем просто говоря — армия любителей никогда не переиграет гроссмейстера, всмысле — вообще никогда. Уровень принципиально не тот.
нормально делай — нормально будет
Re[6]: С++ всё? Rust навсегда?
От: L.K. Марс  
Дата: 18.06.20 11:13
Оценка:
МГ>какой бы великой не была армия идиотов, они принципиально не смогут сделать то, что сможет сделать один умный человек

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

Или, скажем, к.м.с. по боксу встретиться с хлюпиком, вооружённым шокером. Боксёр тренировался 10 лет каждый день, а хлюпик учился обращаться с шокером 10 минут. Но в большинстве случаев победит хлюпик.
Re[7]: С++ всё? Rust навсегда?
От: Мирный герцог Ниоткуда  
Дата: 18.06.20 11:23
Оценка:
Здравствуйте, L.K., Вы писали:

я вроде достаточно прозрачно написал, что не все аналогии уместны, но вы всё продолжаете и продолжаете. Речь же идёт не о физическом превосходстве, а об интеллектуальном, что непонятного?
нормально делай — нормально будет
Re[8]: С++ всё? Rust навсегда?
От: L.K. Марс  
Дата: 18.06.20 11:26
Оценка:
МГ>не о физическом превосходстве, а об интеллектуальном, что непонятного?

Ну так физическое превосходство — у боксёра. Но хлюпик боксёра повалит — за счёт технического превосходства.
Re[5]: С++ всё? Rust навсегда?
От: pagid Россия  
Дата: 18.06.20 14:38
Оценка:
Здравствуйте, L.K., Вы писали:

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

Это только если предполагать, что ружьё стоило примерно столько же сколько и вилы.
Re[2]: С++ всё? Rust навсегда?
От: AlexRK  
Дата: 18.06.20 15:08
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Думаю да, у Rust есть все шансы стать последним ЯП, сложно придумать что-то лучше.


Ой, да ладно. В Rust полно кривизны и костылей.
Re[3]: С++ всё? Rust навсегда?
От: vsb Казахстан  
Дата: 18.06.20 15:15
Оценка:
Здравствуйте, AlexRK, Вы писали:

vsb>>Думаю да, у Rust есть все шансы стать последним ЯП, сложно придумать что-то лучше.


ARK>Ой, да ладно. В Rust полно кривизны и костылей.


Было бы интересно увидеть перечисление.
Re[6]: С++ всё? Rust навсегда?
От: L.K. Марс  
Дата: 18.06.20 17:09
Оценка:
P>Это только если предполагать, что ружьё стоило примерно столько же сколько и вилы.

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

В пересчёте на штуку и в переводе на время, ружьё делается ну за неделю максимум (это вместе с добычей руды и выплавкой железа). А лучник готовится 10 лет.
Re[7]: С++ всё? Rust навсегда?
От: pagid Россия  
Дата: 18.06.20 17:20
Оценка:
Здравствуйте, L.K., Вы писали:

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

Лучник пока учится, пусть 10 лет, в чем я сильно сомневаюсь, все равно же службу несет, какие-никакие, но постоянный армии наверно и тогда были?
Re[2]: С++ всё? Rust навсегда?
От: Lexey Россия  
Дата: 18.06.20 23:55
Оценка:
Здравствуйте, velkin, Вы писали:

V>Во-первых, C/C++ буквально созданы чтобы управлять памятью.


Какое в C управление памятью, кроме стековых и статических переменных и убогих malloc/free (и их аналогов)? В плюсах, да, уже гораздо лучше.

V>Во-вторых, этот аргумент уже настолько надоел, что не могут придумать абсолютно ничего нового.


Да уже давно придумана куча других аргументов. Например, убогая стандартная библиотека, отсутствие модулей (да, планируют завести, но еще хрен знает когда), отсутствие современных асинхронных примитивов (корутины в 20-м обещают, но только кастрированные), отсутствие рефлексии, ...
В этом плане язык лет на 10 отстал от того же C#.

V>Что думаете посадите своих программистов на Rust или C#, который рекламировали точно так же, и всё у вас будет в шоколаде.


Все не будет, но те же проезды по памяти в шарпе практически невозможны. И падения по NPE и прочим исключениям дебажатся в разы проще, чем в плюсах.

V>У меня логика такая, если памятью не управляют напрямую, значит это делает сборщик мусора. Это ещё одна концепция, которой нужно учиться. Не хотите учиться? Ну тогда будете писать тормознутые программы с чудовищным перерасходом памяти.


Нужно, конечно. Но в большинстве случаев хватает базовых знаний о том, как он работает.

V>Очень наивно, я могу на любом языке программирования написать отвратительную программу с кучей глюков. "Нет никаких доказательств того, что один и тот же программист налажав на C/C++ не налажает на других языках программирования".


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

V>Когда Бьерн Страуструп рекламировал C++ он говорил, что одно из его основных достоинств прямое управление памятью. И тут я, например, спрашиваю, какое преимущество у Rust? А мне в ответ C++ небезопасен, потому что позволяет управлять памятью. Нет, постойте ка, какое преимущества у Rust, я не хочу слышать про C++, говорите про Rust. Что там нельзя управлять памятью и это преимущество?


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

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


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

V>А Microsoft известна своими программистами. Они может поэтому и переписывают свой .NET каждый раз, потому что проще переписать с нуля, чем поддерживать и развивать старую версию.


Э... когда это Microsoft переписывала .NET (кроме Core, который, очевидно, невозможно было сделать без частичного переписывания)?
"Будь достоин победы" (c) 8th Wizard's rule.
Re[3]: С++ всё? Rust навсегда?
От: AlexRK  
Дата: 19.06.20 07:28
Оценка:
Здравствуйте, Lexey, Вы писали:

L>Какое в C управление памятью, кроме стековых и статических переменных и убогих malloc/free (и их аналогов)?


Любое можно же сделать, нет?
Re[10]: С++ всё? Rust навсегда?
От: Рома Мик Россия http://romamik.com
Дата: 19.06.20 08:59
Оценка:
Здравствуйте, prog123, Вы писали:

P>Порог вхождения в с++ высокий и с каждым новым стандартом повышается. Помимо старых костылей нужно учить новые фичи. Следовательно те кто уже имеет хороший опыт в с++ имеют преимущество, так как из-за высокого порога вхождения желающих входить немного и конкуренция ниже. Так что и с++ и с с++никами в ближайшие лет 10-20 все будет хорошо.

Вообще-то как раз если так и есть, то c++ников будет становиться меньше, и у них самих-то все будет хорошо, но для языка — это медленная смерть.
Re[3]: С++ всё? Rust навсегда?
От: Artifact  
Дата: 19.06.20 12:02
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, velkin, Вы писали:


AA>И все равно производительности для обработки видео с камеры 640x480 не хватало. Дефолтовый плагин шифровал через виндовый RSA, наш через CryptoPro.


Вот это здесь к чему? Это по-вашему вина С++? И вообще сейчас большинство процессоров содержат инструкции по аппаратному AES, SHA шифрованию, и работает всё со свистом.
__________________________________
Не ври себе.
Re: С++ всё? Rust навсегда?
От: Эйнсток Файр Мухосранск Странный реагент
Дата: 19.06.20 14:04
Оценка:
https://www.linux.org.ru/forum/development/15766724?cid=15767332

набросок сценария: kirk_johnson попадает в 1980-й год в тело ребенка сохранив все свои знания. И к началу 90-х выпускает компилятор раста и ОС kirkuх целиком на расте c системд и вейландом. Микрософт разоряется, а наш герой становится самым богатым и известным человеком на планете, изобретает социальные сети, смартфоны, финансирует полеты на Марс. А в 2020 предотвращает эпидемию коронавируса.

Re[3]: С++ всё? Rust навсегда?
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 19.06.20 15:10
Оценка:
Здравствуйте, Lexey, Вы писали:

L>Да уже давно придумана куча других аргументов. Например, убогая стандартная библиотека, отсутствие модулей (да, планируют завести, но еще хрен знает когда), отсутствие современных асинхронных примитивов (корутины в 20-м обещают, но только кастрированные), отсутствие рефлексии, ...

L>В этом плане язык лет на 10 отстал от того же C#.

Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования. Таким аргументом про стандартную библиотеку можно подловить разве что новичка. Для примера, можно взять Qt, вот и аналог .NET плюс рефлексия, плагины и прочее. Для любителей обобщённого программирования есть boost.

Я, кстати, тоже могу приводить такие смешные аргументы. В C++ есть множественное наследование, а в C# нет, только интерфейсы и это преимущество. Причём некоторые утверждают такое на полном серьёзе. То есть против C++ часто аргументы в стиле слишком много возможностей, нам столько не нужно.

Но как уже сказал, не нужно путать язык программирования и библиотеки программирования. То что добирается сторонними библиотеками лично я сразу отбрасываю как преимущество. И ещё раз повторю, ни один язык программирования не сравнится с C++ по функциональным возможностям сторонних библиотек.

Но мы опять ушли с темы. Люди обычно не пытаются доказать, что C# или какой-нибудь Rust круты. Они всё время начинают с того чтобы обругать лидера. Это позиция слабого, к тому же аргументы ложны по своей сути. Именно об том и был мой комментарий выше.
Re[4]: С++ всё? Rust навсегда?
От: Ночной Смотрящий Россия  
Дата: 19.06.20 17:01
Оценка:
Здравствуйте, velkin, Вы писали:

V>Но мы опять ушли с темы. Люди обычно не пытаются доказать, что C# или какой-нибудь Rust круты. Они всё время начинают с того чтобы обругать лидера.


Ага, вот например: .net всё, C++ навсегда?
Автор: varenikAA
Дата: 11.06.20
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: С++ всё? Rust навсегда?
От: Lexey Россия  
Дата: 19.06.20 21:38
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Любое можно же сделать, нет?


Ну и как ты будешь тот же вектор на C делать (чтобы он автоматом память освобождал при выходе из скоупа)?
"Будь достоин победы" (c) 8th Wizard's rule.
Re[4]: С++ всё? Rust навсегда?
От: Lexey Россия  
Дата: 19.06.20 21:54
Оценка:
Здравствуйте, velkin, Вы писали:

V>Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования.


Увы, нет.

V>Таким аргументом про стандартную библиотеку можно подловить разве что новичка. Для примера, можно взять Qt, вот и аналог .NET плюс рефлексия, плагины и прочее. Для любителей обобщённого программирования есть boost.


Речь про стандартные библиотеки, с не про тяжелые сторонние фреймворки/библиотеки, использования которых в крупных проектах часто просто запрещено.

V>Я, кстати, тоже могу приводить такие смешные аргументы. В C++ есть множественное наследование, а в C# нет, только интерфейсы и это преимущество. Причём некоторые утверждают такое на полном серьёзе. То есть против C++ часто аргументы в стиле слишком много возможностей, нам столько не нужно.


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

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


Голый язык без библиотек практически никому не нужен, так что, никакой путаницы тут нет.

V>То что добирается сторонними библиотеками лично я сразу отбрасываю как преимущество. И ещё раз повторю, ни один язык программирования не сравнится с C++ по функциональным возможностям сторонних библиотек.


Оно не добирается, вот в чем проблема.

V>Но мы опять ушли с темы. Люди обычно не пытаются доказать, что C# или какой-нибудь Rust круты. Они всё время начинают с того чтобы обругать лидера. Это позиция слабого, к тому же аргументы ложны по своей сути. Именно об том и был мой комментарий выше.


Какого лидера? C++ уже давно не лидер, а весьма нишевый язык.
"Будь достоин победы" (c) 8th Wizard's rule.
Отредактировано 20.06.2020 23:28 Lexey . Предыдущая версия .
Re[6]: С++ всё? Rust навсегда?
От: dsorokin Россия  
Дата: 20.06.20 04:16
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективные (там где в C++ будет просто сравнение двух чисел, в языках без шаблонов будет вызов виртуальной функции (или его аналог) со всеми печальными последствиями).


Здесь выбор отвечающих этому требованию языков небольшой: C++, Rust, Ada. Может быть, есть еще что-то?

Динамический диспатчинг, впрочем, также интересен на основе vtable. Кстати говоря, в Rust тоже это есть.
Re[6]: С++ всё? Rust навсегда?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.06.20 07:59
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Lexey, Вы писали:


V>>>Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования.

L>>Увы, нет.

_>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективные (там где в C++ будет просто сравнение двух чисел, в языках без шаблонов будет вызов виртуальной функции (или его аналог) со всеми печальными последствиями).

В этой ветке как раз обсуждают аналог шаблонов на C# с переопределением операторов
http://rsdn.org/forum/dotnet/7749568.flat
Автор: varenikAA
Дата: 08.06.20


Ну и надо не забывать о девиртуализации и онлайнинге существующих компиляторов
и солнце б утром не вставало, когда бы не было меня
Re[6]: С++ всё? Rust навсегда?
От: Lexey Россия  
Дата: 20.06.20 23:47
Оценка:
Здравствуйте, velkin, Вы писали:

V>И какой тогда язык программирования лидирует?


Глобального лидера нет. В разных областях лидеры разные.

V>Дело ведь не в том, что мне есть какое-то дело кто и на чём программирует. Просто все аргументы против я вижу как ложные. Например в C++ предыдущих стандартов не встроена работа с параллельными потоками исполнения, формально это правда, а по факту это ложь, так как эту проблему решает компилятор и сторонние библиотеки.


Подобные решения подходит далеко не всем.

V>Я могу сказать даже более, C++ стандарта ISO/IEC 14882:2003 более чем достаточно для самого изощрённого современного программирования.


А зачем тогда все то новое, что будет в 20-м и далее?

V>Пока новички будут гоняться за "новейшими" разработками профи будут выбирать всё те же C/C++.


Какие-такие "профи"? Профи стараются выбирать тот инструмент, на котором задача лучше решается. И для многих задач плюсы являются плохим выбором.

V>Тот же аллокатор памяти в C++, его можно заменить. Лично я вообще не сторонник конкретных языков программирования, и считаю, что программа должна быть от них независима, и что процесс преобразования программы в код это кодирование и закодировать программу можно на многих языках.


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

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


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

V>Потому простой переход Rust не сделает из программиста профи. Нравится C#, ну так пожалуйста, я не против. Но вот так откровенно дурить головы людям, что C#, Rust или ещё что превосходят C/C++, да ещё и по библиотекам алгоритмов. Ну, ну. Особенно мне нравится бездоказательность этих утверждений.


Тут я прочитал невнимательно (упустил слово "алгоритмов"). Да, насчет алгоритмов можно согласиться, наверное.
За Rust топить не могу, ибо видел его только краем глаза. А вот C# в определенных областях плюсы превосходит.
"Будь достоин победы" (c) 8th Wizard's rule.
Отредактировано 20.06.2020 23:49 Lexey . Предыдущая версия .
Re[6]: С++ всё? Rust навсегда?
От: Lexey Россия  
Дата: 20.06.20 23:58
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...).


Тут мой косяк. Прочитал фразу по диагонали.

_>Любой язык нишевый. Нет ни одного языка, который претендовал был на лидерство в любой области. У каждого языка есть область, в которой его применение имеет смысл. Но при этом он может быть в ней лидером (как C/C++ в свой или Питон в своей или Жабка в своей), а может и не быть (например C# и Ruby не повезло иметь более сильных конкурентов в своей нише).


Собственно, я и хотел сказать, что никакого единого лидера нет. В разных нишах лидеры разные.

_>Rust полностью попадает в нишу C/C++ и соответственно в случае успеха будет пытаться подвинуть его с лидирующих позиций. Я лично не исключаю такое развитие событий и с удовольствием переведу все процессы на Rust в таком случае (лет через 5-10 это возможно начнёт иметь смысл). Если конечно с ним не случится тоже самое, что случилось с языком D (который при выходе был просто на порядки сильнее C++ того же времени по всем пунктам, а в данный момент уже стал уступать современному C++ по целому ряду актуальнейших для индустрии направлений).


ИМХО, он попадает в одну из ниш C++, но не во все. В тот же embedded он вряд ли серьезно зайдет в ближайшем будущем.

_>P.S. Давно не был на этом форуме. Вот сейчас решил вечерком заглянуть, проведать как тут дела... А тут практически ничего не изменилось. )))


Стабильность, однако.
"Будь достоин победы" (c) 8th Wizard's rule.
Отредактировано 21.06.2020 0:15 Lexey . Предыдущая версия .
Re[9]: С++ всё? Rust навсегда?
От: Sheridan Россия  
Дата: 22.06.20 07:17
Оценка:
Здравствуйте, pagid, Вы писали:

S>>Надеюсь, в аду есть специальные котлы...

P>Для нежелающих ускорять программу на 2% за счет её усложнения? Вряд ли
Для тех, кто "срать на оптимизации, всё равно (байтики медленнее передаюцца|юзер купит новый проц)".
И да, некоторым всегда сложно оптимизировать (странно, почему? )) ) и поэтому они называют этот процесс "усложнением".
Ну а некоторым банально лень. Эти ещо могут добавить "бизнес не платит".
Matrix has you...
Re[3]: С++ всё? Rust навсегда?
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.06.20 09:00
Оценка:
Здравствуйте, Lexey, Вы писали:
L>Какое в C управление памятью, кроме стековых и статических переменных и убогих malloc/free (и их аналогов)? В плюсах, да, уже гораздо лучше.
Я так понимаю, что речь идёт не об автоматическом управлении памятью, а как раз о ручном.
Ну, вот скажем, компилятор С++ за вас строит vtbl.
А если вы будете пилить ту же самую задачу на голом С, то ведь никто не может вам запретить навелосипедить ровно то же самое вручную — то есть в начало объекта вклеиваем указатель на метаданные, и поехали
int callVirtualGet(MyObject* object) { return object->vtbl->virtualGet(object) } // convenience function to avoid mixing up vtbl and data

Но! С и не связывает вас этой реализацией — к примеру, можно налудить компрессию vtbl для глубоких иерархий с широкими интерфейсами.
То есть вместо прикапывания номера слота в месте вызова, прикапываем идентификатор и идём вверх по дереву иерархий классов в поисках перегрузки (такая схема была реализована в delphi — при использовании для метода ключевого слова dynamic вместо virtual).

Ну, ладно, в С++ такое тоже можно налудить, и может даже получится чуть меньше бойлерплейта — за счёт шаблонов.
Тем не менее, вот он тот побитовый контроль, которого может не хватать на языках более высокого уровня.
Например, на том же C# (да и вообще любом CLR языке) невозможно написать свой класс "строка". Потому что он описывает объекты переменного размера с фиксированным заголовком, а в дотнете так нельзя.
Либо динамический размер однотипных элементов — массив; либо статический набор разнородных членов — структура.
В плюсах и C такая штука описывается как
struct stringHeader 
{ 
  vtable* vtbl; // we can skip explicit mention in C++ due to the included support for the virtual calls
  int m_size;
  short data[0]; // here goes the dynamic part of string
}

На управляемом языке — нет, никак. Строки порождаются только через магию хоста. (Почти) всё управление памятью вынесено за сцену.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: С++ всё? Rust навсегда?
От: pagid Россия  
Дата: 22.06.20 13:25
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>И да, некоторым всегда сложно оптимизировать (странно, почему? )) ) и поэтому они называют этот процесс "усложнением".

Потому как предыдущий оратор говорил о использовании шаблонов, как усложнении, и задал именно эту оценку полезности — ускорение на 2%
И да, изначально, разговор насколько понял, не о том, использовать ли шаблоны и этим упростить и немного ускорить программу, а о том стоит ли усложнять язык (включая компилятор, библиотеки и проч.) ради этих 2%
Re[12]: С++ всё? Rust навсегда?
От: lpd Черногория  
Дата: 22.06.20 14:15
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, pagid, Вы писали:

S>Давай сразу уж не про шаблоны а про разработку проца и не про 2% а про 0.00002%
S>Ну чтобы даже тупому мне было понятно что овчинка не стоит выделки и вообще поэтому оптимизировать никогда не надо и вдобавок бизнес не платит.

Это ты уже сам написал. Оптимизировать программу добавлением сложных шаблонов(а некоторые еще и мув-семантику для этого везде лепят) совсем тупо. Нужно оптимизировать узкие места, алгоритм, выбирать соответствующие быстрые инструменты и архитектуру.

S>А дальше каждый сам за себя считает — будет ли ему сложно или нет.


Я видел вещи сложнее шаблонов, и в программирование и в других науках. И в код без злоупотребления фич последних стандартов проще добавлять другие оптимизации.
Не надо ипользовать шаблоны только чтобы убедить себя и других в собственном уме — это юношеский максимализм. Можно добавить более эффективные оптизации, при меньшем усложнении.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Отредактировано 22.06.2020 14:17 lpd . Предыдущая версия . Еще …
Отредактировано 22.06.2020 14:16 lpd . Предыдущая версия .
Отредактировано 22.06.2020 14:16 lpd . Предыдущая версия .
Re[14]: С++ всё? Rust навсегда?
От: lpd Черногория  
Дата: 22.06.20 14:37
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, lpd, Вы писали:


S>Ну не умеете в шаблоны — делайте по другому


Я много чего не умею, как и все люди, например в крикет не играю. Но лучше не идти стадом за комитетом, придумавшим новые СТАНДАРТы и объявившим обычный С++03 устаревшим, а самому разобраться что они дают, и прикинуть какая польза от этого леса из угловых скобочек, от которого в глазах рябит.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[7]: С++ всё? Rust навсегда?
От: alex_public  
Дата: 22.06.20 19:07
Оценка:
Здравствуйте, dsorokin, Вы писали:

_>>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективные (там где в C++ будет просто сравнение двух чисел, в языках без шаблонов будет вызов виртуальной функции (или его аналог) со всеми печальными последствиями).

D>Здесь выбор отвечающих этому требованию языков небольшой: C++, Rust, Ada. Может быть, есть еще что-то?

Вот из всех не маргинальных системных языков я не разбирался только с Ada. Так что к сожалению даже не могу прокомментировать подходит или нет. Поверю на слово. )

А так, ещё как минимум язык D позволяет полноценные шаблоны (причём одновременно мощнее и удобнее чем в C++).
Re[7]: С++ всё? Rust навсегда?
От: alex_public  
Дата: 22.06.20 19:34
Оценка:
Здравствуйте, Lexey, Вы писали:

L>Собственно, я и хотел сказать, что никакого единого лидера нет. В разных нишах лидеры разные.


Конечно. Но в контексте сравнения именно C++ и Rust, изначальный тезис о попытках пиара Rust'а исключительно в виде критики текущего лидера выглядит вполне разумным.

L>ИМХО, он попадает в одну из ниш C++, но не во все. В тот же embedded он вряд ли серьезно зайдет в ближайшем будущем.


Ещё год назад помнится прямо на этом форуме кто-то писал, что перешёл на Rust при программирование STM32. Правда ему для этого пришлось руками написать кучу кода (который для плюсов уже есть в соответствующих библиотеках), но оно того стоило (ну по его словам ) ради более приятного языка.
Re: С++ всё? Rust навсегда?
От: FR  
Дата: 23.06.20 04:51
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>Собственно вопрос в теме. Навеяло предыдущими обсуждениями.


На С++ столько всего написано что "С++ всё" точно не будет в обозримом (десяток
другой лет) будущем.
Re[2]: С++ всё? Rust навсегда?
От: FR  
Дата: 23.06.20 04:58
Оценка:
Здравствуйте, velkin, Вы писали:


V>Во-первых, C/C++ буквально созданы чтобы управлять памятью. Во-вторых, этот аргумент уже настолько надоел, что не могут придумать абсолютно ничего нового. Что думаете посадите своих программистов на Rust или C#, который рекламировали точно так же, и всё у вас будет в шоколаде.


У rust фактически такое же управление памяти как и у современного C++ то есть RAII и move. GC в нем нет.

V>Когда Бьерн Страуструп рекламировал C++ он говорил, что одно из его основных достоинств прямое управление памятью. И тут я, например, спрашиваю, какое преимущество у Rust? А мне в ответ C++ небезопасен, потому что позволяет управлять памятью. Нет, постойте ка, какое преимущества у Rust, я не хочу слышать про C++, говорите про Rust. Что там нельзя управлять памятью и это преимущество?


Там можно управлять памятью, разница с С++ только в том что компилятор жестко проверяет корректность этого управления.
Re[7]: С++ всё? Rust навсегда?
От: FR  
Дата: 23.06.20 05:05
Оценка:
Здравствуйте, dsorokin, Вы писали:

D>Здесь выбор отвечающих этому требованию языков небольшой: C++, Rust, Ada. Может быть, есть еще что-то?


Еще FreePascal и Delphi.
Re[14]: С++ всё? Rust навсегда?
От: lpd Черногория  
Дата: 23.06.20 08:37
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>решение 1 — можно сделать оптимизацию для случая, когда параметры занимают мало места и размещать из не в динамической памяти, а в самом объекте Functor. Упрвление памятью не проблема, т.к. функтор реализует value семантику.

CK>решение 2 — используем move семантику для параметров.

Использовать move-семантику для оптимизации, особенно везде — это вообще дно. Оптимизировать нужно только узкие места программы. Передача аргументов не играет решающей роли в быстродействии. ЕСЛИ у тебя большие объекты копируются в критичном коде при легковесной обработке их, можно легко сделать только для них метод MoveObject(), а не перегружать язык новыми типами &&(имеющими только академический интерес) с запутанным синтаксисом.

CK>проблема 3 — внезапно тебе потребовалась поддержка cancellation и для этого тебе нужно добавить еще один метод в твой базовый класс и реализовать его в куче разных реализаций

CK>решение 3 — можно добавить реализацию cancel в одном месте.
CK>Это конечно сложнее в реализации, но это IMO упрощает код. Подход Си с классами проще на первый взгляд, но это выливается в сложности в дальнейшем.

По-моему можно обойтись виртуальными функциями и RTTI.
Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес только для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения. И на Java/C# уже давно пишется гораздо больше.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Отредактировано 23.06.2020 8:39 lpd . Предыдущая версия . Еще …
Отредактировано 23.06.2020 8:38 lpd . Предыдущая версия .
Re[15]: С++ всё? Rust навсегда?
От: chaotic-kotik  
Дата: 23.06.20 08:56
Оценка:
Здравствуйте, lpd, Вы писали:

lpd>Использовать move-семантику для оптимизации, особенно везде — это вообще дно. Оптимизировать нужно только узкие места программы. Передача аргументов не играет решающей роли в быстродействии. ЕСЛИ у тебя большие объекты копируются в критичном коде при легковесной обработке их, можно легко сделать только для них метод MoveObject(), а не перегружать язык новыми типами &&(имеющими только академический интерес) с запутанным синтаксисом.


если у тебя достаточно простые обработчики, то передача параметров это узкое место, для серверов это зачастую так, я может пишу на каком-нибудь DPDK и у меня эти коллбэки миллионы раз в секунду вызываются, какие к черту RTTI с копированием?

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


lpd>По-моему можно обойтись виртуальными функциями и RTTI.


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

lpd>Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес только для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения. И на Java/C# уже давно пишется гораздо больше.


это странное представление, во всех проектах на С++ где я работал, шаблоны вполне себе использовались не академически
Re[16]: С++ всё? Rust навсегда?
От: lpd Черногория  
Дата: 23.06.20 10:57
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, lpd, Вы писали:


CK>если у тебя достаточно простые обработчики, то передача параметров это узкое место, для серверов это зачастую так, я может пишу на каком-нибудь DPDK и у меня эти коллбэки миллионы раз в секунду вызываются, какие к черту RTTI с копированием?


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

CK>про твой MoveObject не будет знать стандартная библиотека, соотв. многие оптимизации не смогут быть использованы


Обычно можно работать вообще с указателями. Если очень-очень нужно, расположить объекты в памяти как угодно.

CK>это странное представление, во всех проектах на С++ где я работал, шаблоны вполне себе использовались не академически


Значит у вас "устаревший C с классами" и "сode smells", если не было многоэтажных шаблонов.
Это вопрос предпочтений, так нравится move-семантика — ок. Только назвали бы язык по-другому, а не С++, который превратили в сборище экзотических фич.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Отредактировано 23.06.2020 11:01 lpd . Предыдущая версия . Еще …
Отредактировано 23.06.2020 10:59 lpd . Предыдущая версия .
Отредактировано 23.06.2020 10:58 lpd . Предыдущая версия .
Отредактировано 23.06.2020 10:58 lpd . Предыдущая версия .
Re[7]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 23.06.20 11:22
Оценка:
Здравствуйте, lpd, Вы писали:

lpd>Можно подумать у программистов других проблем нет, чем возиться с шаблонами ради 2% скорости программы.


Двух процентов, лол, правда?
Не говоря уже про кучу других применений шаблонов, типа проверки безопасности алгоритма длдя каждого типа.
Re[16]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 23.06.20 11:32
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>если у тебя достаточно простые обработчики, то передача параметров это узкое место, для серверов это зачастую так, я может пишу на каком-нибудь DPDK и у меня эти коллбэки миллионы раз в секунду вызываются, какие к черту RTTI с копированием?


CK>про твой MoveObject не будет знать стандартная библиотека, соотв. многие оптимизации не смогут быть использованы


Кстати о мув-семантике, в С++ она на порядок сложнее, чем в Расте. Потому что С++ предполагает, что объект может косвенно содержать ссылку на себя, которую надо править после мува, а Раст предполагает, что не может, и поэтому объекты можно спокойно двигать по памяти, не нарушая их валидность. То есть в Расте вектор любого объекта можно увеличивать тупым realloc, например.
За годы программирования на С++ мне ни разу не понадобились объекты с нетривиальным перемещением. Вектора, строки, хеш-таблицы, юник_птр, шаред_птр — все они могут быть спокойно реаллоцированы без потери смысла. В тех же случаях, когда объекты действительно нужны на своём месте, потому что на них кто-то ссылается из совсем другого места кода, уже приходится отдельно заводить либо юники, либо вектор ЭН-элементных нереаллоцирующих векторов.
Так вот, а кому вообще сдалась сложная С++-ная мув-семантика?
Re[18]: С++ всё? Rust навсегда?
От: dsorokin Россия  
Дата: 23.06.20 14:13
Оценка:
Здравствуйте, AeroSun, Вы писали:

AS>Здравствуйте, T4r4sB, Вы писали:


TB>>Так вот, а кому вообще сдалась сложная С++-ная мув-семантика?


AS>Это попытка исправить родовую травму с++ — копирование по умолчанию.

AS>[..]
AS>Потому имеем что имеем.

Да move и не такой сложный в C++. Просто нужно привыкнуть, что сам std::move ничего никуда не переносит, а лишь меняет тип объекта. Переносят же соответствующий конструктор и оператор присваивания. Еще помнить, что любой метод, который не является noexcept, существенно замедляет перенос, ибо происходит за кулисами копирование объекта на всякий пожарный. Вроде бы ничего не забыл?

Однако, в сравнении с Rust это конечно все слишком сложно. Уверен, что 99% растоманов даже не задумываются о том, как работает move.
Re[19]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 23.06.20 14:28
Оценка:
Здравствуйте, dsorokin, Вы писали:

D>Да move и не такой сложный в C++.


Сложный. Вместо realloc приходится разбирать несколько случаев: у объектов есть ноексептнутый кастомный мув, у объектов запрещён кастомный мув, у объектов есть ексептнутый кастомный мув, итд.
Re[20]: С++ всё? Rust навсегда?
От: chaotic-kotik  
Дата: 23.06.20 14:44
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Сложный. Вместо realloc приходится разбирать несколько случаев: у объектов есть ноексептнутый кастомный мув, у объектов запрещён кастомный мув, у объектов есть ексептнутый кастомный мув, итд.


какая связь между realloc и move семантикой в Rust?
Re[22]: С++ всё? Rust навсегда?
От: chaotic-kotik  
Дата: 23.06.20 16:01
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>В Rust можно тупо вызвать realloc для вектора любый объектов, в C++ нельзя.


таки для любого вектора? и при чем здесь move семантика?
Re[23]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 23.06.20 16:02
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, T4r4sB, Вы писали:


TB>>В Rust можно тупо вызвать realloc для вектора любый объектов, в C++ нельзя.


CK>таки для любого вектора? и при чем здесь move семантика?


Да, для любого.
Тот факт, что объекты С++ имеют право иметь нетривиальный T(T&&), тоже является частью С++ной мув-семантики.
И это право нужно лишь в крайне редкий случаях, для остальных это адовый гемор.
Re[24]: С++ всё? Rust навсегда?
От: chaotic-kotik  
Дата: 23.06.20 16:34
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Да, для любого.


а если аллокатор не может реаллокейтнуть буфер по какой-либо причине?

TB>Тот факт, что объекты С++ имеют право иметь нетривиальный T(T&&), тоже является частью С++ной мув-семантики.

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

гемор для кого? разработчику приложений на С++ практически никогда не нужно реализовывать T(T&&) самостоятельно, что ты имеешь ввиду?

я так и не понял при чем тут reallocate, если ты reallocate буфер в памяти, то тебе ничего мувать не нужно, у тебя остается тот же буфер, меняется только его размер
Re[25]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 23.06.20 16:38
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>а если аллокатор не может реаллокейтнуть буфер по какой-либо причине?


Это особая ситуация

CK>гемор для кого? разработчику приложений на С++ практически никогда не нужно реализовывать T(T&&) самостоятельно, что ты имеешь ввиду?


А если надо? Не перегрузил 100500 версий T(T&&) и дефолтное поведение будет либо некорректное, либо неоптимальное

CK>я так и не понял при чем тут reallocate, если ты reallocate буфер в памяти, то тебе ничего мувать не нужно, у тебя остается тот же буфер, меняется только его размер


Вообще-то буфер может переместиться. И если в буфере сидят С++-объекты, то после влобного побайтового перемещения объекты могут стать инвалидными.
Re[26]: С++ всё? Rust навсегда?
От: chaotic-kotik  
Дата: 23.06.20 20:23
Оценка:
Здравствуйте, T4r4sB, Вы писали:


TB>Это особая ситуация

TB>Вообще-то буфер может переместиться. И если в буфере сидят С++-объекты, то после влобного побайтового перемещения объекты могут стать инвалидными.

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

CK>>гемор для кого? разработчику приложений на С++ практически никогда не нужно реализовывать T(T&&) самостоятельно, что ты имеешь ввиду?

TB>А если надо? Не перегрузил 100500 версий T(T&&) и дефолтное поведение будет либо некорректное, либо неоптимальное

вообще, по хорошему тебе ничего не нужно перегружать, если ты пишешь кастомные T(T&&) и operator = (T&&) то ты что-то делаешь не так скорее всего
само собой, если ты зачем то пишешь свой смарт поинтер, то тебе придется явно определить это (т.к. неявно они не будут определены, т.к. у тебя будут явный к-р и оператор присваивания), но пользователям уже не обязательно сильно в этом разбираться
Re[18]: С++ всё? Rust навсегда?
От: alex_public  
Дата: 23.06.20 22:36
Оценка:
Здравствуйте, AeroSun, Вы писали:

TB>>Так вот, а кому вообще сдалась сложная С++-ная мув-семантика?

AS>Это попытка исправить родовую травму с++ — копирование по умолчанию.
AS>Вот только копирование в 99% не нужно — по умолчанию нужна передача по ссылке (константной). В общем аналогично, как это сделано в С#.

Что-то мне кажется, что ты путаешь модели памяти (в C# все объекты — это ссылки) и модели передачи параметров в функции в C#. )))

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

Однако к семантике перемещения это точно не имеет никакого отношения. Более того, это "ни к чему" не имеет отношения, потому как собственно и проблемы тут нет — язык спокойно поддерживает все возможные способы передачи данных и то, что самый популярный способ не является дефолтным — это всего лишь мелкое досадное неудобство, а не проблема, которую надо как-то решать.

AS>Достаточно было изменить дефолтное поведение + стандартизировать оптимизации при возврате/передаче и всё это обернуть в параметры компилятора для нового/старого с++ и это была бы бомба.

AS>Но это бы сломало уже написанные программы + комитет до усрачки боится перемен (либо кто-то там сознательно старается "прикопать" с++).
AS>Потому имеем что имеем.

И как это позволит написать например unique_ptr? )
Re[28]: С++ всё? Rust навсегда?
От: chaotic-kotik  
Дата: 24.06.20 09:05
Оценка:
Здравствуйте, T4r4sB, Вы писали:

CK>>все, я понял что ты называешь realloc совсем не тоже самое что я, я думал про сишный realloc, который делает совсем другое

TB>Я про сишный и говорю. Он может переместить буфер. Для С++-объекта это проблема. Для Раст-объекта — нет. В чём непонятки-то?

я распарсил, терминология просто немного alien для тех кто не знает Rust
тут у с++ скорее другая проблема, в интерфейсе аллокатора в принципе нет realloc, который std::vector мог бы использовать например для POD объектов, вектор всегда копирует, хотя в linux сишный realloc реализован через mremap, что позволило бы вставлять POD-ы в вектор практически без копирования, насколько я помню folly::vector умеет так делать для POD-ов, лично мне большего и не нужно

но в принципе да, согласен с оригинальным сообщением, в плюсах реализовывать свой вектор довольно сложно из-за exception guarantees

CK>>вообще, по хорошему тебе ничего не нужно перегружать, если ты пишешь кастомные T(T&&) и operator = (T&&) то ты что-то делаешь не так скорее всего

TB>Это всего лишь значит, что я пишу объект, управляющий ресурсом. В С++03 надо было перегрузить 4 хрени: T(), T(T&), =(T&), ~T(). В ++20 я боюсь их считать.
TB>На деле из них большая часть лишние. Всего-то надо было добавить требование тривиальной реллоцируемости.

чем тебе unique_ptr для управления ресурсом не угодил? пользовательский код не должен, как правило, все это реализовывать, только если ты сам пишешь всякие библиотеки контейнеров, так что не такая уж это и проблема, тривиальная реаллоцируемость это хорошо конечно же
Re[29]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 24.06.20 11:12
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>я распарсил, терминология просто немного alien для тех кто не знает Rust


Я тоже не знаю Раст. Реаллок — это термин из древней сишки.

CK>тут у с++ скорее другая проблема, в интерфейсе аллокатора в принципе нет realloc, который std::vector мог бы использовать например для POD объектов, вектор всегда копирует, хотя в linux сишный realloc реализован через mremap, что позволило бы вставлять POD-ы в вектор практически без копирования, насколько я помню folly::vector умеет так делать для POD-ов, лично мне большего и не нужно


А для не-ПОДов? Не может, да? Жаль.

CK>чем тебе unique_ptr для управления ресурсом не угодил?


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

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


А я не хочу быть прибитым гвоздями к мегабайтам СТЛ, например.
Re[29]: С++ всё? Rust навсегда?
От: T4r4sB Россия  
Дата: 24.06.20 11:13
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну вообще говоря оба языка системные и соответственно оба позволяют что угодно. Это я в том смысле, что и в Rust'е ты можешь с помощью unsafe создать любые ссылки самого на себя и т.п. )


При этом библиотека и компилятор вправе игнорить факт наличия таких ссылок и спокойно реаллоцировать такие объекты.
Re[30]: С++ всё? Rust навсегда?
От: dsorokin Россия  
Дата: 24.06.20 14:24
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, chaotic-kotik, Вы писали:


CK>>я распарсил, терминология просто немного alien для тех кто не знает Rust


TB>Я тоже не знаю Раст. Реаллок — это термин из древней сишки.


Подозреваю, что тут получился какой-то глухой телефон.

У меня есть версия, что тут имелось в виду. В языке Rust для того, чтобы перенести объект (из стека в кучу, или из стека в замыкание, или с одного замыкания в другое замыкание) достаточно просто сделать две вещи: 1) тупо по-битово скопировать handle объекта (часто несколько байт); 2) а потом просто для старого объекта _не_ вызывать деструктор Drop, т.е. ничего не делать. Вот и все!

Я так понимаю, что "realloc" это как раз на тему перемещения.

Тем не менее, в Rust можно привязаться к адресу в памяти. Для этого есть std::pin, но честно говоря, я туда вот прямо сейчас единственный раз заглянул за года три только для того, чтобы написать этот комментарий
Re[16]: С++ всё? Rust навсегда?
От: lpd Черногория  
Дата: 26.06.20 08:16
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, lpd, Вы писали:


_>Т.е. в реальности никакого усложнения или увеличения прикладного кода от использования семантики перемещения нет. И использовать её повсеместно более чем правильно.


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

_>И да, сама по себе семантика перемещения нужна в языке в первую очередь не ради оптимизации, а для возможности реализации полноценного RAII и соответствующего управления ресурсами.


Я уже писал про RAII, что считаю это хаком.
Файл — это абстракция ОС, с которой работают через хэндл. А переменная — это абстракция языка программирования, и у этих двух абстракций общего ничего нет. Просто пользуются тем, что переменная когда-то удалится, но это хак.
Аналогично с памятью и умными указателями. Некоторый смысл есть в том, что деструкторы вызовутся по выходу из функции, но это тоже притянуто за уши. GC пользоваться проще, а умные указатели — это редко нужная полумера, и реализованная длиннословно. unique_ptr<>, если он тебе так нужен, можно встроить в язык, и будет удобнее. Вообще в языке нужны и GC и умные указатели с возможностью выбирать.

lpd>>Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес только для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения.


_>Что такое "возможности общего назначения"? )


Нужно делать язык более удобным и простым в использовании для создания приложений со сложной логикой, какие пишут сейчас на Java, а не пытаться сделать монстра.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Отредактировано 26.06.2020 8:17 lpd . Предыдущая версия .
Re[10]: С++ всё? Rust навсегда?
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 27.06.20 09:36
Оценка:
Здравствуйте, prog123, Вы писали:

P>А что мешает с++-нику писать на расте и даже на гоу? Вот у растистов и гоуистов писать на с++ далеко не сразу получится, лет через 5.


С++ даже с нуля можно освоить на хорошем уровне за пару лет. Не настолько уж он сложен.

P>А наоборот без проблем.


..а Rust не настолько уж прост. Да, он значительно проще, чем С++, но порог вхождения в Rust тоже высокий.
Читается код на Rust легко. Ну как и плюсовый код. А вот писать..

Преимущество Rust в защите от многих глупых ошибок и сопоставимой с С++ производительности. Но вот не в простоте языка.
Go проще.
С уважением, Artem Korneev.
Re[2]: С++ всё? Rust навсегда?
От: Erop Россия  
Дата: 07.07.20 06:32
Оценка:
Здравствуйте, velkin, Вы писали:


V>У меня логика такая, если памятью не управляют напрямую, значит это делает сборщик мусора. Это ещё одна концепция, которой нужно учиться. Не хотите учиться? Ну тогда будете писать тормознутые программы с чудовищным перерасходом памяти.


В целом согласен. В частностях, бывают удачные DSL, где удаётся сконцентрировать внимание программиста на предметной области, а вопросы управления памятью вообще никак не возникакют.
Например, язык формул экселя.

V>Очень наивно, я могу на любом языке программирования написать отвратительную программу с кучей глюков. "Нет никаких доказательств того, что один и тот же программист налажав на C/C++ не налажает на других языках программирования".


Ну всё-таки для С++ уровень нужен повыше. И если задачи совсем простые -- типа клепания 100500 шаблонных формочек и отчётов, то С++ таки избыточен

V>Ну, вы знаете, наши программисты пишут лажовый код, мы хотим попробовать Rust в надежде на то, что они перестанут писать лажовый код. А Microsoft известна своими программистами. Они может поэтому и переписывают свой .NET каждый раз, потому что проще переписать с нуля, чем поддерживать и развивать старую версию.


Разве они каждый раз переписывают?
Они же вроде один раз заново начали, когда переносимую версию затеяли?
И я так понимаю, что это потому, что к старой винда была прибита гвоздями. И это было осознанное решение руководства MS, а не ошибка разработчиков...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: С++ всё? Rust навсегда?
От: Erop Россия  
Дата: 07.07.20 07:36
Оценка:
Здравствуйте, L.K., Вы писали:

LK>Потому что армию стрельцов (массовую армию) можно обучить за пару недель ("сыплешь туда порох, засовываешь пулю, поджигаешь фитиль, целишься"). А для стрельбы из лука нужна многолетняя каждодневная тренировка. Т.е. профессиональных лучников будет мало.


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

Но подготовка ниндзя будет включать и лук, и метательные техники и огнестрел и рукопашку и много чего ещё, включая тактику и стратегию ДРГ на задании
Так что вчерашние крестьяне всё равно так не смогут, хоть с луком хоть без...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: С++ всё? Rust навсегда? Простота
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 07.07.20 07:41
Оценка:
Здравствуйте, Erop, Вы писали:

E>Ну всё-таки для С++ уровень нужен повыше. И если задачи совсем простые -- типа клепания 100500 шаблонных формочек и отчётов, то С++ таки избыточен


А я сейчас решил почитать "Язык программирования C++. Специальное издание" Бьёрна Страуструпа.

Часть конспекта по 4.1 Фундаментальные типы:
типы C++
+-------------+--------+-------------------------------+
|название     |тип     |категория                      |
+-------------+--------+------------+--+---------------+
|логические   |bool    |            |  |               |
|символьные   |char    |интегральные|  |               |
|целые        |int     |(целые)     |  |               |
+-------------+--------+------------+  |фундаментальные|
|вещественные |double  |арифметические |(встроенные)   |
+-------------+--------+---------------+               |
|отсутствующие|void    |                               |
+-------------+--------+-------------------------------+
|указательные |тип*    |                               |
|массивы      |тип[]   |построенные поверх типов       |
|ссылочные    |тип&    |                               |
+-------------+--------+-------------------------------+
|перечислимые |enum    |                               |
|структуры    |struct  |определяемые пользователем     |
|классы       |class   |                               |
+-------------+--------+-------------------------------+

И он дальше пишет:

Фундаментальные типы языка C++ вместе с указателями и массивами предоставляют программисту отражение этого машинного уровня в манере, относительно независимой от конкретной реализации.

В большинстве приложений можно обойтись типом bool ддя логики, типом char для символов, типом int для целых чисел и типом double — для дробных (чисел с плавающей запятой). Остальные фундаментальные типы являются вариациями, предназначенными для оптимизации и решения специальных задач, и их лучше до поры игнорировать. Но, разумеется, их нужно знать для чтения существующего стороннего кода на С и C++.

Он буквально говорит,
1) арифметические типы имеют прямое отражение в машинном коде.
2) существует лишь 4-е арифметических типа: bool, char, int, double.

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

Продолжение конспекта:

оптимизация арифметических типов:
1) объём занимаемой памяти
2) точность представления
3) диапазоны значений

без оптимизации рекомендуется использовать арифметические типы:
1) логика bool
2) символы char
3) целые int
4) вещественные double


И опять же помимо этого поверх можно построить:
1) указатель (константный указатель, указатель на константу, константный указатель на константу)
2) массив (многомерный массив)
3) ссылку (ссылку на константу)

И чем дальше в лес, тем толще партизаны. По словам Страуструпа я могу сделать вывод, что даже float это оптимизация. А программисты могли бы не париться и запомнить четыре арифметических типа.

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

Очевидно одна из проблем заключается в принципе:

Если в начале пьесы на стене висит ружье, то к концу пьесы оно должно выстрелить


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

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

Или проведём умственный эксперимент. А что если бы программист не знал про оптимизации арифметических типов в C++? Вот пожалуйста, снижение требований как к программистам, так и к программным системам.

То же множественное наследование вне интерфейсов в C++, так не хочешь, не пользуйся. Но нет, мы же не можем отказаться, на стене висит ружьё: — "Надо Федя, надо". Но почему его отсутствие превратилось в преимущество C# или других языков программирования лично я не понимаю.

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

Афоризмы и цитаты о простоте

Усложнять просто, упрощать сложно.
Все должно быть изложено так просто, как только возможно, но не проще.
Будь проще, и ты поймешь, что проще некуда.
Нужно усложнять, чтобы в результате все стало проще, а не упрощать,
чтобы в результате все стало сложнее.
Если существует более сложный способ делать что либо, кто нибудь
непременно его откроет.
На всякого мудреца простоты не напасешься.
Не корчите из себя ничего; простота есть отпечаток гения.
Простота есть ближайшая родственница ума и дарований.
Простота делает жизнь не только более приятной, но… и более чистой и
прекрасной.
Простота есть необходимое условие прекрасного.
Язык правды прост.
Чем проще человек выражается, тем легче его понимают.
В характере, в манерах, в стиле, во всем самое прекрасное — это
простота.
Нет ничего проще, чем величие; воистину, быть простым — значит быть
великим.
Простота — это то, что труднее всего на свете; это крайний предел
опытности и последнее усилие гения.
Стремление к простоте жизни является у сложнейших душ, а все простое
стремится к сложности.
Все люди, занятые истинно важным делом, всегда просты, потому что не
имеют времени придумывать лишнее.
Ничто так, как простота, не содействует сближению людей.
Простота есть необходимое условие прекрасного.

Отредактировано 07.07.2020 8:17 velkin . Предыдущая версия . Еще …
Отредактировано 07.07.2020 8:15 velkin . Предыдущая версия .
Отредактировано 07.07.2020 8:05 velkin . Предыдущая версия .
Re[6]: С++ всё? Rust навсегда?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 07.07.20 07:43
Оценка:
Здравствуйте, Erop, Вы писали:

E>p. s.

E>Я просто не в курсе. На Расте уже есть написанная ОС например?

Есть поделки разного уровня готовности к использованию. Насколько я знаю, мало чем от C++ ситуация отличается, хотя для написания новой ОС взять Rust будет разумнее чем плюсы в силу того что рантайм гвоздями не прибит.
Re[11]: С++ всё? Rust навсегда?
От: Erop Россия  
Дата: 07.07.20 10:01
Оценка:
Здравствуйте, Слава, Вы писали:

P>>А что мешает с++-нику писать на расте и даже на гоу? Вот у растистов и гоуистов писать на с++ далеко не сразу получится, лет через 5. А наоборот без проблем.

С>Ничто не мешает, кроме религии. И вот с религией-то сделать мало что возможно, как мы видим по этому треду.

Хороший инженер, не может иметь "религии" такого рода.
Язык -- это просто инструмент. Выбирается из ряда соображений. На разных проектах/частях кода может быть разным.
Формошлёпить на С++ странно. ML в продакшен -- вполне конкурентоспособнос. Как-то так.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: С++ всё? Rust навсегда?
От: IID Россия  
Дата: 07.07.20 22:41
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, L.K., Вы писали:


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


НС>Крайне важный в контексте программирования факт!


вынужден уточнить, что шарики нужны свинцовые.
kalsarikännit
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.