Почему все же с++ такой сложный язык?

Попробуй Rust. Он лучше плюсов примерно во всём.

И через 3-5 лет вытеснит упоротую плюсню вообще отовсюду. Помните, как с Жавой было?

Попробуй Rust. Он лучше плюсов примерно во всём.

Спасибо за совет. Присмотрюсь. Пока синтаксис раста кажется очень сложным …

Владимир 123

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

за C++ надо сажать лет на 20. Твари. А вдруг дети увидят.

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

А потом мы пропихнем в УК РФ статью за С++ ложство и будет этих уебков сажать сажать сажать.

Пресловутая контекстная зависимость (одна и та же лексема в разных контекстах означает разное, например «*» или const).

Это плюс, а не минус.

Это плюс, когда люди умеют конструировать синтаксис и семантику. Авторы cpp этому явно не обучены.

Это проблемы сишки. В С++ нет автоматического приведения типов.

Отрицать очевидное - наш стиль. Даже автоматическое приведение переменных к ссылкам мы не признаем автоматическим приведением. И приведение производного типа к базовому тоже. Нет в C++ автоматического приведения типов.

Разница однозначно и простым языком описана в стандарте.

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

Вообще насрать, какие у него истоки. У указателей есть один объективный косяк – кривое поведение SomeType* a, b. Никаких проблем кроме этой ни у кого с ними нет.

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

Никто так не пишет, такой проблемы не существует.

Отрицать очевидное - наш стиль.

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

Ты же не пуп земли, многого не знаешь.

Не должна была.

Отрицать без аргументов - наш стиль.

Которые существуют во многих других языках программирования, включая чисто скриптовые. Для прозрения предлагаю почитать исходники, например, awk.

Чтобы писать на языке awk, надо прочитать его исходники!

Нет, люди на видео не имеют никакого отношения к академической среде. На видео вообще нет задач на С++ как таковой, из него используется пара шаблонных контейнеров и потоковый IO. Больше С++ там нет.

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

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

Этот ваш Раст - такая же галиматья, что и плюсы. Они додумались, что тип слева от имени - это тупик. Но не поняли что тип напрямую связан со значением, и стали его писать зачем-то слева от значения, заодно разрывая эту запись символом связывания. Уродства вида «неизменяемая ссылка на неизменяемое связывание» и «неизменяемая ссылка на изменяемое связывание» с упоротым плюсовым синтаксисом поставляются в комплекте.

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

Написать как на лиспе посчитать Фибоначчи при компиляции?

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

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

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

а тебе что, исходники метапрограммных библиотек нужно ковырять?

среднестатистические плюсовые исходники не несут адовой сложности.

либо ты заведомо пытаешься очернить c++

У вас тут просто консилиум растодилетантов.

Объекты есть: структуры, перечисления, юнионы. Любой объект, описание, метод, поле можно сделать приватным или публичным. Публичные они только в рамках своего модуля-неймспейса. К любому объекту можно прицепить методы или ассоциированные (статические) функции. Наследование решается через трейты (интерфейсы). Трейты могут требовать реализации других трейтов, таким образом, можно добиться многоуровневой функциональности. Всяких конструкторов, деструкторов, операторов копирования и прочей неявно реализуемой плюсовой шелухи нет, вместо них используются трейты. Конструкторы обычно решаются как ассоциированные функции, возвращающие объект.

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

Фух, вроде все ваши домыслы опроверг.

среднестатистические плюсовые исходники не несут адовой сложности.

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

либо ты заведомо пытаешься очернить c++

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

Сам придумал – сам оспорил. Теперь бегом неси мне мои цитаты, на которые ты отвечал в первом параграфе.

Наследование решается через трейты (интерфейсы).

Наследование никак не решается через интерфейсы. Единственный способ в расте сделать «наследование» – через композицию + Deref.

Всяких конструкторов, деструкторов, операторов копирования и прочей неявно реализуемой плюсовой шелухи нет

Потому что в куцей модели для них нет места.

деструкторов […] нет

В С++ вызов деструкторов хотя бы гарантируется. Кстати, чем деструктор в Drop отличается от крестового?

Конструкторы обычно решаются как ассоциированные функции, возвращающие объект.

Которые не работают с обобщенным кодом, да и в целом ничем не отличаются от старого

struct ptr { void* ptr };
void make_ptr (struct ptr* p, void* v) { p->ptr = v; }

