Anton
DPI-системы и им подобное, там сплошь и рядом.
Anton
Первое впечатление от таких сведений очень скептическое :)
Anton
Это уже вопрос реализации. Если делать по-тупому и в лоб, то да.
Ioann_
Ну собственно, вопрос такой. Есть два виджета. Один, лежит на другом(смотри картинку). Когда я навожу мышь на первый(темный), происходит EnterEvent этого виджета, затем, когда я навожу мышь на светлый(тот что внутри темного), не происходит ничего. То есть, я ожидал что произойдет leaveEvent. Но оный происходит только тогда, когда я полностью мышь из окна убираю. Но точно не тогда, когда навожу на внутренний виджет. Вопрос, а как отловить событие, когда я навожу мышь на другой Ивент, но отловить его в том виджете, с которого произошел соскок. Картинка вот:
https://pp.userapi.com/c639218/v639218835/666ad/NK1Jk-HO1k4.jpg
Anton
ограничение потребления памяти приложения сверху.
Egor
waat
Если у нас есть, скажем, lock-free список, то у нас на любом элементе в любой момент могут висеть какие-то рандомные треды, а какие-то могут его из списка удалять. И надо делать так, чтобы треды не упали => нельзя удалять элемент, пока мы не уверены в том, что мы — единственный владелец. А лочить никого нельзя, кого угодно могут когда угодно усыпить на неопределённое время. Получается, что надо писать что-то вроде garbage collection.
Например, есть прикольная схема с hazard pointers.
Berkus
Ну собственно, вопрос такой. Есть два виджета. Один, лежит на другом(смотри картинку). Когда я навожу мышь на первый(темный), происходит EnterEvent этого виджета, затем, когда я навожу мышь на светлый(тот что внутри темного), не происходит ничего. То есть, я ожидал что произойдет leaveEvent. Но оный происходит только тогда, когда я полностью мышь из окна убираю. Но точно не тогда, когда навожу на внутренний виджет. Вопрос, а как отловить событие, когда я навожу мышь на другой Ивент, но отловить его в том виджете, с которого произошел соскок. Картинка вот:
https://pp.userapi.com/c639218/v639218835/666ad/NK1Jk-HO1k4.jpg
leaveEvent это когда мышь выходит ЗА границы виджета, и qt это проверяет без z-ordering-а, просто по внешней границе
Egor
<irony>Ну, сначала нужно доказать, что он понятия не имеет</irony>.
А вообще если свой аллокатор и написан, то, кажется, надо где-то в документации указать, зачем.
И, кажется, кому-то в этом треде надо посочувствовать :)
Anton
Если активно выделяешь/удаляешь, то тут без вариантов.
Ioann_
leaveEvent это когда мышь выходит ЗА границы виджета, и qt это проверяет без z-ordering-а, просто по внешней границе
Угу. Тут я догадался, а как же отловить то, что нужно мне ? То есть, когда навожу на дочерний :?
Berkus
если ты знаешь расположение виджетов то можешь перехватывать enterEvent внутреннего и эмитить leaveEvent для внешнего, но может выйти каша
Egor
А, логика может быть очень простой: "написанное самостоятельно и под задачу всегда быстрее; остальное неважно".
Ioann_
если ты знаешь расположение виджетов то можешь перехватывать enterEvent внутреннего и эмитить leaveEvent для внешнего, но может выйти каша
угу. Все так, а более изящного решения не известно ? В частности и другим в этой группе :?
Ioann_
А, логика может быть очень простой: "написанное самостоятельно и под задачу всегда быстрее; остальное неважно".
Полностью согласен с Егором. Есть ситуации, под которые stl можно как бы 'Переписать'. В частности, и хеш таблицы.
Anton
Оооо... Как хорошо, что мне такое не позволяют на работе делать)
Anton
Ибо мк.
Egor
Там такие требования, что кхм-кхм. Простой быстрый аллокатор, который им удовлетворяет, вообще никак не написать хотя бы из-за rebind
Ioann_
Ну я вижу, да. Аллокатор я использую Пулевый, то есть глобальный - все удаляется за один подход. Что, конечно, дает свои плоды по скорости.
Berkus
стандартные аллокаторы дичь да
Egor
Нельзя просто написать аллокатор, который выделяет массивы типа Foo и ничего больше. Обязательно надо писать что-то мощное. Ну или кидаться assert'ами.
Egor
Скажем, вот прекрасный простой аллокатор: храним отдельно пул элементов, отдельно односвязный список пустых элементов. Выделение/удаление работают за два обращения к памяти и несколько арифметических операций. Но как только у меня появляются элементы, размер которых не равен sizeof Foo, у меня адские проблемы.
Egor
А я обязан гарантировать, что у меня есть и выделение массивов за одну операцию (а это элементы подряд), и rebind
Matwey
Хм
Egor
Ну вот да. Ни то ни другое не выглядит, как что-то милое и приятное.
Egor
Страшное: это уже не "стандартный аллокатор", а что-то совсем своё. Не то чтобы это хуже, чем пытаться писать стандартный аллокатор и написать вместо него что-то, конечно.
Egor
А, да, и в стандартных аллокаторах нельзя иметь состояние (вроде только до C++03), это тоже просто "прекрасно".
</why-standard-allocators-are-strange-rant>
Berkus
когда я делал аллокатор выделяющий из конкретной указанной кучи приходилось таскать стейт с собой, было больно
Ioann_
+
Berkus
я даже свой порт СТЛ под это дело патчил
Egor
Зато не тратит время на блокировки :)
Egor
Ну, местами это вполне себе аргумент.
Berkus
нет, конечно
Berkus
удаляй
Berkus
вредно для здоровья!
Matwey
Ну алокаторы полезнее чем force_inline
Matwey
Да, аллокаторы хоть какую-то пользу несут в себе, а зачем нужнен force_inline я вообще не знаю
Matwey
Конечно не всегда.
Matwey
А форс инлайн, по-моему, вообще никогда
Egor
Ну, компилятор может быть тупым.
Egor
Даже свежий gcc
Egor
И может не догадаться, что в конкретном случае лучше бы эту штуку заинлайнить
Matwey
Даже свежий gcc умнее меня
Egor
Так не в generic случае и во всех выражениях же, а в чуть болпее high level и на конкретных задачах. И, да, вполне себе ситуация после измерений по моему опыту в олимпидных задачах.
Egor
Или, скажем, заменить вектора фиксированного размера на массивы может дать +10% к скорости. В релиз-режиме с оптимизациями, конечно.
Matwey
Вот кстати, бросьте вы это всё. Вы мне лучше другое расскажите
Matwey
Как мне убедить коноплятор, у меня float* выровнен по 128 бит?
Egor
Интересная мысль, надо попробовать. Тогда ещё array был не в моде.
Egor
Сказать "вот этот тип выравнивай по столько байт всегда"?
Egor
А в каком месте он не верит?
Egor
И как это проявляется?
Egor
Если бы там были аллокации — это одно. Но там не было аллокаций: просто заводим несколько векторов размера 10^5 или 10^6 и что-то с ними делаем с рандомными прыжками по памяти.
Egor
Или, скажем, заводим static vector<...>, делаем reserve, потом делаем push_back'и и грустим.
Matwey
Ну векторизатору то наверное интересно было бы знать это.
Matwey
Не придется генерировать код который будет выбирать голову
Matwey
да они наверное хорошие. но я в прошлый раз четыре раза код переписывал, чтобы они поняли, что я от них хочу
Matwey
Правда clang все-равно на 50% более медленный код чем gcc сделал :(
Egor
Ну векторизатору то наверное интересно было бы знать это.
Возможно, есть что-то в районе aligned_storage, std::align, но я не вижу
Matwey
Но это был старый clang
Matwey
Круто, спасибо.
Matwey
Но я все-равно отказываюсь писать руками ассемблерные команды.
Matwey
Пусть коноплятор за меня их пишет
Matwey
Это не переносимо
Matwey
Вдруг под другой архитектурой как-то по другому надо оптимизировать, я откуда должен это знать?
Ioann_
Или, скажем, заводим static vector<...>, делаем reserve, потом делаем push_back'и и грустим.
А если подумать, то почему так, знаете :?
Berkus
И может не догадаться, что в конкретном случае лучше бы эту штуку заинлайнить
да да, force_inline не гарантирует инлайна лел
Matwey
Тут ко мне пришел коллега и начал жаловаться что у него под 64-битной вендой нету float128
Egor
да да, force_inline не гарантирует инлайна лел
А чем он тогда отличается от обычного inline? И вообще, в каком это компиляторе?
Egor
А если подумать, то почему так, знаете :?
Буду рад узнать. Могу предположить, что с массивами компилятору проще догадаться до каких-нибудь оптимизаций
Matwey
Сказал ему, что у нас где-то остались еще Итаниумы
Ioann_
Отличается, типа тем что более строго настаивает на инлайне.
Unhappy
Пусть ты работаешь на двумя различными проектами над которыми ты регулярно переключаешься. Что делать если тебе понадобится версия libpng16-dev для одного проекта и версия libpng12-dev для другого?
Unhappy
Please help
🙃
держать обе версии локально в каждом проекте, а не в системе
🙃
ну или 2 среды отдельные делать
🙃
это конечно если обе либы не ставятся одновременно в систему
Stanislav
conan? :)