тут месяц назад были разговоры по поводу того, как объект разложить на отдельные биты без копирований и динамических аллокаций. Вот на этут тему интересное предложение: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf Можно будет писать: T some_standard_layout_variable; T* p = std::addressof(some_standard_layout_variable); std::for_each(bit_iterator(p), bit_iterator(p + 1), [](bit_reference<T>& b) { b.flip(); })

тут месяц назад были разговоры по поводу того, как объект разложить на отдельные биты без копирований и динамических аллокаций. Вот на этут тему интересное предложение: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r7.pdf Можно будет писать: T some_standard_layout_variable; T* p = std::addressof(some_standard_layout_variable); std::for_each(bit_iterator(p), bit_iterator(p + 1), [](bit_reference<T>& b) { b.flip(); })

кстати, вопрос )

как грамотно сделать класс с юнионом (юнион С++11, где сложные типы могут быть)

чтобы мувался там и прочее

Почему оно не может тип вывести? int main() { for(auto&& _ : {[]{return 72;},[]{return 101;}}) _(); }

Если в 1 элемент делать — всё ок.

чтобы мувался там и прочее

Очень легко: надо заменить union на variant

Почему оно не может тип вывести? int main() { for(auto&& _ : {[]{return 72;},[]{return 101;}}) _(); }

минимальный репро кейс: #include <iostream> #include <functional> int main() { for(auto&& _ : {[]{},[]{},[]{},[]{},[]{},[]{}}) _(); }

rog.cc:5:50: error: unable to deduce 'std::initializer_list<auto>&&' from '{<lambda closure object>main()::<lambda()>{}, <lambda closure object>main()::<lambda()>{}, <lambda closure object>main()::<lambda()>{}, <lambda closure object>main()::<lambda()>{}, <lambda closure object>main()::<lambda()>{}, <lambda closure object>main()::<lambda()>{}}' for(auto&& _ : {[]{},[]{},[]{},[]{},[]{},[]{}}) ^ prog.cc:5:50: note: deduced conflicting types for parameter 'auto' ('main()::<lambda()>' and 'main()::<lambda()>')

the wat

У меня предположение, что все лямбды для него разного типа?

int main() { for(auto&& _ : {[]{},[]{}}) _(); } вот даже так

о, это когда меня чуть не съели

ну похоже на то

Парадоксально как-то.

Учитывая, что на вид тип у них одинаковый.

А, бле.

Точно!

Лямбды же в плюсах это структурки в кишках... Им всем разные имена — читай типы — даются.

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

но понятно что в разными return values все равно будут разные типы :\

ну, посчитали, что все что обладает общностью фигачте к std::function

нужен initializer_list<compatible_lamda_sigs>

ну, посчитали, что все что обладает общностью фигачте к std::function

оно не может инициализировать лист

а каждую лямбду кастить к function defeats the purpose

ну, посчитали, что все что обладает общностью фигачте к std::function

Можно. Но выходит громоздко https://wandbox.org/permlink/mlDWQSNHhvuNEEdr

по поводу уникальности типа 8.1.5.1 Closure types [expr.prim.lambda.closure] 1 The type of a lambda-expression (which is also the type of the closure object) is a unique, unnamed non-union class type, called the closure type, whose properties are described below.

Тут в соседнем жабберочате подкинули идею годную https://wandbox.org/permlink/6JOBavrdz7mZD45W

@berkus ↑

Тут в соседнем жабберочате подкинули идею годную https://wandbox.org/permlink/6JOBavrdz7mZD45W

> {+[]{return 72;},+[]{return 101;}} что тут происходит?

> {+[]{return 72;},+[]{return 101;}} что тут происходит?

Мантикорушка говорит, что плюсики тут — хелперы gcc/clang, которые превращают лямбду в указатель на функцию.

был напуган

зачем плюсы накрепляются?

к каждой лямбде

зачем плюсы накрепляются?

Это ж C++

Мантикорушка говорит, что плюсики тут — хелперы gcc/clang, которые превращают лямбду в указатель на функцию.

а чему это соответсвует в плане языковой конструкции?

интересно, это полнолстью констекспровый список инициализации или нет

вот если рассматривать +[]{return 1;}

Мантикорушка говорит, что плюсики тут — хелперы gcc/clang, которые превращают лямбду в указатель на функцию.

а что разве без плюсов - не указатель?

а что разве без плюсов - не указатель?

да. Оно имеет тим decltype(auto)

в данном случае используется вот это 6 The closure type for a non-generic lambda-expression with no lambda-capture has a conversion function to pointer to function with C++ language linkage (10.5) having the same parameter and return types as the closure type’s function call operator.

+ применяется к указателю int (*)()

да. Оно имеет тим decltype(auto)

неопределённый тип, прямо как квантовая частица?)

в данном случае определенный

decltype(+[]{return 1;}) == decltype(int(*)())

> {+[]{return 72;},+[]{return 101;}} что тут происходит?

каст к int (*)(). вероятно, из-за лагов интернета, моё сообщение дойдёт хз когда