Перегрузки функций нет, и слава Богу - код из-за этого гораздо более читаемый.

Нет, из-за этого нельзя писать обобщенный код. Традиционно предлагаю вам написать emplace_back на расте.

дженерики (шаблоны)

Дженерики != шаблоны.

Даже автоматическое приведение переменных к ссылкам мы не признаем автоматическим приведением.

Объект не «приводится» к ссылке. На него имплицитно берется ссылка.

И приведение производного типа к базовому тоже.

Единственный более-менее валидный пример.

Именно поэтому были придуманы умные указатели,

Умные указатели были придуманы для реализации RAII-обертки вокруг обычных указателей, а вовсе не поэтому.

но и с ними почему-то не все гладко, что-то все время мешает сделать правильную реализацию. Ой, а почему их так много?

Их не «много», а 2 (два) в современном С++. Они реализуют разную стратегию владения ресурсом.

Ты же не пуп земли, многого не знаешь.

А ты, надо полагать, ежедневно с такими индивидами общаешься? Многое говорит о твоем уровне. Советую так же написать пост на тему того, что 2 + 2 != 3.

Чтобы писать на языке awk, надо прочитать его исходники!

Чтобы писать на С++, не нужно знать про lvalue/rvalue references, достаточно пары простых и довольно очевидных правил. Множество живых тому примеров я видел и лично знаю.

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

ууу) хамоватый персонаж просто попался

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

ну ясно... плюсы тогда реально адский ад

Наследование никак не решается через интерфейсы. Единственный способ в расте сделать «наследование» – через композицию + Deref.

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

Дженерики != шаблоны.

Мы же про вот эти? Foo<T>(){} Вот они как раз очень мало отличаются от С++.

В С++ вызов деструкторов хотя бы гарантируется. Кстати, чем деструктор в Drop отличается от крестового?

Ну вот я про такие вещи и говорил. Всякие трейты вроде Default, Clone, и т д

Чтобы писать на С++, не нужно знать про lvalue/rvalue references, достаточно пары простых и довольно очевидных правил. Множество живых тому примеров я видел и лично знаю.

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

Не должен. Так сложилось. Впрочем тот же С++ показывает, что в сложности ничего страшного нет, люди справляются.

Просто подход Раста сильно отличается от подходов других языков, поэтому надо менять мышление, а не тащить в язык всё из С++.

В Rust нет ничего такого, что меняет подходы.

Просто подход Раста сильно отличается от подходов других языков, поэтому надо менять мышление, а не тащить в язык всё из С++.

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

Мы же про вот эти? Foo(){} Вот они как раз очень мало отличаются от С++.

Да ладно? Уверен?

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

Наследование решается через трейты (интерфейсы).

Обе цитаты – твои. Вперед, решай наследование через трейты. Заодно разработчикам rustc расскажешь, а то они не знают, приходится поля структур копипастить.

Ну вот я про такие вещи и говорил. Всякие трейты вроде Default, Clone, и т д

Так ничем не отличаются, или крестовая шелуха?

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

Т.е. знание про lvalue/rvalue references все же не необходимо для них? Ч.т.д

Всяких конструкторов, деструкторов, операторов копирования и прочей неявно реализуемой плюсовой шелухи нет

Деструкторы есть, и RAII такая же священная корова (что по моему плюс) как и в С++.

Отличается фанатичностью хомячков и выбором исходно убогой модели

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

Да ладно? Уверен?

Аргументация слабоватая.

Вперед, решай наследование через трейты.

Вот тут можешь почитать про ООП в Раст. Хотя нужность наследования, как и ООП в целом, сильно преувеличена. Да и вообще Раст не совсем ООП-язык, он скорее императивно-функциональный. https://rustycrate.ru/обучение/2017/06/11/oop-in-rust.html#obobshchieniie-chi...

Так ничем не отличаются, или крестовая шелуха?

Крестовая шелуха во всём своём объёме в каждом новом объекте не нужна, а когда она нужна, её можно включить отдельными трейтами. У меня в крестах процентов в 75 случаев деструктор пустой, например. Ну нечего мне там освобождать или подчищать. А Раст ещё и автоматически многий мусор убирает, вообще сказка.

Т.е. знание про lvalue/rvalue references все же не необходимо для них? Ч.т.д

