Релизнулся LLVM 7.0.0 и сопутствующие вещи: http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html http://releases.llvm.org/7.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html

чот они ускорились

штампуют версии

чот они ускорились

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

Релизнулся LLVM 7.0.0 и сопутствующие вещи: http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html http://releases.llvm.org/7.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html

> The Windows installer no longer includes a Visual Studio integration. Instead, a new LLVM Compiler Toolchain Visual Studio extension is available on the Visual Studio Marketplace. The new integration supports Visual Studio 2017. это чо, долой clang-cl чтоли?

неа

они свою интеграцию не осилили поддерживать

в vs есть свой clang же

только там древний наверное

его дропнули

> The Windows installer no longer includes a Visual Studio integration. Instead, a new LLVM Compiler Toolchain Visual Studio extension is available on the Visual Studio Marketplace. The new integration supports Visual Studio 2017. это чо, долой clang-cl чтоли?

https://blogs.msdn.microsoft.com/vcblog/2018/09/18/exploring-clang-tooling-part-0-building-your-code-with-clang/

о как

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

Главное, чтоб баги не привозили

Главное, чтоб баги не привозили

конечно баги завозят, куда ж без них то

конечно баги завозят, куда ж без них то

без них намного лучше

без них намного лучше

Без них скучно :(

Без них скучно :(

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

без них намного лучше

ну согласись - круто же дебажить код , не понимать, почему падает. А оказывается, что там какая-то оптимизация из набора O2 сломалась в твоём случае

#ирония

ллвм в этом смысле очень неплох, почти на каждое изменение, добавляют тесты

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

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

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

Или даже gcc4.8 =(

Или даже gcc4.8 =(

или даже 4.4 )))

Здравствуйте. Подскажите вызываю EnumWindowProc, она возвращает BOOL получаю неправильное преобразование типов BOOL в WNDENUMPROC. Гугл молчит.

или даже 4.4 )))

Запахло пятой красношляпой

Запахло пятой красношляпой

ага, центос6

Здравствуйте. Подскажите вызываю EnumWindowProc, она возвращает BOOL получаю неправильное преобразование типов BOOL в WNDENUMPROC. Гугл молчит.

WNDENUMPROC - это указатель на функцию же, а не BOOL

EnumWindowsProc callback function (Windows) msdn.microsoft.com The WNDENUMPROC type defines a pointer to this callback function. EnumWindowsProc is a placeholder for the application-defined function name.

т.е. тебе принципиально надо делать callback-функцию с таким прототипом: BOOL CALLBACK yourEnumWndProc(HWND hWnd, LPARAM lParam); (вместо yourEnumWndProc подставляй свое имя функции)

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

Так и делаю, но не робит, тоже самое в 7ке, vs2015 работало, сейчас 10, 2017

скинь код на pastebin

https://pastebin.com/T7mvcsnQ

Так и делаю, но не робит, тоже самое в 7ке, vs2015 работало, сейчас 10, 2017

потому что надо не long Делать, а LPARAM. в 64-битной винде long != LPARAM

делал, но всё так же

сейчас ещё попробую

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

и еще - ты не чистишь память после оператора new[]. У тебя на каждое окно в итоге утекает по 510 байт

прям читаю ваш чатик и охуеваю

жизнь сложная вещь)

Ошибка (активно) E0167 аргумент типа "BOOL (__stdcall WindowChecker::*)(HWND hWnd, LPARAM lParam)" несовместим с параметром типа "WNDENUMPROC" 0

потому что ты передаешь функцию-член класса

надо передавать либо свободную функцию, либо статический метод

статику пробовал, не идет

а свободную это как ?

ллвм в этом смысле очень неплох, почти на каждое изменение, добавляют тесты

я только в llvm компиляторе баги оптимизатора находил, 2 раза, никогда в gcc/msvc

а свободную это как ?

за пределами класса

прям читаю pro.cxx и охуеваю

прям читаю pro.cxx и охуеваю

?

прям читаю pro.cxx и охуеваю

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

?

брейнпозитив и всё такое

Ребят, вопрос на засыпку. Если я использую мьютексы (и потоки) не из стандартной библиотеки, предоставляет ли стандарт synchronize-with отношение?

Ребят, вопрос на засыпку. Если я использую мьютексы (и потоки) не из стандартной библиотеки, предоставляет ли стандарт synchronize-with отношение?

