Почему С++ много вакансий ?

Мне кажется он нужен — в научных вычислениях ( и то не уверен , т.к. мои знакомые используют фортран в том числе на суперкомпьютерах — могу ошибаться ), в игровых движках для ААА-игр , которые можно по пальцам пересчитать.
Что это инертность ( не хотят люди Java, C#, JavaScript, Python изучать ) или сегодня С++ это не тот С++ который был в 2003 году например, где был головняк с линковками, долгими компиляциями, оригинальными решениями для контроля памяти ( автопоинтеры ), сложностью работы с шаблонами ( разворачивались адского размера конструкции от которых иногда компилятору плохо становилось , в том числе из-за нехватки памяти ), также сложность отладки этих самых шаблонов.
Т.е. испытывать эту боль сейчас можно только в случае если без этого никак, т.е. без С++ не обойтись. Но часто встречаются вакансии относящиеся например к разработке интерфейса

Здравствуйте, okon, Вы писали:

O>Почему С++ много вакансий ?

За 30 лет написано тонны с++ кода, который нужно поддерживать.

Здравствуйте, okon, Вы писали:

O>Мне кажется
Не взлетит

Здравствуйте, Klikujiskaaan, Вы писали:

K>Здравствуйте, okon, Вы писали:

O>>Почему С++ много вакансий ?

K>За 30 лет написано тонны с++ кода, который нужно поддерживать.


В свое время много кода нагенерено было на Delphi, который кстати проще, при этом видел не раз как эти решения переписывали на C#, Java, Веб.
Отказаться от C++ намного слаще в этом плане ибо головняка сразу на порядок меньше по сравнению с тем же делфи

Здравствуйте, okon, Вы писали:
O>В свое время много кода нагенерено было на Delphi, который кстати проще, при этом видел не раз как эти решения переписывали на C#, Java, Веб.
O>Отказаться от C++ намного слаще в этом плане ибо головняка сразу на порядок меньше по сравнению с тем же делфи

Делфи — это формошлепство, плюсы это и формошлепство и сервер-сайд.

Здравствуйте, Klikujiskaaan, Вы писали:

K>Здравствуйте, okon, Вы писали:
O>>В свое время много кода нагенерено было на Delphi, который кстати проще, при этом видел не раз как эти решения переписывали на C#, Java, Веб.
O>>Отказаться от C++ намного слаще в этом плане ибо головняка сразу на порядок меньше по сравнению с тем же делфи

K>Делфи — это формошлепство, плюсы это и формошлепство и сервер-сайд.
Ну да согласен, но формошлепство ушло в Веб либо WinForms, WPF. А сервер сайд на тот же Веб, WCF, или Java, питон тот же.

Здравствуйте, okon, Вы писали:

O>Мне кажется он нужен — в научных вычислениях ( и то не уверен , т.к. мои знакомые используют фортран в том числе на суперкомпьютерах — могу ошибаться ), в игровых движках для ААА-игр , которые можно по пальцам пересчитать.
O>Что это инертность ( не хотят люди Java, C#, JavaScript, Python изучать ) или сегодня С++ это не тот С++ который был в 2003 году например, где был головняк с линковками, долгими компиляциями, оригинальными решениями для контроля памяти ( автопоинтеры ), сложностью работы с шаблонами ( разворачивались адского размера конструкции от которых иногда компилятору плохо становилось , в том числе из-за нехватки памяти ), также сложность отладки этих самых шаблонов.
O>Т.е. испытывать эту боль сейчас можно только в случае если без этого никак, т.е. без С++ не обойтись. Но часто встречаются вакансии относящиеся например к разработке интерфейса

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

Здравствуйте, okon, Вы писали:

O>Ну да согласен, но формошлепство ушло в Веб либо WinForms, WPF. А сервер сайд на тот же Веб, WCF, или Java, питон тот же.

Иногда, формошлёпству требуется максимальная скорость отклика на действия пользователя. Внезапно, выясняется, что тут нужны плюсы.

Здравствуйте, okon, Вы писали:

O>Но часто встречаются вакансии относящиеся например к разработке интерфейса

Требования к интерфейсу самые высокие, т.к. по нему конечный пользователь судит о софте, вспоми тоже Chrome где пользователи торчат что быстро работает.Поэтому лучше потратить несколько больше времени на разработку и доводку, чем выпустить сырой и медленный UI. C++ как раз здесь хорошо подходит: 1) скорость программирования сравнялась C#/Java, например, умные указатели не хуже чем GG и пр. "няшки" 2)легко интегрировать со сторонними библиотеками 3) неограниченные возможности оптимизации. Так что, C++ — это сила.

Здравствуйте, kr510, Вы писали:

K>Здравствуйте, okon, Вы писали:

O>>Но часто встречаются вакансии относящиеся например к разработке интерфейса

K>Требования к интерфейсу самые высокие, т.к. по нему конечный пользователь судит о софте, вспоми тоже Chrome где пользователи торчат что быстро работает.Поэтому лучше потратить несколько больше времени на разработку и доводку, чем выпустить сырой и медленный UI. C++ как раз здесь хорошо подходит: 1) скорость программирования сравнялась C#/Java, например, умные указатели не хуже чем GG и пр. "няшки" 2)легко интегрировать со сторонними библиотеками 3) неограниченные возможности оптимизации. Так что, C++ — это сила.

