Если нет технологий синхронизации вывода монитора и видеокарты, то картинка постоянно пролагивает. И может быть так что фрейм передасться так, что будет лаг на 2-3 кадра. Потому раскрыватели любят брать мониторы с частотой по выше. (и графику по ниже) Увы но эта проблема из 2014, сейчас её победили и даже мой 75Гц моник имеет AMD-FreeSynс.
Чтобы заметить разницу между 60 Гц и 144 Гц на Рабочем столе, вам придётся так напрячься, что вены лопнут
Люди которые хоть когда-то имели с долблением чего-то потного по таймингам лучше замечают разницу. (в основном игры) Когда я купил себе 200Гц моник, мой дед сел рядом со мной и реально не мог заметить разницы между 60 и 200. Люди которые любили стратегии говорили в духе "не понимаю, вроде как-то да но принципиально ничо не поменялось". А те кто играл в файтинги или бывшие игроки в кваку были просто в восторге. Увы я из последних, и мне заметно даже разница между 60 и 75. Даже мышка плавнее двигается, как это не замечают другие люди для меня загадка)
движение окна дискретное и чем быстрее вы дергаете мышь, тем реже рисуются новые кадры
Не понял что именно вы имели ввиду. В случае с Windows там используется событийно-ориентированный подход. Тоесть если событий НЕТ то фпс нативных приложений падает буквально до 0. Частоту опроса мышки можно увеличить до условных 1000Гц и соответственно частота отрисовки при движении мыши подскакивает до потолка. В Linux это работает не так, как я знаю. Там всё окружение рисуется с частотой монитора. Так что наверное разницы... Нет? О чём мы?
А в итоге разница есть только в играх, и то она заметна если ты любитель "бахнуть потного", зарубится в рейтинги на "алмаз" в каком-нибудь файтинге или пройти 7 звёзд мании в OSU, иначе - чисто субъективщина.
Я почему то считал, что частоты обновления кадров - удел старых ламповых мониторов, где эта частота непосредственно задает частоту кадровой развертки
Всё зависит от контроллера монитора. По факту у тебя матрица может иметь "стабильные 60Гц" а всё остальное зависит чисто от физических характеристик. Мониторы без защиты разрешают себя гнать и там прям видно как картинка начинает сыпаться если гнать их под +100Гц. (показать не могу, сгорел, ахахаха)
Мониторы по "защищёнее" могут гнаться но в каких-то пределах, мой текущий монитор не разрешает ставить обновление больше 84Гц, ни при каких таймингах. И уже при 84Гц видно как картинка слега сыпется на контрастном изображении, скролинг текста к примеру. (у меня нормальный кабель, не надо)
Остальные же явно дают по заднице за такие выкрутасы и прямо говорят - вот тебе список поддерживаемых стандартов, другое не заведём. Современные телики никогда нормально разогнать себя не дают, ибо там почти всегда есть какие-то "фичи" по улучшению картинки.
Не люблю все эти тесты... Вечно фигню какую-то ставят... Итак есть ровно два момента, первый это нагруженость по спектру. Если её нет, то разницы между битрейтом ты никогда не заметишь. Соответственно если включит музыку где играет целый оркестр, то запись 128 от flac отличить не проблема. Второй момент это акустика. Хоть ты лопни, но на слабой звуковухе+наушниках ты разницу в звуке не услышишь. Этот момент сродни колдовству и обычно окружён мистическими обрядами с подборами проводов по волновому сопротивлению или что-то в этом духе.
Выводы? Пофиг на битрейт, если ты сложне гитары с голосом ничего не слушаешь, а если хочешь слышать еле различимый шопот в зале на фоне музыки - велкам ту к аудиозависимым шаманам. (я же просто ставлю по больше ибо могу, лол)
Первое - вычислители у памяти это нейросети. Такое уже есть но стоит как крыло самолёта.
Второе - у памяти с CPU есть огромные, чисто физические проблемы. Первая это время задержки, она чисто физическая - чем больше память тем дольше время доступа к ней. Потому кэш L1 досихпор в +-30КБ делают, ибо так сохраняются нормальные задержки. Вторая проблема это невыровненых доступ к памяти. Из-за довольно фундаментальных проблем память может быть эффективно реализована только постранично-построчно, что напрочь убивает скорость рандомного доступа. На современных DRAM она что-то порядка 400МТ, в то время как выровненная может доходить до +5000МТ. У L-кэшей она в несколько раз выше, но невыровненый доступ также делает несколько циклов доступа к шине, что дропает скорость не в 10 раз но раза в 2 точно.
Из всех этих нюансов и возникает что единственный эффективный метод сделать универсальную ЭВМ это фигачить её память как бутерброд. В этом плане дна ещё не нащупали. Ибо пока инженеры осваивают L3 кэш в сотню мегабайт, умные дяди потирают ручки в ожидании L4 кэша со сверх широкой шиной в пару гигабайт. Так что всё ещё впереди.
Физически непонятно как делать память которая бы не была организованна постранично-построчно и имела нормальную пропускную способность/скорость доступа/время рандомного чтения. У любой существующей технологии есть только одна сильная сторона, но никогда несколько.
Забавно то, что почти все либы работают на UB. Многие библиотеки работающие с графикой используют union для доступа к членам. Даже могучий glm, который используется почти во всех OpenGL проектах использует техники как наш автор, при том они даже макросами варнинги в этих местах отключают
Получается ли тогда, что мир прогнил и любое дуновение и весь софт взорвётся?
У 4 циклонов есть QFP упаковка вплоть до 22K LUT. У MAX10 есть до 50K LUT в QFP, но там CPLD вроде и схемы в целом чуть жирнее получаются, так что рыба-мясо.
В Quartus циклон I проще всего настраивается в принципе
Все они довольно легко настраиваются, наверное только путает огромное много-образие поддерживаемых стандартов на выводах у более новых камней. Не понимаю этой притеензии.
PS: насколько я знаю, IO блоки у тех же 4 циклонов не поддерживают 5В логику, максимум 3.3В. Только из-за этого некоторые личности пересаживаются на более старые камни.
operator new был введён как расширение и долгое время шло заголовком new.h, в котором были опеределены все операторы с new, которые имели сигнатуру типа void * operator new(std::size_t) Позже его стали автоматически включать в проекты в рамках stdc++. Его так же можно переопределить и оно имеет свои реализации у соответсвующих компиляторах. Где-то оно дёргает вызовы шинды и вбрасывает исключения когда прям всё плохо, кто-то просто в цикле крутит malloc в надежде что вот ща то оно вернёт нужный указатель. Но суть что возвращает оно именно голый void*. И для меня, проблема в том, что компилятор сам занимается инициализацией и кастом этого указателя в нужный тип, что немного не сходится с дрочением типобезопасности. Почему это всё допускается тут? Только из-за того что это, формально, указатель на неинициализированный тип и внутри компилятора оно делает всё тот же placement new? +Компилятор не должен содержать кода внутри себя, это библиотека, и единственное что ему дают делать это заниматься оптимизациями на основе выражений с new. Разве не так?
Насколько я знаю, идея типобезопасности идёт первостепенно внутри комитета. Использованиее union при специфичном рантайме, таком как java/.NET ведёт за собой большие проблемы. Но так как большая часть людей пишет на "низкоуровневом С++" это опускает внутренние проверки union и формирует из него то что и формирует - кусок памяти который можно представить по разному, что не типобезопасно и порецается комитетом. А используя некоторые махинации с TU, мы можем на горбу вертеть UB формально его не нарушать, но нарушать...слово забыл... Короче миграция на другой рантайм всё поломает, о чём и печётся комитет.
Это всё калдунство, а калдовать плоха. Но вот с new непонятнки какие-то.
Мда, заболел как-то, голова совсем не варит, сорян. +На досуге перевариваю стандарт, относительно недавно начал.
Тогда получается использование сырых указателей, даже из всяких системных либ это UB? И единственный вариант использовать их это либо кастить результат в char* либо использовать placement new? Просто как в таком случае работает оператор new, который просто возвращает void*, если он самостоятельно приводит типы...? Ммм, читать....
Грустно однако. Ладно, и как в таком случае компилятор может гарантировать хранящийся тип в функциях на границе библиотек, при возвращении указателя на тот же union? Ведь ограничения на использования union исходят из того, что компилятор знает какой инициализированный тип может хранить union и не допускать использования другого, но тут эти гарантии нарушаются, так как компилятор не имеет информации за это, и тогда всё снова "зависит от реализации"? Или в таком случае запрещают использовать union на границах библиотек?
Копался в анналах своего сознания и вспомнил за сужающие преобразования к void*. Что на этот счёт говорит стандарт?
Как я помню void* разрешает кастовать к нему и из него абсолютно любой cv-совместимый тип. Что так же используется в функции memcpy(void*,const void*,size_t). В таком случае если я приведу тип Т к void а потом приведу его к U будет ли это считаться UB? Я знаю что подобные шаманства используются с функциями, но там другие правила каста, так что немного не то...
Вообще забавно как из такой очевидной проблемы растут неочевидные решения. Комитет С++ хочет создать абстрактный язык который оперировал объектами, чтоб можно было поменять рантайм даже на какой-нибудь CLR и всё работало. В этом случае работа с union кажется специфичной ибо окружение знает что в типе хранится "х" но не "у", как в таком случае гарантировать выполнение кода? Но эти же ограничения полный бред для низкоуровневых абстракций ибо "не важно что, там байты, дайте мне писать память", аоаоао. И это нельзя ничем решить нормально, не нарушая стандарт.
bit_cast использует memcpy для объекта на стеке в своей реализации. При этом memcpy во многих реализациях берёт указатель от объекта и делает так *(char*)dst=*(const char*)scr;такие вещи всё ещё не нарушают стандарт? Могу ли я в таком случае заменить bit_cast на операцию присвоения типов через указатель, максимум обезопасив себя проверкой типа указателя на trivialy_copyable?
Это всё ещё не избавит меня от проблемы, что компилятор не будет знать о том что хранит union и UB не обойдём, но можно будет создавать временные прокси-объекты обычным выражением с указателем на this.
windows.h построен на UB, получается его нельзя использовать в С++ коде?
В windows.h есть довольно много типов, такие как LARGE_INTEGER. LARGE_INTEGER подразумевает что ты работаешь с 64битным числом через пару 32битных, и так же можешь как с одним 64 битным, при поддержке компилятором. Описан через union. ***Раньше не все умели в 64битные числа. Используется обычно для работы с точным временем.
Лично я просто люблю истину искать и рассказывать всем подряд какой "чудесный" язык я изучаю. И если давать советы чо и как делать, не лучше ли вливать больше конкретики? Это может и перегрузит несчастного, но даст ему довольно качественный отзыв о его труде, не?
Большая поддержка ещё не повод говорить о том что это стоит использовать. Если вам недайбог придётся вникать в компиляторы для микроконтроллеров, то узнаете много нового)
Надеятся на поддержку современных версий стандарта тоже не самая лучшая идея) Многие всё ещё сидят на 14 стандарте, и даже msvc всё ещё сидит на 20 стандарте, когда уже вроде 23 утвердили, какбы? (А gcc лагает)
Ну да... Когда вместо constant::Pi is not constant! видишь 3.14 is not constant! , то как-то не по себе становится... Где ошибку то искать?))
...ок
Очень интересное описание проблемы. Но опять же, это всё вкусовщина. Вообще я не люблю холивары вокруг ООП, потому что они "инкапсулируют" в себе реальную проблему которую должен решать программист.)
...ок
Стандарт не говорит про то как должен быть реализован #include. С этой точки зрения он должен просто копировать файл согласно некоторым правилам. Но никто не запрещает тебе сделать компилятор который бы запрещал включение .h файла с С++ кодом и просил тебя поменять расширение на .hpp. +Ситуация с #include "x.cpp" не должна приводить к ошибкам линковки, это всё ещё часть стандарта)) Просто в таком случае выбор символа зависит "от реализации", что для программиста зачастую означает - рандом. Хотя какую именно мы ситуацию рассматриваем не совсем понятно мне.
Стандарт этого не запрещает, но поведение "оставляет за реализацией". У кого-то работает, а кто-то может и на C++ ругаться в .h файлах ведь надо писать .hpp. Каждый развлекается как хочет.
Консолидация памяти вообще тема интересная. А если максимально просто - чем больше подсистем работают в процессе запоминания, тем больше шансов вспомнить что-то. А у людей с идеальной памятью сильно связаны разные отделы мозга и для них цвет может "пахнуть", "иметь температуру" и прочие странные ассоциации. Неудивительно что в тех экспериментах при "более глубоком анализе" люди лучше вспоминали что-то
Второе как бы да, негатив деструктивен и если по началу позволяет тебе быстро чему-то учится, то в долгую вызывает серьёзные нарушения в организме.
А третье можно обозвать ошибкой модели подкрепления. Учитывая что наш мозг стимулирует активность именно процесса достижения цели а не сам факт её исполнения, мы ловим интересные баги в виде "вспоминаю о проблеме"="типо участвую в её решении".
А разве проблема клавиатурного ввода не фундаментальна?
Тоесть если ты запретишь программам не в фокусе реагировать на кнопки, то тогда ты не сможешь даже следующую песню переключить. Тот же Стим не сможет нормально в оверлейном режиме работать, а если разрешить это делать тогда все просто будут пользоваться этим механизмом и продолжать хукать ввод.
Говорят это когда денег много
Вот как вы это делаете?
У меня win10 не глючит даже на атоме с 4ГБ оперативки. Там и WSL, и вижуалка, и браузер вкладок на 10, и ещё попутно видео на Ютубе слушаю.
*Вру, глючит, но чисто когда память заканчивается и ты начинаешь окна активно менять, это как бы своп работает, ничего личного.
Программисты старой школы всё ещё пишут условные
if(ptr==nulltpr) return E_INVALID;Сейчас такая практика "устарела" и принято выкидывать исключения в рантайме, ибо обмазывать код if'ми на проверку корректности душно.
Если нет технологий синхронизации вывода монитора и видеокарты, то картинка постоянно пролагивает. И может быть так что фрейм передасться так, что будет лаг на 2-3 кадра. Потому раскрыватели любят брать мониторы с частотой по выше. (и графику по ниже)
Увы но эта проблема из 2014, сейчас её победили и даже мой 75Гц моник имеет AMD-FreeSynс.
Люди которые хоть когда-то имели с долблением чего-то потного по таймингам лучше замечают разницу. (в основном игры)
Когда я купил себе 200Гц моник, мой дед сел рядом со мной и реально не мог заметить разницы между 60 и 200. Люди которые любили стратегии говорили в духе "не понимаю, вроде как-то да но принципиально ничо не поменялось". А те кто играл в файтинги или бывшие игроки в кваку были просто в восторге.
Увы я из последних, и мне заметно даже разница между 60 и 75. Даже мышка плавнее двигается, как это не замечают другие люди для меня загадка)
Не понял что именно вы имели ввиду. В случае с Windows там используется событийно-ориентированный подход. Тоесть если событий НЕТ то фпс нативных приложений падает буквально до 0. Частоту опроса мышки можно увеличить до условных 1000Гц и соответственно частота отрисовки при движении мыши подскакивает до потолка.
В Linux это работает не так, как я знаю. Там всё окружение рисуется с частотой монитора. Так что наверное разницы... Нет? О чём мы?
А в итоге разница есть только в играх, и то она заметна если ты любитель "бахнуть потного", зарубится в рейтинги на "алмаз" в каком-нибудь файтинге или пройти 7 звёзд мании в OSU, иначе - чисто субъективщина.
Всё зависит от контроллера монитора. По факту у тебя матрица может иметь "стабильные 60Гц" а всё остальное зависит чисто от физических характеристик. Мониторы без защиты разрешают себя гнать и там прям видно как картинка начинает сыпаться если гнать их под +100Гц. (показать не могу, сгорел, ахахаха)
Мониторы по "защищёнее" могут гнаться но в каких-то пределах, мой текущий монитор не разрешает ставить обновление больше 84Гц, ни при каких таймингах. И уже при 84Гц видно как картинка слега сыпется на контрастном изображении, скролинг текста к примеру. (у меня нормальный кабель, не надо)
Остальные же явно дают по заднице за такие выкрутасы и прямо говорят - вот тебе список поддерживаемых стандартов, другое не заведём. Современные телики никогда нормально разогнать себя не дают, ибо там почти всегда есть какие-то "фичи" по улучшению картинки.
Не люблю все эти тесты... Вечно фигню какую-то ставят...
Итак есть ровно два момента, первый это нагруженость по спектру. Если её нет, то разницы между битрейтом ты никогда не заметишь. Соответственно если включит музыку где играет целый оркестр, то запись 128 от flac отличить не проблема.
Второй момент это акустика. Хоть ты лопни, но на слабой звуковухе+наушниках ты разницу в звуке не услышишь. Этот момент сродни колдовству и обычно окружён мистическими обрядами с подборами проводов по волновому сопротивлению или что-то в этом духе.
Выводы? Пофиг на битрейт, если ты сложне гитары с голосом ничего не слушаешь, а если хочешь слышать еле различимый шопот в зале на фоне музыки - велкам ту к аудиозависимым шаманам. (я же просто ставлю по больше ибо могу, лол)
Увы рэвольюции не будет.
Первое - вычислители у памяти это нейросети. Такое уже есть но стоит как крыло самолёта.
Второе - у памяти с CPU есть огромные, чисто физические проблемы. Первая это время задержки, она чисто физическая - чем больше память тем дольше время доступа к ней. Потому кэш L1 досихпор в +-30КБ делают, ибо так сохраняются нормальные задержки. Вторая проблема это невыровненых доступ к памяти. Из-за довольно фундаментальных проблем память может быть эффективно реализована только постранично-построчно, что напрочь убивает скорость рандомного доступа. На современных DRAM она что-то порядка 400МТ, в то время как выровненная может доходить до +5000МТ. У L-кэшей она в несколько раз выше, но невыровненый доступ также делает несколько циклов доступа к шине, что дропает скорость не в 10 раз но раза в 2 точно.
Из всех этих нюансов и возникает что единственный эффективный метод сделать универсальную ЭВМ это фигачить её память как бутерброд. В этом плане дна ещё не нащупали. Ибо пока инженеры осваивают L3 кэш в сотню мегабайт, умные дяди потирают ручки в ожидании L4 кэша со сверх широкой шиной в пару гигабайт. Так что всё ещё впереди.
Физически непонятно как делать память которая бы не была организованна постранично-построчно и имела нормальную пропускную способность/скорость доступа/время рандомного чтения. У любой существующей технологии есть только одна сильная сторона, но никогда несколько.
Надо брать блюпуп со всякими аптиксами и прочими проприетарным технологиями. Если канал не будет засрат можно даже 1Мбит нормально слушать.
Забавно то, что почти все либы работают на UB. Многие библиотеки работающие с графикой используют union для доступа к членам. Даже могучий glm, который используется почти во всех OpenGL проектах использует техники как наш автор, при том они даже макросами варнинги в этих местах отключают
Получается ли тогда, что мир прогнил и любое дуновение и весь софт взорвётся?
У 4 циклонов есть QFP упаковка вплоть до 22K LUT. У MAX10 есть до 50K LUT в QFP, но там CPLD вроде и схемы в целом чуть жирнее получаются, так что рыба-мясо.
Все они довольно легко настраиваются, наверное только путает огромное много-образие поддерживаемых стандартов на выводах у более новых камней. Не понимаю этой притеензии.
PS: насколько я знаю, IO блоки у тех же 4 циклонов не поддерживают 5В логику, максимум 3.3В. Только из-за этого некоторые личности пересаживаются на более старые камни.
Наконец-то я за компом...
operator new был введён как расширение и долгое время шло заголовком
new.h, в котором были опеределены все операторы сnew, которые имели сигнатуру типаvoid *Позже его стали автоматически включать в проекты в рамках stdc++. Его так же можно переопределить и оно имеет свои реализации у соответсвующих компиляторах. Где-то оно дёргает вызовы шинды и вбрасывает исключения когда прям всё плохо, кто-то просто в цикле крутитoperator new(std::size_t)
mallocв надежде что вот ща то оно вернёт нужный указатель. Но суть что возвращает оно именно голыйvoid*. И для меня, проблема в том, что компилятор сам занимается инициализацией и кастом этого указателя в нужный тип, что немного не сходится с дрочением типобезопасности. Почему это всё допускается тут? Только из-за того что это, формально, указатель на неинициализированный тип и внутри компилятора оно делает всё тот же placement new?+Компилятор не должен содержать кода внутри себя, это библиотека, и единственное что ему дают делать это заниматься оптимизациями на основе выражений с
new. Разве не так?Насколько я знаю, идея типобезопасности идёт первостепенно внутри комитета. Использованиее
unionпри специфичном рантайме, таком как java/.NET ведёт за собой большие проблемы. Но так как большая часть людей пишет на "низкоуровневом С++" это опускает внутренние проверки union и формирует из него то что и формирует - кусок памяти который можно представить по разному, что не типобезопасно и порецается комитетом. А используя некоторые махинации с TU, мы можем на горбу вертеть UB формально его не нарушать, но нарушать...слово забыл... Короче миграция на другой рантайм всё поломает, о чём и печётся комитет.Это всё калдунство, а калдовать плоха. Но вот с new непонятнки какие-то.
Мда, заболел как-то, голова совсем не варит, сорян. +На досуге перевариваю стандарт, относительно недавно начал.
Тогда получается использование сырых указателей, даже из всяких системных либ это UB? И единственный вариант использовать их это либо кастить результат в char* либо использовать placement new? Просто как в таком случае работает оператор new, который просто возвращает void*, если он самостоятельно приводит типы...? Ммм, читать....
Грустно однако. Ладно, и как в таком случае компилятор может гарантировать хранящийся тип в функциях на границе библиотек, при возвращении указателя на тот же union? Ведь ограничения на использования union исходят из того, что компилятор знает какой инициализированный тип может хранить union и не допускать использования другого, но тут эти гарантии нарушаются, так как компилятор не имеет информации за это, и тогда всё снова "зависит от реализации"? Или в таком случае запрещают использовать union на границах библиотек?
Копался в анналах своего сознания и вспомнил за сужающие преобразования к void*. Что на этот счёт говорит стандарт?
Как я помню void* разрешает кастовать к нему и из него абсолютно любой cv-совместимый тип. Что так же используется в функции
memcpy(void*,const void*,size_t). В таком случае если я приведу тип Т к void а потом приведу его к U будет ли это считаться UB? Я знаю что подобные шаманства используются с функциями, но там другие правила каста, так что немного не то...Вообще забавно как из такой очевидной проблемы растут неочевидные решения. Комитет С++ хочет создать абстрактный язык который оперировал объектами, чтоб можно было поменять рантайм даже на какой-нибудь CLR и всё работало. В этом случае работа с union кажется специфичной ибо окружение знает что в типе хранится "х" но не "у", как в таком случае гарантировать выполнение кода? Но эти же ограничения полный бред для низкоуровневых абстракций ибо "не важно что, там байты, дайте мне писать память", аоаоао. И это нельзя ничем решить нормально, не нарушая стандарт.
Ужас(((
bit_cast использует memcpy для объекта на стеке в своей реализации. При этом memcpy во многих реализациях берёт указатель от объекта и делает так
*(char*)dst=*(const char*)scr;такие вещи всё ещё не нарушают стандарт? Могу ли я в таком случае заменить bit_cast на операцию присвоения типов через указатель, максимум обезопасив себя проверкой типа указателя на trivialy_copyable?Это всё ещё не избавит меня от проблемы, что компилятор не будет знать о том что хранит union и UB не обойдём, но можно будет создавать временные прокси-объекты обычным выражением с указателем на this.
windows.h построен на UB, получается его нельзя использовать в С++ коде?
В windows.h есть довольно много типов, такие как LARGE_INTEGER. LARGE_INTEGER подразумевает что ты работаешь с 64битным числом через пару 32битных, и так же можешь как с одним 64 битным, при поддержке компилятором. Описан через union. ***Раньше не все умели в 64битные числа. Используется обычно для работы с точным временем.
Лично я просто люблю истину искать и рассказывать всем подряд какой "чудесный" язык я изучаю. И если давать советы чо и как делать, не лучше ли вливать больше конкретики? Это может и перегрузит несчастного, но даст ему довольно качественный отзыв о его труде, не?
Большая поддержка ещё не повод говорить о том что это стоит использовать. Если вам недайбог придётся вникать в компиляторы для микроконтроллеров, то узнаете много нового)
Надеятся на поддержку современных версий стандарта тоже не самая лучшая идея) Многие всё ещё сидят на 14 стандарте, и даже msvc всё ещё сидит на 20 стандарте, когда уже вроде 23 утвердили, какбы? (А gcc лагает)
Ну да... Когда вместо
constant::Pi is not constant!видишь3.14 is not constant!, то как-то не по себе становится... Где ошибку то искать?))...ок
Очень интересное описание проблемы. Но опять же, это всё вкусовщина. Вообще я не люблю холивары вокруг ООП, потому что они "инкапсулируют" в себе реальную проблему которую должен решать программист.)
...ок
Стандарт не говорит про то как должен быть реализован
#include. С этой точки зрения он должен просто копировать файл согласно некоторым правилам. Но никто не запрещает тебе сделать компилятор который бы запрещал включение .h файла с С++ кодом и просил тебя поменять расширение на .hpp. +Ситуация с#include "x.cpp"не должна приводить к ошибкам линковки, это всё ещё часть стандарта)) Просто в таком случае выбор символа зависит "от реализации", что для программиста зачастую означает - рандом. Хотя какую именно мы ситуацию рассматриваем не совсем понятно мне.И ещё раз...
Стандарт этого не запрещает, но поведение "оставляет за реализацией". У кого-то работает, а кто-то может и на C++ ругаться в .h файлах ведь надо писать .hpp. Каждый развлекается как хочет.
Консолидация памяти вообще тема интересная. А если максимально просто - чем больше подсистем работают в процессе запоминания, тем больше шансов вспомнить что-то. А у людей с идеальной памятью сильно связаны разные отделы мозга и для них цвет может "пахнуть", "иметь температуру" и прочие странные ассоциации. Неудивительно что в тех экспериментах при "более глубоком анализе" люди лучше вспоминали что-то
Второе как бы да, негатив деструктивен и если по началу позволяет тебе быстро чему-то учится, то в долгую вызывает серьёзные нарушения в организме.
А третье можно обозвать ошибкой модели подкрепления. Учитывая что наш мозг стимулирует активность именно процесса достижения цели а не сам факт её исполнения, мы ловим интересные баги в виде "вспоминаю о проблеме"="типо участвую в её решении".
А разве проблема клавиатурного ввода не фундаментальна?
Тоесть если ты запретишь программам не в фокусе реагировать на кнопки, то тогда ты не сможешь даже следующую песню переключить. Тот же Стим не сможет нормально в оверлейном режиме работать, а если разрешить это делать тогда все просто будут пользоваться этим механизмом и продолжать хукать ввод.
Если делать безопасно, то делать неудобно. Увы