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

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

смотря как используешь.

И то верно, хотя еще проще наверное волатайлом

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

мне лично непонятно

а "a" - это отмапленная в память какая-то часть железяки

я для красоты всегда вывод пишу в консоль - его компилятор не дропнет (за некоторыми исключениями)

cout в драйвере не лучшая идея, лучше cerr - он не буферизирует!

cout в драйвере не лучшая идея, лучше cerr - он не буферизирует!

в драйвере вообще уж dbgprintEx

я kprintf писал и работало!

int main() { register int a=0; unsigned long d = GetTickCount(); for(register int i=0;i<2000000000;i++) { a++; } DWORD ff = GetTickCount(); cout<<ff-d<<endl; return 0; }

Примерно 50% модулей ядра которые я видел были написаны в этом стиле (т.е. 2 из 4) unsigned long d = GetTickCount(); ... DWORD ff = GetTickCount();

ну только не тиккаунты конечно - это ведь винапи, а KeQuerySystemTime какой-нибудь

guys, гляньте вопрос плиз: https://toster.ru/q/546604

а есть какие-нибудь читы для статической линковки в qtcreator?? чтобы без пересборки среды...

как-нить можно после получения екзешника, ссылающегося на дллки впихнуть в этот екзешник эти самые дллки (.lib ки)

Почему-то вспомнилось. https://habr.com/post/342002/

ахахахахахах, я почитал... кайф статья! ???

а есть какие-нибудь читы для статической линковки в qtcreator?? чтобы без пересборки среды...

пока Qt не соберешь с флагом -static, либы будут бесполезны.

пока Qt не соберешь с флагом -static, либы будут бесполезны.

сам кьют... я знаю, но там наверное муторно

а есть какие-нибудь читы для статической линковки в qtcreator?? чтобы без пересборки среды...

А для чего тебе статическая линковка?

Пересборка Qt — процесс на полдня. Деталей не скажу, мануал на работе. Скажу только, что весь проект был в вижуал-студии, и вручную подключались все препроцессоры к исходным файлам.

А для чего тебе статическая линковка?

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

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

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

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

Человек, десктопный клиент телеграма на Qt написан, и слинкован статически. Всем нравится.

Человек, десктопный клиент телеграма на Qt написан, и слинкован статически. Всем нравится.

Я не спорю, что так можно. Просто если задача - показать прогу преподу или между своими компами таскать - смысла в статик. линковке нету

а вот для тех, кто занимался гуишкой серьезно... Qt - хорошая либа?.. Как лучше гуи делать в дизайнере или ручками?

Сложно сказать.

вы можете готовые скачать, даже на винде, ставьте msys2 и через pacman качаете пакеты qt5-static

Есть виджеты, есть — QML

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

По идее, если работаешь с дизайнером и хочется отвязаться от конкретного представления, то лучше qml.

https://wiki.qt.io/MSYS2

По идее, если работаешь с дизайнером и хочется отвязаться от конкретного представления, то лучше qml.

*здесь дизайнер - это человек, а не прога формошлёпанья

а есть какие-нибудь читы для статической линковки в qtcreator?? чтобы без пересборки среды...

О мои глаза!

О мои глаза!

Давай протру!

О мои глаза!

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

через msys без пересборки qt см. выше

Юра, иди учись.

на винде

статик

а зачем вообще статик линковку делать?

есть какие-то причины помимо эстетических?

Да не за чем, в том и прикол

статик стартует быстрее

Да не за чем, в том и прикол

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

Просто ламера полагают, что так размер программы будет меньше, стартовать она будет быстрее, а работать будет дольше... :-)

ну и dll hell не страшен (?)

статик стартует быстрее

Ага, как же..

в интернете так пишут, проверять я это конечно же не стал

при статик линковке доступнo link time optimizations

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

ну да, lto может бинарь меньше сделать, но я в том же интернете видел сообщения что с lto qt глючит на форумах того же qt

оно и ускорение может дать хорошее

но проблемы со сборкой бывают, да

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

Ребята, давайте прекратим пустой и дешёвый трёп. А то придут люди в чат, и подумают чертечто...

Просто ламера полагают, что так размер программы будет меньше, стартовать она будет быстрее, а работать будет дольше... :-)

Не, ну в теории-то на пару операций меньше. Но блин

(Сорян за оффтоп: Alprog это не тот самый Alprog с gamedev.ru?)

Тот самый

Прикольно)

(меня ещё кто-то помнит - это тоже прикольно)

а вот для тех, кто занимался гуишкой серьезно... Qt - хорошая либа?.. Как лучше гуи делать в дизайнере или ручками?

@qt_chat

а имеет ли право компилятор c++ как-то оптимизировать выражения с double? то есть например x*y*c + z*c свести к (x*y+z)*c ? Ведь по факту ответ может получиться другой.

в большинстве случаев не имеет как раз поэтому

а имеет ли право компилятор c++ как-то оптимизировать выражения с double? то есть например x*y*c + z*c свести к (x*y+z)*c ? Ведь по факту ответ может получиться другой.

да, но только с флагом -ffast-math или аналогичными у других компиляторов. У ICC там конфигурируется достаточно тонко