Т.е. процитированные мною болячки 2003года уже ушли ? просто без них я не понимаю как скорость разработки может сравняться. Чтобы на C# пересобрать изменения нужна пара секунд, на C++ было очень долго. Можно было покурить, а там и какая-нибудь ошибка могла затесаться и несколько раз пересобирать потом. А потом еще ошибка на линковке, еще время чтобы понять что не срослось проверить все настройки.

Здравствуйте, kr510, Вы писали:

K>Здравствуйте, okon, Вы писали:

O>>Но часто встречаются вакансии относящиеся например к разработке интерфейса

K>Требования к интерфейсу самые высокие, т.к. по нему конечный пользователь судит о софте, вспоми тоже Chrome где пользователи торчат что быстро работает.

Согласен, но в конечном счете выигрывают те кто делает может не самый быстрый интерфейс, но самый первый и может не самый быстрый но быстро расширяемый и быстро исправляемые ошибки.
К тому же в интерфейсе там рисовать нечего, для рисования С++ не нужен, нужны технологии вывода, а технологии тут две насколько мне известно GDI и DirectX на винде и узкое горлышко это не скорость вызовов, а скорость копирования в видеопамять. Если там есть какие-то сложные алгоритмы которые тормозят, для этого есть асинхронные методы или вынос на сервер то что должно считаться быстро на хорошем железе.

Здравствуйте, okon, Вы писали:

O>Т.е. процитированные мною болячки 2003года уже ушли ?

Из всех болячек реальна "сложностью работы с шаблонами", но она возникнет в любом языке если не следовать принципу KISS. Многие разработчики так увлекаются красивостью решения, что не оправдано усложняют его. Нужно каждый раз себя спрашивать если используемое решение самое простое.

Хорошим примером является Qt. Здесь и гибкость, и простота реализации одновременно.

O> Чтобы на C# пересобрать изменения нужна пара секунд, на C++ было очень долго.
Не могу сказать, что скорость сборки хоть сколько проблематична. Обычно все делится на модули и build-all делается где-то на континиус интреграшен сервере, а сам девелопишь в своем проекте, в своем модуле где все быстро.

O>> Чтобы на C# пересобрать изменения нужна пара секунд, на C++ было очень долго.
K>Не могу сказать, что скорость сборки хоть сколько проблематична. Обычно все делится на модули и build-all делается где-то на континиус интреграшен сервере, а сам девелопишь в своем проекте, в своем модуле где все быстро.

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

Потом если происходит ошибка на CI сервере в процессе build-all, то не всегда ее можно решить чисто по заголовку ошибки. Приходится либо локально ее искать либо на том же CI сервере делать изменения и проверять через build-all. А это очень больно.

