С++ 2018

Где Царь?

Его jollheef забанил. И ах, как не вовремя. Надо найти, извиниться и накинуть 50 скора или тред для него открыть.

пустой unique_ptr бесплатен по памяти

Не бесплатен. Занимает памяти столько же, сколько и обычный указатель. С custom deleter'ом чуть побольше. Но согласен, оверхед от него пренебрежительно мал.

Пока тут вяло обсуждается унылый вброс от ударенного лиспом по дотнету неадеквата, в Интернетах споры кипят вокруг реально интересного наброса: «Modern» C++ Lamentations

Ribbon
Microsoft Surface Dial
Ответ «ненужно» не принимается.

Ненужно!

Есть еще AOT

Вот это оно, но раз так мало кто делает, видимо есть подводные камни. Ну ок, 1-й пункт засчитываем.

Но этого всё ещё мало. Есть ещё второй пункт. У многих языков есть AOT, да ещё и без сборщика мусора - дельфи, фортран, паскаль... Тем не менее, в отсутствие хорошего оптимизирующего компилятора, они всё равно проигрвают в производительности.

В общем, C# ещё нужно сделать, хотя бы, фронтенд к гцц или ллвм, тогда будет путём. Либо свой компилер написать того же уровня, чего они не осилили.

Да и то, под x86 чемпионы по скорости - не гцц и шланг, а icc.

Это всё хорошо, пока тебе нужно только формочки шлёпать. А как начинаться вещи требующие скорости и отсутствующие в либах доступных через jni, то начинается C++.

Гугли про локальность памяти, фрагментацию,

обеспечивается средствами ОС и libc

фрагментацию

неактуально на 64 битах

итд.

так что же там?

А про умные указатели вообще говорить нечего даже, это помоему очевидно. Но можешь также погуглить «reference counting vs gc performance»

умные указатели - это, в первую очередь, unique_ptr

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

Думаю, что в случае с Фортраном, да еще на вычислительном коде, это будет сильно не так.

Да и в Паскале раньше на ряде операций был проигрыш, но только потому, что там проверки в run-time выполнялись (например, выход индекса за пределы массива). Если директивами компилятора эти проверки отключались, то и скорость оказывалась сравнимая со скоростью C++. По крайней мере во времена, когда Паскаль еще был актуален, сравнения производительности Паскаля и C/C++ регулярно производились.

Гугли про локальность памяти, фрагментацию, итд. А про умные указатели вообще говорить нечего даже, это помоему очевидно. Но можешь также погуглить «reference counting vs gc performance»

Ловко. Теперь твои же тезисы должны доказывать твои оппоненты.

Чем трей не универсален и убог? Вот уж насколько системди-хейтеры неадекватны, но Хейтеры трея даже их переплюнул.

А за что?

Уже даже Rust версию сделали.

Ну и ranges пока что даже плюсовиками как-то не очень принимаются, ибо страшные. Да и время компиляции жуткое.

Уже даже Rust версию сделали.

И что это должно показать?

Ну и ranges пока что даже плюсовиками как-то не очень принимаются, ибо страшные.

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

Во-вторых, в ranges много всего. Что страшного, скажем, в:

extern std::vector<int> read_data();
using namespace ranges;
std::vector<int> vi = read_data() | action::sort | action::unique;

Да и время компиляции жуткое.

Есть мнение, что после добавления концептов в компиляторы, это время станет поменьше.

Уже даже Rust версию сделали.

Ужоснах. Действительно, это тот случай, когда даже императивный кот выглядел бы лучше итераторов. Хотя лучше всего было бы что-то вроде list comprehension.

Ну и ranges пока что даже плюсовиками как-то не очень принимаются, ибо страшные.

Не страшнее дефолтных итераторов.

И что это должно показать?

А вы подумайте.

Что страшного, скажем, в

Это слишком примитивный пример.

А вы подумайте.

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

Давайте я вам объясню одну простую вещь, которую вы, так уж получается, не понимаете: есть такой старый и активно использующийся язык — C++. Ну вот вышло так, что на нем написана туева хуча софта и просто так никто от этого софта не откажется, и никто этот софт просто так на каком-то другом языке не перепишет. Будь то Java, C# или Rust.

А раз так, то есть нетривиальный такой вопрос: как развивать C++ дальше? Так сделать его использование удобнее, но и безопаснее, как повысить продуктивность разработчика.

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

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

Это слишком примитивный пример.

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

Чем трей не универсален

тем что там не гуёвых демнонов нет. Очевидно же. Тем что он ограничен по размеру и если туда пихнуть всё что работает фоном будет лента в несколько рядов во весь экран. Тем что там описания того что там висит нет и т.д. и т.п..

Ну вот вышло так, что на нем написана туева хуча софта и просто так никто от этого софта не откажется

Бесспорно

как развивать C++ дальше?

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

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

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

