>>18362
Да, не посмотрел, где ошибка. Тогда так. http://coliru.stacked-crooked.com/a/b8887c7f9859e0c5 Но ты это и так знал и вопрос в том, почему так? На самом деле, понятия не имею, что это и что ты делаешь.

>If the deferred flag is set (i.e. (policy & std::launch::deferred) != 0), then async converts f and args... the same way as by std::thread constructor, but does not spawn a new thread of execution. Instead, lazy evaluation is performed: the first call to a non-timed wait function on the std::future that async returned to the caller will cause the copy of f to be invoked (as an rvalue) with the copies of args...
Так, теперь понятно, почему оно не должно работать - флаг рантаймный, а в одном из вариантов происходит копирование (или в обоих).
>>18351
Да. Осталось только понять, как тип возрващаемого указателя влияет на вычислимость возвращаемого типа. Обрати внимание - я не меняю тип аргумента функции, я меняю тип аргумента функции, указатель на который возвращает функция.
>>18362
Дык там функция принимает ifstream по значению, а возвращает указатель на функцию, которая принимает по ссылке.

>>18365
Не я делаю. Он берёт вывод из >>18351 и пытается понять, где ошибка. Не ясно пока, почему работает WAT3.

>>18365
Он не я. Спасибо тебе огромное, до меня допёрло. То есть, аргумент для result_of - это и тип Callable и список желамых параметров в одном.
http://coliru.stacked-crooked.com/a/093a22237891f112
Тогда ещё вопрос: почему как мне сделать то же самое с, например, функцией от инт, возвращающей инт? Мне нужно написать int(int)(int), но это оказывается функцией, возвращающей функцию.

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

>>18368
> Мне нужно написать int(int)(int)
Нет, нужно написать int(int). Но result_of не для этого.

>>18370
Так я уже пробовал до того, как допёр, и это не компилится по названой причине - должен быть коллэбл-тип и скобки со списком араетров.

http://www.acodersjourney.com/2017/08/top-20-cplusplus-multithreading-mistakes/

>>18399
Оценил.

>>18399
Mistake # 21: Showing any weakness to std::async

>>18457
Is it about shared_future or what? Looks perfectly normal considering RAII and absence of thread isolation.

>>18529
Мне не нужен был возвращаемый результат, передаваемая функция была void, поэтому я вызывал async без future. А потом удивился, обнаружив последовательное выполнение.

>>18530
Вот не вижу ничего удивительного в этом, ведь завершение async-функции - это тоже результат. Если тебе нужен detached thread, то тебе нужен detached thread.

>>18457
В первом параграфе говорится о shared_future? Как могут несколько future относится к одному shared state?

https://hastebin.com/conuvaxiyi.cpp
Попросили сделать реализацию алгоритма Прима. Вроде даже не совсем говнокод.

>>18635
https://stackoverflow.com/questions/30810305/confusion-about-threads-launched-by-stdasync-with-stdlaunchasync-parameter
http://scottmeyers.blogspot.ru/2013/03/stdfutures-from-stdasync-arent-special.html

Да, там о shared.

Бампну ради великого правосудия.

https://solarianprogrammer.com/2017/12/27/cpp-17-constexpr-everything-as-much-as-the-compiler-can/
Что-то я не понимаю этого. Зачем именно everything? Это же вредит читаемости кода. Почему нельзя констэксприть только очень важные для производительности части кода?

>>18836
Как вредит? Вредить разве что компайл тайму может.

>>18837
Вредит таким образом, что нужно код переписывать в соответствии с требованиями constexpr.

>>18843
Н-е совсем. Скоро сделают, что можно будет действительно везде приписывать, как инлайн, например, а компилятор будет решать. Ну, а если тебе вправду нужно, чтоб функция на компайл тайме считалась, то перепишешь. Компилятор умный, так что это совсем не сложно.
Вообще, не очень понял твоё высказывание. Никто же тебя не заставляет переносить всё в компайл тайм, ну.

>>18844
>Никто же тебя не заставляет переносить всё в компайл тайм, ну.
Я уже в нескольких местах видел такое предложение. Ясен хер, меня не заставляют, но мотивы этих людей мне непонятны (они шутят?).

Поясните за скрипты линкера. Кто-то писал?

>>19004
Пояснился. Осознал, что ничего не знаю, стал плакать в подушку.

Посоветуйте плиз, чем профилировать выделение памяти и потребление cpu софтинки на плюсах, собранной под mingw.

