кто-нибудь тестил новый препроцессор у vs 15.8?

при компиляции должен быть флаг -g, при сборке не должно быть -s. Плюс к этому хорошо бы -O0

Оук, спасиб

Вот

кто-нибудь тестил новый препроцессор у vs 15.8?

нет еще

кто-нибудь тестил новый препроцессор у vs 15.8?

Я боюсь ставить, меня Толя со Стасом напугали...

кто-нибудь тестил новый препроцессор у vs 15.8?

я собираюсь в отпуске

при компиляции должен быть флаг -g, при сборке не должно быть -s. Плюс к этому хорошо бы -O0

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

Если что, makefile не мой)

кто-нибудь тестил новый препроцессор у vs 15.8?

Lol эта версия мне не понравилась, когда компилятор стал out of heap space от шаблончиков средней сложности

Если есть жирные std::tuple как контейнеры типов - он не может компилить

У меня есть constexpr std::tuple 290 размера

И он вообще не компилится

На 15.8

На 15.7.6 - всё норм

https://developercommunity.visualstudio.com/content/problem/296784/158-regression-fatal-error-c1060-compiler-is-out-o.html Тоже ссылаются на боль с шаблонами в visual studio 15.8

Thank you for your feedback! We have fixed the problem in an upcoming release 16.0 Preview 1. Thank you for helping us build a better Visual Studio!

ждём 16.0)

Всем кто обновился советую откатиться https://docs.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017#installing-the-earlier-release

Lol эта версия мне не понравилась, когда компилятор стал out of heap space от шаблончиков средней сложности

вообще сыро все капец

https://developercommunity.visualstudio.com/content/problem/296784/158-regression-fatal-error-c1060-compiler-is-out-o.html Тоже ссылаются на боль с шаблонами в visual studio 15.8

Sooqa, они пофиксили это в 16.0 preview 1( а не в 15.8.1

Sooqa, они пофиксили это в 16.0 preview 1( а не в 15.8.1

которого нет еще :D

Да

видимо выйдет после 1809 с новыми аби

Да, я не нашёл как установить 16.0 preview 1

на след неделе видимо появится

ну просто как альтернатива, по идее вместо g_ для глобальных можно всегда дописывать ::, а для мемберов вместо m_ дописывать this->, просто не понимаю в чём их принципиальное отличие при написании кода

в том, что можно не написать this->, но нельзя не написать m_, кроме того - да, :: это явный индикатор namespace

https://developercommunity.visualstudio.com/content/problem/296784/158-regression-fatal-error-c1060-compiler-is-out-o.html Тоже ссылаются на боль с шаблонами в visual studio 15.8

ну, твою хоть пофиксили, мою инвестигируют https://developercommunity.visualstudio.com/content/problem/310976/vc-internal-compiler-error-1580.html

ну, твою хоть пофиксили, мою инвестигируют https://developercommunity.visualstudio.com/content/problem/310976/vc-internal-compiler-error-1580.html

Это был не мой репорт, я кинут тот репорт, который тоже выявил проблемы с шаблонами. Я в основном на gcc собираю код, на линуксе, поэтому даже поленился зарепортить о своём кейсе.

Если в новой версии не закроют - тогда зарепорчу.

Господа, загадка: чему равно foo<int>(1) если foo определена следующим образом template <typename T> constexpr int foo(int) { return 1; } template <typename T> constexpr int foo(T) { return 2; } template <typename T> constexpr int foo(decltype(T{})) { return 3; } Подсказка: gcc (trunk), clang (trunk) и MSVC Pre 2018 считают разное.

емнип, должно быть 1, вариант без вывода типа вроде должен быть приоритетнее вариантов с выводом

емнип, должно быть 1, вариант без вывода типа вроде должен быть приоритетнее вариантов с выводом

Тут ни в одном из вариантов типы выводить не надо: мы явно указываем шаблонный аргумент f<int>(1). Но версия хорошая, clang считает так же.

ну я просто помню что при void foo(int); и template<class T> void foo(T); предпочтение должно отдаваться нешаблонной перегрузке; хз как оно в данном случае себя поведёт

Господа, загадка: чему равно foo<int>(1) если foo определена следующим образом template <typename T> constexpr int foo(int) { return 1; } template <typename T> constexpr int foo(T) { return 2; } template <typename T> constexpr int foo(decltype(T{})) { return 3; } Подсказка: gcc (trunk), clang (trunk) и MSVC Pre 2018 считают разное.

А это вообще должно скомпилиться? Тут нигде нет "неоднозначного вызова"?

У нас язык свободный :), такая точка зрения тожет имеет право на существование, так считает MSVC.

я за ошибку компиляции: неоднозначность перегрузки

Но что интересно, MSVC говорит, что 2 кандидата одинаково хороши -- 1-й и 3-й, а 2-й им уступает.

Но что интересно, MSVC говорит, что 2 кандидата одинаково хороши -- 1-й и 3-й, а 2-й им уступает.

а что согласно Стандарту должно быть?

Но что интересно, MSVC говорит, что 2 кандидата одинаково хороши -- 1-й и 3-й, а 2-й им уступает.

А decltype(1) это же int? Тогда 2 отлетает, но я не понял, как работает deduction в случае 3 (я идиот, его там нет)

Тут ни в одном из вариантов типы выводить не надо: мы явно указываем шаблонный аргумент f<int>(1). Но версия хорошая, clang считает так же.

Там есть правило, что считается более специализированным, и мое интуитивное понимание совпадает с вижаком

Такой вопрос. Линуксы. Через fork, а потом execve, запускаем нужную нам прогу. Как потом у родителя получить потоки ввода/вывода (дескрипторы) у вызванной программы?

Такой вопрос. Линуксы. Через fork, а потом execve, запускаем нужную нам прогу. Как потом у родителя получить потоки ввода/вывода (дескрипторы) у вызванной программы?

pipe()

@Artalus Andrey Есть вариант посмотреть как реализован std::vector Там для bool, как я слышал, другая реализация, нежели все остальное

а что вектор? в векторе просто специализация общего template<class T, class Allocator> class vector; на конкретное template<class Allocator> class vector<bool>; а тут в (int) версии шаблон T всё равно остаётся

а что вектор? в векторе просто специализация общего template<class T, class Allocator> class vector; на конкретное template<class Allocator> class vector<bool>; а тут в (int) версии шаблон T всё равно остаётся

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

и & / && квалификаторов не хватает, да?)

