Qubc

Параметры - Приложения - Приложения и возможности - Фрагмент экрана - Дополнительные параметры - Сброс

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

Чтобы понять поведение кода в C++, нужно сперва разобраться с поиском имен в C++.
Коротко, поиск имен запускается всегда для каждого имени, которое встречается в коде, и связывает использованное в коде имя с конкретным, единственным из всех прочих, объявлением этого имени.

cat1 -> sound();
Тут по пунктам. Сперва UNL определит имя cat1 как переменную в локальном пространстве с типом Cat*.
Далее UNL же определит что в пространстве класса Cat есть метод sound.
Далее для определения перегрузки Cat::sound запустится ADL и найдет в пространстве только одну перегрузку - метод без параметров. ADL вернет объявление этой перегрузки, т.к. она удовлетворяет условиям вызова метода.

Отдельно отметить стоит то, что это именно писатель определил в пространстве класса только одну перегрузку метода sound. Алгоритм ADL довольно строг и не будет искать объявления где-либо еще.
Именно поэтому при данном определении класса Cat код cat1 -> sound(1); трансляцию никогда не пройдет. Просто потому что в пространстве класса написана только одна перегрузка метода.

Что делать, когда перегрузки из родительского класса нужны все, но замещать их все в классе дочернем нужды нет?
Тут на помощь приходит ключевое слово using[?].
Это слово нужно использовать в контексте делегирования из пространства родительского класса. Определение класса Cat должно быть таким.

class Cat : public Animal
{
public:
	// Delegate all overloads of `sound`.
	using Animal::sound;
	
	void sound () override
	{
		std::cout << "Cat.sound()" << '\n';
	}
};

В этом случае код cat1 -> sound(1); пройдет трансляцию и приведет к вызову void Animal::sound(int i).

Ну вообще, char - integral type. Поэтому передавать туда числовую константу можно - это никакой не варнинг. Компилятор сам понимает, что она должна быть типа char и даже проверяет на переполнение и выдает warning, если что.

Очевидно, же что компилируется по разному.
1) если хотите явно обращаться к свойствам и методам других классов, то нужно их указывать пабликами.
2) дефолтный уровень (обычно!) это уровень пакета, но в листинге я не вижу единого для двух классов объявление пакета - javac с дефолтными настройками все правильно понимает, а для VC (волков командер???) нужна явна подсказка - хз какие он ключи передает компилятору.

Я тоже до конца не понимаю цели и задачи которые ставились для winsock2 но вот можно
почитать аннотацию здесь https://learn.microsoft.com/en-us/windows/win32/wi...

С моей точки зрения было время большого разлада между лагерем Microsoft и Unix. И вместо того
чтобы просто позаимстовать сетевые библиотеки или купить лицензии, MS как всегда стал делать
что-то свое, "сумчатое" и ни на что не похожее. Яркий пример Component-Object Model (COM).
Нигде такого нет.

Для чего создаватьtypedef struct addrinfo{}? Только ради того, чтобы не писать struct в Си?

Да все верно. Именно для такого юзкейса typedef и создавался. Плюс еще можно примитивы определять.

Для чего определять *PADDRINFOA

Вот здесь не знаю для чего. Хотя подобный подход я видел не только у Microsoft но и у других.
Вообще иногда мы не догадываемся но код может быть сгенерирован кросс-компилляторами
и в этом случае названия идентификаторов могут быть очень длинными и причудливыми.
А удаление звездочки из синтаксиса сужает возможности разработчика тоесть не дает
допустить ошибку. Такая себе строгая типизация в квадарате.

Где-то спокойно используется int, а где-то используетсяtypedef unsigned __int64 UINT_PTR, опять же вместо того, чтобы просто писать unsigned __int64.

