но делай отключаемым

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

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

и чо?

10/10

по скринам не понятно или что?

Ты сейчас серьезно?

прога не упадет в любом случае

там будет инфа о готовности фреймбуфферов например и все

остальную всеравно собирать дополнительно

Можно подробнее?

отправлю в лс, а то оказывается я тут бесправный(((

окей

Всегда можно сделать цепочки ошибок/исключений как в java, c# и прочих. Например у WindowException есть поле innerException или cause, без разницы, в котором содержится информация о другом исключении которое привело к WindowException.

Ребят, а если есть базовый класс, в нем есть енамчики, а я их хочу расширить, но так, чтобы все виртуальные функции адекватно работали после расширения, то как мне собсно эти енамчики расширить ?

менять базовый класс я не могу, если что

Врапать

а многие виртуальные функции - в аргументах передают сий енам

Будто это тхирдпати

ну это Qt

И что?

Если врапать, то как ?

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

У енама будут доп значения

У врапперов классов-нужные методы с конвертацией параметров в формат сигнатур методов врапнутых классов

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

Обернуть

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

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

объясни, что ты хочешь расширить и как ты хочешь, чтобы базовый класс узнал о твоих изменениях?

Сделай класс в котором один приватный мвар - враппнутый класс. В паблике копии всех нужных методов

объясни, что ты хочешь расширить и как ты хочешь, чтобы базовый класс узнал о твоих изменениях?

Ну, собсно, тут все просто - у Qt, в qstyle.h есть enum ControlElement, менять сорсы кути я не могу, потому что лицензия у него такая. Хочу туда добавить свой тип в уже существующий enum

Проблема в том, что у него все виртуальные функции завязаны на этом енаме - его перечислениях, типа CE_PUSH_BUTTON и т.п

Сделай класс в котором один приватный мвар - враппнутый класс. В паблике копии всех нужных методов

На сколько я понимаю, мне придется каждый enum Qt, конвертировать в свой :)?

А тот класс все енумы из qt использует?

Ну, собсно, тут все просто - у Qt, в qstyle.h есть enum ControlElement, менять сорсы кути я не могу, потому что лицензия у него такая. Хочу туда добавить свой тип в уже существующий enum

для тебя там завели специальную константу QStyle::CE_CustomBase 0xf0000000 Base value for custom control elements; custom values must be greater than this value.

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

Не очень понимаю, как этим пользоваться. Для чего константа - я понимаю, чтобы я мог продолжать что-то делать, но как это правильно в классе наследнике использовать ?

Вообще тебе надо врапать только те енумы которые тебе нужны. А остальные использовать как есть, просто прокидывать значение без доп действий

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

То есть, тут они намекают, просто на то, что я должен создать свой любой ENUM и дальше делать что хочу, начав с нужного конста ?Я об этом думал, и потом подумал, а вдруг Qt заменят на enum class эту штуку :?

class MyStyle : public QStyle { enum { MY_CUSTOM_CONTROL = QStyle::CE_CustomBase, ...} void drawControl(ControlElement element, const QStyleOption *option, QPainter *painter, const QWidget *widget = Q_NULLPTR) const override { if( element == MY_CUSTOM_CONTROL) { ... } else { QStyle::drawControl(...); } } }

То есть, тут они намекают, просто на то, что я должен создать свой любой ENUM и дальше делать что хочу, начав с нужного конста ?Я об этом думал, и потом подумал, а вдруг Qt заменят на enum class эту штуку :?

Пока это есть в официальной документации можешь не беспокоится.

Тогда все хорошо, потому что я про это скоро забуду, мало ли чего у них там поменяется. Спасибо и Антону и Анатолию :)

Хей бейбы. У меня появилась больная фантазия, но что-то мне подсказывает, что подобное уже делали. Язык С с иммутабельными переменными и нормальным variable shadowing. Подобные попытки уже были?

В принципе одного нормального shadow'инга достаточно. Сейчас же нельзя делать так: const int a = 4; const int a = a * 10; а было бы весьма занятно

weak_ptr - это так, воспоминание о былой юности

А он нилится при смерти объекта?) сорян за тупой вопрос