Ну вот и имеем такие падающие, текущие и виснущие плюсовые поделки, как в том же КДЕ.

В Rust нет ничего такого, что меняет подходы.

Вместо ООП - ОО на трейтах в стиле хаскеля.
Вместо полноценных тьюринг полных утино-типизированных шаблонов - жестко ограниченные дженерики.
Вместо полноценных тьюринг полных утино-типизированных шаблонов - полноценные процедурные макросы.
Вместо сишных текстовых макросов - безопасные декларативные подстановочные макросы (macro_rules!).
Вместо исключений - явный возврат ошибок с сахаром.
Плюс боров чекер.
Плюс более жесткая типизация.
Плюс всегда неявная константность при объявлении переменных.
Плюс АТД и паттерн матчинг.
Плюс поощрение псевдофункционального стиля в виде цепочек трансформаций в виде map filter и т. п.

У меня в крестах процентов в 75 случаев деструктор пустой

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

Да и вообще Раст не совсем ООП-язык, он скорее императивно-функциональный.

Как бы привычнее противопоставлять императивный и функциональный подходы. Вы же умудрились скрестить их и получившегося ежа противопоставить ОО-подходу.

Скажите, вы уже совсем перестали на C++ программировать и полностью перешли на Rust?

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

 
#ifndef _MIDIIO_HPP_
#define _MIDIIO_HPP_

#include <vector>
#include <string>

#include <portmidi.h>

namespace Sinistra {

using MidiDevice = int;

class MidiIO {
	std::vector<const PmDeviceInfo *> m_devices;
	std::vector<std::string> m_inputs;
	std::vector<std::string> m_outputs;

	public:
		MidiIO(MidiIO & another) = delete;
		MidiIO & operator=(MidiIO & another) = delete;
		static MidiIO & get_instance();
		int get_device_count() const;
		std::vector<std::string> get_inputs();
		std::vector<std::string> get_outputs();
		std::string get_device_name(MidiDevice device);
		MidiDevice get_device_id_by_name(const std::string & name);
		std::string get_default_device();
		void set_device(const std::string & device_name);

	private:
		MidiIO();
};

};

Мы же про вот эти? Foo(){} Вот они как раз очень мало отличаются от С++

отличие есть, причём принципиальное.

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

А теперь представь, к чему приводит эта «фича», если у нас есть большое дерево вызова функций

Как бы привычнее противопоставлять императивный и функциональный подходы.

Это было давно и больше в интернет срачах чем реально, тому же гибридному функционально императивному и ОО языку OCaml уже 25 лет исполняется. А сейчас похоже уже почти все языки, включая и С++ гибридные.

Вы же умудрились скрестить их и получившегося ежа противопоставить ОО-подходу.

Rust вполне себе ОО язык.

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

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

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

Не, хотел доделанный. Интересно было, такое норм?

class Q {
   int ...;
   vector<int> ...;
   Any_object ...;
public:
   Q() {}
   ~Q() {}
};

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

Нет, вы просто критикуете вовсе не то, что стоит критиковать.

Аргументация слабоватая.

Почему я должен доказывать, что A != B, а не ты должен доказывать, что A = B? Это как минимум не так работает.

Но хорошо, давай вернемся к классике. Роди мне вот такую штуку. Сможешь – значит как минимум в одном юзкейсе эквивалентны. Не сможешь – контрпример найден, не эквивалентны.

auto try_emplace_back(auto & v, auto && ... xs) {
    if (some_condition) {
        v.emplace_back(xs...);
    }
}

Вот тут можешь почитать про ООП в Раст.

Я тебе открою глаза, возможно, но я сам пет-проекты пишу на расте.

Хотя нужность наследования, как и ООП в целом, сильно преувеличена

Открываешь код rustc и читаешь копипасту до полного просветления.

У меня в крестах процентов в 75 случаев деструктор пустой, например.

Вот он, уровень хейтера. Зачем вы пишете пустые деструкторы, если вы можете их не писать, или писать ~SomeType() = default;, если вам нужно явно показать тривиальность деструктора.

Крестовая шелуха во всём своём объёме в каждом новом объекте не нужна,

…И вы ее просто не пишете в таком случае, и все отлично работает.

А Раст ещё и автоматически многий мусор убирает, вообще сказка.

Какой мусор, что к чему…

Ну вот и имеем такие падающие, текущие и виснущие плюсовые поделки, как в том же КДЕ.

