Mercury13

Иногда, чтобы прикрыть теоретическую возможность важной ошибки.
Чаще нужно в Си++ с его автодеструкторами.
На чтение особо не влияет.

Вот пример на Си…

{ char* buf = calloc(n, sizeof(char));  // Ради чего я создал блок — ставлю в той же строке
    snprintf(buf, n, some_shit);
    strcpy(dest, buf);
    free(buf);
}

Ну а это чистые «кресты».

{ std::ofstream os(fname);
   os << someData;
}  // Тут файл закрыт

1. Каким-то образом преобразовать обе строки, чтобы избавиться от расхождений по стартовым слэшам. Слишком мало информации, КАК это сделать — возможна ситуация, когда вторая строка не начинается со слэша, а первая нет, но бывают ли другие?
2. Убедиться, что вторая строка — префикс первой. Если нет — непонятно, что делать.
3. Если вторая строка непуста и не кончается слэшом, убедиться, что в первой на этом месте слэш. Пропустить его.
4.1. Если от первой строки ничего не осталось — если в конце слэш, пропустить, и извлечь кусок до следующего с конца слэша.
4.2. А если осталось — извлечь кусок до слэша.
5. Придумай методику хранения информации. Вероятно, выделить память? — тогда на каждый результат придётся давать free.

Разрешите вмешаться. Штатное процессорное выравнивание — 8 на x64.

Выравнивания ниже штатного иногда увеличивают, чтобы одним махом обрабатывать несколько полей. Например, для умножения цветов в формате RGB на x86 кто-то одним махом множил R и B, а вторым — G. Но при этом для производительности цвет должен иметь выравнивание 4.

Выравнивания выше используют только для хитрых системных целей: выйти за строку кэша, работать с железом, которому такое выравнивание нужно, иногда для оптимизации: улучшенный Doom грузил таблицы преобразования цветов по адресам, кратным 64K, и собственно в EDX грузил адрес, в DH цвет фона, в DL цвет изображения — и получал в EDX указатель на новый цвет.

Касательно SDL — они в этой функции хотели абстрагироваться от формата цвета (RGB или BGR).

С enum — всё больше зависит от архитектуры проги: например, вы можете абстрагироваться от реальных значений цветов и иметь цвета «фон», «передний план», «рамка таблицы», «хороший», «плохой». Разница в производительности невелика.

Программа туда не уместится, если не предусмотрено способа разбить её пополам. Перемещение происходит, если её адрес по умолчанию чем-то не нравится: или занят, или надо утрамбовать адреса плотнее (было важно в эпоху DOS), или…

А пока — три важных ремарки.
1. В пользовательском пространстве у нас 2 гигабайта или больше виртуальной памяти, и она условно «пуста»: в любых адресах этой памяти можно разместить что угодно. Но если мы обратимся к отсутствующей странице, получим аварийный останов — такова уж издержка виртуальности. Сначала надо обратиться к системному менеджеру памяти, и он выдаст рабочий диапазон адресов.
2. Программа перемещается посегментно.
3. Есть два главных способа перемещения программы: адресация от IP и relocations.

Адресация от IP работает, понятное дело, если исходный и целевой адрес в одном сегменте. По какому адресу ни располагай сегмент — адреса от IP менять не надо. В x86, НЯЗ, она работает в одном-единственном случае: короткие переходы (±127 байтов). Ветвления все короткие, а если нужно ветвиться далеко — ответвляется на безусловный переход, который уносит далеко-далеко.

В x64 режим адресации от IP есть во всех обращениях к памяти, переходах и вызовах, но только на ±2Г (точно не в курсе).

Во всех версиях x86 базовый адрес при адресации от IP — это конец текущей команды, не начало.

Relocations — это ремарки: сегмент 1 рассчитан на базовый адрес 12. Если он другой — подкорректируй адреса 34 и 56. Независимо от метода адресации — от IP или абсолютного. Если сегмент загрузился не по штатному адресу — например, 23 — к числам по адресам 34 и 56 прибавляем разницу 11. Скажем, было 78, стало 89.

