C++20 и 2D Graphics

Какой «вывод типов», алло? Там 4 функции тупо вызывается. Ты чтобы мусор вынести на мусорку в 15 метрах от подъезда, на машине ездишь?

Какой «вывод типов», алло?

Тот, из-за отсутствия которого приходится писать больше кода.

Ты чтобы мусор вынести на мусорку в 15 метрах от подъезда, на машине ездишь?

Нет. Но я еду на лифте. Причем 2 раза.

Чтобы позвать метод класса, теперь нужен вывод типов. Какая интересная история.

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

Нет виляй. Речь шла о многословности.

devzero> Вся «многословность» Си здесь исключительно в невозможности использовать сахар «вызов метода».

Так вот, не вся.

Если не задумываться об обработке паники и бросить ее — да, не будет. Какая от этого практическая польза?

Похоже мы о чём-то разном говорим. Что мешает панику ловить и обрабатывать? Или ты о том Result, который catch_unwind вернёт? Но он в сигнатуре функции не фигурирует.

Что мешает панику ловить и обрабатывать?

Панику можно отключить.

Ну и 99.9% либ используют Result. Поэтому толку от паники - 0.

Если мы пишем всё свое - да, можно сделать исключения на паниках, но какой смысл?

Смысла мало (с этим я и не спорил), но можно ведь.

Просто считаю, что заявления о том, что в Rust (Go) «нет исключений» не совсем честные.

Просто считаю, что заявления о том, что в Rust (Go) «нет исключений» не совсем честные.

Они вполне честные - исключений нет. Их можно сделать, но их даже в Си можно сделать. Наверное, правильно говорить «в Rust нет исключений, но есть всё необходимое для реализации исключений, которые буду ломать программу в зависимости от опций сборки».

Панику можно отключить.

Смотри выше.

Они вполне честные - исключений нет.

Ага, только есть (практически) аналогичная сущность с другим названием. Ничего реализовывать не надо, разве что catch более громоздкий получается.

буду ломать программу в зависимости от опций сборки

Передёргиваешь, добавляй, в таком случае, «с версии 1.10». Ну да ладно.

Безотносительно этого: какой по твоему процент приложений на расте будет использовать «abort» стратегию обработки паники? Интересен прямой ответ. Так-то я (тоже?) считаю, что возможная фрагментация библиотек по данному признаку - это плохо.

Ничего реализовывать не надо

Что, вообще ничего? Окей, покажи мне, как поймать Ex1 и игнорировать (передавать дальше) все остальные исключения.

Из того, что нужно для исключений, реализована раскрутка стека. Механизм сопоставления и языковые конструкции - не реализованы.

Передёргиваешь, добавляй, в таком случае, «с версии 1.10»

Зачем? Если время не указано, имеется в виду настоящее время.

Безотносительно этого: какой по твоему процент приложений на расте будет использовать «abort» стратегию обработки паники?

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

Так-то я (тоже?) считаю, что возможная фрагментация библиотек по данному признаку - это плохо.

" - Мне плохо? Мне плохо? ДА МНЕ П*Ц!!!11" (ц) анекдот

Вообще, со стратегией обработки ошибок у Rust сейчас всё плохо.

Что, вообще ничего? Окей, покажи мне, как поймать Ex1 и игнорировать (передавать дальше) все остальные исключения.

Как тебе такая наркомания?

Как тебе такая наркомания?

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

Окей, покажи мне, как поймать Ex1 и игнорировать (передавать дальше) все остальные исключения.

Вон уже показали. Давая уточним: ты считаешь, что если на реализацию такого перехвата придётся каждый раз писать условные 100 строк кода, то это означает «отсутствие исключений», так?

Просто я считаю, что отсутствием исключений можно было бы назвать отсутствие функций catch_unwind, resume_unwind, ну и/или «abort», как единственную стратегию «обработки» паники.

Вон уже показали. Давая уточним: ты считаешь, что если на реализацию такого перехвата придётся каждый раз писать условные 100 строк кода, то это означает «отсутствие исключений», так?

~$ cat ./test.c
#include <setjmp.h>
#include <stdio.h>
#include <string.h>

jmp_buf try_blocks__[256];
jmp_buf *try_blocks_end__ = try_blocks__;
void pop_try_block(int* p) { --try_blocks_end__; }
void* thrown_value() { static char r[1024]; return r; }