Это очень старый технический долг языка С++ и его уже нельзя исправить. Дело в том
что спецификация языка не объясняет какой разрядности должен быть int. Он может быть
16, 32 бит в зависимости от целевого железа. По сути он - синоним регистра процессора.
И когда мы делаем цикл от 1 до 10 и нам по сути неважна разрядность параметра цикла - мы просто заказываем
int чтоб долго не думать. И компиллятор собирает очень быстрый и оптимальный код.
sizeof(int), или константы в в limits.h могут дать подсказку по вашей текущей архитектуре.

typedef unsigned __int64 UINT_PTR

Здесь идет форсирование разрядности в 64 бита. Такие потребности возникают
в момент когда у нас есть например жестко заданный формат (сетевой протокол
или дисковый формат файла) и мы должны гарантировать что другие архитектуры
микрокотноллеры, мобилы и прочее правильно смогут интерпретировать эту структуру.
Тут еще и порядок байтов внутри слова тоже важен. В наше время даже есть сет
стандартов на описание таких структур ASN, AVRO, Protobuf, Thrift.

Видимо разработчикам из MS действительно было удобно такое выкатить.
А может и для обратной совместимости что-то.
Если не устраивает - ты всегда можешь написать свою библиотеку, которая будет это оборачивать.

Какой смысл задавать вопросы к причинам существования древнего легаси? Написал когда-то студент за миску риса, с тех пор и кочует для обратной совместимости

Уловка в системе процессорных комманд: 48 c7 45 08 - позволяет загрузить в 64-битную ячейку памяти 32 битное число, автоматически расширяя его до 64 бит.

Смотрите список кодов x64:
0x48 - означает, что следующая комманда работает с 64-битами.
0xC7 - mov immediate (данные в команде)
Дальше идут флаги, указывающие как интерпретировать аргументы, что куда адресовывать и т.д.

Но важно, что команда C7 работает с r/m16/32/64 данными, а аргумент у нее может быть только imm16/32 (третий столбец). Т.е. она принимает или 2 или 4 байта, в зависимости от обвеса, а записывать может до 64 бит. Сравните это с коммандой 0xB8 в той же таблице, она уже может принимать 64 бита.

Если аргумент меньше ячейки памяти, то он расширяется (sign extended) до нужного размера (бит знака копируется влево до упора). Это позволяет записать числено равное значение в более битную ячейку. ведь 32-битное число 0xFFFFFFFF - это -1 в дополнительном бинарном коде, а 0xFFFFFFFFFFFFFFFF - это тоже -1 в дополнительном 64-битном коде.

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

Верно. Можно вставить исходник на сайте C++ insights и посмотреть, какие типы там где используются.

Да, тип будет именно таким.
Чтобы самостоятельно увидеть вывод типа, который вывел компилятор Scott Meyers предлагает намеренно создать ошибку конвертации типа и посмотреть что же компилятор написал.
https://godbolt.org/z/6bobqTG58

В рассуждениях есть ошибка.

Да, стандарт утверждает что тип int может иметь размер не меньше 16 бит.
Таблица имеет название "Minimum width", т.е. минимальный размер. Минимальный - это значит что int может иметь размер в 16 бит. А может иметь и 64 бита.

В большинстве случаев нам это и не важно. Наоборот даже, нам важна оптимальность, с которой вычисления переходят от операций на памяти к операциям на регистрах. Но есть целый (немалый такой) ряд задач, когда о размере значения нужно не просто думать, а точно его знать и гарантировать при сборке в любых условиях.
Запись в файл, передача по сети, коммуникации с устройствами в составе компьютера (звук, видео, геоданные, низкоуровневый ввод и вывод)... Все это требует соблюдения протоколов, а протоколы требуют строгого соблюдения размеров и выравнивания передаваемых значений.

Ошибка в рассуждениях заключается в том, что ты проводишь нить только от int32_t к int и дальше к стандарту. В то время как стандарт определяет и требования к типу int32_t тоже.
Тип int32_t всегда и для любой модели памяти выбирается таким образом чтобы гарантировать размер в 32 бита.

