так и shared_ptr быстрая

при multicore contention - ОЧЕНЬ медленная

проверка на null в деструкторах

а это зачем?

ты же в курсе что delete nullptr это вполне ок и описано в стандарте? проверка не нужна

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

ты же в курсе что delete nullptr это вполне ок и описано в стандарте? проверка не нужна

зато delete this опасен всегда

и так лучше не делать никогда

зато delete this опасен всегда

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

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

вот-вот, согласен. не надо так делать

ты же в курсе что delete nullptr это вполне ок и описано в стандарте? проверка не нужна

да, но проверки при вызовах методов на этом ptr, потому что nullptr->method() почему-то не работает

да, но проверки при вызовах методов на этом ptr, потому что nullptr->method() почему-то не работает

а на delete this надо проверку делать?

да, но проверки при вызовах методов на этом ptr, потому что nullptr->method() почему-то не работает

я щас конкретно про деструктор

проверка на null в деструкторах

вот это

а на delete this надо проверку делать?

да, if (delete this) { убиться_апстену(); }

вот это

там тоже проверка на нулл не себя, т.к. по стандарту this не может быть null

это только в уебанском msvc бывает что this == nullptr

да я ваще не this, я походу пропустил всю дискуссию

это только в уебанском msvc бывает что this == nullptr

в каком месте?

в MFC (лол)

это только в уебанском msvc бывает что this == nullptr

класика