Так мы говорим про минимально необходимый набор для написания программ, или для профессиональной разработки?

Неа, это синглтон. Его возвращает статическая функция.

«Крестовой шелухи» здесь ровно 2 строчки, все остальное – обычный код. Как так получилось?

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

В любом случае это будет не тот тип, с которым ты объявил переменную, а нечто куда более ограниченное.

Да согласен, но это дает как минусы, так и плюсы. В раст еще плохо то что не поддерживается GADT (https://en.wikipedia.org/wiki/Generalized_algebraic_data_type) поэтому дженерики намного слабее чем могли бы быть. Но уже начали поддерживать более ограниченный GATs (фактически тот же GADT, но только для ассоциированных типов) https://www.reddit.com/r/rust/comments/k4vzvp/gats_on_nightly/ так что раст потихоньку подтягивается к С++ и haskell и в этом вопросе.

Не синглтон это никакой. В общем ни в чем уже не сознаешься, ждешь подвоха. Просто после фразы - 75% пустой деструктор, сразу появились вопросы. Во-первых, сделатье его пустым имеет смысл лишь для переноса его в private, это явно не 75% случаев. Значит, ты шлепаешь их везде подряд. Хотел понять, осознаешь ли, что ломаешь объекту move, или же вдобавок вставляешь декларации для move версий, и как при этом обходишься с noexcept. Хочется понимать уровень хейтер-цпп-экспертов. В любом случае - у тебя там какие-то проблемы, либо плодишь жуткую избыточность, либо что-то ломаешь из-за невежества.

Как интересно! А теперь попробуйте скомпилировать.

Окей, окей, сейчас специально для тебя пустой напишу. Вот видишь, а в Раст мне не приходится писать того, что мне не надо.

Не синглтон это никакой.

Интересно, почему же это? Майерс, выходит, тоже дилетант?

В Раст, кстати, они практически никогда не нужны, там память чистится сама. Это надо ещё умудриться там сделать утечку памяти.

Интересно, почему же это? Майерс, выходит, тоже дилетант?

Я про свой пример имел в виду.

Это надо ещё умудриться там сделать утечку памяти.

Прикольно, думал, что синглтоны для другого.

Прикольно, думал, что синглтоны для другого.

Причём тут это? Смешались в кучу кони, люди...

Ты у меня спрашиваешь? Я и сам не знаю зачем ты это написал

Интересно, почему же это? Майерс, выходит, тоже дилетант? В Раст, кстати, они практически никогда не нужны, там память чистится сама. Это надо ещё умудриться там сделать утечку памяти.

Ладно, в общем не утруждай себя примерами, после твоих повсеместных пустых деструкторов все понятно в целом.

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

Чтобы понимать, что повар не умеет готовить, не обязательно быть поваром. Глупо есть хреновую пищу и думать: «Еда, конечно, дермище, но кто я такой, чтобы высказывать мнение о способностях повара? Буду есть мерзость дальше».

Если у тебя везде не пустые деструкторы, то значит у тебя до сих пор там new и delete, как в 90-е. Впрочем, большинство плюсеров застряло на стандарте 2003 года, так что не стесняйся с умным видом читать лекции тем, кто намного младше тебя.

Их вообще не должно быть, раз ты этого не понимаешь, значит с плюсами знаком поверхностно. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-dtor

If the default destructor is sufficient, use it. Only define a non-default destructor if a class needs to execute code that is not already part of its members’ destructors.

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

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

Вот вы, будучи откровенным C++критином, себе такое в адрес C++ позволяете. За что вас заслуженно хлещут ссаными тряпками по морде лица.

Эта писулька сборник «хороших» практик по мнению ее авторов, но никто не запрещает тебе использовать свои «хорошие» практики, если ты понимаешь что ты делаешь. Так что не убедительно.

Если у тебя везде не пустые деструкторы, то значит у тебя до сих пор там new и delete, как в 90-е.

Вовсе не обязательно. Ресурсами являются не только динамически созданные объекты. Но и, например, коннекты к БД с транзакциями, сокеты (для которых нужно делать shutdown и close) и т.д.

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

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

Кстати, вы так и не ответили на заданный вам вопрос: на C++ еще продолжаете программировать или уже полностью ушли в Rust?

Последние пару недль пишу на Раст, доволен, как слон.