Если что - помог Intel VTune. Триалка месяц, для разового ресёрча хватило.

Какой забавный спам приходит.

>>26517
А неплохо.

По мотивам треда для новичков.

>>26973
Более смешной вариант.

>>26974
Еще более смешной

>>26976
Вчера, кстати, пришлось погрустить из-за того, что мапа действительно не умеет сортироваться "автоматически". Мне хотелось иметь контейнер для N объектов, каждый из которых содержит в себе свой поток, живущий отдельной жизнью и в произвольные моменты времени меняющий состояние объекта - причем я планировал периодически находить самый "старый" (давно не менявший состояние) из объектов и заменять другим.

Конечно, рефлекторным порывом было определить оператор сравнения для объектов по дате изменения и складывать их в std::set - но сразу стало ясно, что оно не будет так работать.

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

https://onlinegdb.com/vfSmqJ6kqO

А еще в нагрузку дали девочку-студентку (не лоли, крупную и потрепанную). Три месяца назад ей дали амбициозное задание сделать свой кастомный видеоплеер для подглядывания за идущими в нейросеть данными. Девочка молодец и многое сделала, но небыстрыми темпами - и я типа должен помочь ей побыстрее закончить.

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

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

>>27103
Когда у тебя нет этой библиотеки под рукой и тебе хорошо знакомой - именно так.

Какие-то вы мертвенькие.

>>27141
Летние каникулы~

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

inline

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

>>27223
Пока мы ждем рыцарей-джейдаев, хотел спросить, подходит ли тебе вот такой вариант с extern?
https://stackoverflow.com/a/23432044

Здравствуйте.
Захотел написать обертку для редис, как часть Rails-подобного C++-фреймворка.
Что думаете по первому впечатлению?
https://github.com/movepointsolutions/activeredis/tree/main

>>27223
Нет смысла руками прописывать inline.
Компилятор сделает это лучше тебя.
Выноси большие функции, время выполнения которых много больше 4-5 тактов связки CALL/RET, в .cpp файл, а если хочешь обнять линк-тайм инлайнинг, читай документацию.

>>27228
Не знаю даже, попозже посмотрю, имеет ли это смысл. Сейчас, почитав Вашу ссылку, у меня появились сомнения в использовании встраиваемых функций.
>>27230
>Компилятор сделает это лучше тебя.
Ему же вроде надо подсказать. Нf пикриле доки MS.

>>27229
Да вроде норм.
Кода у Тебя мало, ещё неизвестно, как он себя поведёт при усложнении проекта. Ты лучше пока обдумай, как будет структура классов.
Старайся делать обёртку с нулевыми издержками и не забывать о KeepItSimple,Stupid и DontRepeatYourself.

А так, продолжай в том же духе и поглядывай на обёртки других библиотек/фреймворков.

>>27229
>Rails-подобного C++-фреймворка
Звучит так, что у тебя должен быть ActiveCache/ActiveObject/(другое название), который внутри вызывает, например, абстрактный ImdbAdapter. И уже на нижнем уровне должна быть реализация в виде RedisAdapter, наследующегося от ImdbAdapter.

Функция redisContext() уж точно должна быть приватной, иначе непонятно, что именно обёртка должна скрывать.

Интересно узнать, как твой Rails-подобный C++ фреймворк будет работать, в частности, какие практики из "convention over configuration" ты хочешь применить. В отличие от Ruby, язык не динамический и имеет меньше возможностей для метапрограммирования.

>>27223

Очевидные C++-модули.

>>17934

Всех приветствую. Делаю задание для шараги, нужно написать прогу которая способна сжимать и растягивать файл алгоритмом LZW. Сам алгоритм предполагает наличие начального словаря, который по ходу сжатия файла(нахождения в нём новых последовательностей байтов) расширен. То есть для того чтобы в дальнейшем растянуть файл обратно, нужно знать словарь. И вообще понять, подлежит файл растягиванию или же это просто белиберда из битов. Пока такие соображения: первые биты в сжатом файле сделать что-то типа сигнатурных, чтобы можно было сходу определить можно ли растянуть файл. И после сигнатурных битов будут биты сжатого файла, а потом будет магическое число типа как "разделитель" между файлом и словарём. Насколько хорошая идея использовать магическое число как разделитель? Или же лучше будет выделить под сжатый файл первые 4 бита как сигнатурные, где помимо метки сжатия файла будет ещё число под оффсет, как количество битов после которых заканчивается сжатый файл и будут пары ключ-значение из словаря? Или может быть лучше сделать по-другому как-то?