Здравствуйте, okon, Вы писали:

O>Мне кажется он нужен — в научных вычислениях ( и то не уверен , т.к. мои знакомые используют фортран в том числе на суперкомпьютерах — могу ошибаться ), в игровых движках для ААА-игр , которые можно по пальцам пересчитать.
O>Что это инертность ( не хотят люди Java, C#, JavaScript, Python изучать ) или сегодня С++ это не тот С++ который был в 2003 году например, где был головняк с линковками, долгими компиляциями, оригинальными решениями для контроля памяти ( автопоинтеры ), сложностью работы с шаблонами ( разворачивались адского размера конструкции от которых иногда компилятору плохо становилось , в том числе из-за нехватки памяти ), также сложность отладки этих самых шаблонов.
Люди набираются опыта, учатся, умнеют. И, как прямое следствие, начинают работать в удовлетворяющем их изменившиеся требования языке?


O>Т.е. испытывать эту боль сейчас можно только в случае если без этого никак, т.е. без С++ не обойтись. Но часто встречаются вакансии относящиеся например к разработке интерфейса
Отстрелил себе пару конечностей в своё время? Ты не был еще готов. Может быть сейчас готов?

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, okon, Вы писали:


S>Люди набираются опыта, учатся, умнеют. И, как прямое следствие, начинают работать в удовлетворяющем их изменившиеся требования языке?
Не знаю у меня первое требование к языку , впрочем как к любому инструменту, чтобы он позволял мне делать фичи, не отвлекаясь на танцы с самим инструментом. В C++ у меня я помню самый приятный момент — когда программа все таки скомпилилась после какого-нибудь очередного рефакторинга или прикручивания сторонней библиотеки.

O>>Т.е. испытывать эту боль сейчас можно только в случае если без этого никак, т.е. без С++ не обойтись. Но часто встречаются вакансии относящиеся например к разработке интерфейса
S>Отстрелил себе пару конечностей в своё время? Ты не был еще готов. Может быть сейчас готов?
Да, и не пару, все конечности повреждены. Прежде чем снова идти в лес к волкам хочу разведать

Здравствуйте, okon, Вы писали:

S>>Люди набираются опыта, учатся, умнеют. И, как прямое следствие, начинают работать в удовлетворяющем их изменившиеся требования языке?
O>Не знаю у меня первое требование к языку , впрочем как к любому инструменту, чтобы он позволял мне делать фичи, не отвлекаясь на танцы с самим инструментом. В C++ у меня я помню самый приятный момент — когда программа все таки скомпилилась после какого-нибудь очередного рефакторинга или прикручивания сторонней библиотеки.
Всё верно. Ты говоришь именно про опыт.

O>>>Т.е. испытывать эту боль сейчас можно только в случае если без этого никак, т.е. без С++ не обойтись. Но часто встречаются вакансии относящиеся например к разработке интерфейса
S>>Отстрелил себе пару конечностей в своё время? Ты не был еще готов. Может быть сейчас готов?
O>Да, и не пару, все конечности повреждены. Прежде чем снова идти в лес к волкам хочу разведать
Ну попробуй оценить твой уровень знаний тогда и сейчас. Попробуй прикинуть — хватит ли тебе опыта

Здравствуйте, okon, Вы писали:

O>Т.е. процитированные мною болячки 2003года уже ушли ? просто без них я не понимаю как скорость разработки может сравняться. Чтобы на C# пересобрать изменения нужна пара секунд, на C++ было очень долго. Можно было покурить, а там и какая-нибудь ошибка могла затесаться и несколько раз пересобирать потом. А потом еще ошибка на линковке, еще время чтобы понять что не срослось проверить все настройки.

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

Здравствуйте, okon, Вы писали:

K>>Требования к интерфейсу самые высокие, т.к. по нему конечный пользователь судит о софте, вспоми тоже Chrome где пользователи торчат что быстро работает.
O>Согласен, но в конечном счете выигрывают те кто делает может не самый быстрый интерфейс, но самый первый и может не самый быстрый но быстро расширяемый и быстро исправляемые ошибки.
O>К тому же в интерфейсе там рисовать нечего, для рисования С++ не нужен, нужны технологии вывода, а технологии тут две насколько мне известно GDI и DirectX на винде и узкое горлышко это не скорость вызовов, а скорость копирования в видеопамять. Если там есть какие-то сложные алгоритмы которые тормозят, для этого есть асинхронные методы или вынос на сервер то что должно считаться быстро на хорошем железе.

Ну так тот же C# или Java проигрывают C++ почти в десять раз по скорости именно на обработке (в том числе и копирование) таких матриц в памяти. )))

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, okon, Вы писали:

K>>>Требования к интерфейсу самые высокие, т.к. по нему конечный пользователь судит о софте, вспоми тоже Chrome где пользователи торчат что быстро работает.
O>>Согласен, но в конечном счете выигрывают те кто делает может не самый быстрый интерфейс, но самый первый и может не самый быстрый но быстро расширяемый и быстро исправляемые ошибки.
O>>К тому же в интерфейсе там рисовать нечего, для рисования С++ не нужен, нужны технологии вывода, а технологии тут две насколько мне известно GDI и DirectX на винде и узкое горлышко это не скорость вызовов, а скорость копирования в видеопамять. Если там есть какие-то сложные алгоритмы которые тормозят, для этого есть асинхронные методы или вынос на сервер то что должно считаться быстро на хорошем железе.

_>Ну так тот же C# или Java проигрывают C++ почти в десять раз по скорости именно на обработке (в том числе и копирование) таких матриц в памяти. )))
Но быстрое копирование памяти это же не язык, а в конечном счете команды процессора делают, не помню как называются но загружаешьв них откуда куда и длинну и они это делают, быстрее помоему не возможно. Если компилятор C# генерит не тот ассемблерный код для копирования, то ведь всегда можно небольшой код unmanaged с ассемблерной вставкой сделать который копирует правильной инструкцией, если это критично.
Да и наверняка для этого дела уже есть библиотеки которые это все делают был бы спрос ?

Здравствуйте, okon, Вы писали:

O>К тому же в интерфейсе там рисовать нечего, для рисования С++ не нужен, нужны технологии вывода,

С++ позволяет оптимизировать вплоть до машинных команд, а скрипторбразные языки имеют жесткий предел, нельзя сделать быстрее чем поставленный фреймворк. Да и сам фреймворк обычно тяжел. Его надо отдельно ставить, скачивать, обнавлять.

Здравствуйте, okon, Вы писали:

_>>Ну так тот же C# или Java проигрывают C++ почти в десять раз по скорости именно на обработке (в том числе и копирование) таких матриц в памяти. )))
O>Но быстрое копирование памяти это же не язык, а в конечном счете команды процессора делают, не помню как называются но загружаешьв них откуда куда и длинну и они это делают, быстрее помоему не возможно. Если компилятор C# генерит не тот ассемблерный код для копирования, то ведь всегда можно небольшой код unmanaged с ассемблерной вставкой сделать который копирует правильной инструкцией, если это критично.

Ну так обычно почти так и делают. ))) Обычно пишется некий мощный и быстрый движок на C++ и потом на чём-то лёгком и удобном (например на Питоне) дописываются управляющие им скрипты. По такому принципу сейчас построено множество успешных сложных продуктов.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, okon, Вы писали:

_>>>Ну так тот же C# или Java проигрывают C++ почти в десять раз по скорости именно на обработке (в том числе и копирование) таких матриц в памяти. )))
O>>Но быстрое копирование памяти это же не язык, а в конечном счете команды процессора делают, не помню как называются но загружаешьв них откуда куда и длинну и они это делают, быстрее помоему не возможно. Если компилятор C# генерит не тот ассемблерный код для копирования, то ведь всегда можно небольшой код unmanaged с ассемблерной вставкой сделать который копирует правильной инструкцией, если это критично.

_>Ну так обычно почти так и делают. ))) Обычно пишется некий мощный и быстрый движок на C++ и потом на чём-то лёгком и удобном (например на Питоне) дописываются управляющие им скрипты. По такому принципу сейчас построено множество успешных сложных продуктов.

Кстати сейчас же Roslyn открыт, почему бы не сделать инструкцию для быстрого копирования. Это не возможно технически или просто надо таск завести ?

S>Всё верно. Ты говоришь именно про опыт.
S>Ну попробуй оценить твой уровень знаний тогда и сейчас. Попробуй прикинуть — хватит ли тебе опыта
Опыта в принципе хватало , по крайней мере задачи решались. Не хватало терпения,а сейчас его стало еще меньше. Очень больно когда идет время а задача решается не так быстро как это возможно

