T>>Можно примеры?
AG>Да, если рассматривать С++ Builder по сравению с современными продуктами —
AG>тот же Qt (со слотами и сигналами); C# (c поддержкой делегатов) — то система отправки и обработки сообщений в билдере выглядит очень скромно.

С# тогда не было еще. Что значит скромно по сравнению с Qt?

Ну, начнём с того, что я пока не вижу фич, которые поломают обратную совместимость. А если будут ломать — то в чём проблема сделать ключики компиляции? Старые либы, которые ломаются компилить как обычно, а новые фичи будут доступны в либах, скомпиленых с нужным ключиком (как, например в msvs есть ключики для разных версий языка, а можно делать и по другому — вообще только на фичи языка). Проблемы я вообще никакой не вижу.

А во-вторых, оно уже как бы да — auto, спецификация исключений И ничего, все выжили.

Здравствуйте, Слава, Вы писали:

С>Ну вот поэтому для mission-critical софт на C++ и не пишут. Используют либо Си, либо прочее такое, простое и сертифицированное.

Подозреваю, что дело прежде всего именно в простоте.
Сертифицированное, но сложное — ИМХО в таких местах также вряд-ли применят.
Если простое — то и крайнего найти (в случае проблем) всегда проще.

Здравствуйте, Privalov, Вы писали:

P>Pzz сказал же — это появилось в Снобол-4. Это 60-е годы прошлого века. Создатели Java тогда в детский сад ходили (те, кто уже родился).

Я не удивлюсь, если это появилось еще раньше. Я никогда не интересовался историей вопроса. Но в Сноболе это было сделано именно так.

Все давно украли до нас (ц)

Здравствуйте, turbocode, Вы писали:

T>С# тогда не было еще. Что значит скромно по сравнению с Qt?
Слоты и сигналы в Qt:
https://woboq.com/blog/new-signals-slots-syntax-in-qt5.html

НС>Не обязательно. Обычно просто делают регистронезависимый хэш. Приводить саму строку надо только если хеш совпал.

Только для английских букв я еще могу понять, но для общего случая нет

Здравствуйте, AlexGin, Вы писали:

AG>P.S. Возможность выполнить то же самое преобразование Фурье примерно в 100 раз быстрее на C++, нежели то же самое на C# (в управляемом коде) — с лихвой компенсирует эти небольшие недостатки.

Преобразование Фурье на С++ пишут только полные неадекваты, ибо GPU сделает это в десятки раз быстрее. Особенно если речь идёт об embedded системе, где обычно такие вещи и требуются — туда проще поставить ПЛИСку для (I)FFT, чем насиловать AP.

Здравствуйте, MTD, Вы писали:

MTD>Например, в С++ передали вектор в функцию не по ссылке — получили тормоз.
Ну да, С++ требует чтоб аффтар понимал что он делает.
Передача по ссылке, по const & и по значению — это ж три кардинально разных use case.

Здравствуйте, MTD, Вы писали:

MTD>Мне бы хотелось, чтобы наконец в стандарте появились адекватные средства для этого. Ты против?
Да, потому что будет как с другими стандартными всемогутерами: громоздко и неудобно но зато на все случаи жизни.
"А клиент хотел просто шину на верёвке" (С)
Так что нафиг, уж лучше мы своими специализированными фреймворками будем и дальше пользоваться.

Здравствуйте, MTD, Вы писали:

MTD>Ты про то, что угара нет? А по моему есть, в 3 раза слить Питону — это надо постараться.
А при чём тут С++ к криворуким погромистам? При должной кривизне верхних хваталок можно и в бОльшее колво раз слить.

Здравствуйте, AlexRK, Вы писали:

ARK>Я слышал, что планируется создание некоего "C++ lite" — простого подмножества. Было бы круто.
А что тебе мешает писать прямо сейчас на этом подмножестве?

Какой то нежный программист пошёл — всё ему надо чтоб за него делали.

Здравствуйте, scf, Вы писали:

scf>Просто для С++ почему-то не нашлось корпорации, которая бы родила к нему простой, но обширный рантайм.
Для всех платформ под который он существует?
Это будет такой суровый героизм!

Здравствуйте, MTD, Вы писали:

MTD>Нет, я хочу из коробки кроссплатформенно создать директорию. Это рокет сайнс?
Ты не поверишь но для абстрактной платформы в вакууме — да!
Кроссплатформ в этом плане страшное зло.