if (this != nullptr) { ... бла бла

не только кстати в MFC

в MFC (лол)

так-так-так, MFC это библиотека промышленного уровня, попрошу

так-так-так, MFC это библиотека промышленного уровня, попрошу

ну там довольно промышленные индусы наворотили промышленной хуйни

или промышенные...

В Питере

надо б заметку в @procxxnews зафигарить

по сути это call_back функция, вызываемая потрохами windows

можно в User Data хранить данные полезные, тот же shared_ptr ,ну или что там надо

SetWindowLongPtr

SetWindowLongPtr

так и хранится, я не хотел деталей, а хотел описать, что не объект С++ управляет временем жизни ресурса, а ресурс (окно) управляет временем жизни объекта С++. и что в этом случае, чтобы осуществить удаление объекта С++ и используется delete this при получении оповещения от Windows Manager-a об уничтожении окна

так и хранится, я не хотел деталей, а хотел описать, что не объект С++ управляет временем жизни ресурса, а ресурс (окно) управляет временем жизни объекта С++. и что в этом случае, чтобы осуществить удаление объекта С++ и используется delete this при получении оповещения от Windows Manager-a об уничтожении окна

ок

так и хранится, я не хотел деталей, а хотел описать, что не объект С++ управляет временем жизни ресурса, а ресурс (окно) управляет временем жизни объекта С++. и что в этом случае, чтобы осуществить удаление объекта С++ и используется delete this при получении оповещения от Windows Manager-a об уничтожении окна

так. а у нас объект класса окна где создается?

обычно в win api-приложухах идет так: 1. регистрация класса окна; 2. создание окна; 3. цикл сообщений; 4. чистка дерьма.

где тема заз

мне нужен стикер с ассенизаторской машиной и надписью delete this; на ней

обычно в win api-приложухах идет так: 1. регистрация класса окна; 2. создание окна; 3. цикл сообщений; 4. чистка дерьма.

мы чуть выше поднялись, на уровень MFC, где это все скрыто и до нас доходят только обработчики в контексте объекта С++

а, если mfc, то там тяжко, да. Кстати. Тут WTL 10 зарелизился недавно!

а, если mfc, то там тяжко, да. Кстати. Тут WTL 10 зарелизился недавно!

я не знаю куда это засунуть при наличии того же Qt. разве что у кого-то написано что-то на нем.

где тема заз

он тут есть!

мы чуть выше поднялись, на уровень MFC, где это все скрыто и до нас доходят только обработчики в контексте объекта С++

ну, получается, что да, тут мы в оковах фреймворка *вздохнул*

а это зачем?

потому что взаимные оповещения о смерти

if (this != nullptr) { ... бла бла

там эта проверка в одном случае, кстати

и без нее реально заебешься кодить

if (this != nullptr) { ... бла бла

гцц вроде может отломить код из-за оптимизации

гцц вроде может отломить код из-за оптимизации

Они так и делают. А вижаку норм, ибо ответ "почему так не надо" не самый интересный

гцц вроде может отломить код из-за оптимизации

не, это всегда true поэтому вся ветка выполняется без ифов

Они так и делают. А вижаку норм, ибо ответ "почему так не надо" не самый интересный

вижак просто non-conformant стандарта

вот и всё

вижак просто non-conformant стандарта

ну да, вижак не по стандарту, зато нет копипасты 1000 раз одного и того же

потому что этот внутренний this == nullptr выносить наверх с расстрелами ноги

в conformant

он там используется для запроса wrapped handle из wrapper-а

ну да, вижак не по стандарту, зато нет копипасты 1000 раз одного и того же

@AlexFails это в xthon

мне на самом деле интересно, в 2к4 как там были дела с не-MFC объектными обертками над виндой

ATL вроде более-менее

там полный ужас

я бы за паттерн class some : template<some> вообще убивал бы

я бы за паттерн class some : template<some> вообще убивал бы

это нормальный CRTP

я бы за паттерн class some : template<some> вообще убивал бы

обычный CRTP, ну

это нормальный CRTP

и как там дела с наследованием таких классов

и как там дела с наследованием таких классов

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

ты знаешь что делает template<some>?

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

ну давай, унаследуй T: enable_shared_from_this<T> нормально

ну давай, унаследуй T: enable_shared_from_this<T> нормально

зачем, я предпочитаю плоские иерархии

зачем, я предпочитаю плоские иерархии

ну то есть предпочитаешь отсутствие иерархии, динамического полиморфизма и компиляцию вечность

ERROR: S client not available

ну то есть предпочитаешь отсутствие иерархии, динамического полиморфизма и компиляцию вечность

предпочитаю дружить с логикой и не делать идиотские выводы как ты сейчас только что

окай, скажи мне, как мне объявить абстрактное дерево с узлами под shared_ptr

окай, скажи мне, как мне объявить абстрактное дерево с узлами под shared_ptr

не скажу

гцц вроде может отломить код из-за оптимизации

и может, и ломает, со свистом, пританцовывая

не скажу

ну вот тебе и ответ про логику

как только возникает малейшая естественная иерархия, enable_shared_from_this летит на помойку

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

Ребят, у меня к вам вопрос

Как такое возможно, что я запускаю тест - он рабоает одно время, запускаю его снова - другое, большее ?

и так, постоянно время скачет ...

у системы буфер записи кончился, а ты пишешь на HDD 1ГБ инфы

А что тест делает?

Тест, вычисления делает

В моем случае, примитивном - банальное умножение матриц

В моем случае, примитивном - банальное умножение матриц

а профилировщик какое самое горячее место показывает?

И я никак не могу, замерить что и сколько у меня работает. Совершенно не могу. Так как работает оно по разному.

Как такое возможно, что я запускаю тест - он рабоает одно время, запускаю его снова - другое, большее ?

у меня тоже вопрос - на каком языке тест, какие фичи использует, чем компилириуется

а профилировщик какое самое горячее место показывает?

Да там просто три цикла бахнуто, вот они скорее всего и будут узким местом. Вопрос то не в узкости и горлышке бутылки. А в том, почему разные запуски теста, дают разный ответ.

если просто три цикла то cache скорее всего, prefetch используешь?

в single-user mode тестируешь?

вопрос по cmake. перед проектом задаю set(CMAKE_CXX_STANDARD 17) и set(CMAKE_CXX_STANDARD_REQUIRED ON). Если собирать с компилятором по умолчанию (xcode toolchain on macos) то все хорошо и компилятору передается флаг -std=gnu++1z. но если указать другой компилятор через опции cmake -DCMAKE_C_COMPILER и -DCMAKE_CXX_COMPILER то флаг не передается и ничего не комплируется. Как указать cmake чтобы он вызывал мой компилятор с нужным флагом?

если просто три цикла то cache скорее всего, prefetch используешь?

for (int i_3 = 0; i_3 < nColumnA; i_3 += BLOCK_STRIDE_ROW) { for (int i_1 = 0; i_1 < nRowA; i_1 += BLOCK_STRIDE_COL) { for (int i_2 = 0; i_2 < nColumnB; ++i_2) { C(i_1, i_3) += A(i_2, i_3) * B(i_1, i_2); C(i_1 + 1, i_3) += A(i_2, i_3) * B(i_1 + 1, i_2); C(i_1 + 2, i_3) += A(i_2, i_3) * B(i_1 + 2, i_2); C(i_1 + 3, i_3) += A(i_2, i_3) * B(i_1 + 3, i_2); } } }

вопрос по cmake. перед проектом задаю set(CMAKE_CXX_STANDARD 17) и set(CMAKE_CXX_STANDARD_REQUIRED ON). Если собирать с компилятором по умолчанию (xcode toolchain on macos) то все хорошо и компилятору передается флаг -std=gnu++1z. но если указать другой компилятор через опции cmake -DCMAKE_C_COMPILER и -DCMAKE_CXX_COMPILER то флаг не передается и ничего не комплируется. Как указать cmake чтобы он вызывал мой компилятор с нужным флагом?

А какой ты компилятор задаешь?

То есть, код такой - самый что ни на есть примитивный. Размеры матриц - степени двойки, т.е выходы за границы нету

А какой ты компилятор задаешь?

Он должен адекватно детектить и добавлять флаг для GCC/Clang.

вопрос по cmake. перед проектом задаю set(CMAKE_CXX_STANDARD 17) и set(CMAKE_CXX_STANDARD_REQUIRED ON). Если собирать с компилятором по умолчанию (xcode toolchain on macos) то все хорошо и компилятору передается флаг -std=gnu++1z. но если указать другой компилятор через опции cmake -DCMAKE_C_COMPILER и -DCMAKE_CXX_COMPILER то флаг не передается и ничего не комплируется. Как указать cmake чтобы он вызывал мой компилятор с нужным флагом?

а другой компилятор поддерживает c++17?

А какой ты компилятор задаешь?

clang из brew

Видимо, скорее всего да, кеш. И префетч, видимо надо делать руками. Просто проблема в том, что там где он делается, а это уже asm код, тоже самое по прыгучести.

clang из brew

а где ты эти переменные ставишь, до project() или после?

до

а компилятор через командную строку