мне нужна тулза которую не надо месяцами кастомизировать

+

и система плагинов радует

Вим — фигня, сублайм — параша. Имакс, вперёд, победа наша!

Вим — фигня, сублайм — параша. Имакс, вперёд, победа наша!

#holywar

Вим — фигня, сублайм — параша. Имакс, вперёд, победа наша!

С таким заявлением вам лучше сюда: pro.cxx.holywars

Вим — фигня, сублайм — параша. Имакс, вперёд, победа наша!

Превышено содержание Столлмана в крови

ща только ноготь доем

ща только ноготь доем

лисп любишь?

эх, вот помню писал в универе lr/ll парсеры для лиспа на лиспе, хорошее время было

Собственно, std::function начинает инстанцировать _func_impl с шаблонным параметром, зависящем от типа lambda - выражения. В итоге линковщик выдает предупреждение при включенном /ODR, что _func_impl<lambda_type, [...]> нарушает ODR.

Догадок лучше у меня нет :) Можно завтести тикет и смотреть что скажут разработчики VS

Догадок лучше у меня нет :) Можно завтести тикет и смотреть что скажут разработчики VS

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

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

Так там лямбда без захвата параметров же

вопрос: являются ли well-formed по стандарту конструкции вида template <typename T> inline std::function<void()> f(T * object) { return [object](){}; }

template <typename T> inline std::function<void()> f(T * object) { return [object](){}; }

с захватом

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

само по себе, например, инстанцирование разных шаблонных подстановок при одинаковых шаблонных параметрах не является нарушением ODR?

1к сообщений за день?

Хорошо, что не за минуту

само по себе, например, инстанцирование разных шаблонных подстановок при одинаковых шаблонных параметрах не является нарушением ODR?

мне бы пример...

мне бы пример...

Тот же самый. Возврат осуществляется как std::function, в данном случае используется ее шаблонный конструктор (причем параметром шаблона будет тип лямбда-выражения) template <typename T> inline std::function<void()> f(T * object) { return [object](){}; }

на мой взгляд всё ОК со стороны стандарта

ладно, чиркну тогда завтра feedback to microsoft

хмм, имею две функции которые принимают анонимные функции разного типа: typedef QSharedPointer<Stream> Reference; typedef std::function<Reference ()> FunctionS; typedef std::function<void ()> FunctionV; Stream::attach(FunctionS function); Stream::attach(FunctionV function); к сожалению не работает, компилятор ругается: C2668 'Stream::attach': ambigious call to overloaded function не могу понять как разрешить ситуацию, подскажет кто?

а строку вызова покажи плиз

stream->attach([this, transaction, chunkSize]() { return write( transaction->fileId, transaction->uploadProgress, chunkSize ); }) write() возвращает Reference (QSharedPointer<Stream>)