Те же Фортран и Кобол живут себе (доживают) без новых фич, вот и C++у пора. Когда-то и Rust переполнится и новое в него перестанут добавлять, сделают другой язык.

Очевидно же что попытки развивать переполненное тормозят прогресс.

Для растишки нет Qt

Отличный повод сделать process separation.

А зачем?

Затем, что ваши последующие предположения, а именно:

Те же Фортран и Кобол живут себе (доживают) без новых фич, вот и C++у пора. Когда-то и Rust переполнится и новое в него перестанут добавлять, сделают другой язык.

оторваны от действительности. Целиком и полностью.

Я то как раз понимаю. Проблема в том, что не все согласны с результатами «как развивать C++ дальше?».

Можно даже вспомнить С, у приверженцев которого полная ортодоксальность и «C89 хватит всем». А это язык ещё старше и популярнее.

А Rust тут при том, что на него можно ориентироваться. Ибо это единственная альтернатива C++.

Покажите что-нибудь пострашнее.

let data1 = &[1, 2, 3, 4, 5];
let data2 = &[1, 2, 3, 4, 5, 6];
    
for (a, b) in data1.iter().zip(data2).skip(1).step_by(2) {
    println!("{} {}", a, b);
}

Вывод:

2 5
4 3

Я то как раз понимаю.

Судя по тому, что вы пишете:

А Rust тут при том, что на него можно ориентироваться.

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

Ну и зачем мне пример на Rust-е? Вы хотите, чтобы я вам его на ranges-v3 изобразил?

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

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

Не понимаете.

Речь шла про комитет, а не про вас.

Вы хотите, чтобы я вам его на ranges-v3 изобразил?

А к чему тогда был ваш пассаж? Разве ranges не являются аналогом итераторов из Rust?

А по-русски?

То, что он коряво реализован в линуксе, не значит, что концепция плохая.

ubuntu != linux

В KDE можно выбирать что показывать, а что нет.

Речь шла про комитет, а не про вас.

Я тут вообще не причем. Это вы не понимаете. Хоть и пользуетесь двумя этими языками, но что-то не видите между ними разницу. Что, при вашем уровне владения C++, вполне ожидаемо.

Соответственно, комитет берет из других языков то, что можно адаптировать под C++ (тот же if constexpr наглядный пример). Но работа комитета — это вообще сильно специфическая штука. Которую вы так же вряд ли понимаете.

А к чему тогда был ваш пассаж?

Я вас просил показать C++ный код с ranges, который, по вашему мнению, выглядит страшно.

Разве ranges не являются аналогом итераторов из Rust?

С хрена ли?

Уже даже Rust версию сделали.

Ужоснах.

Вот первая Си++-версия из «Lamentations» - это да, ужоснах (или просто ужос? трудно сказать). А Rust-версия, особенно если ее выравнять нормально, вполне терпимо.

да что ж тебе с++ в штаны-то срёт постоянно. прям какой-то копрохолокост.

Благо дело вы всё понимаете.

Апелляция к авторитету - это уровень Царя, что печально.

Я вас просил показать C++ный код с ranges, который, по вашему мнению, выглядит страшно.

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

Апелляция к авторитету - это уровень Царя

Да где была апелляция?

Он в принципе страшный. В этом и проблема.

Давайте уточним: мы все еще про ranges или уже про C++ вообще?

Если про ranges, то примеры ужастности в студию.

Да где была апелляция?

Не придуривайтесь.

Если про ranges, то примеры ужастности в студию.

Что непонятного во фразе «в принципе»?

Не придуривайтесь.

В очередной раз вы обосрались с доказательной базой.

Что непонятного во фразе «в принципе»?

Непонятно к чему относится «в принципе», т.к. в исходном предложении было: «просил показать C++ный код с ranges». Ваше «в принципе» можно трактовать и как «в принципе C++ный код страшный», так и «в принципе код с ranges страшный».

Так вот, если мы все еще про ranges, то что страшного в уже показанном коде:

extern std::vector<int> read_data();
using namespace ranges;
std::vector<int> vi = read_data() | action::sort | action::unique;

Процесс, который рулит логикой, написан на Rust и ограничен по сисколам для необходимого минимума работ. Рудиментарный процесс на C++ рулит только мордой (на qml) и имеет доступ только на проходку по директориям. Данными обмениваются через анонимный domain сокет.

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

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

если С++ такой плохой - не пиши на нём. это же так просто.

Так ему за кодирование на C++ деньги платят. А на Rust он пока не может перейти, т.к. для Rust-а, при всех его достоинствах и продуктивности разработчика, хотя бы жалкого подобия Qt еще не написали.

Ну а сменить работу на какую-то другую, где можно без C++ обойтись, видимо, нет возможности, желания или того и другого вместе.

хехехе.

раст походу станет чем-то типа клуба анонимных алкоголиков, которые пострадали срачиной от С++.

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