То что где-то int32_t является псевдонимом int - это не более чем временное совпадение.

Смотрите документацию. Там действительно утверждается, что int32_t должен иметь размер ровно 32 бита ("exactly").

Где вы взяли, что int32_t - это псевдоним int?
Подозреваю, что там, где вы это видели, куча #ifdef и проверок архитектуры.
Возмножно, на вашей системе, где int итак имеет 32 бита так оно и есть. При компиляции на другую архитектуру внезапно может оказаться, что int32_t - нифига не псевдоним к int.

Нет ветки master, вот и ругается. Ветка по умолчанию на GitHub теперь называется main.

Команда git branch -vv покажет какие ветки есть локально и с какими внешними ветками связаны.
* main 0e02250 [origin/main] v.01

Надо было делать git push origin main
Либо просто git push т. е. отправить текущую ветку в связанную с ней ветку на внешнем репозитории.
В нашем случае текущая ветка main (помеченная звёздочкой)
отслеживает исходную ветку main в репозитории обозначенном как origin

Что скрывается за сокращением origin покажет команда git remote -v

origin	https://github.com/xxx/xxx.git (fetch)
origin	https://github.com/xxx/xxx.git (push)

Потому что так реализовано:

[set]
matches a non-empty sequence of character from set of characters.
If the first character of the set is ^, then all characters not in the set are matched. If the set begins with ] or ^] then the ] character is also included into the set. It is implementation-defined whether the character - in the non-initial position in the scanset may be indicating a range, as in [0-9]. If width specifier is used, matches only up to width. Always stores a null character in addition to the characters matched (so the argument array must have room for at least width+1 characters)

Ссылка

Если вам не нужно "зависать" на символе, то используйте другой формат, например %c, %s (симолы/строки)

Интересный вопрос. Ответа у меня нет, что-то не приходилось использовать режимы "+".
Попробуйте обнулять errno перед вызовом fopen. Возможно значение, осталось от предыдущего вызова. Вообще читать errno надо, только если fopen вернул NULL. При нормальном завершении errno не меняется.
И если pFile == NULL, очевидно, что не надо вызывать fclose.

Символы с кодами от 0 до 31 куда входит ТАБ являются управляющими символами (comma control / control symbold). И их задача - вызывать разные эффекты при выводе строки на экран. Звук. Backspace. Движения
курсора в разные стороны. Поэтому данный диапазон символов не рекомендуется к оформлению текста. Потому что при печати текста на принтер например - эффект непредсказуем. Многие из них были частью сетевых протоколов и сейчас уже не используются.

Символ табуляции в середине 20-го века использовали для оформления исходников на ассемблере
ради экономии места. Это было удобно. Когда вся память ПК мерялась десятком килобайт - надо было
экономить даже на тексте программы. И это реально работало. В современной разработке вообще
нет необходимости использовать TAB (0x09). Ну разве что в Makefile он по старинке еще используется.
Но мейк делали такие длинно-бородые колдуны что там нет диалога о модернизации. Часть колдунов
уже померли. А оставшимся пофиг.

Еще иногда символ TAB я встречаю в экспортах баз данных в формате TSV (Tab-Separated) но
честно говоря на экране такой дамп выглядит ужасно. Все равно по 1 линии выравнивание не
получается. Поэтому втопку такое.

Сегодня в современнных IDE символ табуляции автоматически заменяется на серию пробелов. Поэтому
смысла спорить о ТАБ нет никакого. Потому что и символа то уже нет. Есть просто клавиша которая
имеет семантику добивания пробелов.

UPD: Для исходников типа Python/Scala TAB (0x09) может создавать проблемы. Особенно когда идет
микс отступов например одна строка TAB а другая spaces. Это сложные невидимые глазами
проблемы. Только компиллятор увидит и ругнётся. Поэтому - выпиливайте ТАБы как сорняк.
Чем скорее - тем лучше.