>>27307

>Делаю задание для шараги, нужно написать прогу которая способна сжимать и растягивать файл алгоритмом LZW.

Нахрена нужен ещё один LZ*-алгоритм, их и так как собак нерезанных.

#include <zstd.h>

и пошли нафиг. Требуемые возможности в нём есть. А неподдерживаемую самоделку, которую самим же и развивать придётся, в прод тащить - себе дороже. Мелкошарага - это не FAANG, чтобы свои алгоритмы компрессии общего назначения тянуть.

>>27313
Вполне возможно, речь идёт не про фирму, а про университет.

>>27307 >>27314
Ну раз курсовая работа....

>растягивать файл алгоритмом LZW.
>Сам алгоритм предполагает наличие начального словаря, который по ходу сжатия файла(нахождения в нём новых последовательностей байтов) расширен. То есть для того чтобы в дальнейшем растянуть файл обратно, нужно знать словарь. И вообще понять, подлежит файл растягиванию или же это просто белиберда из битов. Пока такие соображения: первые биты в сжатом файле сделать что-то типа сигнатурных, чтобы можно было сходу определить можно ли растянуть файл. И после сигнатурных битов будут биты сжатого файла, а потом будет магическое число типа как "разделитель" между файлом и словарём. Насколько хорошая идея использовать магическое число как разделитель? Или же лучше будет выделить под сжатый файл первые 4 бита как сигнатурные, где помимо метки сжатия файла будет ещё число под оффсет, как количество битов после которых заканчивается сжатый файл и будут пары ключ-значение из словаря? Или может быть лучше сделать по-другому как-то?

Строение формата: разделить стрим, словарь и контейнер. Все числа - little endian! Файл маппится в память целиком через либу mio, дальше работаешь с std::span и структурами. Стрим состоит из заголовка стрима и стрима. Без сигнатуры. Контейнер состоит из сигнатуры, глобального заголовка, содержащего длину области контейнера и смещения областей стрима и словаря в ней ОТНОСИТЕЛЬНО КОНЦА ЗАГОЛОВКА. После следуют области, сначала область словаря, потом область стрима, потом конец файла. Ты провершь это при загрузке файла. Размеры вычислишь как разницы этих смещений.

Начальный словарь может иметь смысл хранить в отдельном файле для переиспользования, поэтому область словаря - это может быть просто CRC32-хэш от файла словаря, который при операциях надо задать явно. Также начальный словарь можно
хранить внутри контейнера или использовать захардкоденный. Поэтому сначала 1 байт перечисление. 0 - хардкод, 1 - файл, 2 - внутри. Если 0 - то инициализируем хардкодом. Если 1 - берём имя файла, добавляем ".dic" - вот и наш словарь. Проверяем наличие файла. Маппим его. Проверяем формат словаря. Поскольку задача учебная, то для твоего удобства в его редактировании это просто массив, сериализованный в BSON/bencode. Поскольку тебя просили сделать только компрессию, то ты волен для словаря юзать другие либы. Если 2 - то сначала 8 бит длина, потом - блоб словаря.

Дальше идёт область стрима.

>Насколько хорошая идея использовать магическое число как разделитель?

Абсолютно идиотская. Тебе задачу делать надо, или извращаться? Ты либо делаешь всё максимально просто, либо огребаешь проблем немеренно. Что если у тебя в блобе словаря случайно встретится разделитель? Сигнатура используется исключительно для проверки принадлежности файла конкретному формату. Она располагается строго в начале и занимает строго либо 4 байта, либо 8 и не будет меняться никогда. Если планируется много версий формата - делается заголовок с версиями, формат которого не будет меняться вообще никогда. Вся информация, необходимая для парсинга структуры, должна быть известна ДО начала её парсинга.

При проектировании формата рекомендую использовать Kaitai Struct. Парсер получишь бесплатно.

Наткнулся при компиляции на ошибку вот в этой строчке
> typedef int Check[sizeof(A) == sizeof(int) + sizeof(bool) ? 1 : -1];
Долго думал, что это за ерунда такая, а потом как понял.
Структура А определена как
> struct A {bool b; int a;};
Оказалось, что это проверка на отключение выравнивания в структурах -fpack-struct=1.