Здравствуйте, okon, Вы писали:

S>>Всё верно. Ты говоришь именно про опыт.
S>>Ну попробуй оценить твой уровень знаний тогда и сейчас. Попробуй прикинуть — хватит ли тебе опыта
O>Опыта в принципе хватало , по крайней мере задачи решались. Не хватало терпения,а сейчас его стало еще меньше. Очень больно когда идет время а задача решается не так быстро как это возможно
Снова зависит от опыта.

Здравствуйте, okon, Вы писали:

_>>Ну так обычно почти так и делают. ))) Обычно пишется некий мощный и быстрый движок на C++ и потом на чём-то лёгком и удобном (например на Питоне) дописываются управляющие им скрипты. По такому принципу сейчас построено множество успешных сложных продуктов.
O>Кстати сейчас же Roslyn открыт, почему бы не сделать инструкцию для быстрого копирования. Это не возможно технически или просто надо таск завести ?

Ну вообще то речь не просто о копирование (это мало кому интересно на практике). Речь о том, чтобы написать например такой код "for(int i=0; i<size; i++) a[i]=b[i]+c[i];" и получить максимальную допустимую данным процессором скорость выполнения. Чистый C++ (без специальных ручных оптимизаций по размеру кэша и т.п., которые кстати тоже делаются в C++, но цикл уже меняет свой вид) обычно позволяет достичь не менее половины этой скорости. Ну а C# чаще всего (в зависимости от конкретного кода) будет раз в 7-8 медленнее такого же кода на C++. )))

Ну и потом, какой уровень ты собственно хочешь закрыть C#? Если уровень скриптов, то он в любом случае не сможет достичь такой же лёгкости и скорости разработки, как у Питона. Ну а если низкий уровень движка на C++ пытаться переделать на C#, то это будут постоянные тяжёлые страдания с ручной оптимизацией на каждом шаге (в то время как C++ сам делает это всё на автомате).

Здравствуйте, okon, Вы писали:

O>Что это инертность ( не хотят люди Java, C#, JavaScript, Python изучать )
Буквально все знакомые хорошие программисты на плюсах знали еще несколько языков, питон и жабаскрипт — почти все, причем "знали" в данном случае, это — не знакомство с синтаксисом, а проекты, написанные на этом языке.

O>или сегодня С++ это не тот С++ который был в 2003 году например,
Да, плюсы очень сильно изменились, новые фичи языка плюс буст избавляют программиста от рутинной работы в степени, сравнимой с тем же питоном.

O>где был головняк с линковками, долгими компиляциями, оригинальными решениями для контроля памяти ( автопоинтеры ), сложностью работы с шаблонами ( разворачивались адского размера конструкции от которых иногда компилятору плохо становилось , в том числе из-за нехватки памяти ), также сложность отладки этих самых шаблонов.
Опять же, по сравнению с тем же питоном под виндой, где установка почти каждого нетривиального модуля — это боль, проблемы в сях, где ты полностью контролируешь все, даже если и не все понимаешь, — фигня, в общем-то.

O>Т.е. испытывать эту боль сейчас можно только в случае если без этого никак, т.е. без С++ не обойтись. Но часто встречаются вакансии относящиеся например к разработке интерфейса

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

Здравствуйте, jahr, Вы писали:

J>Когда писал на других языках — часто упирался в стенку из-за того, что что-то сделать нельзя из-за ограничений самого языка, с плюсами такого никогда не случается.

Я вот раньше упирался в частности например в отсутствие самоописания , т.е. например такого понятия как в .net — Reflection, в частности таких вещей как в C# аттрибутов и простого DI когда можно по метаинформации вычислить типы свойств, создать экземляр класса по текстовому названию типа, передав нужные значения в конструктор. В современной версии это есть ?

Здравствуйте, okon, Вы писали:

O>Я вот раньше упирался в частности например в отсутствие самоописания , т.е. например такого понятия как в .net — Reflection, в частности таких вещей как в C# аттрибутов и простого DI когда можно по метаинформации вычислить типы свойств, создать экземляр класса по текстовому названию типа, передав нужные значения в конструктор. В современной версии это есть ?

В самом языке — нет, но есть разные способы это эмулировать, и существуют они достаточно давно. Как
пример — COM и разные прибамбасы вокруг него. Как я понимаю, все вышеперечисленное в нем есть, он вообще, в некотором смысле, идеологический предшественник шарпа со всеми этими прибамбасами.

Здравствуйте, jahr, Вы писали:

J>Здравствуйте, okon, Вы писали:

O>>Я вот раньше упирался в частности например в отсутствие самоописания , т.е. например такого понятия как в .net — Reflection, в частности таких вещей как в C# аттрибутов и простого DI когда можно по метаинформации вычислить типы свойств, создать экземляр класса по текстовому названию типа, передав нужные значения в конструктор. В современной версии это есть ?

J>В самом языке — нет, но есть разные способы это эмулировать, и существуют они достаточно давно. Как
J> пример — COM и разные прибамбасы вокруг него. Как я понимаю, все вышеперечисленное в нем есть, он вообще, в некотором смысле, идеологический предшественник шарпа со всеми этими прибамбасами.

Не ну COM это совсем зло, .net хоть под линухом можно скомпилить и он будет работать, а ком там не запустится
На КОМ Reflection немного похож конечно но совсем не то, рефлексия гораздо приятнее

Здравствуйте, okon, Вы писали:


O>Не ну COM это совсем зло,
Мне кажется, это требует обоснований. Меня вот COM восхищает, примерно с тех пор, как я прочитал Inside COM и Essential COM в начале нулевых.

O>.net хоть под линухом можно скомпилить и он будет работать, а ком там не запустится
Это не довод, COM под линух смогу портировать даже я, уверен, для портирования точки нета потребовалось сильно больше усилий, просто микрософту это было стратегически выгодно, поэтому был портирован .Net

O>На КОМ Reflection немного похож конечно но совсем не то, рефлексия гораздо приятнее

Я не ощущаю себя сильно знакомым с рефлекшеном, был бы благодарен за пример того, чего принципиального можно сделать в языке с рефлекшеном, чего нельзя сделать в COM с TypeLib'ами.

Здравствуйте, jahr, Вы писали:

J>Здравствуйте, okon, Вы писали:


O>>Не ну COM это совсем зло,
J>Мне кажется, это требует обоснований. Меня вот COM восхищает, примерно с тех пор, как я прочитал Inside COM и Essential COM в начале нулевых.
КОМ требует регистрации своего КОМ-сервера, при изменениях интерфейса его нужно перерегистрировать, а не просто скопировать новый файл.
Не всегда перерегистрация успешно отрабатывает. Т.е. определенные боли с деплойментом возникают.
Также были случаи когда одно приложение вызывает сбой в КОМ-сервере в результате все приложения который данный КОМ-сервер используют сбоят.
Типы не очень удобны, не всегда коррелируют с типами приложения, всякие строки и прочее.
Это то что я успел словить в начале нулевых в процессе недолгого использования.

O>>.net хоть под линухом можно скомпилить и он будет работать, а ком там не запустится
J>Это не довод, COM под линух смогу портировать даже я, уверен, для портирования точки нета потребовалось сильно больше усилий, просто микрософту это было стратегически выгодно, поэтому был портирован .Net
Ну странно т.к. КОМ требует оснастки которая вся в WinDLL описана их тоже придется переписать.


J>Я не ощущаю себя сильно знакомым с рефлекшеном, был бы благодарен за пример того, чего принципиального можно сделать в языке с рефлекшеном, чего нельзя сделать в COM с TypeLib'ами.

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

Рефлекшене совершенно иначе. Допустим у тебя есть .net сборка .dll. Ты можешь легко перечислить все типы /классы/енамы/параметры/конструкторы/поля/свойства которые в этой сборке есть, не только паблик , но и приватные. В КОМе насколько я помню видно только то что сделано как паблик. Отфильтровать классы которые наследуются от определенных классов/интерфейсов. Но есть и еще киллер фича которой нету в коме или я думаю что нету — это аттрибуты. Т.е. любое поле/класс/метод можно пометить аттрибутом или несколькими и потом по этому аттрибуту найти нужные классы/методы/поля. Это используется например для XML сериализации.

[XmlRoot("Doc")]
public class Document
{
    [XmlAttribute("Id")]
    public int Id;
    
    [XmlElement("Value")]
    public string Value;
}

или например для PropertyInjection

public class BugMagic
{
    [PropertyInject]
    public ILogger _logger {get;}
}

Здравствуйте, okon, Вы писали:

O>Я вот раньше упирался в частности например в отсутствие самоописания , т.е. например такого понятия как в .net — Reflection, в частности таких вещей как в C# аттрибутов и простого DI когда можно по метаинформации вычислить типы свойств, создать экземляр класса по текстовому названию типа, передав нужные значения в конструктор. В современной версии это есть ?

Рефлексия (интроспекция времени выполнения) в нормальном компилируемом языке просто не нужна. Данная функция реально может понадобиться только для очень редкого класса задач и для них легко реализуется вручную (см. например метаинформацию в Qt или вообще COM/CORBA и т.п. технологии).

А вот интроспекция времени компиляции — это крайне необходимая функция в любом современном компилируемом языке. И её отсутствие является одним из главных недостатков текущего C++, заставляющего плодить монстров на макросах для задачек типа банальной автоматической сериализации. И есть надежда, что в стандарте C++17 это будет исправлено. Хотя в этом стандарте вообще столько изменений обещают, что даже не знаю как они справятся. Ну посмотрим. )))

