гиперсложности, связанной с тоннами нюансов, на изучение и понимание которых уходит неимоверное количество времени и мозгоциклов. Не зря же в книгах по C++ говорится, что C++ - это язык, который следует изучать постепенно. Пока всё освоишь в мире появится много-много других интересных вещей и событий :-) И дело тут далеко не в синтаксисе, как наивно думают новички;
неудобства использования идиом и приёмов; Не зря же сказано: «простые вещи на C++ делаются сложно, а сложные не делаются вообще»;
выносящего мозг аппарата типов, с которым либо приходится бороться изо дня на день, чтобы добраться до финиша;
исключений и навязанной в их связи философией «программист всегда должен быть на чеку, так как в любой момент может возникнуть исключение»;
из-за трудностей ограничится самым малым его подмножеством, и, как следствие, риска постепенного вовлечения в проект всех его возможностей, из-за которых код становится гиперсложным для понимания.
Единственной полезной *возможностью* C++ являются деструкторы (при выключенных исключениях). Остальное всё не нужно, достаточно просто C :-)
Специально для идиотов - он большой только из-за того, что там выписана стандартная библиотека, в том числе и стандартная библиотека С.
Там не выписана стандартная библиотека C. Максимум — перечисляются константы/имена функций, на которые опирается библиотека C++ и ссылаются на ISO C стандарт.
Описание всего-всего, и языка, и 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 думаю ты и сам всё понимаешь. Плата за потенциальные оптимизации плюс сишное наследие.
А вопрос «доступности» провокационный. Если хочешь спора из-за формальностей, то ок - ты «победил». Если интересует практическая сторона, то последний драфт тоже доступен бесплатно.
А самое главное, этот стандарт почти никому не нужен.
Писать на плюсах, причём вполне профессионально, тоже можно даже не заглядывая в стандарт. Он нужен разработчикам компиляторов или для уточнения тонких вопросов. Впрочем, (почти?) на все такие вопросы, ответы будут и в другой, «написанной нормальным языком» литературе.
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.
Пока нет. Но как раз хороший пример того, что пространства имен и модули могут друг друга отлично дополнять. И что у каждой из этих вещей могут быть уникальные возможности.
Он 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.» :-)
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
Только что вверху гнал на namesapce'ы
Короче, да, товарищ что-то неасилил. Я бы писал по умнее :)
Причем деструкторы есть только для одного класса объектов; для скопов и функций их не придумано. Зато придумана куча костылей в стандартной библиотеке.
Меня всю жизнь напрягала неразбиваемая тройка тип-интерфейс-поведение. Хорошо, взяли и в Go сделали по-другому. Оно помогло? Нет.
Чтобы сделать что-то похожее, о чём пытается сказать Степанов, нужен язык уровня хаскеля. Вперёд и с песней. Только в нагрузку ты получишь сложнейший языковой рантайм (50k строк на чистом C), без понимания тонкостей работы которого, невозможно писать реальные программы.
Ты аргументы читал? К IDE у него претензии уровня - IDE хорошая, но компилятор не встроили, IDE хорошая, но я не осилил кросскомпиляцию, IDE хорошая, но я не умею в cmake и т.д.
Не знаю, Страуструп неоднократно писал, что 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 может сделать любой школьник и даже ты.
OMG! Ты нашёл один из двух с половиной случаев приминимости цепепе. Эмуляция чужого железа.
А еще игра в эмуляторе написана на С++, а еще ядро современной Windows на С++, как и драйвер видеокарты, да и смотрел ты это все на браузере, написанном на С++, вероятно в Linux, ядро которого собрано компилятором написанным на С++.
Вообще, не вижу, почему на 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();
}
То есть, в языках, где нет неймспейсов, как отдельной сущности, модули полностью берут на себя их функциональность. Хотя в С# неймспейсы имеются, хотя язык довольно новый. Другое дело, что модули довольно часто к файловой системе привязывают. И вот тут неймспейсы могут быть удобнее просто из-за того, что меньше приседаний делать приходится. Особенно при рефакторинге. Вот и интересно есть ли ещё какие-то преимущества кроме «мелкого удобства».
Для любого более-менее серьезного модуля количество таких use-ов будет слишком большим, чтобы выписывать подобное ручками.
И вот тут неймспейсы могут быть удобнее просто из-за того, что меньше приседаний делать приходится. Особенно при рефакторинге.
Ну в этом и поинт, что если противопоставлять модули пространствам имен, то теряются «мелкие удобства» либо того, либо другого. Гораздо лучше, когда эти вещи дополняют друг друга.