Здравствуйте, push, Вы писали:

P>2) Долго упирались на счёт range-based for. Ну хоть ввели. А интерфейсы стандартной библиотеки остались старыми. *FACEPALM* Ну хоть к с++20 опомнились.
А в чём проблема то? range for у меня в С++17 прекрасно жрал любые контейнеры, включая самописные.

P>3) Ввели потоки. Помню сколько фрики писались, что они не нужны, тра-ля-ля...
Потоки шмотоки! CreateThread наше всио!

P>4) constexpr — серьёзно?
Серьёзно, полезная вещь временами.

P>5) auto — до сих пор не понимаю как фрики пропустили эту вещь. О боже, работу компилятора переложили на компилятор. Почему изначально этого небыло — вопрос века. К с++50 доведут до ума.
А что там доводить то? Работает как надо

P>- отсталость основных конструкций: нет IPC, RPC, filesystem, DateTime, Plugin framework и т.д.
P>- отсутствие стандартных библиотек для основных направлений разработки ПО: audio, video, images, net, text processing, embedded, GUI, science, и т.д. короче тут можно перечислять вообще всё.
— отсутствие стандартной библиотечной функции give_me_money(size_t amount), ага.

P>*я пишу нет — это значит, что нет стандартных и удобных средств и библиотек. Так-то в плюсах всё есть. Теоретически. А практически либо переусложнённое, либо настолько раком вывернутое, что можно с уверенностью сказать — практически этого нет.
Ну не умеешь на плюсах — иди на то, где можешь и не мельтеши.

Здравствуйте, koandrew, Вы писали:

K>Преобразование Фурье на С++ пишут только полные неадекваты, ибо GPU сделает это в десятки раз быстрее. Особенно если речь идёт об embedded системе, где обычно такие вещи и требуются — туда проще поставить ПЛИСку для (I)FFT, чем насиловать AP.

Неадекваты — пытаются на форумах привести абсолютно всё к одной общей гребенке.
В той компании где я тогда работал, требовалось выполнить это на PC, в среде ОС Windows, при этом без спец-требований к аппаратуре.

P.S. Хорошо что я свалил оттуда пару лет назад
Однако сути это НЕ МЕНЯЕТ — цифры эти не с потолка, а из экспериментов.

Здравствуйте, CreatorCray, Вы писали:

CC>Для всех платформ под который он существует?
CC>Это будет такой суровый героизм!

Как будто разработчики компиляторов стандартную библиотеку всегда целиком портируют
Могли бы взять пример с Java — в ней рантайм делится на слои — от самого урезанного embedded до полноценной JRE.

Здравствуйте, scf, Вы писали:

scf>А вот как раз библиотек и не наблюдается.
scf>Набираем в гугле c++ unicode string и радуемся жизни и советам тащить iconv или юзать чей-то код с сотней звезд на гитхабе.
scf>Пример, конечно, единичный, но показательный. Правильно сделать юникод — задача непростая и посильная только крупной компании, которые почему-то не рвутся поддерживать опнсорс С++ библиотеки.

А чем Boost.Locale не устраивает? )))

Здравствуйте, MTD, Вы писали:

MTD>Мне например нужны юникодные строки, классы работы с временем и датой, файловые операции, модули, корутины — это только так навскидку, что нужно и чего нет.

И всё это (не считая модулей, которые очевидно нельзя реализовать библиотекой) имелось в Boost'е уже много много лет назад (и частично уже переехало в стандарт). Но у тебя же фобия на Boost, поэтому для тебя это реально проблема. ))) Сочувствую. )))

T>>С# тогда не было еще. Что значит скромно по сравнению с Qt?
AG>Слоты и сигналы в Qt:
AG>https://woboq.com/blog/new-signals-slots-syntax-in-qt5.html

И чё?

M>>Если тебе нужно хранить строки в нижнем регистре
MTD>Переведи в нижний регистр и храни. Что за дичь для этого класс делать? Во-первых, явное лучше неявного.
Вот есть у тебя куча объектов const std::string, неясного происхождения — было или не было вызвано приведение в нижний регистр при создании — хз, этж нужно явно делать. Как регистронезависимо сравнивать будешь их друг с другом?

MTD>Во-вторых, ты не сможешь использовать методы которые принимают std::string.
Метод стандартной библиотеки? Можно пример?
Твой собственный метод? Ты автор — пиши метод так чтобы он принимал все что должен принимать.