#define try for(int pop__ __attribute__ ((__cleanup__(pop_try_block))) = 0 ; pop__ < 1 ; ++pop__) if(!setjmp(*try_blocks_end__++))
#define catch else
#define throw(x) { __auto_type tmp = (x); memcpy(thrown_value(), &tmp, sizeof(tmp)); longjmp(*(try_blocks_end__ - 1), 1); }
#define rethrow longjmp(*(try_blocks_end__ - 2), 1)


int main(int argc, char** argv) {
    try {
        printf("Ok, let's begin.\n");

        try {
            printf("Nested try block.\n");
            throw(1.5);
            printf("I do not appear.\n");
        }
        catch {
            printf("Got Exception: %f\n", *(double*) thrown_value());
            rethrow;
        }

        printf("I do not appear.\n");
    }
    catch {
        printf("Got Exception again: %f\n", *(double*) thrown_value());
    }

    return 0;
}

~$ clang ./test.c
~$ ./a.out 
Ok, let's begin.
Nested try block.
Got Exception: 1.500000
Got Exception again: 1.500000

В С есть исключения! Можно еще прикрутить, например, GVariant и С11 и сделать такое:

try {
    printf("Ok, let's begin.\n");

    try {
        printf("Nested try block.\n");
        throw(1.5);
        printf("I do not appear.\n");
    }
    catch(double d) {
        printf("Got Exception: %f\n", d);
        rethrow;
    }
    catch(int n) {
        printf("Got Exception: %d\n", n);
    }
    finally {
    }

    printf("I do not appear.\n");
}
catch(double d) {
    printf("Got Exception again: %f\n", d);
}

Как минимум я сходу не вижу, что может этому помешать. Но по факту в С исключений нет и не будет. Так же и в Rust, если авторы языка захотят добавить языковые конструкции, то в Rust будут исключения, иначе - только костыли, которыми будут пользоваться единицы. И тут я с tailgunner'ом полностью согласен.

// CAPTCHA: Toilets LOVERS

В С есть исключения

Не, это ерунда а не исключения. Деструкторов или их аналогов нет, барьера на catch нет - локальный контекст поломается. В Rust, полагаю, это решено.

Деструкторов или их аналогов нет,

Ну это уже проблема С, а не «исключений».

барьера на catch нет - локальный контекст поломается

Подробней?

Ну это уже проблема С, а не «исключений».

Кроме того можно же finally запилить, и в нем чистить все что надо.

Ну это уже проблема С, а не «исключений»

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

можно же finally запилить, и в нем чистить все что надо

Половина удобства исключений теряется, придется в каждой функции с ресурсами писать try/catch/finally.

Подробней

Локальные non-volatile переменные ломаются при выходе из longjmp - могут кэшироваться на регистрах.

Можно еще прикрутить, например, GVariant и С11 и сделать такое:

Я бы с интересом посмотрел.

...которыми будут пользоваться единицы. И тут я с tailgunner'ом полностью согласен.

Так тут и я не спорю.

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

Эта проблема не только с исключениями, но и с goto, break, continue, return etc. Такой уж C - надо постоянно следить за ресурсами.

Половина удобства исключений теряется, придется в каждой функции с ресурсами писать try/catch/finally.

Да, но опять же такой уж С.

Локальные non-volatile переменные ломаются при выходе из longjmp - могут кэшироваться на регистрах.

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

Я бы с интересом посмотрел.

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

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

Давая уточним: ты считаешь, что если на реализацию такого перехвата придётся каждый раз писать условные 100 строк кода, то это означает «отсутствие исключений», так?

Нет. Если на реализацию исключений всякий жук и жаба будут писать по 100 строк, это означает, что исключений нет; если все жуки будут писать свои 100 строк, а все жабы - свои, то это будет значить, что исключений нет. Если все жуки и все жабы соберутся и выработают единые 100 строк, это будет означать, что в Rust есть неофициальная реализация исключений, которая иногда не работает.

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

подели свои знания на 0

вообще то умножать надо, а то совсем зазнается

Посмотрев на «батарейки» Python, std С++14 кажется прошловековым.

Разные вещи? ну да, разные, только прогеру побарабану где оно, оно должно быть!

