Mercury13

Я сделал вот такой код (простите, для простоты «с крестами»).

#include <stdio.h>
#include <iostream>

int main() {
    int a = getchar();

    while (a != '\n') {
        std::cout << a << "-" << static_cast<char>(a) << std::endl;
        a = getchar();
    }
}

143-П
224-р
168-и
162-в
165-е
226-т

Так что не здесь полом. Но учтите, что работа была под виндой, а значит, в кодовой странице DOS-866. Подкиньте ОС, рабочую кодировку и чуть больше кода обвязки.

UPD1. Если символов 12 вместо 6 и ОС Android — перед нами кодировка UTF-8. И выводить в консоль по одному символу не очень кузяво, поскольку для русского текста получаются неполные кодовые позиции. Закройте буфер нулём и выведите целиком.

Потому что низкоуровневый софт должен…
• Быстро выполняться. Потому что его выполняют или в глубоких циклах (например, ОС), или на слабом железе.
• Расходовать мало памяти и не «течь». Потому что его часто выполняют на слабом железе. Или в чужих стеках, как драйвер.
• Содержать мало зависимостей. Если мы зависим от большой библиотеки вроде Qt, а её реализации на данной машине нет — выкуси. Точно так же интерпретатор Питона может оказаться лишней зависимостью. И многопоточка, которая часто требуется для «мусорщика».
• Быть совместимым с кодом на других языках. Это касается системного и драйверного кода, который вызывают из прикладного ПО (или, наоборот, прикладной кода из системной проги) — и даже с кодом на разных версиях .NET в расширениях оболочки Windows есть вопрос.
• И в то же время требуется некая доля переносимости и абстракции. Например, мы пишем джойстик на AtMega и не хотим мучиться с длинными числами — ЯВУ лучше будет, чем ассемблер. 10 бит АЦП на 8-битном процессоре уже длинное число!!

Почему Си? У него есть две фишки: большое поле для ручной оптимизации (ключевое слово register, op++), и он полагается на две ассемблерных утилиты — линкер и библиотекарь (tlink и tlib, например). Из-за этого компилятор Си довольно просто написать под новую машину, и на НЕоптимизирующем компиляторе можно писать довольно быстрый код.

Можно, и я бы посоветовал посмотреть на две вещи.
1. MiniZip. Настоящие виртуальные потоки, написанные на чистом Си!
Кстати, у нас на работе есть библиотека MiniZipPort, представляющая собой тупой перевод MiniZip на виртуальные потоки и шаблонные контейнеры — две строчки Си превращались в одну строчку на «крестах». К тому же для хранения каталога я использовал уже имевшийся самописный AccuStream (что-то вроде std::deque, только в виде потока).
2. Doom. Самый первый, 1993–94 года. Там тоже ухитрились делать объектно — правда, другими методами.

feof возвращает true, когда мы попытались прочитать и не смогли, потому что каретка ударилась в конец файла. А не когда каретка аккуратно припарковалась в конце файла — и уж тем более не когда она отделена от конца пробелами.

Лучше прочитайте про scanf…

On success, the function returns the number of items of the argument list successfully filled. This count can match the expected number of items or be less (even zero) due to a matching failure, a reading error, or the reach of the end-of-file.

…и посмотрите, как можно переделать условие цикла.

К.О.: Потому что void* — это не void. Первый — это вполне конкретный тип, второй — «псевдотип», используемый в двух контекстах.

Что собой представляет 17? Это 10001₂, или 1,0001₂·2⁴, или 1000,1000₂·2¹. Теперь видите, откуда две восьмёрки и порядок 1? Правильно не 0x1.1p+1, а 0x1.1p+4.

На основании каких правил — не могу сказать, думаю, какая-то оптимизация. Подождите, скачаю Qt, выяснилось, что на домашнем компе не осталось ничего прогерского.

Моя первая догадка. Если исходное число было float, то первая цифра 8…F тупо проще: отрезаешь порядок и знак, добавляешь неявную единицу, и получаем 24 бита, шесть шестнадцатеричных цифр.

Действительно библиотека MinGW выводит первую цифру 8…F, что для float, что для double. Зачем, не знаю.

Смотря в чём задача.
Возможно, нет никаких проблем.
Возможно, удастся вытащить общую функциональность в defines.h.
Возможно, удастся каким-то образом разорвать порочный круг. Например, в ООП это можно делать через интерфейс.

Дело тут в очерёдности операций.
Сначала вычисляются правые одноместные, потом левые.

Надо (**h)[1] = 0;.

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

Кстати, посмотри интереса ради gcc -Os.

Без особого консольного API той или иной ОС — никак. Потому что строка передаётся в консоль, когда пользователь нажимает на ввод.