Те же Фортран и Кобол живут себе (доживают) без новых фич

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

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

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

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

Куда приехали?

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

Суть в том, что для большинства задач, которые стояли перед разработчиками раньше (т.е. 30-40 лет назад, когда C++ появлялся), да и которые стоят сейчас, достаточно было безопасных языков. Ну вот так уж получается, что людям свойственно ошибаться, поэтому разработчики то с индексами ошибутся, то память забудут выделить, то не освободят, то освободят, но не ту или освободят повторно.

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

Но раньше было две серьезнейшие проблемы.

Первая - это мощность вычислительной техники. Если у тебя всего 16MHz и 4Mb памяти, то проверять каждый индекс в run-time или отдавать память на откуп GC, слишком жирно. Поэтому широкое распространение получил C и другие языки с гарантиями из категории «мамой клянусь».

Вторая - это сложность решаемых задач и требующаяся для этого выразительность языка. Ну вот как-то так получилось, что тот же C и тот же Pascal оказались не очень-то удобны для написания сложного софта. Тогда как ООЯ с этим более-менее справлялись.

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

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

Плюс большое количество новых разработчиков, зачастую недоученных.

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

Что, собственно, мы и наблюдаем с конца 90-х на примере роста популярности Java, C#, Scala и динамически-типизированных языков до кучи (всякие Python-ы, Groovy, Ruby, Erlang-и и иже с ними).

Но время опять изменило ситуацию. Мощность компьютеров все еще растет, но просто так получить прирост в быстродействии уже не получается. Да и выяснилось, что подходы на базе VM, когда якобы пишешь один раз, а работает потом везде, как это мы видим в JVM, не сильно-то и нужны. Т.е. как рекламный слоган в 90-е вполне себе, но сейчас это уже больше понты. И уж тем более это плохо работает на мобильных устройствах (поэтому Apple вообще всю эту шнягу с Java на iOS зарубила).

Поэтому появился интерес к нейтиву. Вот Go отлично зашел. Но Go слишком примитивный. А C++ — древний, большой, сложный и опасный. Ну так почему бы тогда не Rust?

Для многих задач, которые решаются на C или C++, Rust зайдет вполне себе. А с учетом обилия криворуких недоучек, так это вообще будет наилучшим выбором. По крайней мере коэффициент спокойного сна будет сильно выше.

Так что для нового софта Rust вполне себе OK (хотя убогости синтаксиса это не отменяет). Что вовсе не значит, что C++ нужно закапывать.

В никуда. Как вы предлагаете хранить таблицу, чтобы с ней можно было работать в Rust и отображать в Qt?

В никуда. Как вы предлагаете хранить таблицу, чтобы с ней можно было работать в Rust и отображать в Qt?

Понятия не имею, какие к работе с этой таблицей требования. Но я предполагаю, что две тыщи строк вполне себе влезают в память процесса, и при скроллинге мы запросто можем их подгружать, передавая через сокет. Мы ведь не дампаем их все сразу, верно? Если уж мой vim, читая данные с диска, справляется, то мы тоже как-нибудь сможем.

В ваших фантазиях - да.

for (a, b) in data1.iter().zip(data2).skip(1).step_by(2) {

#include <iostream>
#include <range/v3/all.hpp>

using namespace ranges;

int main()
{
    std::array data1{1, 2, 3, 4, 5};
    std::array data2{1, 2, 3, 4, 5, 6};
    
    for (auto t : view::zip(data1, data2) | view::drop(1) | view::stride(2)) {
        std::cout << t.first << " " << t.second << std::endl;
    }
}

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

Он в винде и есть убогий. А меню то же самое что и через условный systemctl командами можно сделать. Можно дать API и для своих действий, чтоб не было обидно разработчикам.

Картина маслом: Благородные доны рассказывают быдлу как жить.

В ваших фантазиях - да.

Я уже и забыл, что ты не очень адекватный.

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

но вот с тем что именно раст «закопает С++» - я категорически несогласен. если что я ваш блог на блогспоте смотрел. так вот: беда в раста в том, что его коммунити - это люди именно что «умученные от С++». причем умученные на галерах.

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

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

кстати отмечу, что сама концепция языка программирования - она из 60х. тогда, нет .. ТОГДА! это было прорывным подходом. но на мой взгляд, язык программирования нужно преобразовать во что-то иное. с одной стороны, язык рулит: буквами писать удобно. с другой: есть проблема «сложности», когда тебе надо держать в уме много особенностей. Например: класс Х кидает исключение в методе Y, эту переменную могут поюзать из соседнего потока, и т.д. Это всё в итоге - finite state machine. и для них лучшая форма представления - это диаграмма с возможностью представления её частей в виде текста программ. то есть должен быть смешанный режим. графическая форма представления fsm - компактнее и удобнее простыней текста, особенно когда работаем «по событиям».

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

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