Антон Барышев

Тут все пишут про отличия. Рискну написать про сходства.

Во-первых, о чём бы ни писала Елена и Си++ и C# - оба языки общего назначения. Даже больше, оказывается - C# ни разу не заточён под объёмную библиотеку (или фреймворк) .NET, однако с ним намного, много проще. Но если таки учитывать .NET, то для Си++ есть Boost и Qt, так что здесь скорее паритет - библиотек для обоих хватает.
Во-вторых, сложность разработки на Си++ часто преувеличена. Разве только дисциплины надо поболее - выстрелить в ногу здесь попроще. Однако при этом Си++ будет чутка более гибкий и без танцев с бубнами unmanaged код не запустить на C#. Если внезапно потребуется.
В-третьих, оба языка, раз они общего назначения, таки мультипарадигмальные. То есть они реализуют большинство практик. И хотя Си++ развивается довольно медленно, сейчас Си++ резко догнал C# в плане нереализованных фич (здесь как минимум лямбды). Ну и метапрограммирования у Си++ поболее будет (наглая ложь).
В-четвёртых, оба языка кроссплатформеные. Впрочем, C# будет более кроссплатформенный, чем Си++. Разве только тот же Qt резко стёр границы, но это не значит почти ничего - C# компилируется в тот же самый CIL для всех платформ, Си++ - в совершенно разный код для разных платформ (i386, amd64, ARM Cortex-AXX).
Наконец, в пятых, синтаксис у них действительно очень похож. Оба языка принадлежат к семейству Алгол-подобных, так что и брейсы, и остальные скобки здесь имеют примерно одно предназначение.

Различия, которые казалось бы делают языки совершенно разными, таки не столь принципиальны на том уровне абстракции, на котором был задан вопрос. А различия действительно колоссальны: C# - managed код, что означает, что скомпилированный код будет исполнятся не на прямую в CPU, а на специальной виртуальной машине. Это съедает производительность, но сильно облегчает перенос кода. Ну и потом, C# - полупроприетарный ответ Java (что интересно, так как получается, что C# - более свободный, чем Java), которая была создана как замена сложному и небезопасному C++ в том числе.

В общем, как человек, который начал давно с C#, продолжив C++ и по пути изучив Python, Java, D и другую ООП-чушь могу с уверенностью сказать, что разницы в общем-то и нет... То есть придётся немного проникнуться в чуть другую философию и выяснить, какие проблемы более новый язык пытался решить. Но если подходить к этому, как подошёл lookid, то это скорее не как изучать языки одной языковой группы, а как изучать один и тот же язык в разное время или в разных сферах.

Почему так? Потому что ООП... Оно как бы ООП, ничего сверхъестесственного ни один язык не предлагает, это не Haskell, и тем более не Brainfuck. Так что принципиально общие вещи в них будут. То подмножество, что реализует машину Тьюринга - у них общие. Сами посмотрите: циклы, ветвления, передача аргументов, арифметика... С небольшими правками всё совершенно одинаковое. Да, Дмитрий совершенно прав, traits на C# не повторишь, ибо та аналогия будет уже не traits, однако... Это уже [programming_language] related, то есть это попытка совладать с особенностями.

Немного пруфов: лично я ходящий пруф. Зная C++ и C# и немного Java я просто начал программировать на Python. При том, что Python даже алголоподобным не принадлежит. А всё потому, что логика одна и та же, хотя различий между Python и C(++|#) намного, много больше. Но не читая почти никаких туториалов, пройдясь галопом по европам с документацией сейчас я знаю python достаточно для серьёзного проекта.

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

ns.Read(headerBuffer); // прочитали заголовок
Вот здесь нет гарантии, что вы прочитали именно столько байт сколько у вас буфер.
Поэтому метод Read возвращает количество фактически прочитанных байт.
Это классические проблемы чтения, про которые можно почитать тут
Там как раз про то, как решить это все с помощью pipelines, которые упоминал Василий Банников

Сначала слать размер файла затем файл. Вычитывать размер, вычитывать заданное количество байт и снова вычитывать размер и т. д.

Почему бы и не плясать именно от расположения исполняемого файла?
Например ..\..\config

p.s. Только Environment.CurrentDirectory - штука несколько зыбкая, лучше Assembly.GetExecutingAssembly().Location

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

Можно в тестах требовать совпадение с некоторой абсолютной или относительной погрешностью.

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

Еще можно использовать более устойчивые к ошибкам округления методы. Метод гаусса не лучший выбор.

Это нормально и так и должно быть - компьютеры считают с погрешностью. В зависимости от того, насколько плохо обусловлена система, вы можете получить погрешность от 0 до примерно 15 верных знаков после запятой.

1. Использовать
private readonly object timeLock = new();
2. Использовать Mutex/Semaphore/SemaphoreSlim
3. Использовать класс Interlocked

Но я бы попробовал так:
4. Переосмыслить архитектуру, чтобы не было общих изменяемых ресурсов
5. Убедиться, что действительно вам нужен именно long, а не DateTime(Offset) или TimeSpan

Как организовать постоянное обновление DataGrid в отдельном потоке, чтобы при этом DataGrid был доступен, т.к. планируется добавить возможность выбирать строку из DataGrid и смотреть подробную информацию.

Нельзя обновлять элементы UI из не UI потока. Можно получать данные в другом потоке, но обновлять UI нужно из UI потока. Я бы просто пробегал по ObservableCollection<{T}>, где T это класс, реализующий интерфейс INotifyPropertyChanged и обновлял нужные объекты уже в UI потоке. Судя по всему, проект не придерживается паттерна MVVM, а лучше бы придерживался.

Список процессов нужно получать как раз в Task.Run(...), а вот вызывать обновление процессов в UI через Dispatcher или SynchronizationContext.

Посмотри мои ответы здесь:
Как осуществить ввод и вывод данных WPF?
Здесь про Task.Delay и вообще цикл в Task.Run Как сделать цикл на основе ответа на Web запрос в C#?
Здесь как перенаправлять выполнение через SynchronizationContext в UI поток С# Taks и Invoke почему то блокируется форма?

Ещё, ожидание в методах, которые запускаются тасками нужно делать через вызов await Task.Delay(...), но точно не через Thread.Sleep(...):

using System;
using System.Threading.Tasks;

namespace Tasks
{
    class Program
    {
        static async Task Main(string[] args)
        {
            // Так
            await Task.Run(async () =>
            {
                while (true)
                {
                    await Task.Delay(1000);
                    Console.Write("=");
                }
            });

            // Или так (обрати внимание на Unwrap()) 
            await Task.Factory.StartNew(async () =>
            {
                while (true)
                {
                    await Task.Delay(1000);
                    Console.Write("=");
                }
            }).Unwrap();
        }
    }
}