Если пишете на С++ то в том то и смысл чтобы использывать собственные библиотеки где только можно.

Иначе лучше сразу писать на С#, Бейске и.т.п.

Конечно пока что разница есть ещё.

В .Net настораживют многие вещи.

Например сама концепция "управляемого кода"

На мой взгляд ничто иное как самая обычная интерпретация во время выполнения
программы а не во время компиляции.

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

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

Сложность ещё также в том что для совмшения модулей написанных под .NET и
обычных нативных модулей приходится дополнительную работу выполнять.

В то время как поддержка совмешения нативных модулей написанных даже на разных языках реализуется аппаратно при помощи стандартизирваного механизма вызова функций и программно при помощи унифицированного объектного формата и.т.п.


Странно почему это Майкрософт продвигая .NET в первую очередь всё-таки как особый стиль "фрейворка" решила резко отойти от общепринятого стандарта на системном уровне, которого сама же в своих собственных программах придерживается очень строго.

С другой стороны врядли объективно есть альтернатива .NET сегодня.
Прежде всего это касается конечно тех частей программы под Виндовс которые отвечают за действия выполняемые операционной системой.
Тут разница как раз небольшая. Что обычная "нативная" программа вызывает системную функцию операционки (которая естественно уже выполняется процессором напрямую) что программа написанная на интерпретируемом коде вызывает всё ту же
системную функцию опять таки выполняемую процессором напрямую . Разница только в том что в последнем случае эта функция не доступна напрямую, но только через
виртуальную среду выполнения.

Также можно сказать, что писать нормальные программы, подлежашие отладке,и.т.п. под Виндовс не используя жёскую объектно-ориентируемую концепцию просто нереально. Прежде всего это касается конечно же User Interface

Виндовс настолько сложно устроенна на системном уровне что если не абстрагироваться от него и каждый раз закапываться в особенности реализации конкретного механизма то в итоге по сути каждую программу придётся начинать писать с нуля. А что такое писать с нуля даже "простенькую программку" которая ничего кроме окошка на экране не выводит под Виндовс все знают.

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

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

Разговоры о том что "это потребует много времени" справедливы если фирме срочно нужен какой-то мега-проект "на позавчера" а под рукой ничего кроме уже готовых библиотек, фреймворков и.т.п. нету. Совсем другое дело когда вопрос касается самого программиста тем более в небльшой фирме. Тут то всё наоборот. Как раз написание таких собственных библиотек экономит львиную долю времени в конечном итоге. К тому если с самого начала подойти к вопросу обстоятельно то нет никакой необходимости писать "сразу всё", Достаточно схематично обрисовать общую концепци и лишь те классы реализовывать которые нужны в настоящий момент.
Это что касается UI и прочей системной чепухи.
Остальное же вообще само собой понятно что реализовывать нужно самому и лучше чем это делают конкуренты. Иначе же в чём смысл работы программиста



Всю системную функциональность желательно вообще запихнуть в объекты
один раз и потом о ней вообще забыть. Возвращаться только тогда когда
реализация той или иной фунции системой меняется в новой версии и.т.п..
К тому же иногда интересно писать программы которые легко переносятся
на другую платформу. Делать это используя "библиотеки Микрософт" сами понимаете
занятие довольно глупое в принципе.
Если же программа абстрагируется от конкретной системной функциональности при помощи ваших собственных библиотек классов то ничто вам не мешает писать прикладую программу (в том числе и UI) меняя только системные библиотеки
под разные платформы а сам код прикладой программы (ну если вы не используете какие-то специфические экзотические контролы их свойства и методы) остаётся той же.


Например сразу когда начинает писать программу под Виндовс писать
простенькую бибиотеку классов с реализации всего двух классов "главного окна" и "приложения".
Используя всю мощь С++ Можно в итоге добится того что минимальная "программа под Виндовс" (и не только) состоит из максимум 5 строк.

НАпример таким образом:

clApplication APP;
ClMainWindow MW


MW.Create();
MW.Show(SW_NORMAL);
APP.WaitForEnd (MW.hThread);


Естественно реализация объекта "Главного Окна" таким образом задача не очень простая.
Прежде всего наталкивается на целый ряд проблем связанных с особенностью
архетектуры Виндовс. Но более менее оптимальные решения существуют в любом
случае.


Таскание мышкой контролов и.т.п. Тоже нет никаких проблем.
Реализуется "класс Диалога" таким образом чтобы например после того как натаскать мышкой контролов в редакторе ресурсов вызывать таким образом.





clDialog D;
D.Create(MW.hwnd,hTemplate);
D.AttachControlsWithTvents(&arrClControls);

D.Show();


Контролы также можно реализовать в виде классов.
В конструкторе которых указывать параметр ID из ресурса.

Например чтобы диалог с двумя кнопочками кнопочками обрбатывал их события.

что-то типа такого можно реализовать перед созданием диалога.


ClControlButton CB_Ok(IDOK), CB_Cancel(IDCANCEL);

CB_Ok.Events.OnClick = &CB_Ok_Clicked;
CB_Cancel.Events.OnClick = &CB_Cancel_Clicked;



То есть если кто-то действительно считает нужным реализовывать руками с нуля подобного рода функциональность то тогда конечно же лучше использывать "натив программирование и С++."
Хотя по большому счёт хождение по лесу граблей тут обеспеченно однозначно.

Но если вообще писать программы "в лоб" на фактически "чистом С" то в таком случае лучше сразу от этого отказатся.
Доводилось видеть мне кучу кода где народ пытался писать без создания хотя бы простенькой собственной библиотеки общих классов на "чистом С" там где прямо в функции окна релиузется какая то прикладная функциональность и.т.п. Чесно говоря сами же разработчики подобного были не в состоянии разобраться с собственным кодом.
Естественно в таком случае однозначно гораздо лучше использывать уже готовые библиотеки, фреймворки и.т.п.