Здравствуйте, kr510, Вы писали:

K>Поэтому лучше потратить несколько больше времени на разработку и доводку, чем выпустить сырой и медленный UI.

Никто не спорит, но при чем здесь С++? На плюсах полно сырых и медленных UI.

K>скорость программирования сравнялась C#/Java,

Щито?

K>например, умные указатели не хуже чем GG



K>пр. "няшки"

Что за няшки?

Здравствуйте, okon, Вы писали:

O>Рефлекшене совершенно иначе. Допустим у тебя есть .net сборка .dll. Ты можешь легко перечислить все типы /классы/енамы/параметры/конструкторы/поля/свойства которые в этой сборке есть, не только паблик , но и приватные. В КОМе насколько я помню видно только то что сделано как паблик. Отфильтровать классы которые наследуются от определенных классов/интерфейсов. Но есть и еще киллер фича которой нету в коме или я думаю что нету — это аттрибуты. Т.е. любое поле/класс/метод можно пометить аттрибутом или несколькими и потом по этому аттрибуту найти нужные классы/методы/поля. Это используется например для XML сериализации.
O>[XmlRoot("Doc")]
O>public class Document
O>{
O> [XmlAttribute("Id")]
O> public int Id;

O> [XmlElement("Value")]
O> public string Value;
O>}
O>[/c#]


Ну вот к примеру есть у нас самописная библиотека сериализации/десериализации xml на с++. Кода не на много больше, а по сути делается всё тоже самое.

class Document
{
public:
    struct LayoutDefault : Serializer::Layout < Document >
    {
        LayoutDefault()
        {            
            Attribute( L"Id", &Document::Id, int32_t() );
            Attribute( L"Value", &Document::Value, std::wstring() );            
        }
    };
public:    
    int32_t Id;
    std::wstring Value;
};

Кроме того к примеру в Qt есть аналог рефлекшена, там у наследника класса QObject тоже можно перечислить методы и свойства, и вызвать любой метод или изменить свойство, имея только метаинформацию. В этом и сила С++, можно реализовать всё что хочешь совершенно разными способами. А C# прибит гвоздями к одной реализации в Framework.

Здравствуйте, okon, Вы писали:

O>КОМ требует регистрации своего КОМ-сервера
Во-первых см. registration Free COM activation.
Во-вторых, никто же не мешает вернуть COM объект из обычной C функции, как это делают например CLRCreateInstance, D3D11CreateDevice, MFCreateMediaSession, и т.п.

O>при изменениях интерфейса его нужно перерегистрировать, а не просто скопировать новый файл
Зависит от интерфейса и изменений. При некоторых изменениях (добавили метод в конец интерфейса) не надо, при некоторых интерфейсах (IDispatch) тоже.

O>Также были случаи когда одно приложение вызывает сбой в КОМ-сервере в результате все приложения который данный КОМ-сервер используют сбоят.
Мне кажется out of process COM используется довольно редко сейчас.
O>Типы не очень удобны, не всегда коррелируют с типами приложения
Во-первых поддержка этих странных COM-типов основными языками очень хорошая.
Во-вторых COM бинарный стандарт взаимодействия компонентов, написанных на разных языках. Если бы COM-типы хорошо коррелировали например с C++ типами, с ними было бы сложно работать например из JavaScript, PHP и питона.

F>Ну вот к примеру есть у нас самописная библиотека сериализации/десериализации xml на с++. Кода не на много больше, а по сути делается всё тоже самое.

F>

F>class Document
F>{
F>public:
F>    struct LayoutDefault : Serializer::Layout < Document >
F>    {
F>        LayoutDefault()
F>        {            
F>            Attribute( L"Id", &Document::Id, int32_t() );
F>            Attribute( L"Value", &Document::Value, std::wstring() );            
F>        }
F>    };
F>public:    
F>    int32_t Id;
F>    std::wstring Value;
F>};
F>

Ну вот именно что самописная, т.е. этот механизм работает только для вас и только для конкретного сценария а другие разработчики никак не узнают что этот тип может сериализоваться и предложить например иной алгоритм сериализации, допустим вам нужен не XML а JSON. А также что если я просто хочу сериализовать свой класс просто сохранив все public поля с названиями по умолчанию. И при добавлении нового свойства чтобы оно автоматом подхватывалось.

В .net вы просто напишете вместо new DataContractSerializer().Serialize(stream, myobject) замените на DataContractJsonSerializer().Serialize(stream, myobject), который знает что то что вам нужно помечено стандартными аттрибутами [DataContract] и другие разработчики могут написать алгоритм общего пользования
Т.е. ваша dll останется как черный ящик с некоторыми публичнымы функциями. В .net сборки в этом плане намного прозрачнее можно перечислить все что в них есть, найти типы с определенными аттрибутами, наследниками.

Например у вас есть функция DoSomething( object &obj ), которая принимает ссылку на любой объект , причем вы делаете API в которое разработчики другие могут пихать что угодно и вы никогда не сможете проверить obj is List<DeveloperType> потому что вы ничего не знаете о существовании DeveloperType. А в случае .net вы сможете определить что вам передали на вход List<> , вычислить тип <T> и разобрать его состав вплоть до приватных полей и методов. Найти то что нужно, например поля с которыми надо работать ( если вы например разработчик очередного сериализатора ).

Здравствуйте, okon, Вы писали:

O>Здравствуйте, jahr, Вы писали:

J>>Здравствуйте, okon, Вы писали:


O>>>Не ну COM это совсем зло,
Ну не обязательно регистрировать COM, правда тогда им можно пользоваться только если его знаешь)))