хз

Удобный синтакс!

но если можно перед void то можно и после чо уж

[[attribute]] void [[attribute]] f() [[attribute]]; найдите функцию среди ее декларации

f() выдаёт тебя с головой.

это просто атрибуты короткие

Лучше уж тогда [[attribute]] void [[attribute]] f [[attribute]] () [[attribute]];

Есть мнение, что в таком виде реализация контрактов только усугубит ситуацию. Все будут ставить contract-level=always и по двадцать раз платить за одну и ту же проверку.

И вот тут я реально уже начал теряться.

void f(int x, int y) [[expects: x>0]] [[expects: y!=0]] [[ensures result: result > x+y]]; примеры то подлиннее будут

void f(int x, int y) [[expects: x>0]] [[expects: y!=0]] [[ensures result: result > x+y]]; примеры то подлиннее будут

Ок, резонно.

Контракты в С++ добавляют: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r3.html

о свежие пейперы

Есть мнение, что в таком виде реализация контрактов только усугубит ситуацию. Все будут ставить contract-level=always и по двадцать раз платить за одну и ту же проверку.

Да ну уж, все совсем дураки? Если им по умолчанию этот уровень не воткнут — то так не будет.

Есть мнение, что в таком виде реализация контрактов только усугубит ситуацию. Все будут ставить contract-level=always и по двадцать раз платить за одну и ту же проверку.

Поведение контракта регулирется опциями компилятора - в дебаг режиме их можно превращать в ассерты, в релизной сборке - в хинты оптимизатору

статическим анализом надо контракты гонять кек

Под то и задел

статическим анализом надо контракты гонять кек

Да, надо. Я так понимаю, компилятор будет пытаться что-то из этого сразу и проверять.

Надеюсь к C++20 сойдётся

вроде как в С++20 не успеют

Поведение контракта регулирется опциями компилятора - в дебаг режиме их можно превращать в ассерты, в релизной сборке - в хинты оптимизатору

Я про это и пишу. Энтерпрайз заставит своих разработчиков ставить always, ибо так типа безопаснее. И никие опции уже не помогут.

вроде как в С++20 не успеют

Ок, сошлись на том, что не успели 😉

Я про это и пишу. Энтерпрайз заставит своих разработчиков ставить always, ибо так типа безопаснее. И никие опции уже не помогут.

А энтерпрайз уже заставляет разработчиков всегда собирать в дебаге?

статическим анализом надо контракты гонять кек

под них и пляшут. одно из основных назначений - помощь статическому анализу

И писать всё на Java вместо C++, потому что «типа безопаснее»? 😂

Я про это и пишу. Энтерпрайз заставит своих разработчиков ставить always, ибо так типа безопаснее. И никие опции уже не помогут.

появляется опциональность. Нужна безопаность аки в джаве - выбираешь одно. Нужна скорость - выбираешь второе

И писать всё на Java вместо C++, потому что «типа безопаснее»? 😂

конечно безопаснее, что лучше - темплейты или генерики? )

это же прекрасно

конечно безопаснее, что лучше - темплейты или генерики? )

Лучше... ээ, ничего из этого? (Go?)

Лучше... ээ, ничего из этого? (Go?)

ахахах 😊

А энтерпрайз уже заставляет разработчиков всегда собирать в дебаге?

Нет, из-за слишком ощутимых различий в производительности. А плюс 10% из-за ассёртов уже колебать не будет.

как там generic programming в Go? Multiple cursors?

Нет, из-за слишком ощутимых различий в производительности. А плюс 10% из-за ассёртов уже колебать не будет.

Ну, гм, если эдак на 10% меньше самолётов упадёт, то пускай заставляют. Я не против.

[Note: An always contract-level is expected to be used for those contracts where the cost of run-time checking is assumed to be very small compared to the cost of executing the function and that should be checked regardless of the build mode. A default contract-level is expected to be used for those contracts where the cost of run-time checking is assumed to be small (or at least not expensive) compared to the cost of executing the function. An audit contract-level is expected to be used for those contracts where the cost of run-time checking is assumed to be large (or at least significant) compared to the cost of executing the function. An axiom contract-level is expected to be used for those contracts that are formal comments and are not evaluated at run-time. — end note]

Лучше... ээ, ничего из этого? (Go?)

го и правда лучше.. туда б еще генерики завезти..

го и правда лучше.. туда б еще генерики завезти..

Слишком сложно ⇒ ненадёжно!

Лучше, наоборот, выпилить чего-нибудь.

Ну, гм, если эдак на 10% меньше самолётов упадёт, то пускай заставляют. Я не против.

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

