Я, скажем так, не видел ни одной программы на плюсах, в которой я бы мог быть уверен.
Учитывая, какое количество всякого софта написано на плюсах, Вы ими пользуетесь так или иначе. А уж ваше к ним доверие (я так полагаю, Вам нужно строгое доказательство корректности) — дело десятое.
Когда программа 95% времени ждёт IO, это не очень важно.
Не все программы заняты только вводом-выводом.
Может, я не в тех галерах работал, но они как-то обнаруживались. Даже побольше, чем на каком-нибудь го или котлине.
Хоспаде, ну Вы же прекрасно представляете какие результаты даст поиск по вакансиям на хаскелле и, к примеру, джаве. Там разница в пару порядков.
Как к range'ам из C++20 относитесь?
Никак. Я их не трогал, и их функционал мне пока что особо нужен не был.
А вообще на хаскеле можно спокойно и без вопросов писать код, который будет примерно аналогичен по понятности коду на каком-нибудь питоне, только со статическими гарантиями и с производительностью раз в 100-200 выше.
Видимо, толпа питонистов ещё не распробовала все сладкие плюшки хаскеля.
А никто не говорит, что мин под ногами нет. Всё программирование — это одно большое минное поле. Но на плюсах можно писать надёжные и эффективные программы. Да, скорость написания обычно ниже, чем в джавах и питонах, что, в принципе, коменсируется лучшей производительностью.
Тогда опшионалы в std::optional std::optional UserAddress (кек, хабр не переваривает шаблоны тоже) обозначают соответственно, например, отсутствие юзера в базе и присутствие юзера, но отсутствие его адреса.
Никогда не стал бы так писать просто потому, что это слишком неявно даже для автора.
Меньше кода заведомо надёжнее, чем больше кода (при прочих равных).
Имхо у Вас явно не прочие равные, если надо держать указатели за пределами массива. Но это всё разговоры ни о чём без примера кода.
Запускаю хром на C++
А есть для сравнения браузер на питоне?
То, что какая-то программа на каком-то языке жрёт память и тормозит, не означает, что на языке невозможно писать быстрые и эффективные программы.
Нет, не означает. Но только почему-то не пишут. CLion мне очень нравится, но он как жрал память гигабайтами, так и жрёт, хотя его пилит команда профи надо думать за хорошие деньги. Тот же VS работает обычно гораздо шустрее в среднем, а QtCreator ещё шустрее (во всяком случае так было пару лет назад). Есть прекрасный по возможностям и удобству гиткракен (написанный на питоне), который просто не вывозит крупные проекты, а есть встренный плагин в CLion, который работает шустрее.
А чего так?
Ну во-первых найдите такое количество гребцов на хаскеле для галер =)
Во-вторых: я люблю функциональщину (пусть это и любовь на расстоянии), но в классических задачах оно обычно малоприменимо. Просто потому, что функциональный код либо слишком плотный в плане смысловой нагрузки, либо мало отличается от классического в плане лаконичности, уступая при этом в простоте понимания.
Это несколько затрудняет написание обобщённого-кода.
Не совсем понимаю в чём проблема. Укажите явно аргумент шаблона, и не будет никаких неопределённостей. А приведение типов в вашем примере вполне логично. Во всяком случае мне трудно представить необходимость использования optional<optional >. И опять же при желании это всё проверяется соответствующими функциями.
Я-то и предложил использовать индексы, но вот не очень опытный в плюсах чувак не понял, в чём проблема, и зачем-то подключил тимлида, который в плюсах тоже не очень опытный, и ему стоило больших трудов доказать, что формировать указатель дальше arr + n для массива из n элементов нельзя.
Ну то есть проблема вообще ни разу не в плюсах. Для какой-то специфической задачи Вы решили пожертвовать надёжностью для краткости, а ваши коллеги в силу незнания добавили Вам проблем.
У вас есть какие-то подтверждения этому? Особенно той части, что «гораздо»?
Вот я каждый раз вижу на хабре и других ресурсах фразы вроде «добавьте вот эту строчку в код на питоне, и он будет работать почти так же быстро, как на плюсах» (и ваш пост недавний читал про быстрый хаскель), но почему-то когда я запускаю какую-нибудь программу на джаве или питоне, она явно жрёт больше памяти чем нужно и грузит процессор больше чем нужно. Получается, все знают, как на джавах писать эффективно, но никто не пишет?
А что вас позабавило?
Далеко не каждый выпускник топового технического ВУЗа сможет хорошо писать код в принципе, а Вы тут рассказываете о каких-то мифических ребятах, который через пол года шпарят на хаскелле как на родном языке. При том, речь шла, вроде как, о типичных бизнес-задачах, что в контексте хаскелля добавляет смеха.
Вы намекаете, что там может быть условный T, T& и T&&? Если да, то это можно проверить на этапе компиляции. Или явно указывать аргумент шаблона. Или не передавать всякое непотребство.
А чем будете? Итераторами? Так там та же проблема.
Какая проблема? Создать итератор за пределами массива? Зачем? Если уж Вам кровь из носа нужен такой костыль, то используйте индексы целочисленные.
Ну а мне вот пришлось, когда нужно было решать задачу эффективно. А если бы не нужно было её решать эффективно, то зачем брать плюсы?
Потому что не совсем эффективно на плюсах всё ещё гораздо эффективнее чем на шарпах или джаве.
Если мне не нужна топовая производительность, то можно вместо плюсов взять сишарп, джаву или вообще хаскель. Через полгода смышлёные ребята, которые на плюсах смогут быть самостоятельными, вам всё про профункторы расскажут и сами линзы напишут.
Не знаю что такое профункторы и линзы, поэтому не впечатлён. Но с хаскелля, конечно, посмеялся.
У нас с Вами, видимо, разное понимание «большинства случаев». Я профессионально пишу на плюсах 4 года (не бог весть что, но всё-таки), и ни разу мне не пришлось столкнуться с вашими примерами. Что я делаю не так?
Ваши выкладки прямо конспект типичного собеседования: выстрелил себе в ногу, чтобы похвастаться навыками оказания первой помощи.
какой конструктор тут вызовется?
Копирования. Конструктор перемещения обычно надо указывать явно.
Хочется прочитать данные из сокета в структуру?
У вас бинарный протокол? Есть куча либ для сериализации.
Хочется написать свой полувектор-полудек для POD'ов с некоей хитрой стратегией роста?
Типичная задача, каждый день что-то такое пишу.
Надо помнить о лайфтаймах объектов даже в случае POD'ов.
Не вижу проблемы в том, чтобы знать особенности того, что используешь при написании низкоуровневого кода.
Хочется сравнить две структуры эффективно?
Сравните неэффективно.
Не смей даже формировать указатель за пределы одного из массивов.
И в мыслях не было. Предпочитаю пользоваться указателями в крайних случаях.
В конце концов, можно ли взять свежих выпускников вузов и бросить их на плюсовый проект, надеясь, что они там будут так же производительны, как на каком-нибудь пусть даже жс или питоне? Думаю, что ответ вы знаете.
Смотря что считать производительностью: если вам нужно быстро набросать говнокод, берите питонистов, а если нужно, чтобы продукт не тормозил, то берите плюсовиков. Если у вас не куча легаси, а ребята смышлёные, то через пол года они станут вполне самостоятельными.
Я считаю, что в большинстве случаев на C++ можно написать понятный, надёжный и производительный код, не тратя какие-то большие ресурсы. Проблемы могут начаться только в случае, когда идёт война за байты и такты.
То есть понятно, что раст многие проблемы решает за счёт своего устройства, но при этом сильно теряется гибкость в плане безопасности. Тут, кстати, пример красочный проскочил: habr.com/ru/post/484436 Получается, что у пользователей раста нет возможности скрыть какой-то небезопасный участок кода внутри проекта, чтобы не мучиться с его вылизыванием.
Имхо спорно. На моей практике проще за три дня написать код на C++, написать для него тесты, отладить и исправить ошибку, чем неделю воевать с компилятором Rust за право успешно собрать код.
Есть шаблоны (templates) — механизм замены, но не такой блевотный, как в C++ (там это всё ещё просто текстовая замена, или уже что-то поумнее?).
Так, а чем плохи шаблоны в плюсах? Имхо явно лучше, чем в этом вашем nim, где можно пихать что угодно куда угодно.
Вообще от nim осталось впечатление какого-то франкенштейна, который сам не знает чем является.
Кто-нибудь сталкивался с внезапным исчезновением подсветки синтаксиса? Я поискал по багтрекеру, и ничего не нашёл. Проблему тяжело воспроизвести, но вроде помогает смена цветовой схемы подсветки.
Господи, ну сделайте уже в плюсах «нормальное» метапрограммирование (я почему-то думаю, что оно должно быть с состояниями на этапе компиляции), а то в языке много чего не хватает для хорошей жизни.
Реализовал недавно хороший вариант Enum (с итерацией, строковыми именами и поиском по этим именам) на основе упомянутой в посте статье. И оверхед малый из-за почти всего в compile-time, и пользоваться удобно, но последние компиляторы не дают собрать моё счастье — какие-то ребята из комитета коварно нашли и устранили «недоработку».
И что, мне теперь макросы фигачить?
*Вздыхает и устремляет печальный взгляд в сторону Rust*
Изобрёл свой велосипед, наткнулся на пост, и возник вопрос: почему так сложно?
Почему бы просто не сделать массив с указателями (например, тремя) и бегать по этому массиву счётчиком? При каждой записи мы просто лочим на запись, записываем в текущий элемент (следующий относительно «итератора чтения») массива, а затем инкрементируем итератор чтения. Остаётся только подождать, пока предыдущий элемент перестанут читать.
Набросал код:
Код
#include <atomic>
#include <array>
#include <thread>
template <typename Value_type>
struct Cell
{
Value_type read()
{
++_readers_counter;
auto result = _value;
--_readers_counter;
return result;
}
std::atomic<short> _readers_counter;
Value_type _value;
};
template <typename Value_type>
class Lock_free_cell
{
Lock_free_cell() :
_read_cell_pointer_id(0),
_pointers({new Cell<Value_type>{0},
new Cell<Value_type>{0},
new Cell<Value_type>{0},
new Cell<Value_type>{0}})
{ }
Value_type read()
{
auto cell_pointer = _pointers[_read_cell_pointer_id.load() % 4];
auto result = cell_pointer->read();
return result;
}
bool write(const Value_type& new_value)
{
while (_is_write.test_and_set())
{
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
auto read_pointer_index = _read_cell_pointer_id.load();
_pointers[(read_pointer_index + 1) % 4]->_value = new_value;
++_read_cell_pointer_id;
auto previous_read_pointer = _pointers[read_pointer_index % 4];
while (previous_read_pointer->_readers_counter.load() != 0)
{
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
_is_write.clear();
return true;
}
private:
std::atomic<unsigned char> _read_cell_pointer_id;
std::atomic_flag _is_write;
std::array<Cell<Value_type>*, 4> _pointers;
};
Простой пример: прикладной программист может не сильно задумываться о «правиле пяти» или о том, как правильно сделать swap для своего класса (и нужно ли его делать вообще). Тогда как разработчику библиотеки желательно не только иметь обо всем этом представление, но и уметь делать такие вещи чуть ли не на автомате.
Согласен. Мне просто кажется, что любой код должен писаться как библиотечный, т. е. для многократного использования.
Какие же они тайные? Вам ссылку дали, прошли бы по ней, нашли бы уже интересные ссылки, например, на доклады с CppCon-а. И сами бы эти знания приобрели бы.
Правильно ли я понимаю, что в доказательство кроссплатформенности C++ Вы приводите в пример Djinni, который создаёт мосты между кодом на плюсах и нативным кодом на платформе? И где тут кроссплатформенность конкретно плюсов?
Например, на C просто делать библиотеки, но неудобно. На Rust не просто (как и вообще программировать на Rust), но удобно. В C++ и не просто, и неудобно.
C предоставляет намного меньше возможностей, чем C++, поэтому и делать проще. Так-то библиотеки на C++ можно писать в чистом C стиле, и разница, насколько мне известно, будет минимальна.
Т. е. C и C++ одинакового порядка сложности языки, просто C++ больше, а значит для новых (относительно C) фич нужно больше знаний.
Поэтому-то я и прицепился к вашему сравнению, потому что относится к делу тут только сравнение с Rust, которое вообще говоря C++ проигрывает. Но в этом нет ничего удивительного, учитывая, что Rust создавался как замена C++.
Касательно Ada не могу сказать, ибо не знаком, но судя по малой распространённости, там своих проблем хватает.
Это я всё к тому, что сравнивая языки, нужно брать их из одной ниши, и в своей нише конкурент у плюсов только раст.
Ваше утверждение отнюдь не обратно моему. Они вообще друг другу не противоречат.
Вы из своего утверждения делали вывод:
И это еще одна причина, по которой C++у предпочитают другие языки даже там, где применение C++ выгодно.
Вот вывод-то у меня и другой: низкая осведомлённость о возможностях C++ не является причиной того, что его используют реже. Точнее, это в какой-то мере так, но влияние минимально, и проблема не исключительно плюсов, а свойственна любой технологии.
Очевидно, что вы спорите не со мной, а с тараканами в своей голове.
А с чем конкретно Вы не согласны? Ваше изначальное утверждение о том, что для разработки на языке A, который является расширением (пусть и не строгим) языка Б, нужна большая квалификация, чем для разработки на языке Б, видится мне совершенно бессмысленным ввиду очевидности и отсутствия конструктивных выводов. Я попытался так истрактовать ваше высказывание, чтобы придать ему какое-то значение в контексте разговора. Если был неправ, то каюсь.
ибо обратного здесь не видно
Хм, ваше утверждение: «о языке мало знают, поэтому не используют». Моё утверждение: «язык не используют не потому, что мало о нём знают». Где же тут обратное?
Между тем вы сами прекрасная иллюстрация того, почему C++ не используют даже там, где от него есть выгода.
Ну, Вам виднее. Продолжайте хранить свои тайные знания.
Вот не могу понять, как из тезиса «языки, в которых разработка библиотек не требует такой высокой квалификации, как в случае C++» прийти к вопросу о большем удобстве написания библиотек на C. Поделитесь логической цепочкой?
Не требуется квалификации -> проще -> удобнее. Хотя, я не понимаю как Вы сравниваете по этому параметру C и C++. Развлекаться с указателями проще, чем написать шаблонную функцию?
А прекрасную иллюстрацию сложности C++ недавно JetBrains сделал: blog.jetbrains.com/rscpp/cpp-quiz-cpp-russia-2019
Да, несколько сферических примеров в вакууме, которые с 99% вероятностью не встретятся на практике. К тому же большая часть из них просто не скомпилируется.
И где же здесь обратное?
Ваши слова были о том, что «мало кто знает», и поэтому не используют. Мои слова о том, что знают те, кому надо. А те, кому не надо, не использовали бы даже узнав.
в подтверждение тезиса о том, что на чистом C++ делают ядра кроссплатформенных приложений.
Делать могут на чём угодно, но о предпосылках к использованию плюсов в кроссплатформенном коде мне неизвестно.
Нет. В пример приводились языки, в которых разработка библиотек не требует такой высокой квалификации, как в случае C++. Причем если в библиотеке используется обобщенное программирование, то требования в C++ становятся еще выше.
Ну то есть на C удобнее писать библиотеки?
Как уже говорилось, в одном комментарии такой сложный вопрос не раскрыть.
Вы уже десяток написали так-то.
Пояснение «в трех словах» уже было дано ранее.
По поводу Dropbox Djinni не было.
мало кто сейчас имеет представление о возможностях C++ и о том, что на нем можно делать кроме «прямого доступа к памяти».
Мой опыт говорит об обратном: те, кому надо, имеют прекрасное представление, а остальные спокойно пользуются другими инструментами.
Вы, похоже, давно утратили нить разговора. Речь была о том, что на C++ можно писать так, что это будет просто, удобно, лаконично и это не будет вызывать никакой боли.
Речь была о том, что Вы ради своего удобства хотите притащить в язык вредные для него конструкции, которые конфликтуют с текущей парадигмой. И оправдываете это сложностью написания высокоуровневых библиотек. Я до Вас, в свою очередь, пытался донести, что если пихать в язык все «удобные» фишки, то он превратится в помойку. И что не стоит пытаться втащить язык во все ниши, для которых он не задумывался.
С конкретным примером.
Если Вы о коде со static if, то он принесёт больше боли, чем SFINAE и касты вместе взятые. Меня, как разработчика на C++, успокаивает лишь уверенность в том, что комитет никогда не догадается так «облагораживать» плюсы.
Вы мне приводили в пример языки, которые, как я понял, имеют преимущество перед плюсами в обобщённом программировании. Хотите сказать, что на C удобнее программировать те же контейнеры, чем на плюсах?
для разработки библиотек на C++ требуется высокая квалификация
Всё никак не могу понять чем C++ отличается в этом плане от других языков. И почему именно библиотек? Для приложений нужна меньшая квалификация?
в существующее C++ приложение за 15 минут
То, что вы тащите за собой готовый проект, и в нём внезапно понадобился какой-то особенный сервер (раз готовые решения не устраивают), не проблема языка.
Ну вот люди берут и без проблем используют.
Без проблем, но потом плачутся, что в плюсах слишком сложно работать с шаблонами, и предлагают обогатить язык совершенно чуждыми ему конструкциями? Или как это понимать?
Напрямую. Но чтобы это узнать нужно взять труд и ознакомиться с причинами появления этого инструмента.
Нет, спасибо. Если у Вас не хватает времени написать три слова для пояснения, то у меня для проведения исторической экспертизы — тем более.
На самом деле это не такая уж большая проблема.
Согласен, можно потерпеть. Но до тех пор, пока не используются вещи, зависящие от ОС или железа. Хотя, казалось бы, зачем использовать C++, если тебе не нужен какой-нибудь прямой доступ к памяти.
Или вот, помнится, были баги в том же std::thread от msvc под виндой. Не знаю, остались ли сейчас.
Да, обобщённое программирование на C — очень смешно.
Ada, насколько я понял, крайне редко используется.
В итоге единственный язык, который в данной категории конкурент C++ — это Rust, и он, внезапно, именно для этого создавался много позже плюсов.
По вашему — это забивание гвоздей микроскопом?
Ну можно было взять java или C# и написать тот же сервер за 15 минут, или взять готовые либы. А можно взять C++ и получить очень много веселья.
Поинтересуйтесь, если будет время и желание, таким проектом, как Dropbox Djinni. Почему он возник, для чего применялся.
И как он относится к кроссплатформенности C++?
Ну вот тот же SObjectizer, фрагмент кода которого и разбирался в обсуждаемой статье, работает под Win, Lin, macOS, FreeBSD, Android.
А что вы там делаете, кроме работы со стандартными либами?
Учитывая, какое количество всякого софта написано на плюсах, Вы ими пользуетесь так или иначе. А уж ваше к ним доверие (я так полагаю, Вам нужно строгое доказательство корректности) — дело десятое.
Не все программы заняты только вводом-выводом.
Хоспаде, ну Вы же прекрасно представляете какие результаты даст поиск по вакансиям на хаскелле и, к примеру, джаве. Там разница в пару порядков.
Никак. Я их не трогал, и их функционал мне пока что особо нужен не был.
Видимо, толпа питонистов ещё не распробовала все сладкие плюшки хаскеля.
А никто не говорит, что мин под ногами нет. Всё программирование — это одно большое минное поле. Но на плюсах можно писать надёжные и эффективные программы. Да, скорость написания обычно ниже, чем в джавах и питонах, что, в принципе, коменсируется лучшей производительностью.
Никогда не стал бы так писать просто потому, что это слишком неявно даже для автора.
Имхо у Вас явно не прочие равные, если надо держать указатели за пределами массива. Но это всё разговоры ни о чём без примера кода.
А есть для сравнения браузер на питоне?
Нет, не означает. Но только почему-то не пишут. CLion мне очень нравится, но он как жрал память гигабайтами, так и жрёт, хотя его пилит команда профи надо думать за хорошие деньги. Тот же VS работает обычно гораздо шустрее в среднем, а QtCreator ещё шустрее (во всяком случае так было пару лет назад). Есть прекрасный по возможностям и удобству гиткракен (написанный на питоне), который просто не вывозит крупные проекты, а есть встренный плагин в CLion, который работает шустрее.
Ну во-первых найдите такое количество гребцов на хаскеле для галер =)
Во-вторых: я люблю функциональщину (пусть это и любовь на расстоянии), но в классических задачах оно обычно малоприменимо. Просто потому, что функциональный код либо слишком плотный в плане смысловой нагрузки, либо мало отличается от классического в плане лаконичности, уступая при этом в простоте понимания.
Не совсем понимаю в чём проблема. Укажите явно аргумент шаблона, и не будет никаких неопределённостей. А приведение типов в вашем примере вполне логично. Во всяком случае мне трудно представить необходимость использования optional<optional >. И опять же при желании это всё проверяется соответствующими функциями.
Ну то есть проблема вообще ни разу не в плюсах. Для какой-то специфической задачи Вы решили пожертвовать надёжностью для краткости, а ваши коллеги в силу незнания добавили Вам проблем.
Вот я каждый раз вижу на хабре и других ресурсах фразы вроде «добавьте вот эту строчку в код на питоне, и он будет работать почти так же быстро, как на плюсах» (и ваш пост недавний читал про быстрый хаскель), но почему-то когда я запускаю какую-нибудь программу на джаве или питоне, она явно жрёт больше памяти чем нужно и грузит процессор больше чем нужно. Получается, все знают, как на джавах писать эффективно, но никто не пишет?
Далеко не каждый выпускник топового технического ВУЗа сможет хорошо писать код в принципе, а Вы тут рассказываете о каких-то мифических ребятах, который через пол года шпарят на хаскелле как на родном языке. При том, речь шла, вроде как, о типичных бизнес-задачах, что в контексте хаскелля добавляет смеха.
Вы намекаете, что там может быть условный T, T& и T&&? Если да, то это можно проверить на этапе компиляции. Или явно указывать аргумент шаблона. Или не передавать всякое непотребство.
Какая проблема? Создать итератор за пределами массива? Зачем? Если уж Вам кровь из носа нужен такой костыль, то используйте индексы целочисленные.
Потому что не совсем эффективно на плюсах всё ещё гораздо эффективнее чем на шарпах или джаве.
Не знаю что такое профункторы и линзы, поэтому не впечатлён. Но с хаскелля, конечно, посмеялся.
Ваши выкладки прямо конспект типичного собеседования: выстрелил себе в ногу, чтобы похвастаться навыками оказания первой помощи.
Копирования. Конструктор перемещения обычно надо указывать явно.
У вас бинарный протокол? Есть куча либ для сериализации.
Типичная задача, каждый день что-то такое пишу.
Не вижу проблемы в том, чтобы знать особенности того, что используешь при написании низкоуровневого кода.
Сравните неэффективно.
И в мыслях не было. Предпочитаю пользоваться указателями в крайних случаях.
Смотря что считать производительностью: если вам нужно быстро набросать говнокод, берите питонистов, а если нужно, чтобы продукт не тормозил, то берите плюсовиков. Если у вас не куча легаси, а ребята смышлёные, то через пол года они станут вполне самостоятельными.
То есть понятно, что раст многие проблемы решает за счёт своего устройства, но при этом сильно теряется гибкость в плане безопасности. Тут, кстати, пример красочный проскочил: habr.com/ru/post/484436 Получается, что у пользователей раста нет возможности скрыть какой-то небезопасный участок кода внутри проекта, чтобы не мучиться с его вылизыванием.
Так, а чем плохи шаблоны в плюсах? Имхо явно лучше, чем в этом вашем nim, где можно пихать что угодно куда угодно.
Вообще от nim осталось впечатление какого-то франкенштейна, который сам не знает чем является.
Реализовал недавно хороший вариант Enum (с итерацией, строковыми именами и поиском по этим именам) на основе упомянутой в посте статье. И оверхед малый из-за почти всего в compile-time, и пользоваться удобно, но последние компиляторы не дают собрать моё счастье — какие-то ребята из комитета коварно нашли и устранили «недоработку».
И что, мне теперь макросы фигачить?
*Вздыхает и устремляет печальный взгляд в сторону Rust*
Почему бы просто не сделать массив с указателями (например, тремя) и бегать по этому массиву счётчиком? При каждой записи мы просто лочим на запись, записываем в текущий элемент (следующий относительно «итератора чтения») массива, а затем инкрементируем итератор чтения. Остаётся только подождать, пока предыдущий элемент перестанут читать.
Набросал код:
Согласен. Мне просто кажется, что любой код должен писаться как библиотечный, т. е. для многократного использования.
Правильно ли я понимаю, что в доказательство кроссплатформенности C++ Вы приводите в пример Djinni, который создаёт мосты между кодом на плюсах и нативным кодом на платформе? И где тут кроссплатформенность конкретно плюсов?
C предоставляет намного меньше возможностей, чем C++, поэтому и делать проще. Так-то библиотеки на C++ можно писать в чистом C стиле, и разница, насколько мне известно, будет минимальна.
Т. е. C и C++ одинакового порядка сложности языки, просто C++ больше, а значит для новых (относительно C) фич нужно больше знаний.
Поэтому-то я и прицепился к вашему сравнению, потому что относится к делу тут только сравнение с Rust, которое вообще говоря C++ проигрывает. Но в этом нет ничего удивительного, учитывая, что Rust создавался как замена C++.
Касательно Ada не могу сказать, ибо не знаком, но судя по малой распространённости, там своих проблем хватает.
Это я всё к тому, что сравнивая языки, нужно брать их из одной ниши, и в своей нише конкурент у плюсов только раст.
Вы из своего утверждения делали вывод:
Вот вывод-то у меня и другой: низкая осведомлённость о возможностях C++ не является причиной того, что его используют реже. Точнее, это в какой-то мере так, но влияние минимально, и проблема не исключительно плюсов, а свойственна любой технологии.
А с чем конкретно Вы не согласны? Ваше изначальное утверждение о том, что для разработки на языке A, который является расширением (пусть и не строгим) языка Б, нужна большая квалификация, чем для разработки на языке Б, видится мне совершенно бессмысленным ввиду очевидности и отсутствия конструктивных выводов. Я попытался так истрактовать ваше высказывание, чтобы придать ему какое-то значение в контексте разговора. Если был неправ, то каюсь.
Хм, ваше утверждение: «о языке мало знают, поэтому не используют». Моё утверждение: «язык не используют не потому, что мало о нём знают». Где же тут обратное?
Ну, Вам виднее. Продолжайте хранить свои тайные знания.
Не требуется квалификации -> проще -> удобнее. Хотя, я не понимаю как Вы сравниваете по этому параметру C и C++. Развлекаться с указателями проще, чем написать шаблонную функцию?
Да, несколько сферических примеров в вакууме, которые с 99% вероятностью не встретятся на практике. К тому же большая часть из них просто не скомпилируется.
Ваши слова были о том, что «мало кто знает», и поэтому не используют. Мои слова о том, что знают те, кому надо. А те, кому не надо, не использовали бы даже узнав.
Делать могут на чём угодно, но о предпосылках к использованию плюсов в кроссплатформенном коде мне неизвестно.
Ну то есть на C удобнее писать библиотеки?
Вы уже десяток написали так-то.
По поводу Dropbox Djinni не было.
Мой опыт говорит об обратном: те, кому надо, имеют прекрасное представление, а остальные спокойно пользуются другими инструментами.
Речь была о том, что Вы ради своего удобства хотите притащить в язык вредные для него конструкции, которые конфликтуют с текущей парадигмой. И оправдываете это сложностью написания высокоуровневых библиотек. Я до Вас, в свою очередь, пытался донести, что если пихать в язык все «удобные» фишки, то он превратится в помойку. И что не стоит пытаться втащить язык во все ниши, для которых он не задумывался.
Если Вы о коде со static if, то он принесёт больше боли, чем SFINAE и касты вместе взятые. Меня, как разработчика на C++, успокаивает лишь уверенность в том, что комитет никогда не догадается так «облагораживать» плюсы.
Вы мне приводили в пример языки, которые, как я понял, имеют преимущество перед плюсами в обобщённом программировании. Хотите сказать, что на C удобнее программировать те же контейнеры, чем на плюсах?
Всё никак не могу понять чем C++ отличается в этом плане от других языков. И почему именно библиотек? Для приложений нужна меньшая квалификация?
То, что вы тащите за собой готовый проект, и в нём внезапно понадобился какой-то особенный сервер (раз готовые решения не устраивают), не проблема языка.
Без проблем, но потом плачутся, что в плюсах слишком сложно работать с шаблонами, и предлагают обогатить язык совершенно чуждыми ему конструкциями? Или как это понимать?
Нет, спасибо. Если у Вас не хватает времени написать три слова для пояснения, то у меня для проведения исторической экспертизы — тем более.
Согласен, можно потерпеть. Но до тех пор, пока не используются вещи, зависящие от ОС или железа. Хотя, казалось бы, зачем использовать C++, если тебе не нужен какой-нибудь прямой доступ к памяти.
Или вот, помнится, были баги в том же std::thread от msvc под виндой. Не знаю, остались ли сейчас.
Да, обобщённое программирование на C — очень смешно.
Ada, насколько я понял, крайне редко используется.
В итоге единственный язык, который в данной категории конкурент C++ — это Rust, и он, внезапно, именно для этого создавался много позже плюсов.
Ну можно было взять java или C# и написать тот же сервер за 15 минут, или взять готовые либы. А можно взять C++ и получить очень много веселья.
И как он относится к кроссплатформенности C++?
А что вы там делаете, кроме работы со стандартными либами?