А теперь объясни, каким образом тебе Qt запретила использовать современную инициализацию в конструкторе. А то получается, что Спартак продул Зениту, а у тебя телевизор сгорел.

А теперь объясни, каким образом тебе Qt запретила использовать современную инициализацию в конструкторе.

Любезнейший, вы точно читали то, что пытаетесь комментировать?

А теперь объясни, каким образом тебе Qt запретила использовать современную инициализацию в конструкторе. А то получается, что Спартак продул Зениту, а у тебя телевизор сгорел.

прошу заметить, что сраптак просрал ливерпулю 7:0

Ага. По крайней мере, начиная с

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

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

Ага.

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

Тараканы в голове отдельно взятого разработчика в качестве аргумента выглядят слабовато.

И поэтому вы спрашиваете личное мнение человека, у которого вообще проблем с использованием Qt и C++ нет? Ну логично, чё.

Да ладно тебе, не придирайся. Тулкитофобия у разработчика - это его сугубо личное дело, если на своём тулките он пишет хорошо.

Куда более забавно было, когда Harald начал отрицать полезность работы того же Xintrea с весьма оригинальными аргументами. Я хотел было поинтересоваться, о каком непонимании идёт речь, и как конкретно оно мешает работе MyTetra, но тему уже огородили (она действительно про другое была).

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

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

более квалифицированный опенсорсный разработчик всяко лучше менее квалифицированного

C++ не хватает всего того, что завезли в rust.

Из подобных проблем мне приходит в голову только отсутствие полноценной модульности

Ты наверно не видел ничего кроме C++ и паскаля.

Да и решить эту проблему, не ломая совместимость, сложновато будет

Ее решают, и есть шанс что к 20-му решат.

О, вот и баба Ванга подтянулась.

Лучше б по теме что-нибудь ответил. Модули нужны, но на фоне одних только концептов и рефлексии они - ничто.

Самое интересное, что все его мнение о switch свелось в всего к двум фразам (орфография сохранена):

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

В то время как ничего не понимающий Xintrea расковырял ассемблерный листинг и посмотрел как оно кодируется в машинных кодах.

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

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

Если кто-то не понимает, зачем это нужно, то это их проблемы (возня с include guards очень удобно же!). Совместимость и так ломается, как только начинают использовать новые возможности очередного стандарта.

Ещё не хватает кучки функций для работы со строками, чтобы каждый раз не городить велосипеды; человеческого форматирования вывода, хотя бы как в printf (или «безопасной» его реализации), а не того, что воткнули в std::cout - почему-то есть реализации в библиотеках fmt и в boost, но что-то их не запихивают в стандарт (лучше fmt - она легче); работа с сетью - да кому она нужна?; нормальные многомерные массивы и поддержка стандартных математических функций для работы с ними (valarray был хорошим началом, но так и остался одномерным), а так же срезы, маски, векторные индексы; switch case поддерживающий работу со строками; переход к метке для break, continue.

Да, согласен. В частности, форматированный вывод из std мне тоже показался крайне неудобным на фоне того же printf.

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

Вы бы это, за пределы своего унылого Qt-шного мира выглянули бы. Удивились бы. Свои строки уже лет 15-20 никто не пишет.

Может, потому, что тех, которые наплодили 15-20 лет назад, хватит ещё на 30? У GLib/GObject свои строки, у Qt свои. А в мире Windows-only программирования некоторые, не поверите, до сих пор используют MFC (в проектах, где нужна производительность, а не сисярп). И там, ЕМНИП, свой CString.

И всем этим люди пользуются...

Может, потому, что тех, которые наплодили 15-20 лет назад, хватит ещё на 30?

Может и поэтому. Может и не на 30, а на 60. Суть в другом: сейчас в C++ свои строки пишут или малолетние дебилы (с) патологические велосипедостроители, или же те, кому в связи с очень специфическими требованиями, ничего из уже существующего не подходит. Я, например, за последние лет 15 не видел самописных строк.

Насколько я помню, массовое строкостроительство имело место быть где-то до 1995-го. После уже все устаканилось, уже даже STL-евский string при желании можно было использовать. В начале 2000-х был еще небольшой хайп вокруг ROPE-strings. Но он как-то быстро стих и широкого применения ROPE-strings не нашли.

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