в данном случае определенный

я про без плюсика

если без + уникальный тип лямбды

если без + уникальный тип лямбды

но он кастится неявно в тип указателя на функцию всегда

короче без плюсиков плюсики не могут

почему всегда?

у VS2015 +[]{return 1;} не переваривает

хреновый VS2015

я передам :)

Мантикорушка говорит, что плюсики тут — хелперы gcc/clang, которые превращают лямбду в указатель на функцию.

тут я могу только одно ответить

у VS2015 +[]{return 1;} не переваривает

написано же - gcc/clang extension

это не по стандарту

int(*l[])() = { ([]() {return 0; }) , []() {return 1; } };

вот это студия кушает

decltype(+[]{return 1;}) == decltype(int(*)())

srsly?

вот это студия кушает

студия кушает клей

srsly?

век воли не видать

окай

попытался нащупать с какой версии работает — оказывается очень давно. gcc-4.6.4 c++0x

век воли не видать

prog.cc:4:28: error: lambda-expression in unevaluated context std::cout « decltype(+[]{return 1;}) == decltype(int(*)()) « std::endl;

попробуй auto a = +[]() {return 0; }; decltype(a)

вообще говоря, увидев +[]{return 1;} я прифигел

остается вопрос: унарный + можно применять к указателю на функцию? если по стандарту, то может 7 The operand of the unary + operator shall have arithmetic, unscoped enumeration, or pointer type and the result is the value of the argument. Integral promotion is performed on integral or enumeration operands. The type of the result is the type of the promoted operand

тогда это не extention gcc/clang

если пойнтер - то не экстеншен, но выше ты постил что там conversion operator

это получается implicit conversion to pointer триггерится плюсиком

тогда встает вопрос к гражданину Дроздову почему студия это не жрёт

ребят, кто-то пробовал в мобильную разработку на плюсах? интересует как android, так и ios (возможно, кроссплатформ). знаю, что есть в qt, но хз, как там под ios будет) еще знаю, что теперь visual c++ вполне подходит для разработки кроссплатформенных мобильных приложений, к тому же vs17 так же предоставляет инструменты виртуализации (физический айфон не нужен, получается), по этому вроде как этот вариант ярче кажется, чем qt. что вы думаете по этому поводу? кто-то уже пробовал? поделитесь опытом плес)

что-то мне подсказывает, что С++ на базе Android NDK оправдывает себя только на очень низком уровне и то если ты получил просадку в производительности, используя рекомендованный Google-ом Android SDK.

если ты хочешь игру замутить, то смотри на Unity, если хочешь что-то социалки смотри в сторону Ionic на базе Cordova или ReactJS. В противном случае, получить конфетку на С++ потребует несоизмеримых затрат по сравнению с другими инструментами

ребят, кто-то пробовал в мобильную разработку на плюсах? интересует как android, так и ios (возможно, кроссплатформ). знаю, что есть в qt, но хз, как там под ios будет) еще знаю, что теперь visual c++ вполне подходит для разработки кроссплатформенных мобильных приложений, к тому же vs17 так же предоставляет инструменты виртуализации (физический айфон не нужен, получается), по этому вроде как этот вариант ярче кажется, чем qt. что вы думаете по этому поводу? кто-то уже пробовал? поделитесь опытом плес)

Мы пробовали. У нас написан движок, который позволяет один и тот же C++ код запускать под asm.js/Android/Linux/NaCL/OSX/Windows. Стоило это три-четыре месяца работы. Переписывать приходится всё (например, нельзя использовать NativeActivity на Андроиде - он не на всех девайсах нормально работает, поэтому его надо было переписывать). Плюс добавлять freetype/libogg/OpenSL ES и т.д. код. В общем, это очень дорого.

ребят, кто-то пробовал в мобильную разработку на плюсах? интересует как android, так и ios (возможно, кроссплатформ). знаю, что есть в qt, но хз, как там под ios будет) еще знаю, что теперь visual c++ вполне подходит для разработки кроссплатформенных мобильных приложений, к тому же vs17 так же предоставляет инструменты виртуализации (физический айфон не нужен, получается), по этому вроде как этот вариант ярче кажется, чем qt. что вы думаете по этому поводу? кто-то уже пробовал? поделитесь опытом плес)

ну я пишу c++ lib + JNI + Java classes

что-то мне подсказывает, что С++ на базе Android NDK оправдывает себя только на очень низком уровне и то если ты получил просадку в производительности, используя рекомендованный Google-ом Android SDK.

Если есть уже готовый С++ код, то проще его перенести на Андройд, чем писать всё с нуля на Java. На прошлой работе с нуля на С++ разрабатывали engine базы данных для поиска по графам. Переносили на Андроид, делали встраиваемой базой. В основном всё было без проблем (ну разве что линкер там абсолютно другой и поведение у него сильно отличается + помучались с boost). Сейчас все патчи для буста уже в upstream, так что прблем быть не должно.

буст собираю под андроид, 1.63 и выше работает хорошо