точнее как двойной указатель разворачивать

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

Есть у кого годная литература по c++?

Есть у кого годная литература по c++?

держи моё https://cloud.bagrintsev.me/s/v9OUBm0oFg3Vsum?path=%2FCPP

держи моё https://cloud.bagrintsev.me/s/v9OUBm0oFg3Vsum?path=%2FCPP

спс,мне какраз надо для моего облачка

https://github.com/orlp/pdqsort

кто там тимсорт продвигал?

?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf Просто шикарнейший пропозал по метаклассам и миксинам

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf Просто шикарнейший пропозал по метаклассам и миксинам

@webreh

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf Просто шикарнейший пропозал по метаклассам и миксинам

а вообще, больше подъязыков богу подъязыков

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf Просто шикарнейший пропозал по метаклассам и миксинам

о нет

а вообще, больше подъязыков богу подъязыков

Нужно построить Зиккурат.

Нужно построить Зиккурат.

нужно больше золота

А почему нет? Если переводим вычисления на стадию компиляции, то и генерацию кода можно перенести на нее. DRY-таки. Хоть замена макросам появится

А почему нет? Если переводим вычисления на стадию компиляции, то и генерацию кода можно перенести на нее. DRY-таки. Хоть замена макросам появится

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

а вообще, больше подъязыков богу подъязыков

Да и нет там подъязыков, пара новых не конструкций

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

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

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

Oleg has been warned (2/5)

(

/warn

(

@w3bsme не пость оффтоп.

@w3bsme балаган не устраивай

держи моё https://cloud.bagrintsev.me/s/v9OUBm0oFg3Vsum?path=%2FCPP

Класс. А есть на русском языке?

Класс. А есть на русском языке?

ну, там что-то на русском, что-то — нет

не все книжки по плюсам есть на русском, увы

и вообще, ИМХО, надо на языке авторов читать

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

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

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

Согласен, просто это утомительно) я обычно читаю на русском, потом если что-то не понятно смотрю английскую версию. У Седживка "Алгоритмы" нашёл одну ошибку перевода и вот из последних у Курта Гантерота "Оптимизация программ на С++"

кстати, я встречал ляпы в коде даже в the c++ programming language (не бумажный вариант). правда, они были скорее связаны с опечаткой, но начинающего могли ввести в заблуждение

Есть у кого годная литература по c++?

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

тут месяц назад были разговоры по поводу того, как объект разложить на отдельные биты без копирований и динамических аллокаций. Вот на этут тему интересное предложение: 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()>')

ERROR: S client not available

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;}} что тут происходит?