Это, блин, какой-то альтернативный взгляд на совместимость. Совместимость ломается, когда новый компилятор не может собрать старый код.

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

Не хватает. Но есть тот же Boost.StringAlgorithms. Недавно открыли Google Abseil, там есть алгоритмы для работы со стороками. Т.е. велосипеды городить давно не нужно.

человеческого форматирования вывода, хотя бы как в printf (или «безопасной» его реализации), а не того, что воткнули в std::cout - почему-то есть реализации в библиотеках fmt и в boost, но что-то их не запихивают в стандарт (лучше fmt - она легче);

AFAIK, автор fmtlib готовит предложение в коммитет по стандартизации.

работа с сетью - да кому она нужна?

Уже есть Networking TS, в C++17 не попала, идет работа над включением в С++20.

нормальные многомерные массивы и поддержка стандартных математических функций для работы с ними (valarray был хорошим началом, но так и остался одномерным), а так же срезы, маски, векторные индексы;

Предполагаю, какой вой начнется по этому поводу. В С++17 несколько специализированных математических функций добавили, уже куча недовольных с воплями. Для будущих версий С++ предложение по включению 2D-графики начали готовить (еще даже до принятия TS-а не дошло), а уже срач и вонизм на 10 страниц. С матрицами будет еще хуже, т.к. на практике они нужны еще меньшему количеству народа, чем 2D-графика + к тому библиотеки для этих целей существуют давно.

switch case поддерживающий работу со строками;

case для вещей, которых нет в языке? Да вы мечтатель. Ну вот нет в C++ такого понятия, как «строка». Может быть когда-нибудь появится, тогда можно будет и на счет switch-а по строкам говорить. Но вряд ли появится.

переход к метке для break, continue.

Спасибо, но для любителей писать на Fortran-е в языке с самого начала существует goto.

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

А вообще, для интересующихся, вот интересный и большой отчет о последнем заседании комитета в 2017-ом году: https://botondballo.wordpress.com/2017/11/20/trip-report-c-standards-meeting-...

Не хватает. Но есть тот же Boost.StringAlgorithms. Недавно открыли Google Abseil, там есть алгоритмы для работы со стороками. Т.е. велосипеды городить давно не нужно.

А ещё есть QString. Но оно ж всё здоровое и для мелких программ тащить их нет никакого желания. И вот здесь то все и начинают городить велосипеды.

С матрицами будет еще хуже ... к тому библиотеки для этих целей существуют давно.

Библиотеки есть много для чего, разной степени проработанности и иногда запущенности, без них было бы совсем тяжко :( А почему вой из-за пары математических функций поднялся не знаю, хуже никому не стало. А вот 2D в каких рамках предлагается использовать пока не совсем понятно. Неплохо, если будет поддержка отрисовки графических примитивов. В своё время на уроках физики учитель демонстрировал решение некоторых задач с использование графических возможностей какого-то Basic с выводом в консоль. В Turbo Pascal во время обучения подобная библиотека тоже полезна была.

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

Спасибо, но для любителей писать на Fortran-е в языке с самого начала существует goto.

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

AFAIK, автор fmtlib готовит предложение в коммитет по стандартизации.

А вот это хорошая новость, надеюсь, что у него получится. Боюсь, только, что в C++20 не успеет протолкнуть.

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

Ну да, посыпанный сахаром goto уже перестал быть goto. OK.

case для вещей, которых нет в языке? Да вы мечтатель. Ну вот нет в C++ такого понятия, как «строка»

Итераторов и begin/end в языке тоже нет, но range for с ними работает. В C# switch даже с пользовательскими типами работать может. Было бы желание.

Было бы желание.

О чём желании вы говорите? У вас, например, есть желание сделать соответствующее предложение в комитет?

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

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

Вы хотите сказать, что какой-нибудь break my_label делает код принципиально другим, нежели goto my_label? Если да, то покажите пример кода, на котором это было бы видно.

Я хочу сказать, что cycle cycle_name/continue cycle_name или exit cycle_name/break cycle_name в случае циклов нагляднее и удобнее чем goto 110/goto label_name, при этом отсутствует возможность промахнуться при установке метки строчкой и воткнуть её, как в случае 110/label_name, немного не туда. Об изменении структуры кода речь не шла. Не то, чтобы такие ситуации часто встречались, но если встречаются, то удобнее использовать первый способ.