Почему C++ сосет (редакция 2016 года)

Сосёт он из-за:

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

Единственной полезной *возможностью* C++ являются деструкторы (при выключенных исключениях). Остальное всё не нужно, достаточно просто C :-)

Пространства имен не нужны, когда есть модули.

Аминь.

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

Там не выписана стандартная библиотека C. Максимум — перечисляются константы/имена функций, на которые опирается библиотека C++ и ссылаются на ISO C стандарт.

Про Java — не совсем так.

https://docs.oracle.com/javase/specs/

Описание всего-всего, и языка, и JVM, и стандартной библиотеки, не влезет и в 10к страниц.

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

А самое главное, этот стандарт почти никому не нужен. OpenJDK — референсная реализация. Гугл взял, и выкинул JVM, и все равно прорва кода работает и на JVM, и на Dalvik, и на ART. Ни разу не видел претензий «это не по стандарту, так что ССЗБ», а в плюсах такое слышно постоянно (GCC-измы, Windows-only, etc).

В общем, тут все просто несравнимо.

Пространства имен не нужны, когда есть модули.

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

Интересно насколько полезны они будут в С++ когда мы наконец-то до модулей доживём.

И откуда такие люди берутся? По всем пунктам полуправда и FUD.

Самая большая проблема C++ — отсутствие аннотированного стандарта, поэтому лепят всякую херню в типа return std::move(...); в возвращающем по значению методе.

Мейерс спасает, но у него, сука, словесное недержание. Лучше уж стандарт курить.

И вообще, странно. Разве можно любить плюсы?

Потому что сосёт. Ваш КО

И вообще, странно. Разве можно любить плюсы?

Пфф... Конечно можно. Главное вазелина побольше, чтобы вошло хорошо, дальше легче становится, ага. :-)

95% нативность идет именно из-за кроссплатформенности. Уже есть OpenCV/либы для нейросеток, они уже написаны на C/C++, и переписывать их никто не будет. Отсюда и приходит требование JNI.

С физикой та же петрушка: есть Box2D, на C++, его переписывать никому не нужно. Хотя есть его порт на Javascript, так что managed-язык производительности не помеха. По части 3D физик не в курсе, но, как понимаю, NVidia PhysX уже есть и работает, это раз, и постепенно переводится на ускорение видеокартами, это два.

Вообще, не вижу, почему на Java нельзя сделать всю эту машинерию. Главная проблема — GC, решается работой в статических массивах. На ARM, как понимаю, никаких особенных вывертов ассемблера нет, так что asm-вставки много скорости не прибавят. Из реальных плюсов у плюсов остаются только готовые библиотеки и кроссплатформенность. Производительность — это так, на сдачу.

Но их можно разбить на части.

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

И такой гадости, как UB, тут не наблюдается. И доступен кому угодно и нахаляву.

Про UB думаю ты и сам всё понимаешь. Плата за потенциальные оптимизации плюс сишное наследие.

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

А самое главное, этот стандарт почти никому не нужен.

Писать на плюсах, причём вполне профессионально, тоже можно даже не заглядывая в стандарт. Он нужен разработчикам компиляторов или для уточнения тонких вопросов. Впрочем, (почти?) на все такие вопросы, ответы будут и в другой, «написанной нормальным языком» литературе.

Интересно насколько полезны они будут в С++ когда мы наконец-то до модулей доживём.

Еще, кстати, интересно, какой эффект дадут на практике inline namespaces

I like to call myself stupid. It’s obvious that I am, that’s why I became a programmer – to make computers do the work for me, because I’m not to be trusted.

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

Еще, кстати, интересно, какой эффект дадут на практике inline namespaces

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

STL and Boost suck
They do suck and they suck big time.

Он нравится мне все больше и больше!

Мейерс спасает, но у него, сука, словесное недержание.

Мейерс завязал с C++ после того, как посвятил ему 25 лет своей жизни - «Anyway, I'm only mostly retiring from C++» http://scottmeyers.blogspot.ru/2015/12/good-to-go.html

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

Неделя травли C++ на ЛОР'e объявляется открытой!

Ага, пришла пора вылить очередной ушат помоев :-)

The code becomes incredibly hard to read when it has a lot of text with tags in them, like X_ptr code does.

What’s clear, however, is that boost libraries are a guarantee that your resulting code is as template heavy and as unreadable as possible.

The language is too complicated, it respects too much of the C legacy, and C can be a messy language.

Мейерс завязал с C++ после того, как посвятил ему 25 лет своей жизни

Он 1959-го года рождения. И вполне может завязать с программированием вообще. Как это недавно сделал Алекс Степанов.

Мейерс завязал с C++ после того, как посвятил ему 25 лет своей жизни

Я в курсе. Но его книжки ещё долго останутся актуальными.

И правильно. Ему, на минуточку, годков-то без малого 57. На пенсию пора.

Он 1959-го года рождения. И вполне может завязать с программированием вообще.

По его же признаниям, программирование последние 25 лет было связано исключительно с C++ - «I've spent the last quarter century focusing almost exclusively on C++, and that's caused me to push a lot of other things to the sidelines.». За 25 лет он стал таки экспертом по C++, мои поздравления :-)

Как это недавно сделал Алекс Степанов.

А этот вообще разочаровался в ООП: «I find OOP technically unsound.. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all.» :-)

Мне тут в одном растотреде рассказывали, что на самом деле Степанов считает, что обобщенные алгоритмы и шаблоны, это антиООП, да...

(заодно и проверю свои незнания)

C++ IDEs suck.
Даа, это именно у языку.

1. The split between source and headers
Не хочешь - не делай. Это фича, а не обязанность.

2 You still can’t write template code in .cpp files.
Это к тому, что шаблоны нельзя скомпилитть, а потом линковать? Ну так не компиль, кто ж мешает. Дело не в cpp, а как по-другому чделаешь?

