mayton2019

Тут нужно акцент не на С++ делать а на то что разработка ведется для Windows. Тегнул топик.

Вот ссылочка на DLL-linked ordering. Может будет полезна

https://docs.microsoft.com/en-us/windows/win32/dll...

Первое. Тема топика Python + PowerShell. Тоесть непонятно тебе нужно программировать и развивать этот софт или решить задачу 1 раз и забыть. В зависимости от желания - будет разная реализация.

Второе. Есть коробочные утилиты fc (Windows) diff (Linux) которые такое сравнение делают. Но обычно для исходников и при условии что изменений мало. Почитай про них. Возможно это частично решит твою задачу.

Третье. Ты хочешь сравнивать одну строку со всеми из другого файла. Это декартово произведение. В данном случае тебе можно сортировать оба файла и тогда одинаковые значения будут кластеризованы рядом. Sort + Diff решают твою беду.

Вобщем думай. Но лучше 1 раз сделай покрывающий пример двух файлов. И результат чего надо на выходе. Это сэкономит время.

Программист управляет двумя потоками вывода текста. STDOUT и STDERR через функции printf(...) или через расширенную версию с указанием файлового дескриптора вывода fprintf( stderr, ....).

При запуске в консоли вы можете указывать что например вывод ошибок идет в err.log и стандартный вывод в std.log
application.exe > std.log 2>err
(в данном случае двойка - это номер дескриптора STDERR. Есть альтерантивный синтаксис когда для STDOUT
мы указываем единичку "1>std.log" но ее просто опускают поэтому синтаксис так странно отличается)

Как поступает с обоими потоками среда - я не помню. Скорее всего она их объединяет. Поэтому запускайте в консоли.

Это вобщем-то архитектура любого процесса Unix и Windows.

Размышления по code-review. Мне совершенно непонятно почему в одном условии выбран switch а в другом if.

switch (a) {
    case 'n': fl = (b == 'o'); break;
    case 'o': fl = (b == 'n'); break;
    }

Они ведь совершенно одинаковые по смыслу! Кроме того case без default секции всегда рассматривается как потенциальный баг.

Судя по скриншоту это windows. Если вы делаете бенчмарки под windows - то нужно правильно мерять время. Скорее всего вы меряли не время цикла а время запуска windows процесса + время цикла. Вместе с статическими конструкторами. И эти конструкторы в go оказались удачнее.

Короче вы не втом месте включали секундомер. А то так можно и доказать что PHP быстрее чем C++.

Данный вопрос выходит за рамки C++.

Он касается разработки под конкретную ОС (windows например) и эти вопросы нужно адресовать их API.

int64_t a = b/0

Тут проблема наверное в том что PWSTR - имеет фиксированную разрядность (это широкий символ w_char). А std::string зависит от опций препроцессора UNICODE. Так-то оно конструируется через конструктор string или присвоение.

Вещественные бывают float и double. И у них - разная точность при работе с десятичной системой.
Вообще все они не точно отражают введенную тобой десятичную дробь. Вопрос в том что ты с этого хочешь
получить?

Вот есть онлайн-калькулятор https://www.h-schmidt.net/FloatConverter/IEEE754.html
Понабирай в нем твои числа и понаблюдай во что они превращаются после присвоения. А тогда уже
и вопросы по вычитаню отпадут.

Какое-то время я посвятил играм с простыми числами. В студенчестве еще.
Вот тут не надо каждый раз прибавлять единичку.
if (K % (i + 1) == 0) {
Ее просто надо учесть в условиях цикла.
if (K % i == 0) {
Далее. Если нужно найти первый попавшийся делитель - то не надо перебирать все числа. Достаточно только 2 и все нечетные. Или даже лучше задать хард-кодом таблицу простых чисел до 2^16. Это как раз будет половина разрядной сетки int32.
int primes[] = { 2,3,5,7,11,13,17...... 65521 }
Это даст хорошее ускорение для поиска. Хотя время загрузки executable может увеличится. Кстати у меня много вопросов к бенчмаркам где стоит запредельно короткое время инициализации (0.25 s). Здесь - практически невозможно вычленить где время занимает алгоритм а где - просто запуск процесса операционки. Обычно когда меряют что-то подобное - меряют длительные процессы хотя-бы порядка минут но никак не секунд.

В С++ массивы нумеруются от нуля до (n - 1).

Чтобы просто почитать память процесса - ему можно послать сигнал SIGQUIT и он должен ссыпать самого себя в дамп файла. Это законный метод. Программист пытается понять state процесса.

Все прочие методы должны вызывать настоящий ужас спецов по инфо-безопасности. Кому понадобилось изменять чужие процессы? Какой юзкейс?

Если компиллятор глотает оба варианта и тесты проходят - то я-бы взял просто первый вариант.

Там меньше букв.

Замер i/o это хитрая штука. Тут недостаточно просто программирования. Нужно знать что ОС обычно берет на себя часть функций по управлению (планировщики) вводом-выводом и кеширование.

Тоесть если ты будешь тестить свои программы в порядке 1->2 то вторая будет иметь фору в виде прогретого дискового кеша. И нужно делать хотябы -4-6 экспериментов чередуя 1->2->1->2 несколько раз и собирать кумулятивное время для каждого приложения и потом брать арифметическое среднее.

Данный класс Timer в таком виде не нужен. Он слишком прост и его можно заменить в коносли на вызов

$ time yourapplication

В качестве улучшений таймера я-бы сделал StopWatch. Это таймер который можно вызывать несколько раз и он будет кумулятивно считать время между begin-end и выводить его в конце. Так можно мерять интересующие фрагменты кода которые работают только с диском и игнорировать например вычисления с CPU.

Для хранения матрицы 10000 на 10000 в формате double вам понадобиться кусок памяти порядка 800 Мб.
И это только для хранения исходных данных. А если нужно будет искать всякие определители и обратные матрицы
то сложно себе представить сколько дополнительной памяти будет нужно.

Если курсовая затрагивает разреженные матрицы (это где много дырок или областей без данных) - то можно
посмотреть в сторону сжатых матриц. Не знаю как щас а в 90-е была куча библиотек для этого дела.

Чем заполнить матрицы в данном примере - ХЗ. Надо погружаться в сам курсовой. Если он растет из физики то и исходные данные надо брать оттуда. Там всякие диагональные и треугольные и прочие.

Если функция непрерывна и если задана таблично. То можно проинтерполировать значения на интервалах между точками хотя бы по любой гладкой кривой типа полинома. И тогда окажется что несмотря на то что дискретные точки недостаточно близко находились друг к другу, а интерполированные отрезки сблизились к некому "эпсилон".

Тоесть в условии задачи скорее всего не хватает деталей.