В принципе одного нормального shadow'инга достаточно. Сейчас же нельзя делать так: const int a = 4; const int a = a * 10; а было бы весьма занятно

зачем?

А он нилится при смерти объекта?) сорян за тупой вопрос

У него lock возвращает нулевой указатель

А он нилится при смерти объекта?) сорян за тупой вопрос

weak_ptr не влияет на счетчик, объект может умереть. Просто валидировать нужно вручную каждый раз

А ну норм, спасибо

А сто там внутри кстате? Счет мьютексом обмазан?

В шаредптр

зачем?

Иммутабельность переменных исключит проблемы в многопоточном программировании const int a = 4; const int a = a * 10; //старый a продолжит свою жизнь до тех пор, пока кто-то в нем нуждается. Просто произойдет отвязка от своего идентификатора конкретно в этой строке. Считай, что создалась новая переменная

А сто там внутри кстате? Счет мьютексом обмазан?

там атомарный счетчик

Писать одновременно из разных потоков в одно и то же место нельзя. Но мы-то работаем только в read-only режиме и можем создавать переменные с теми же названиями локально, так что проблемы не будет

weak_ptr не влияет на счетчик, объект может умереть. Просто валидировать нужно вручную каждый раз

ну хз, например нужно знать ему когда можно удалить кусок памяти

объект то умрет а вот память нет

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

да я про то что там счетчик всетаки тикает

там 2 счетчика

unique_ptr - только один объект может владеть ресурсом shared_ptr - на ресурс можно ссылаться из нескольких мест, причем ресурс будет уничтожен только тогда, когда умрет последний потребитель ресура weak_ptr - может ссылаться на shared_ptr, но он никак не влияет на время смерти ресурса. Если все привязанные shared_ptr умрут, то weak_ptr станет невалидным

там у всех этих умных указателей по идее переопределен каст в bool, так что тупо через if можно чекнуть

объект то умрет а вот память нет

а если построить через weak_ptr shared_ptr ПОСЛЕ гибели последнего shared_ptr, то что произойдет?

я с weak_ptr особо не работаю просто, вот интересно стало

а если построить через weak_ptr shared_ptr ПОСЛЕ гибели последнего shared_ptr, то что произойдет?

думаю оно проверит

std::shared_ptr<T> lock() const noexcept; оно исключения не кидает

If there is no managed object, i.e. *this is empty, then the returned shared_ptr also is empty.

там у всех этих умных указателей по идее переопределен каст в bool, так что тупо через if можно чекнуть

Не стоит. У всех у них определен comparison с nullptr, поэтому лучше писать ```if(smartPtr != nullptr)```

ага, понял

>Return value A shared_ptr which shares ownership of the owned object if std::weak_ptr::expired returns false. Else returns default-constructed shared_ptr of type T.

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

shared_ptr вообще в реальной задаче нужны как правило исключительно редко. Но для ленивых программистов подойдёт.

shared_ptr вообще в реальной задаче нужны как правило исключительно редко. Но для ленивых программистов подойдёт.

еслиб они всегда локфри копировались то юзались бы исключительно часто

Не в этом дело. А в отсутствии ясного лайфтайма у ресурса.

у меня на ум приходит только какой-нибудь менеджер ресурсов. Типа в map хранить weak_ptr, но во время запроса ресурса выплевывать shared_ptr. Если ресурс уже помер - создать заново

или это bad case?

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

Например два треда и одна память, или два класса, с доступом к файлу.

это понятно, я просил реальную задачку :)

Не в этом дело. А в отсутствии ясного лайфтайма у ресурса.

да просто тогда на них удобно делать локфри контейнеры

Но даже эти кейсы в общем-то решаются введением менеджера ресурса с unique_ptr-ом и внятным временем жизни.

Но даже эти кейсы в общем-то решаются введением менеджера ресурса с unique_ptr-ом и внятным временем жизни.

но тогда зачем unique_ptr? Просто чтобы руками не писать delete? =)

но тогда зачем unique_ptr? Просто чтобы руками не писать delete? =)

да