если без флага, то не имеет

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

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

да

спасибо

ну как бы Стандарт не запрещате такие оптимизации, там просто сказано, что операции с float-point реализщованы согласно IEEE какой-то номер

в с++ не сказано про IEEE. сказано в си (то есть там это обязательно по IEEE теперь).

гм. в icc похоже -ffast-math вшит по умолчанию.

Друзья, а можно краткий в пару предложений ликбез о смартпойнтерах в многопотчном окружении: трейдофф выходит равный атомикам? Это самый оптимальный способ управления в случае создания и удаления в хипе большого количества обьектов, используемых в многих потоках без создания пулла переизпользования таких объектов? Как взгугольнуть сравнение с отложенной сборкой мусора? Или это к новичкам?

Интересует в контексте внезапно возникшего вопроса в голове о категорическом нежелании питоновского сообщества встраивать ARC/GC и избавления от GIL даже в каком-нибудь форке интерпритатора. Медленно, говорят, и не понимаю, как так ведь в плюсах смарты- тот же ARC только руками. Я правильно понимаю?

Друзья, а можно краткий в пару предложений ликбез о смартпойнтерах в многопотчном окружении: трейдофф выходит равный атомикам? Это самый оптимальный способ управления в случае создания и удаления в хипе большого количества обьектов, используемых в многих потоках без создания пулла переизпользования таких объектов? Как взгугольнуть сравнение с отложенной сборкой мусора? Или это к новичкам?

Что-то ты бредняк какой-то понаписал... Давай детально и последовательно.

Интересует в контексте внезапно возникшего вопроса в голове о категорическом нежелании питоновского сообщества встраивать ARC/GC и избавления от GIL даже в каком-нибудь форке интерпритатора. Медленно, говорят, и не понимаю, как так ведь в плюсах смарты- тот же ARC только руками. Я правильно понимаю?

если shared_ptr, то да. Со всеми вытекающими радостями в виде circular dependencies. Это что касается ARC. А про многопоточное окружение я ни черта не понял.

Интересует в контексте внезапно возникшего вопроса в голове о категорическом нежелании питоновского сообщества встраивать ARC/GC и избавления от GIL даже в каком-нибудь форке интерпритатора. Медленно, говорят, и не понимаю, как так ведь в плюсах смарты- тот же ARC только руками. Я правильно понимаю?

И с каких таких пор в питоне нет GC?

Друзья, а можно краткий в пару предложений ликбез о смартпойнтерах в многопотчном окружении: трейдофф выходит равный атомикам? Это самый оптимальный способ управления в случае создания и удаления в хипе большого количества обьектов, используемых в многих потоках без создания пулла переизпользования таких объектов? Как взгугольнуть сравнение с отложенной сборкой мусора? Или это к новичкам?

Для начала расскажи, блин, каким макаром связаны в твоей голове три эти вещи: (многопоточность и атомики;Смартпоинтеры и ARC;Python и GIL)

Интересует в контексте внезапно возникшего вопроса в голове о категорическом нежелании питоновского сообщества встраивать ARC/GC и избавления от GIL даже в каком-нибудь форке интерпритатора. Медленно, говорят, и не понимаю, как так ведь в плюсах смарты- тот же ARC только руками. Я правильно понимаю?

Вообще, от питонистов слышать что -то типа "Это не будем, потому что это медленно" -- это как-то очень странно.

)))

Вообще-то, это очень хороший вопрос. Да, в JVM и .NET предпочли чисто GC гибридной схеме reference counting + GC, чтобы не платить стоимость атомарной операцией при каждом копировании ссылочного объекта. Я сталкивался, с тем что из-за false sharing объекта (созданного через make_shared) и его счетчика ссылок программа замедлялась.

Python просто тупо самый медленный из всех существующих нынче языков.

Вообще-то, это очень хороший вопрос. Да, в JVM и .NET предпочли чисто GC гибридной схеме reference counting + GC, чтобы не платить стоимость атомарной операцией при каждом копировании ссылочного объекта. Я сталкивался, с тем что из-за false sharing объекта (созданного через make_shared) и его счетчика ссылок программа замедлялась.

Это, как раз таки, неудивительно.

В питоне референс каунтинг, у каждого обьекта внутри есть счетчик ссылок. Ок. Многоточность и атомики: если ты хочешь считать внутри обьекта количество активных ссылок на него, то для этого прийдется использовать атомики ибо этот счетчик - общий ресурс. Нет? ARC - automatic reference counting, objc/swift. Компайлер расставляет вызовы повышения и понижения счетчиков сам. Смартпойнтеры - суть для того же, только счетчик в объекте смартпойнтера, а не самих обьектах, в отличии от арц. Нет? Питон и GIL - не знаю, как пояснить. Неразрывно идут под ручку, ибо в питоне тот же подсчет ссылок внутри обьекта, но из-за лока на выполнение в одной лишь треде одновременно подсчет происходит без атомарных операций. (Тогда тут уже плавать пошли). Нет?

