Василий Мельников

[StructLayout(LayoutKind.Sequential)]
        public unsafe struct PLUGININFO
        {              
            public fixed byte name[101];      
            public fixed byte describe[201];
            public short version;

            // либо
            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 101)]
            public string name;
            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 201)]
            public string describe;

            public short version;
        }

То, что вы просите, невозможно сделать по одной простой причине. Наследование в .NET бывает только "настоящее", т.е. когда устанавливается отношение is-a. Ваш MyTCPStream не может быть Stream-ом, если не реализует метод Read (Byte[], Int32, Int32). Спросите себя - что произойдёт, если я скастю объект MyTCPStream к Stream, и попытаюсь вызвать Read(Byte[]...)?

Вы конечно можете в теле метода бросить InvalidOperationException, но это однозначно признак неверно выбранной абстракции. Лично я не понимаю, зачем вам мог понадобиться TCPStream, из которого вы читаете не байты, а символы.

Для реализации процесса чтения более сложных объектов (а символ это более сложная штука, т.к. его представление в потоке зависит от кодировки) в дотнете есть TextReader и его наследники. Было бы хорошо, если б вы описали изначальную задачу - возможно мы посоветуем вам что-то полезное, а не странные хаки.

1. is-a - наследование

class Car : public Vehicle {
 // автомобиль является транспортом
};

2. has-a - отношение типа "композиция"

class Car {
 Engine v8; // автомобиль имеет (содержит) двигатель
};

3. uses-a - отношение типа "агрегация"

class Driver {
 Car* myCar; // водитель использует автомобиль
};

4. is-like-a

class Square : public Figure;
class Rectangle : public Figure;
// квадрат и прямоугольник похожи по свойствам, но это разные фигуры

5. is-implemented-as-a

class Engine { // абстракция
public:
 virtual void start() = 0;
protected:
 float power;
};

class V8 : public Engine { // реализация
 virtual void start() {
  // wroom wroom
 }
};

// Двигатель ДВС реализован как 8-ми цилиндровый двигатель V-конфигурации

1) Документируй
2) Абстрагируйся всегда максимально
3) Пиши классы по принципу "черного ящика"
4) Один класс решает одну конкретную задачу, не стоит городить комбайны.

Я стараю придерживаться простого совета: один метод - одно действие. Т.е. каждый метод класса должен выполнять строго одну функцию. Число строк одного метода - не более 20.

1) стоит инициализировать Arg: Arg* arg = new Arg;
Не забудьте удалить его в конце использования ( как понимаю в threadFunction).
2) Используйте std::function<void()> вместо c-style функции, чтобы избежать лишних проблем с удалением лямбды.

1) ваши for (i = thread;i < threads;i += threads) ничего не делают и эквивалентны int i = thread;
2) когда вы печатаете массив целиком, потоки могут печатать значения в произвольном порядке. выводите на печать номер треда, который печатает это значение

3) не сразу заметил. переменные, описанные вне pragma omp - общие для всех потоков. в итоге переменная с номером потока оказывается перезаписанной другим потоком. и к моменту сравнения в переменной уже будет значение чужого потока.

int main()
{
  int thread;
  int table[8] = { 0 };
  omp_set_num_threads(8);
#pragma omp parallel private(thread)//всё, что дальше в скобках - будет запущено в 8 потоках одновременно
  { //потоки могут получать управление в произвольном порядке
    thread = omp_get_thread_num(); //каждый поток получает свой номер
    if (thread%2 ==0)  //четные потоки записывают в табличку единицу
        table[thread] = 1;
#pragma omp critical //критическая секция в один момент времени может выполняться только одним потоком
    {               //это необходимо, чтобы печать из разных потоков не перемешивалась
        std::cout << "Hello, I am thread no " << thread << std::endl;
        std::cout << "My table value is" << table[thread] << std::endl;
    }               //потоки проходят секцию также в произвольной очередности
  }
}

https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx

Все дело в том, что функция time() возвращает UTC метку времени. То есть, время по Гринвичу.
Тебе надо сделать корректировку на свой часовой пояс для получения локального времени.

Посмотри пример по этой ссылке:
en.cppreference.com/w/cpp/chrono/c/gmtime

Постинкрмент (i++) отличается от преинкремента тем, что возвращает значение, которое было до инкремента, изменяя значение самой переменной. Это хорошо видно в примере на С++. Семантика в языках одинакова.

Для перевода в восьмиричный вид можно воспользоваться методом Integer.toOctalString(int);

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

если вы без указания типа и так УЖЕ ИМЕЕТЕ достаточно информации, чтобы уверенно работать со значением - тогда можно использовать auto. Если чувствуете, что не имеете, или сомневаетесь, что имеете - лучше тип указать.

При объявлениях функций auto в качестве типа возвращаемого значения вы так просто не напишете. Это должны быть инлайн функции. Как правило, такая потребность может встретиться разве что при написании шаблонов, которые реализуются прямо в хедере и для методов в которых порой вывести тип возвращаемого значения без auto крайне тяжело. Если вы школьник и не так давно программируете, на ближайшее время вообще забудьте про такую возможность. Она вам не нужна. А для разработчиков всяких хитроумных шаблонных библиотек это может быть очень даже полезной фичей.

И ещё один аргумент за использование auto при определении переменных. Большинство современных IDE нормально справляются с тем, чтобы сообщить вам тип переменной, когда вы просто наводите мышкой на её имя, даже если она объявлена как auto. Это во многих случаях смягчает негативные стороны использования auto, если таковые вообще имели место в данном куске кода.

А для более "продвинутых" программистов рекомендую к прочтению вот эту статью Герба Саттера. Всё прекрасно разложил по полочкам насчёт использования auto и объяснил, почему это в большинстве случаев не так страшно, как некоторым кажется на первый взгляд. Конечно, предложенная в конце идиома "almost always auto" спорная, C++ это всё-таки не джаваскрипт. Но остальное написано очень разумно.

Такие дельные советы тут...

А правило проще некуда: если вы без указания типа и так УЖЕ ИМЕЕТЕ достаточно информации, чтобы уверенно работать со значением - тогда можно использовать auto. Если чувствуете, что не имеете, или сомневаетесь, что имеете - лучше тип указать. Пример, где использование auto отлично подходит - итераторы:

std::list<int> items;
auto i = items.cbegin();

Во второй строке четко написано - items.cbegin - константный итератор по items, бегущий с начала списка. Мне этого более чем достаточно. Указание типа std::list<int>::const_iterator мне никакой новой информации не принесет. Тем более, т.к. итераторы от разных контейнеров несовместимы, то мне нужно еще и сразу знать, по какому конкретно списку у меня итератор - я опять-таки посмотрю на items.cbegin, а не на тип.

А вот auto в объявлениях функций/методов и правда ни к чему. Его, кстати, даже не сразу там разрешили использовать (только в C++14). Причина тому вновь читабельность - чтобы понять, что возращает функция, нужно прочесть ее текст как минимум до первого return, а лучше - полностью. Единственный сценарий, где без auto не обойтись при указании возвращаемого типа - это стрелочная нотация с decltype, но я думаю вы не скоро с ней столкнетесь.