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

+ уходит пласт проблем с fallthrough в части случаев

О! http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1235r0.pdf

да, это получше constexpr! :D

да, это получше constexpr! :D

это вообще ужос, я считаю

да, это получше constexpr! :D

constexpr(true)

хм

О! http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1235r0.pdf

а как же аргументы мол что переносимость пострадает? в стандартной либе что-то использует simd например, а в другой реализации нет.

это навряд ли может быть причиной. поменяют синтаксис просто. как это делается с метаклассами

кмк, лучше б синтаксис был такой: const Vec3 opengl_color = switch(c) { red => Vec3(1.0, 0.0, 0.0) yellow => Vec3(1.0, 1.0, 0.0) green => Vec3(0.0, 1.0, 0.0) blue => Vec3(0.0, 0.0, 1.0) };

а как же аргументы мол что переносимость пострадает? в стандартной либе что-то использует simd например, а в другой реализации нет.

а как пострадает переносимость?

Вот это вообще огонь http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1135r1.html Хочу ожидание на атомиках в стандартной библиотеке!!

там вроде какой то пропозал есть constexpr by default

было б неплохо

а как же аргументы мол что переносимость пострадает? в стандартной либе что-то использует simd например, а в другой реализации нет.

Ага, этот аргумент остаётся

constexpr(true)

а может посмотреть в сторону атрибутов? [[constexpronly]] constexpr bool isXXX(...) { ... }

было б неплохо

так вот вроде его скинули implicit constexpr

Ага, этот аргумент остаётся

я не понимаю аргумента

а как пострадает переносимость?

constexpr int value = std::some_function(); и вот для some_function не определено в стандарте должна ли она соответствовать constexpr стандартам.

а может посмотреть в сторону атрибутов? [[constexpronly]] constexpr bool isXXX(...) { ... }

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

constexpr int value = std::some_function(); и вот для some_function не определено в стандарте должна ли она соответствовать constexpr стандартам.

но в Стандарте функции, которые constexpr, помечаются constexpr

но в Стандарте функции, которые constexpr, помечаются constexpr

ну, придется тогда все остальные пометить как constexpr(false)

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

ай, чорт. эта дискуссия в разрезе того пропозала :)

Это я упустил :) прошу прощения. Тогда с Вами согласен

Ещё очень хорошая штука http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1285r0.pdf Позволит найти ошибки в тех местах, о которых никто и не догадывался )

И ещё mmap http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1031r1.pdf

И ещё mmap http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1031r1.pdf

интересная почта у него :)

Вот эти последние 2 — очень круты

Вот это вообще огонь http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1135r1.html Хочу ожидание на атомиках в стандартной библиотеке!!

а вот тут я не понял. Какая-то гиперспециализация получается. Это вроде всё и так легко реализуется на существующих атомиках, только то, что есть — гораздо гибче.

Ещё очень хорошая штука http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1285r0.pdf Позволит найти ошибки в тех местах, о которых никто и не догадывался )

о, оно еще и баги в стд пофиксит

а вот тут я не понял. Какая-то гиперспециализация получается. Это вроде всё и так легко реализуется на существующих атомиках, только то, что есть — гораздо гибче.

Увы, но реализровать это очень нетривиально Например ожидание на атомиках требует использования futex на Linux

Оно должно выглядеть как-то вот так: https://github.com/boostorg/sync/blob/develop/include/boost/sync/events/auto_reset_event.hpp

а вот тут я не понял. Какая-то гиперспециализация получается. Это вроде всё и так легко реализуется на существующих атомиках, только то, что есть — гораздо гибче.

Как-то странно будет стандарт выглядеть, если в нём это окажется, но при этом семафоры нужно будет всё ещё делать на мютексе и кондваре)

Как-то странно будет стандарт выглядеть, если в нём это окажется, но при этом семафоры нужно будет всё ещё делать на мютексе и кондваре)

да не важно уже - всё равно почти никто полностью не читает :)

Как-то странно будет стандарт выглядеть, если в нём это окажется, но при этом семафоры нужно будет всё ещё делать на мютексе и кондваре)

есть же POSIX https://linux.die.net/man/7/sem_overview или я чего-то не понял?

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

На кой хрен нам ещё паттерн матчинг тут в С++?

На кой хрен нам ещё паттерн матчинг тут в С++?

а чо нет?

а чо нет?

Ну, очень развесистая концепция, и совсем не в духе С++.

а switch вообще не развесистый

Это утверждение?

да, саркастическое