В архитектурах с сегментной памятью (x86-16) эта самая сегментная память — также метод перемещения программы. Старый добрый COM-файл имел абсолютные адреса, но только от начала текущего сегмента — и представлял собой исключительно машинный код, загружаемый по адресу не то 128, не то 256 (вот не помню). А перемещение его по памяти сводится к установке нужных значений в сегментные регистры SS/CS/DS/ES.
(Да, *.COM не имел вообще никакого формата, это просто куча кода и данных, которая 1:1 грузится в память.)

Вариантов много.
1. Непрозрачные указатели, которые нельзя разыменовывать.

struct OpaqueAddress;
using Address = OpaqueAddress*;

2. void*, const void*.
3. uintptr_t.
4. Жёсткие int’ы, если работаем с конкретной посторонней прогой под конкретную архитектуру (например, пишем чит к игре).
using Address = uint32_t;
5. Enum class, основанный на соответствующем int’е.
enum class Address : uintptr_t { NUL = 0 };

У вас две ошибки.
1. Целочисленное переполнение в знаменателе в prog += (double)1/(i*(i+1));. Вычисляйте знаменатель в double, его длины более чем хватит.
2. Нельзя брать в счёт аналитический результат, надо высчитывать погрешность по имеющимся данным. Поскольку ещё и ряд сходится ХУдожественно — придётся помучиться, 1/(i(i+1)) < k·eps не катит (катит, если элемент ряда убывает экспоненциально, а у нас всего лишь квадратично).

В таком случае, когда есть подозрение на конец файла, надо проверять возвращаемое значение функции fscanf:
• EOF — файл закончился;
• 0 — не прочитали (в данном случае, когда читаем символ такого явно не будет);
• 1 — прочитали.

Если во втором случае MSVC возвращает EOF, но заполняет — поведение некузявое, но допустимое.
Если во втором случае MSVC возвращает 1 — поведение дрянь.

Вообще для такого дела fscanf — большая пушка, лучше использовать fgetc.

Что тогда делают? Есть три варианта.
1. Перейти на кроссплатформенную библиотеку (Qt, например).
2. Наладить свою небольшую библиотеку, которая когда-нибудь станет кроссплатформенной.
3. Наладить механизм псевдонимов.
Эти варианты можно объединять: что-то перевести на другую библиотеку, что-то написать своё.

Примеры из личного кода.

ОДИН. Ну, например, собственные механизмы работы с путями к файлам потихоньку уходят в сторону std::filesystem::path.

ДВА. Ну, допустим, сделал свою библиотеку доступа к файлам — бонуса три. 1) Есть функции вроде writeIW (Intel word). 2) Проще писать свои абстрактные потоки, чем с std. 3) Феноменальная скорость под Windows (использует нечастый, но быстрый overlapped API с двойной буферизацией). На остальных ОС — обычная обёртка над FILE*.

ТРИ. std::random_device из MinGW 9 давал детерминированную последовательность. Потом попытался бросить эту обходную ветку, но кто-то из программистов пожаловался — на его машине r_d просто не инициализировался.

#if defined(__MINGW32__) && defined(__GNUC__) && !defined(__clang__)

    #define MINGW_RANDOM_DEVICE_WORKAROUND

    class MingwRandomDevice {};  // куча WinApi, опустим
#else //defined(__MINGW32__) && defined(__GNUC__) && !defined(__clang__)
    #include <random>
    using MingwRandomDevice = std::random_device;
#endif //defined(__MINGW32__) && defined(__GNUC__) && !defined(__clang__)

Если возвращаем НОВУЮ память:
1. вернуть массив заведомо бóльшей длины и поле длины.

struct Arr1 {
  int length;
  int data[100];
}
struct Arr1 someFunc() {}

2. Вернуть динамический массив.

struct Arr2 {
  int length;
  int* data;   // не забудь free(arr.data);
}
struct Arr2 someFunc() {}

Если работаем в ИМЕЮЩЕЙСЯ памяти.
3. Тот же Arr2, но разница в том, что data не надо высвобождать.
4. А если arr.data гарантированно понятное — то можно вернуть только int, поле длины (как в функции sprintf).

int sprintf ( char * str, const char * format, ... );

Она и возвращает массив — только его адрес гарантированно будет str и вернуть надо только длину.