думаю, да, это же просто очередной bullshit термин

как будто старых мало )

за пределами класса

Заработало. Спасибо.

Ну он не совсем bullshit. Ты спрашиваешь, будет ли при использовании своих потоков реализовываться гарантии на модели памяти?

Я так понимаю, что гарантии предоставляются примитивами, так что скорее да.

Ну он не совсем bullshit. Ты спрашиваешь, будет ли при использовании своих потоков реализовываться гарантии на модели памяти?

они все не совсем bullshit )

Ребят, вопрос на засыпку. Если я использую мьютексы (и потоки) не из стандартной библиотеки, предоставляет ли стандарт synchronize-with отношение?

Стандарт ничего не гарантирует в отношении сторонних библиотек. В реальности -- практически наверняка. Зависит от реализации твоего мютекса. Если он под капотом дёргает системные вызовы для лока/анлока, то точно. Если разновидности спинлоков (читай, работает без переключения контекста), то от годности реализации.

Стандарт ничего не гарантирует в отношении сторонних библиотек. В реальности -- практически наверняка. Зависит от реализации твоего мютекса. Если он под капотом дёргает системные вызовы для лока/анлока, то точно. Если разновидности спинлоков (читай, работает без переключения контекста), то от годности реализации.

какая разница, через что будет реализован mutex?

как примитив синхронизации может не гарантировать синхронизацию? ))

какая разница, через что будет реализован mutex?

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

как примитив синхронизации может не гарантировать синхронизацию? ))

Хреново реализованный примитив? )

Хреново реализованный примитив? )

ну вот и я про то же )

барьер, да, надо

иначе будет бобо

@AlexFails а закинь в мероприятия ещё и наш сабантуйчик по C++ https://events.yandex.ru/events/meetings/11-oct-2018/

О_О закину!

Можно ещё и в чатик по Яве закинуть :) Там один доклад про нетормозящую Яву

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

Не, вопрос не про реальный мир, а про абстрактную машину

Не, вопрос не про реальный мир, а про абстрактную машину

В стандарте прописано что мьютекс ставит барьеры

Не, вопрос не про реальный мир, а про абстрактную машину

Ну, тогда если твой абстрактный мютекс ставит барьеры, то да :)

В стандарте прописано что мьютекс ставит барьеры

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

В стандарте прописано что мьютекс ставит барьеры

Он спрашивает про нестандартный мютекс)

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

Как ты представляешь себе эту реализацию?

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

"Synchronization: Prior unlock() operations on the same object shall synchronize with (6.8.2) this operation."

А нестандартный - да, может делать любую фигню. Ну как бы сам виноват :)

@AlexFails а закинь в мероприятия ещё и наш сабантуйчик по C++ https://events.yandex.ru/events/meetings/11-oct-2018/

А я думал что таксисты теперь на павелецкой а не на льватолстого Звучит вкусно

Как ты представляешь себе эту реализацию?

ну вот спинлок с atomic переменной например - выше упоминали

А нестандартный - да, может делать любую фигню. Ну как бы сам виноват :)

на самом деле почти все используют примитивы из ОС, а там всё точно то же

стандартный mutex просто обёртка над ними

ну вот спинлок с atomic переменной например - выше упоминали

Atomic всегда ставит барьер, по определению

Atomic всегда ставит барьер, по определению

ну это опять же из стандарта?

а если ты тупо int используешь для 32-х бит или long long для 64-х?

ну это опять же из стандарта?

Да

Atomic всегда ставит барьер, по определению

Нет, барьеры указываются последними параметрами к операции. Можно делать атомарные операции без барьеров

а если ты тупо int используешь для 32-х бит или long long для 64-х?

Не надо так

Не надо так

иногда может работать )

смотря что за алгоритм, что надо

а если ты тупо int используешь для 32-х бит или long long для 64-х?

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

Нет, барьеры указываются последними параметрами к операции. Можно делать атомарные операции без барьеров

Эмм. Ну там же по умолчанию sec_cst же, не?

да, и это супер правильно

да, и это супер правильно

Безусловно. Я имею ввиду, что нет варианта вообще без барьера.

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

работать будет, переносимо не будет

Безусловно. Я имею ввиду, что нет варианта вообще без барьера.

memory_order_relaxed - без барьера

работать будет, переносимо не будет

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

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

я не о реализации локов если что

просто пользоваться тем, что это атомарные переменные