это везде не хватает)

а вот noexcept-ов каких-то там нет

по сравнению с основной

Такой вопрос. Линуксы. Через fork, а потом execve, запускаем нужную нам прогу. Как потом у родителя получить потоки ввода/вывода (дескрипторы) у вызванной программы?

А ещё можно посмотреть имплементацию popen().

pipe()

https://www.opennet.ru/man.shtml?topic=pipe&category=2&russian=2 Вот в примере по этому системному вызову показано как из под ребёнка общаться с родителем, но у меня то ребёнком будет заменяться другим процессом

А ещё можно посмотреть имплементацию popen().

Спасибо за помощь

можно ли как-нибудь проверить свою программу на работу в условиях очень малого доступного объема ОЗУ на linux x86_64? Объем RAM может быть килобайты (стек + куча). Ну и вообще, как-нибудь точно мониторить сколько ОЗУ требуется проге. Или лучше сразу куда-нибудь в эмулятор залезть?

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

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

а как загнать всю стандартную либу (в том числе и сишную) в этот пул?

ну и стек, до кучи

придется изощряться, но так ты сможешь контролировать чтобы программа лишнего не потребляла

стек хз как

напиши свой маллок для этого пула и через него память выделяй

почитай в интернете много примеров

пока самое вменяемое что позволяет посмотреть сколько оно жрет - это valgrind

чисто смотреть под линукс это valgrind

под винду вообще куча разных

Чуваки а можно как нибудь внутри cmake проверить, что поддерживается тот или иной стандарт? Мне нужно выключить сборку одного из проектов если не поддерживается c++14

А есть ли какой-нибудь вообще смысл поддерживать разные стандарты?

а зачем детач? сделай пул потоков и в io_service контролируй их завершение

@Ioann_V >но в потоке родителе содержать некий потокобезопасный контейнер Все потоки владеют памятью в равных условиях, не стоит обосабливать на объект родителя и объект ребенка Я понял что ты хочешь создать какой-то контейнер, который будет заполняться с разных потоков? Да, нужно использовать мьютексы в этом случае

Ещё можно запускать их через std::async, и на фючере спрашивать wait с нулевым таймаутом.

детач это ты их отправишь в асинхрон и только через содержимое потоков сможешь контролировать завершились они или нет

И детач совсем не нужен, да.

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

там в самых первых главах есть прям на это пример с futures

auto future = std::async(std::launch::async, &func); ... if (future.wait_for( std::chrono::seconds(0) ) == future_status::ready) { // завершился. }

и вообще там грамотно расписано с примерами как многопоточный код организовывать, многого и в интернете нет так грамотно описанного, например про shared_mutex-ы

+. Шикарная книга.

А если основной поток больше ничем не занимается, только ждёт, то и просто через join.

и? Они и будут одновременно. Вопрос в том, чем должен заниматься поток, их создавший. Если просто ждать их окончания, то join.

они и будут работать одновременно (на самом деле как ОС решит) а в join ты синхронизируешь точку в которой они все должны завершиться

да.

Thx

а что согласно Стандарту должно быть?

Я не могу понять

Я не могу понять

скинь места из Стандарта

[temp.func.order] "Partial ordering of function templates"

Экспериментально, можно получить, такой порядок на фукнкциях (> значит более специализированная): clang: 1 > (2 = 3) msvc: (1 = 3) > 2 gcc: 3 > 1 > 2

Экспериментально, можно получить, такой порядок на фукнкциях (> значит более специализированная): clang: 1 > (2 = 3) msvc: (1 = 3) > 2 gcc: 3 > 1 > 2

?

на чем делать разметку лутчше visual studio ,suble text or brackets?

на чем делать разметку лутчше visual studio ,suble text or brackets?

вы чатом не ошиблись?

std::make_unique<BYTE[]>(size); хм, так ведь нельзя делать? Неправильный деструктор вызовется.