Ну, гм, если эдак на 10% меньше самолётов упадёт, то пускай заставляют. Я не против.

а как ты выберешь в каких 10% самолёта сидеть, чтобы они не упали?

а как ты выберешь в каких 10% самолёта сидеть, чтобы они не упали?

http://funpark.ru/item/6045

http://funpark.ru/item/6045

РАЗУМНО!

не знаю, по адресу ли вопрос. при сборке opencv с cuda 8, nvcc 7.5, постоянно вылезает ошибка nvcc fatal : Unsupported gpu architecture 'compute_60'

единственный раз, когда она не вылезла, это когда я из интереса поставила cuda generation = kepler

но вообще то это неправильно, потому что у меня ge force 1050, а это поколение pascal

вылезает на билде, cmake завершается успешно

CUDA 7.5 is not supporting pascal gpus.

так у меня 8 куда

nvcc 7,5

nvcc 7,5

чето фиг знает nvcc должен версию куды выдавать и должно быть 8.0

Интересно, почему std:: function не догоняет по функциональности лямбды? Нельзя mutable, только CopyConstructible...

Подскажите по логике. Хочу реализовать подобное: https://wandbox.org/permlink/TNeXmPKnkkXHEiWj Задача - запилить базовый класс с определенным интерфейсом, который бы требовал от наследника реализации, скажем: 1) алиаса using data_t = ...; 2) функции void foobar(data_t&) 3) еще каких-нибудь алиасов и функций чтобы всё это дело работало по CRTP и базовый интерфейс пользовался алиасами/функциями родителя. Алиасы, конечно, можно передавать в параметрах шаблона, а вот с функциями не прокатит. Есть мысли?

Любопытно, что incomplete не возникает при использовании функций из Parent, однако std::is_detected на функции из Parent фолсит

https://wandbox.org/permlink/vkhaARzRnF248dZk А вот здесь видно, что std::is_detected ломается. Код рабочий, но закомментированный static_assert фолсит и не даёт скомпилироваться. И это очень грустно

template<class Data> void f(Data& d) { static_assert(std::is_same< Data, typename Parent::data_t>::value, "parent Data type only accepted as f argument"); d++; }

А требование на существование самой функции где?

Я не хочу разбираться в ошибках компиляции, что где-то там Parent::f() нельзя вызвать, я хочу static_assert

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

Можно написать has_function если есть сигнатура и имя функции наверное.

И завернуть его в static_cassert

Посмотри мою последнюю ссылку :)

Там std::is_detected во всей красе. Служит ровно для этого

Только нифига не работает

Тип ещё не определён, можно просто перенести в тело функции.

Хм, хорошая идея, только надо обдумать

Либо разделить данные с интерфейсом и испльзовать множественное наследование и в CRTP делать cast<Data😠cast<Parent😠this)).

Да интерфейс не хранит данные, а работает с ними

CRTP это скорее обобщённая реализация интерфейса.

Так здесь он идеально заходит, если бы не incomplete type

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

Типы можно завернуть в отдельные traits ещё навреное....

template<class T> struct InterfaceTraits; template <class Parent> struct Interface { using traits = InterfaceTraits<Parent>; using data_t = typename traits::data_t; void f(data_t& d) { d++; } }; struct Foo; template<> struct InterfaceTraits<Foo> { using data_t = int; }; struct Foo : Interface<Foo> { };

Ну это ж извращение..

Всё-таки типы лучше передать через параметры шаблона

Но идея с переносом зависимости в отдельную шаблонную структура классная

Зависит от того сколько типов...

> Да интерфейс не хранит данные, а работает с ними Это что, просто алгоритм? А зачем тут CRTP тогда?

> Да интерфейс не хранит данные, а работает с ними Это что, просто алгоритм? А зачем тут CRTP тогда?

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

template<class ImplDetail> struct BasicAlgorithm { using data_t = typename ImplDetail::data_t; }; struct Foo { using data_t = int; }; using FooAlgorithm = BasicAlgorithm<Foo>;

Проблема в том, что сам интерфейс отнаследован от кое-чего важного и это что-то требуется и в интерфейсе, и в наследнике. Так что наследование отрубить нельзя

Значит, данные всё-таки есть?

Значит, данные всё-таки есть?

Ну хорошо. Данные есть :)

Ну хорошо. Данные есть :)

Тгда таки да, просто отложить CRTP на один шаг. template<class Target, class CommonBase> struct Mixin { using data_t = typename CommonBase::data_t; }; struct FooBase { using data_t = int; }; struct Foo : FooBase, Mixin<Foo, FooBase> {};