3. C++ still uses the C preprocessor.
Этот препроцессор нужно расширять, а не убирать. Очень полезная штука.

4. Namespaces are useless and make the code way too verbose.
Задрали; нехочешь - не юзай. А вот от проблем они спасают периодически.

5. Lack of ABI makes it impossible to deliver C++ components without a C interface.
Не знаю. Честно.

It’s a barely portable language
Покажите мне компилируемый язык без проблем с protability

It’s a counterproductive language
Есть моменты, Но не прям чтоб уж так.

STL and Boost suck
Не знаю как на счет boost, к STL есть свои претензии касающиеся в первую очередь удобства. Но вцелом свою функцию выполняет. И привыкнуть можно.

C# equivalent (and seriously written from memory)

using System.Linq;
using System;
namespace X

Налетай!

Нет.

Язык это средство, а не фетиш. Каждый выбирает под свои задачи\предпочтения.

Добра тебе.

А разве это не так? ООП это subtyping, а шаблоны это parametric polymorphism.

C++ IDEs suck.
Даа, это именно у языку.

Именно к языку. Если язык не позволяет за 40 лет своего существования запилить нормальную IDE...

Я бы писал по умнее

Сначала русский язык выучи.

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

А классы-шаблоны, это что?

Это классы-шаблоны.

Пусть C<T> — шаблонный класс.
Простой вопрос: есть D это подтип B, то в каком отношении состоят друг к другу C<D> и C<B>.

А этот вообще разочаровался в ООП

Вот те раз! А какое отношение C++ имеет к ООП?

Меня всю жизнь напрягала неразбиваемая тройка тип-интерфейс-поведение. Хорошо, взяли и в Go сделали по-другому. Оно помогло? Нет.

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

за 40 лет своего существования

LOL, за 100 тогда уж.

запилить нормальную IDE...

Ты аргументы читал? К IDE у него претензии уровня - IDE хорошая, но компилятор не встроили, IDE хорошая, но я не осилил кросскомпиляцию, IDE хорошая, но я не умею в cmake и т.д.

Вот те раз! А какое отношение C++ имеет к ООП?

Не знаю, Страуструп неоднократно писал, что C++ - это язык, который напрямую поддерживает ООП :-) Дескать, средствами языка можно описать спроектированный по канонам ООП проект, выражая отношения между классами :-)

Зависит от внутренностей С, не?

хочет добавить

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

Не))

Почему?

Вообще, не вижу, почему на Java нельзя сделать всю эту машинерию.

Потому что тормозит. За примерами далеко ходить не нужно:

JPCSP на Java мало того, что хреново эмулирует, так жрёт ещё RAM и CPU так, как будто ему серверный XEON нужен.

PPSSPP на быстрых крестах, в отличие от Java-поделки работает на отлично и не жрёт системные ресурсы, как сумашедший, позволяя эмулировать PSP даже на слабых Android-устройствах.

JPCSP: http://i.imgur.com/H9loiej.png
PPSSPP: http://i.imgur.com/ZUALnx4.png
Кстати постом выше ты пукнул про Unity, так вот, Unity, как и Unreal Engine — тоже на C++, а C# или JavaScript используется лишь для скриптопараши, благодаря чему игру на Unity может сделать любой школьник и даже ты.

И такой гадости, как UB, тут не наблюдается.

Кстати, на счет взаимосвязи UB и быстродействия, совсем свеженькое: http://kristerw.blogspot.com.by/2016/02/how-undefined-signed-overflow-enables...

Спроси у создателей языка.

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

OMG! Ты нашёл один из двух с половиной случаев приминимости цепепе.

Эмуляция чужого железа.

Вон из профессии.

OMG! Ты нашёл один из двух с половиной случаев приминимости цепепе.
Эмуляция чужого железа.

А еще игра в эмуляторе написана на С++, а еще ядро современной Windows на С++, как и драйвер видеокарты, да и смотрел ты это все на браузере, написанном на С++, вероятно в Linux, ядро которого собрано компилятором написанным на С++.

Это ещё полтора случая.

Эмуляция чужого железа.

Именно. Угадай, на каком языке все популярные JVM для Java и других языков написаны.

Ну да. Рантаймы на C или C++.

Вообще, не вижу, почему на Java нельзя сделать всю эту машинерию. Главная проблема — GC

Отнюдь. Главная проблема - дорогие оптимизации компилятора, в частности оптимизации вложенных циклов, векторизация (в т.ч. скалярная), оптимизации агрегатов, межпроцедурные оптимизации. С JIT-компилятором они могут замедлить выполнение нечислодробильных программ, если применять их направо и налево, а в числлодробилке критичны.

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

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

Дык, нужного поведения можно и чисто модулями добиться ведь? Или я чего-то упускаю? Но вот пример (на расте):

mod some {
    pub mod impl_1 {
        pub fn foo() {
            println!("impl_1 foo");
        }
    }
    
    pub mod impl_2 {
        pub fn foo() {
            println!("impl_2 foo");
        }
    }
    
    // В зависимости от условия "делаем инлайновым" или один или другой модуль.
    #[cfg(foo)]
    pub use self::impl_1::foo;
    
    #[cfg(not(foo))]
    pub use self::impl_2::foo;
}

fn main() {
    some::foo(); // impl_2 foo
    some::impl_1::foo();
    some::impl_2::foo();
}

pub use self::impl_1::foo;

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

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

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

Угадай, на каком языке все популярные JVM для Java и других языков написаны.

Что ты этим хочешь сказать? Что C++ не сосёт?

для скопов и функций их не придумано.

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

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

Речь всё ещё про деструкторы? Тогда о каких костылях речь?