stream->attach([this, transaction, chunkSize]() -> Reference { а так?

stream->attach([this, transaction, chunkSize]() -> Reference { а так?

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

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

Неужели помогло?

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

Такое еще с функциями, возвращающими auto, работает. Особенно в 11 стандарте, где еще не было дедакшена.

Неужели помогло?

хммм, чёт нет, не хочет

C2668: ambigious call to overloaded function по прежнему

https://stackoverflow.com/questions/22146749/overload-resolution-with-stdfunction

Если коротко, то std::function разрешается "отбросить" возвращаемый тип. И обе функции можно сконвертировать в std::fuction<void()>

только там не возвращаемый, а принимаемый, не?

т.е. эта пропблема решена в C++14 ?

Это не проблема, это фича.

только там не возвращаемый, а принимаемый, не?

Возвращаемый std::function<Reference ()>

В C++14 хотя бы гарантируется SFINAE при конвертации в std::function

Возвращаемый std::function<Reference ()>

я про ссылку на SO. там std::function<void()> и std::function<void(int)>

я про ссылку на SO. там std::function<void()> и std::function<void(int)>

Note that there's been a slight change to the wording above, due to LWG 2420: There's an exception that if the return type R of a std::function<R(ArgTypes...)> is void, then any return type is accepted (and discarded) for the Callable in the constructor template mentioned above. For example, both []() -> void {} and []() -> bool {} are Callable for std::function<void()>

я про ссылку на SO. там std::function<void()> и std::function<void(int)>

А, это да. Но там в комменте и про возвращаемый есть: void foo(std::function<void()>); void foo(std::function<bool()>); foo([]() -> bool {}); // ambiguous

хммм, я немного растерян этим немалым потоком инфы, в данном случае я пытаюсь упростить интерфейс библиотеки чтоб не приходилось писать: ->attach([]( const StreamHandle& handle, const QVariant& data, ) { Q_UNUSED(stream) Q_UNUSED(data) // ... return nullptr; }) а можно бы было просто: ->attach([]() { // ... })

это вообще, в таком случае, возможно?

Не возвращайте void Возвращайте, допустим, struct Unit{};

Не возвращайте void Возвращайте, допустим, struct Unit{};

А если возвращать struct Unit : {int a[0];}?

да можно оставить и Reference и возвращать nullptr

без перегрузки attach

А если возвращать struct Unit : {int a[0];}?

Важно, чтобы Stream::attach(std::function<Unit()> function); а не Stream::attach(std::function<void()> function);

в сущности перегрузка с void это всего лишь сахар

Важно, чтобы Stream::attach(std::function<Unit()> function); а не Stream::attach(std::function<void()> function);

Надо потестить, будет ли оно нормально работать. У меня как-то были траблы с зеросайзед объектами.

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

int boo() {return 0;} void boo() {}

не скомпилируется

отсюда и std::function ведет себя подобным образом

Надо потестить, будет ли оно нормально работать. У меня как-то были траблы с зеросайзед объектами.

но они же нe zero sized

короче нельзя перегрузить attach разными типами ламбды

придётся тогда nullptr возвращать по старинке

можно, если будут разные сигнатуры

можно, если будут разные сигнатуры

не совсем понял, поясни пожалуйста

ну, если они будут отличатся числом или типом параметров

отсюда и std::function ведет себя подобным образом

Но std::function при конвертации учитывает возвращаемое значение. Спецэффект именно с void.

Но std::function при конвертации учитывает возвращаемое значение. Спецэффект именно с void.

короче нельзя из ламбды void возвращать, правильно я понял?

можно

можно

ну так иначе же хрень будет с resolving'ом?

std::function<void(void)> x = []{return std::string();}; компилируется. В этом проблема

ERROR: S client not available

можно, если нет перегрузки с таким же типом и числом аргументов, но отличающейся типом результата

std::function<void(void)> x = []{return std::string();}; компилируется. В этом проблема

а это не UB?

std::function<void(void)> x = []{return std::string();}; компилируется. В этом проблема

а в чем здесь проблема?

а в чем здесь проблема?

в том что стринг ты не получишь

лол, очевидно же

std::function<void(void)> x = []{return std::string();}; компилируется. В этом проблема

2 A callable object f of type F is Callable for argument types ArgTypes and return type R if the expression INVOKE (f, declval<ArgTypes?)..., R), considered as an unevaluated operand (Clause 5), is well formed (20.9.2).

2 A callable object f of type F is Callable for argument types ArgTypes and return type R if the expression INVOKE (f, declval<ArgTypes?)..., R), considered as an unevaluated operand (Clause 5), is well formed (20.9.2).

Тьфу. То есть на http://cplusplus.github.io/LWG/lwg-defects.html#2420

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

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

С++20

самый сок

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

C, без ++.

Тьфу. То есть на http://cplusplus.github.io/LWG/lwg-defects.html#2420

почему же? просто не знал, спасибо!

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

C++ можно учить инкрементально, это не python со сломанной совместимостью между версиями

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

#supapro

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

Чат supapro.cxx: https://telegram.me/joinchat/BYlFbD3eN3JMaG34hyh96w

лан.

C++ можно учить инкрементально, это не python со сломанной совместимостью между версиями

это ты ещё разговоров про std2 не слышал?))

Сижу, переписываю красивый код с std::variant обратно на switch. std::variant не просто тормозит, а ужасно тормозит. В ассемблере полная каша. На MSVC variant замедляет мой код на 70%, на Clang - 30%.

Разумеется, -O3

Сижу, переписываю красивый код с std::variant обратно на switch. std::variant не просто тормозит, а ужасно тормозит. В ассемблере полная каша. На MSVC variant замедляет мой код на 70%, на Clang - 30%.

ого

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

а код не под управлением чего-то гитоподобного?

откатится нельзя?

Гит, да. Куда откатиться?

или ты с нуля написал и теперь отказался, сорри не понял

Мы месяца четыре назад с радостным улюлюканьем перебежали на std::variant. А вот сегодня я засел профайлить.

а профилировщик на что показывает? какие места проседают? я бы попробовал, если у тебя есть синтетический тест

Собственно, во внутренности variant и показывает.

Сижу, переписываю красивый код с std::variant обратно на switch. std::variant не просто тормозит, а ужасно тормозит. В ассемблере полная каша. На MSVC variant замедляет мой код на 70%, на Clang - 30%.

А он у тебя прямо в critical path используется?

В моём понимании, эта штука должна полностью уйти в процессе оптимизации. Ан нет. Попытался почитать ассемблер - там кошмар.

А он у тебя прямо в critical path используется?

Остальной код писан осторожно, каждый лишний if на счету. Вот на фоне кода, который писался с производительностью в уме, variant и "заиграл". В обычном коде думаю не было бы так критично.