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

Я тоже, но это значит только то, что мы сами ископаемые.

Огласите весь список, пожалуйста.

Огласите область применения и задачи.

Заранее предупрежу, что под «двиганьем»(наверное лучше бы было сказать жонглирование?) я понимаю не только ручное управлени памятью, но и прочее увлечение «производительностями», «временем жизни» итп.

PS. «ископаемым gcc 4.2» — это мощно, да.

Не говори, C++ до 11-го стандарта вообще сплошная боль :(. Буст, конечно, эту боль немного смягчал, но добавлял много другой боли.

я еще и Turbo C++ помню

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

Не говори, C++ до 11-го стандарта вообще сплошная боль :(

Ерунда. GCC 4.3 предшествует С++11 (выпущен в 2008, ЕМНИП), и он уже вполне приличный.

Ты еще Borland C++ 2.0 вспомни.

быть ограниченным 4.2 в 2012 году - это как бы очень не ок

Быть в зоне комфорта - это очень важно.

очень

я еще и Turbo C++ помню

я тоже помню

«Маленькая ложь рождает большое недоверие, Штирлиц» (ц)

быть ограниченным 4.2 в 2012 году - это как бы очень не ок

Нет, конечно. Только надо понимать, что уже лет 5, как Си++ - это C++11.

«Маленькая ложь рождает большое недоверие, Штирлиц»

А где тут ложь?

Огласите область применения и задачи.

С чего бы? Вы сказали, что «Фигня в том, что для почти всего, кроме «двиганья байтиков» есть более комфортные инструменты.» Ну так назовите эти инструменты.

Заранее предупрежу, что под «двиганьем»(наверное лучше бы было сказать жонглирование?) я понимаю не только ручное управлени памятью, но и прочее увлечение «производительностями», «временем жизни» итп.

Ну т.е. если нужно сделать что-нибудь инфраструктурное, вроде СУБД или браузера, то придется погрузиться в это самое «двиганье».

Очень маловероятно, что ты помнишь именно Turbo C++ - его время было очень коротким (его почти сразу сменил Borland C++) и для того, чтобы его застать, тебе должно быть 40+ (ЕМНИП, тебе поменьше).

С чего бы? Вы сказали, что «Фигня в том, что для почти всего, кроме «двиганья байтиков» есть более комфортные инструменты.» Ну так назовите эти инструменты.

Ггг, ну раз область применимости не важна, ну, например, Go.

Ну т.е. если нужно сделать что-нибудь инфраструктурное, вроде СУБД или браузера, то придется погрузиться в это самое «двиганье».

тут есть один нюанс, большинство популярных сейчас СУБД или браузеров было писано ещё с 90х годов, когда альтернатив C или C++ было сильно меньше, а компьютеры сильно медленнее

ну, например, Go.
There is no inheritance in Go

Удачи.

тут есть один нюанс, большинство популярных сейчас СУБД или браузеров было писано ещё с 90х годов, когда альтернатив C или C++ было сильно меньше, а компьютеры сильно медленнее

Чушь, которую любят повторять любители недоязыков.

MS Edge вроде как написан совсем недавно, а он на C/C++. Назовите хоть одну популярную БД не на сях? Mongo вроде как новая, а на C.

Ггг, ну раз область применимости не важна, ну, например, Go.

Да, блин.

тут есть один нюанс, большинство популярных сейчас СУБД или браузеров было писано ещё с 90х годов, когда альтернатив C или C++ было сильно меньше, а компьютеры сильно медленнее

Ну да, поэтому СУБД, которые появились относительно недавно, пишут на C++ (скажем, MongoDB или RethinkDB). Или переписывают на C++ (Couchbase).

его время было очень коротким (его почти сразу сменил Borland C++)

а википедия пишет, что

Starting with version 3.0, Borland segmented their C++ compiler into two distinct product-lines: «Turbo C++» and «Borland C++»

В общем, почему-то в голове чётко отложилось Turbo. И почему-то версия 3.1 (хотя на тот момент уже Builder точно был).

Раскроешь мысль какие в расте проблемы с «вызовом функции»?

Возьмем самое простое:

string foo( optional<int> a ) {
    return a ? to_string( *a ) : "nil";
}

int bar( optional<string> s ) {
    return s ? stoi( *s ) : 0;
}

int main() {
    bar( foo( 123 ) );
}

Как будет выглядеть на rust?

MS Edge вроде как написан совсем недавно, а он на C/C++. Назовите хоть одну популярную БД не на сях? Mongo вроде как новая, а на C.

Cassandra, например.

Cassandra, например.

Встречайте ScyllaDB (переписанную на С++ Apache Cassandra)

Приведи примеры 64-бит систем, где int 64бит.

Например ILP64.

Приведи примеры 64-бит систем, где int 64бит.

Например ILP64.

Примеры живых систем. Понятно, что на 64-бит системе можно сделать int любой разрядности <= 64.

Как будет выглядеть на rust?

Вот так, если более-менее дословно.

fn foo(a: Option<i32>) -> String {
    match a {
        Some(val) => val.to_string(),
        None => "nil".to_owned(),
    }
}

fn bar(s: Option<String>) -> i32 {
    match s {
        Some(val) => val.parse().unwrap(),
        None => 0,
    }
}

fn main() {
    bar(Some(foo(Some(123))));
}

то суть претензий будет в отсутствии неявных приведений

Это только начало. Дальше:

fstream f( "file.txt" );
fstream f( "file.txt", ios_base::app );

Покажи чудеса выразительности на Rust, ведь то, что я сходу увидел в доке:

let mut f = File::open("foo.txt";

let file = OpenOptions::new().write(true).append(true).open("foo.txt");

это явно что-то другое, а я просто не нашел нужное.

Тогда это считается достоинством языка

LOL, а достоинство языка С, что надо руками вызывать malloc и free. А то этот ваш Rust что-то там неявно делает.

LOL, а достоинство языка С, что надо руками вызывать malloc и free.

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

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

Да, иногда оно бывает полезно. Ну так для этих случаев в расте существуют From/Into трейты.

это явно что-то другое, а я просто не нашел нужное.

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

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

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

Зачем передёргивать? Вряд ли, у тебя в плюсовом коде неявные приведения на каждом шагу.

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

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

Разжевываю (странно, что фанат языка сам не знает) - в Rust нет параметров по умолчанию. Потому авторы библиотеки и не могли сделать как в С++. Вот и родилось уродство в виде OpenOptions, которое уродливо в том числе потому, что в нем логика перевернута с ног на голову, и OpenOptions открывает файл, а не файл открывается с опциональными параметрами.

но ты обещал проблемы с «вызовом функций».

А это и есть проблема - нельзя вызвать функцию не использовав все параметры. Продолжаем:

set<int> s {};
set<int> s { 1, 2, 3, 4, 5 };

В С++ есть возможность использовать переменное кол-во аргументов (без шаблонов и макросов, с ними тоже можно), покажи аналог на Rust?

Таких, как в примере с optional, достаточно много.

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

«Выписывать руками» - для наглядности. По месту вызова видно что передаётся optional, а не значение. Можно, конечно, кричать, что это фатальный недостаток, но это компромисс. Явно/«надёжности» и краткости. Да, во многих случаях, неявные приведения никак не влияют на надёжность, но как по мне, лучше иметь одно правило, чем 100500 особых случаев.

Про опциональные параметры в курсе, просто не понял суть претензии. Согласен, это весьма неприятно.

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

Обычный «buider» паттенр, ничего особенного. Хотя и неприятно, что в нём есть необходимость.

В С++ есть возможность использовать переменное кол-во аргументов

Да, переменного количества аргументов тоже нет. Но тебе не кажется, что ограничения типа «чур без использования макросов» не слишком честные? Можно делать так (через стороннюю либу), например:

let v: Vec<i32> = collect![1, 2, 3];

Почему C++ сосет

Нечитабелен;
Неудобен в разработке (у связки CL+Emacs+Slime сосёт только в путь);
Код о-очень долго собирается. Истоки языка явно эстонские.

Преимуществ нет никаких. Когда скорость неважна – можно взять практически любой ЯВУ, а для перформанса пока ничего лучше C || asm нет.

Продолжаем:

Опережу тебя - ещё можешь успеть (до следующего релиза время есть) поныть про отсутствие специализации.

полегчало?)

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

// captcha antioch ben

Но тебе не кажется, что ограничения типа «чур без использования макросов» не слишком честные?

А я не ставил такие ограничения :) Можно и макросы. Кстати, я верно понимаю, что, если в С++ тот же вектор инициализируется целиком, то в Rust макрос родит массу одиночных вставок?

поныть

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

то в Rust макрос родит массу одиночных вставок?

Да, хотя предварительный resize (если нужен) всё-таки будет.

и не мне по их поводу ныть (или делать вид, что все хорошо и так и надо)

Ок, погорячился, «но ты первый начал».

И я не делаю вид, что прямо уж так замечательно. Отсутствие опциональных (и желательно - именованных) параметров - это реально убого. И хуже даже не дурацкие «билдеры», а загромождение стандартной библиотеки фигнёй типа (на примере HashMap) new, with_capacity, with_hash_state, with_capacity_and_hash_state. И соответствующие предложения имеются, но видимо ни у кого руки не доходят и приоритет отдаётся другим вещам.

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

презентацией серьезных, крупных, успешных, надежных и живых проектов

Такие проекты, чаще всего, являются приватным ноу-хау, таким образом никакая их презентация невозможна. Зачем коммерческой конторе брать и палить своё секретное оружие?

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

Конечно, в 2016 году пора бы убрать из определения C++ фразу «язык общего назначения». Оно давно уже язык специального назначения, за имением лучших инструментов общего назначения.

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

2016

Лисперы все еще считают что их язык кому-то нужен.

в Rust макрос родит массу одиночных вставок?

Нет. Данные будут перемещены (aka memcpy) в кучу, а Vec получит указатель на эту память.

Данные будут перемещены (aka memcpy) в кучу, а Vec получит указатель на эту память.

Речь про vec! или про collect! (нестандартный)? Или это справедливо для обоих?

Про vec!. Мой косяк.

Для collect! будет по элементу.

impl<T> Vec<T> {
    fn extend_desugared<I: Iterator<Item = T>>(&mut self, mut iterator: I) {
        // This function should be the moral equivalent of:
        //
        //      for item in iterator {
        //          self.push(item);
        //      }
        while let Some(element) = iterator.next() {
            let len = self.len();
            if len == self.capacity() {
                let (lower, _) = iterator.size_hint();
                self.reserve(lower.saturating_add(1));
            }
            unsafe {
                ptr::write(self.get_unchecked_mut(len), element);
                // NB can't overflow since we would have had to alloc the address space
                self.set_len(len + 1);
            }
        }
    }
}

Why Dorin Lazăr sux:

1. не сказал ничего нового

2. не сказал ничего неочевидного

3. не сказал ничего интересного

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

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

Лолшто, какие еще удобства? С нэймспейсами код DarkEld3r будет абсолютно аналогичным.

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

И как нэймспэйсы его сократят?

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

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

И как модули тому препятствуют?

https://github.com/janestreet/core/blob/master/src/uuid.ml

Вот пример janestreet core. Все подмодули и функции, которые должны быть видимы извне, входят в модуль Core и его подмодули. Твое представление о модулях, наверное, просто пасраликом каким-нибудь ограничевается. Расширяй кругозор — полезно.

Модули можно также открывать, вкладывать, но к тому же их еще можно наследовать и генерировать с помощью функторов.

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

В яве вот модули заменяют классы

Может покажете на примере? Поскольку в моем представлении, модули в Java — это package.

Поскольку в моем представлении, модули в Java — это package.

На каком примере? Каждый класс — модель, за примером в свинг.

Пакет — это не модуль.

несколько своеобразно

Чем? Что можно модули расширять и вкладывать друг в друга? Такие-то девиации, да. Модули как модули, в расте именно такие должны быть, впрочем, я его еще не тыкал его.

Может покажете на примере?

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

На каком примере? Каждый класс — модель, за примером в свинг. Пакет — это не модуль.

Вы бы сначала с терминологией определились: говорите ли вы про модЕли или про модУли. Это ведь разные вещи.

Ну и с моей точки зрения, package в Java — это тоже самое, что package в Ada или unit-ы в Turbo Pascal, module в Module-2 и т.д. Т.е. сущности для раздельной компиляции и раздельной поставки.

Чем?

Тем, что у некоторых функциональщиков модули воспринимаются сильно по-своему. Полагаю, в силу того, что в языках вроде OCaml или Haskell, где весь код, по сути, шаблонный, деление модуля на интерфейсную часть и реализацию (вроде того, что было в Module-2 и Turbo Pascal) попросту не имеет смысла.

Что можно модули расширять и вкладывать друг в друга? Такие-то девиации, да. Модули как модули, в расте именно такие должны быть, впрочем, я его еще не тыкал его.

Или я тебя не понял или в расте нельзя «расширять модули». В том смысле, что имея модуль А нельзя сделать модуль Б, который использовал такой же «неймспейс». Можно только сделать модуль АБ, который включал бы в себя оба и экспортировал необходимое.

Именно поэтому в C# есть и модули и неймспейсы.