Вообще-то, это очень хороший вопрос. Да, в JVM и .NET предпочли чисто GC гибридной схеме reference counting + GC, чтобы не платить стоимость атомарной операцией при каждом копировании ссылочного объекта. Я сталкивался, с тем что из-за false sharing объекта (созданного через make_shared) и его счетчика ссылок программа замедлялась.

Из-за этого, например, запретили CoW в std::string. Но если нужно именно шарить, а не перемещать - то какие варианты?

Python просто тупо самый медленный из всех существующих нынче языков.

есть ещё как минимум Ruby

В питоне референс каунтинг, у каждого обьекта внутри есть счетчик ссылок. Ок. Многоточность и атомики: если ты хочешь считать внутри обьекта количество активных ссылок на него, то для этого прийдется использовать атомики ибо этот счетчик - общий ресурс. Нет? ARC - automatic reference counting, objc/swift. Компайлер расставляет вызовы повышения и понижения счетчиков сам. Смартпойнтеры - суть для того же, только счетчик в объекте смартпойнтера, а не самих обьектах, в отличии от арц. Нет? Питон и GIL - не знаю, как пояснить. Неразрывно идут под ручку, ибо в питоне тот же подсчет ссылок внутри обьекта, но из-за лока на выполнение в одной лишь треде одновременно подсчет происходит без атомарных операций. (Тогда тут уже плавать пошли). Нет?

0) Ок. Многоточность и атомики: если ты хочешь считать внутри обьекта количество активных ссылок на него, то для этого прийдется использовать атомики ибо этот счетчик - общий ресурс. Нет? Ответ -- НЕТ. Если ты хочешь считать ссылки в многопоточном окружении -- то да.

0) Ок. Многоточность и атомики: если ты хочешь считать внутри обьекта количество активных ссылок на него, то для этого прийдется использовать атомики ибо этот счетчик - общий ресурс. Нет? Ответ -- НЕТ. Если ты хочешь считать ссылки в многопоточном окружении -- то да.

std::shared_ptr не даёт гарантию работы в многопоточном окружении.

Из-за этого, например, запретили CoW в std::string. Но если нужно именно шарить, а не перемещать - то какие варианты?

Иметь вариант shared_ptr с не атомарным счетчиком ссылок. Большинство объектов все равно не thread-safe и при работе с ними все равно придется выполнять какую-то синхронизацию.

В питоне референс каунтинг, у каждого обьекта внутри есть счетчик ссылок. Ок. Многоточность и атомики: если ты хочешь считать внутри обьекта количество активных ссылок на него, то для этого прийдется использовать атомики ибо этот счетчик - общий ресурс. Нет? ARC - automatic reference counting, objc/swift. Компайлер расставляет вызовы повышения и понижения счетчиков сам. Смартпойнтеры - суть для того же, только счетчик в объекте смартпойнтера, а не самих обьектах, в отличии от арц. Нет? Питон и GIL - не знаю, как пояснить. Неразрывно идут под ручку, ибо в питоне тот же подсчет ссылок внутри обьекта, но из-за лока на выполнение в одной лишь треде одновременно подсчет происходит без атомарных операций. (Тогда тут уже плавать пошли). Нет?

2) -- я вообще не понял.

2) https://en.m.wikipedia.org/wiki/Automatic_Reference_Counting

В питоне референс каунтинг, у каждого обьекта внутри есть счетчик ссылок. Ок. Многоточность и атомики: если ты хочешь считать внутри обьекта количество активных ссылок на него, то для этого прийдется использовать атомики ибо этот счетчик - общий ресурс. Нет? ARC - automatic reference counting, objc/swift. Компайлер расставляет вызовы повышения и понижения счетчиков сам. Смартпойнтеры - суть для того же, только счетчик в объекте смартпойнтера, а не самих обьектах, в отличии от арц. Нет? Питон и GIL - не знаю, как пояснить. Неразрывно идут под ручку, ибо в питоне тот же подсчет ссылок внутри обьекта, но из-за лока на выполнение в одной лишь треде одновременно подсчет происходит без атомарных операций. (Тогда тут уже плавать пошли). Нет?

Питон и GIL - не знаю, как пояснить. Неразрывно идут под ручку, ибо в питоне тот же подсчет ссылок внутри обьекта, но из-за лока на выполнение в одной лишь треде одновременно подсчет происходит без атомарных операций. (Тогда тут уже плавать пошли). Нет? Как это связано с многопоточностью всё ?

std::shared_ptr не даёт гарантию работы в многопоточном окружении.

Вот видимо по этому к новичкам. Я думал там атомики

Питон и GIL - не знаю, как пояснить. Неразрывно идут под ручку, ибо в питоне тот же подсчет ссылок внутри обьекта, но из-за лока на выполнение в одной лишь треде одновременно подсчет происходит без атомарных операций. (Тогда тут уже плавать пошли). Нет? Как это связано с многопоточностью всё ?

Под словом многопоточность в этом контексте я подразумываю одновременное выполнение нескольких потоков. Global interpreter lock - запрет на подобное одновременное исполнение.

Так, а что в итоге в плюсах используют для этого в многопоточном окружении, если sharedptr без атомиков?

посылка ложна