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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 хорошо в своей и т.д. Компромиссный универсальный язык — это не нужное зло.

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

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

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

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

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

Преимущество Rust в защите от многих глупых ошибок и сопоставимой с С++ производительности. Но вот не в простоте языка.
Go проще.

Здравствуйте, 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 будет тоже выглядеть нелепо для будущего времени, но для настоящего он по дизайну на мой личный субъективный взгляд выглядит просто превосходно!

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


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

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

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

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

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

Разве они каждый раз переписывают?
Они же вроде один раз заново начали, когда переносимую версию затеяли?
И я так понимаю, что это потому, что к старой винда была прибита гвоздями. И это было осознанное решение руководства MS, а не ошибка разработчиков...

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

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

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

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

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

AA>У С++ слишком богатый синтаксис с неоднозначной семантикой. По моему скромному опыту.
По моему опыту, судить о С++ по скромному опыту бессмысленно. Это примерно, как критиковать боб для бобслея или там космический корабль, по опыту вождения "Мерседеса"...
С++ -- чудовищно мощная штука, и применять её надо тока там, где менее мощные и более удобные почему-то не канают

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

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

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

Но подготовка ниндзя будет включать и лук, и метательные техники и огнестрел и рукопашку и много чего ещё, включая тактику и стратегию ДРГ на задании
Так что вчерашние крестьяне всё равно так не смогут, хоть с луком хоть без...

Здравствуйте, 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++ запредельно сложен, а в том, что не все умеют использовать его по простому. Я, например, не умею, потому и решил почитать Страуструпа.

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

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

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

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

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

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

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

На Rust пишут Hash &mdash; платформу будущего.

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

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

Хороший инженер, не может иметь "религии" такого рода.
Язык -- это просто инструмент. Выбирается из ряда соображений. На разных проектах/частях кода может быть разным.
Формошлёпить на С++ странно. ML в продакшен -- вполне конкурентоспособнос. Как-то так.

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

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

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

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

L>В этом плане язык лет на 10 отстал от того же C#.
Это просто другие задачи.
В С++ и так напихали кучу всего. Зачем из него ещё и эрланг делать?

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Так никто и не говорил, что речь про простые вещи.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

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

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

вынужден уточнить, что шарики нужны свинцовые.