Почему нельзя? Пишу на Си с крестами, но там ничего специфичного нет, кроме парочки перестраховок.
В Си++20 появился ещё и bit_cast.

#include <iostream>

union DoubleInt {
    double asDouble;
    uint64_t asInt;
};

static_assert(sizeof(double) == sizeof(uint64_t), "Strange machine with double != int64");

constexpr int BITS_MANTISSA = 52;
constexpr int BITS_EXPONENT = 11;
constexpr int BITS_SIGN = 1;

static_assert(BITS_MANTISSA + BITS_EXPONENT + BITS_SIGN == 64, "Programmer's funkup");

constexpr uint64_t MANTISSA_UNIT = uint64_t(1) << BITS_MANTISSA;
constexpr uint64_t MANTISSA_MASK = MANTISSA_UNIT - 1;

constexpr int EXPONENT_SHIFT = BITS_MANTISSA;
constexpr uint64_t EXPONENT_MAX = (uint64_t(1) << BITS_EXPONENT) - 1;
constexpr uint64_t EXPONENT_ORIGIN = EXPONENT_MAX >> 1;
constexpr uint64_t EXPONENT_MASK = EXPONENT_MAX << EXPONENT_SHIFT;
constexpr uint64_t EXPONENT_SHIFTED_ORIGIN = EXPONENT_ORIGIN << EXPONENT_SHIFT;

constexpr int SIGN_SHIFT = BITS_MANTISSA + BITS_EXPONENT;
constexpr uint64_t SIGN_MASK = uint64_t(1) << SIGN_SHIFT;

int main()
{
    DoubleInt x { -3.45 };

    // Простите уж, без денормализованных чисел

    // Оставим знак и мантиссу
    DoubleInt xMantissa = x;
    xMantissa.asInt &= (MANTISSA_MASK | SIGN_MASK);
    // И добавим туда стандартный нулевой порядок
    xMantissa.asInt |= EXPONENT_SHIFTED_ORIGIN;

    // Извлечём порядок
    int exponent = ((x.asInt & EXPONENT_MASK) >> EXPONENT_SHIFT) - EXPONENT_ORIGIN;

    std::cout << xMantissa.asDouble << "*2^" << exponent << std::endl;

    return 0;
}

не удается преобразовать 'char*' в 'int*' для аргумента '1' в 'int

Как правило, ошибка. Функция хотела указатель на 4-байтовые слова — а мы передаём ей указатель на байты.
Если очень нужно рассматривать int* как char* (например, работаем не с данными какого-то определённого типа, а просто с байтами в памяти) — используйте reinterpret_cast.

недопустимое преобразование из 'int*' в 'int'

Почти всегда ошибка. Функция хотела число — а мы ей передаём ей указатель.
Если реально по какой-то причине нужно значение указателя воспринимать как число — используйте reinterpret_cast.

Возможен и другой вариант — вы просто упустили операцию «разыменовать» *.

warning: narrowing conversion of '143' from 'int' to 'char' inside

Точно ошибка — 143 не вписывается в char (−128…127). Если очень надо, используй static_cast.

Покажите лучше код, и я устрою ему ревизию.

Связано это в первую очередь с механизмом передачи переменных аргументов в функцию Си.
Они просто сваливаются в стеке один за другим — и нужно каким-то образом показать, сколько этих аргументов и каких типов. И уж во вторую очередь — формат вывода: точность, система счисления, заглавные буквы, ширина и прочее.

Именно по этой причине — спецификаторы printf в первую очередь задают типы аргументов — функция printf ничего не может сделать, если мы ошиблись с типом. Потому что %d (%ld, %lld) для неё в первую очередь способ понять, сколько байтов взять со стека и как их интерпретировать.

Си++ для этих целей использует перегрузку функций, Delphi — тэгированные данные, Java — объектный полиморфизм. Так что они знают, с каким типом данных имеют дело — и для них не нужно различать signed/unsigned int/long/long long. Для них %d/%x/%X означает разные варианты целого, %e/f/g — разные варианты дробного, и. т.д. Если для дробного пользователь напишет %d, они или выкинут ошибку, или как-то интерпретируют.