Ну switch не развесистый. Он простой по концепции. Есть сравнение и константы типов, всё на этом строится.

надо сделать operator switch() для классов, и в нем делать всякие стркмп и то, что душе угодно

он простой по реализации, а вот по концепции как раз сложный: нужно понимать, что можно пихать в switch, как работает fallthrough и объявление переменных в блоке switch

надо сделать operator switch() для классов, и в нем делать всякие стркмп и то, что душе угодно

?

есть же POSIX https://linux.die.net/man/7/sem_overview или я чего-то не понял?

в posix есть, а в стандарте нет. Если хочется переносимости — приходится делать свой семафор

он простой по реализации, а вот по концепции как раз сложный: нужно понимать, что можно пихать в switch, как работает fallthrough и объявление переменных в блоке switch

Чего? что там сложного?

Увы, но реализровать это очень нетривиально Например ожидание на атомиках требует использования futex на Linux

ага. Уловил. Это не спинлоки, а блокирование, передающее управление при неудачном локе, но не использующее API ядра. Тогда, пожалуй, полезно.

Чего? что там сложного?

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

ну это все на мой взгляд, конечно

ну это все на мой взгляд, конечно

Вот именно, что на твой.

ну как видишь, не мне одному нравится паттерн матчинг)

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

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

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

+1

Да ладно. Паттерн матчик дичайше удобная штука.

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

ну это очевидно, что голову на плечах нужно иметь в любом случае. Речь же об удобстве и читаемости. switch очевидно в этом проигрывает

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

Да ладно. Паттерн матчик дичайше удобная штука.

Ну вот так чтобы я спал и видел чтобы он был в С++ -- так нет.

Ну вот так чтобы я спал и видел чтобы он был в С++ -- так нет.

А у меня — есть.

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

А так-то мы и без constexpr можем прожить. Да и без лямбд остаётся функции и std::bind. ;P

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

Пример можешь показать? Кусочек?

А так-то мы и без constexpr можем прожить. Да и без лямбд остаётся функции и std::bind. ;P

классы тоже не нужны, просто делаем void method(Foo* this);

Пример можешь показать? Кусочек?

Любой код, где идёт активная работа с variant. Вместо overload-костылей прекрасно можно использовать pattern matching.

Добрый день комрады, можете подсказать по такому вопросу, активно изучаю разработку vst плагинов. Из можно из под unix среды как то тестировать, я так понимаю если уж ведётся разработка, то дебаг своего приложения надо осуществлять на винде, или я не прав?

А причем тут С++? Впрочем, audacity работает и под linux.

Добрый день комрады, можете подсказать по такому вопросу, активно изучаю разработку vst плагинов. Из можно из под unix среды как то тестировать, я так понимаю если уж ведётся разработка, то дебаг своего приложения надо осуществлять на винде, или я не прав?

можно тестить и в винде, и на линуксе, т.к. VST - это, грубо говоря, DLL с нужными точками входа

Но вот там написано, что Audacity поддерживает плагины эффектов, но не инструментов... (ну и странно было бы)

А где можно более детально на эту тему почитать инфу?

Да хрен знает...

Aoudour или как его там, есть на лине и должен VST поддерживать.

https://ardour.org/features.html -- написано, что может.

Я давно его пощупать хочу...

https://m.habr.com/post/224911 Я только это нашёл на тему создания плагинов, но из под юниксов это я так понимаю не запустить

https://m.habr.com/post/224911 Я только это нашёл на тему создания плагинов, но из под юниксов это я так понимаю не запустить

Выше то ты что, не читал?

Что нам понадобится Mac с Xcode 4 или выше, или Windows с Visual Studio C++ 2010 или выше

Видели что предлагают pattern matching? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1308r0.html

Как-то выглядит совсем плохо

Что нам понадобится Mac с Xcode 4 или выше, или Windows с Visual Studio C++ 2010 или выше

а там CMake'а разве нету?

Улетели в @supapro.

Вот зачем вы так с человеком... Даже задание не дослушали до конца. Может там надо вывести это в compile time

Вот зачем вы так с человеком... Даже задание не дослушали до конца. Может там надо вывести это в compile time

Судя по supapro, то нет, увы)

Именно вывести, не создать в памяти, а вывести. Причем циклом!

Вот зачем вы так с человеком... Даже задание не дослушали до конца. Может там надо вывести это в compile time

compile time io, звучит как прорыв

Дык с этого начинали - выводили факториал в сообщение компилятора об ошибке