Здравствуйте, Ночной Смотрящий, Вы писали:

ARK>>Де-факто у меня нет ни одной программы с WPF. Какая жалость.
НС>Студией не пользуешься совсем?

Я имел в виду домашний комп, на нем не пользуюсь. На работе есть, да. Интересно, кроме студии есть ли что-то еще на рабочем компе с участием WPF. Вряд ли...

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

ARK>Я имел в виду домашний комп, на нем не пользуюсь. На работе есть, да. Интересно, кроме студии есть ли что-то еще на рабочем компе с участием WPF. Вряд ли...

Это уж тебе виднее, что у тебя на рабочем компе. У меня из рабочего еще SourceTree имеется.

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

AO>Всем привет.
AO>В рамках будущего проекта будем создавать ПО под Windows.
AO>Решаем, какой инструмент разработки выбрать Visual C++ или Visual C#
AO>Я пытаюсь собрать информацию, оценить ”минусы” и “плюсы” и сравнить перспективу.
AO>Например, C# требует .NET. Что здесь хорошего, а что плохого?
AO>Какие еще ключевые отличия C++ от C# ?

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

1. Первым и ключевым шагом при выборе языка очевидно должно быть рассмотрение его применимости в данной области. Не в смысле сравнения удобства и т.п. подлежащих дискуссии вопросов, а в теоретической возможности вообще решить на данном языке требуемую задачу. В этом смысле с C++ всё очень просто — он может всё. Естественно не везде он будет самым удобным решением, но принципиальных врождённых ограничений у него нет. В случае C# ситуация принципиально другая, причём это в основном следствие ограничений не самого языка (хотя тут тоже кое-что есть, но это уже чаще актуально для эстетов), а платформы .Net. C# принципиально не способен на решение некоторых задач. Чаще всего это задачи в таких областях как: реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС. Но есть и некоторые другие, более редкие. В общем если ваша задача относится к одной из этих областей (я из ответов в данной дискуссии так и не понял что за ПО вы будете писать), то на этом алгоритм останавливается с очевидным ответом (C++), если же нет, то переходим к шагу номер 2.

2. Вторым шагом будет вопрос наличия в команде или потенциальной возможности нанять команду реальных специалистов по C++. Это не такой простой вопрос как кажется. Дело в том, что наверное 95% программистов заявляющих, что они умеют работать на C++, на самом деле даже близко не являются приемлемыми профессионалами в нём. А этот язык требует именно профессионализма. Даже если ограничиться самым самым минимумом, типа знания современного стандарта (C++17) и библиотек Boost (стандарт де-факто в мире C++), то уже легко отсеивается большинство "претендентов", а это ещё только верхушка айсберга. Поэтому серьёзные IT компании принимают весьма нетривиальные усилия для поиска и найма реальных специалистов по C++. Соответственно если у вас есть где-то под рукой подобная готовая команда, то конечно же лучшим выбором будет C++, просто потому что на нём в итоге получится более качественный продукт. А вот если подобной команды нет, то лучше сразу ориентироваться на C#. Продукт на нём возможно будет не так хорош, как на C++, но он хотя бы в итоге будет, даже при наличие только слабых программистов на C#. В отличие от команды слабых программистов на C++, которая скорее всего вообще завалит проект. Собственно данное отличие и является основным и единственным (но весьма важным для бизнеса) преимуществом C# над C++.

3. И только выбрав язык, мы можем приступать к следующему шагу — выбору наилучших инструментов для него. Делать же наоборот (выбирать язык по фиксированным инструментам, как предложено в изначальном сообщение) — это полная глупость. Набор инструментов зависящих от языка (а не универсальных, типа системы контроля версий или трекера задач) это обычно: компилятор, отладчик, IDE/редактор, набор библиотек (здесь частенько выделяют жирные GUI библиотеки, вырождающиеся в целые фреймворки). В случае C# здесь всё довольно просто — MS предлагают полный стек решения, который при этом ещё и является самым лучшим в мире C#. Разве что JetBrains являются конкурентом в области IDE. В случае же C++ ситуация обратная. Здесь MS опять же предлагает полный стек решения, но почти ни один его элемент не является лучшим в своей области. Их компилятор C++ ещё совсем недавно был крайне отсталым. В последний год они серьёзно подтянулись, но всё равно уступают лидерам (типа gcc). Их IDE для C++ становится сравнима с лидерами только при условие установки набора недешёвых плагинов от сторонних компаний. Ну а их GUI фреймворк для C++ (его зовут MFC) является просто диким ужасом и отстаёт от лидеров (типа Qt) на десятилетия. В общем в случае выбора в качестве языка C++, наилучший набор инструментов как минимум будет состоять не только из продуктов MS, а как максимум вообще будет обходиться без них. Но это всё не является каким-то сложным вопросом для реальных профессионалов в C++ (а как мы помним по шагу2, мы выбираем этот язык только при наличие такой команды) — они легко выберут оптимальные инструменты на данный момент времени.

P.S. Заранее прошу не обижаться. Но на мой взгляд, человек задающий подобные вопросы не может претендовать на звание архитектора проекта. Архитектор должен иметь хотя бы базовые технические знания в данной области, а судя по вопросам в теме нет даже этого. Так что рекомендую вам всё же найти для этого соответствующего специалиста, а то боюсь иначе проект будет обречён изначально.

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

Q>В C++ это не так: выбираешь ли ты «Go To Declaration Ctrl+F12», или «Go To Definition F12» — он может выдать список. Потому что компилятор на «этапе чтения мной кода» (евпочя) не имеет достаточной информации; он будет её иметь, только когда я попытаюсь код вызвать, SFINAE, и всё такое. А в нормальных языках компилятору не нужна поздняя стадия инстанцирования, чтобы знать, что к чему.
Q>Разобрался?

Что-то ты тут бредишь, причём сразу по нескольким пунктам.

1. Компиляторы не имеет никакого отношения ни к каким "Go To Declaration" или "Go To Definition". Они занимаются исключительно преобразованием исходных кодов в исполняемые и всё. А то, что ты описываешь — это работа IDE, у которых для этих целей есть свои анализаторы кода.

2. IDE и для C++ и для C# бывают разные, с очень разными анализаторами кода. Начиная от простейших на базе ctags и кончая сложными решениями, строящими полноценное AST в реальном времени. Уточни про какую конкретную IDE ты пишешь и какие конкретно примеры в ней работают не так, как тебе нравится. Возможно тебе подскажут IDE, которая делает всё как надо.

3. Рассуждения о недостаточности информации у IDE для построения полноценного AST (причём почему-то именно для C++) вообще смешны. Т.е. у компилятора есть вся необходимая информация (он же создаёт вполне однозначный исполняемый файл по данных исходникам), а у IDE значит нет? Откуда тогда её берёт компилятор, телепатически? На самом деле каждому адекватному специалисту вполне очевидно, что вся необходимая информация у IDE имеется и в C# и в C++. Разница тут в другом, достаточно банальном нюансе — для анализа C++ кода требуется существенно больше процессорного времени, так что построение AST в реальном времени (а именно это надо в IDE) является не такой простой задачей, как в случае C#. Соответственно в прошлом подобные анализаторы для C++ или работали точно, но сильно подтормаживали, или же работали быстро, но использовали некоторые эмпирики. Отсюда появление у некоторых неразбирающихся программистов мифов о невозможности анализа C++ кода в IDE. Однако в большинстве случае это уже всё в прошлом — анализаторы постоянно совершенствовались, оптимизировались и сейчас уже вполне себе нормально работает в реалтаймe и для сложного C++. Естественно речь про лидеров в данной области, а не про всякие убогие IDE.

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

_>1. Первым и ключевым шагом при выборе языка очевидно должно быть рассмотрение его применимости в данной области. ... Чаще всего это задачи в таких областях как: реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС. Но есть и некоторые другие, более редкие.

Я бы сюда добавил вопрос количества одновременных клиентов у сервера. Если это внутрифирменное приложение с не более чем сотней клиентов, то C# может потянуть. Если одновременных клиентов тысячи, то быстродействия C# не хватит.

_>2. Вторым шагом будет вопрос наличия в команде или потенциальной возможности нанять команду реальных специалистов по C++. Это не такой простой вопрос как кажется. Дело в том, что наверное 95% программистов заявляющих, что они умеют работать на C++, на самом деле даже близко не являются приемлемыми профессионалами в нём. А этот язык требует именно профессионализма. Даже если ограничиться самым самым минимумом, типа знания современного стандарта (C++17) и библиотек Boost (стандарт де-факто в мире C++), то уже легко отсеивается большинство "претендентов", а это ещё только верхушка айсберга. ... В отличие от команды слабых программистов на C++, которая скорее всего вообще завалит проект.

Ну вот: наслушались C++17 евангелистов, и теперь на C++ не пишут, только на С++17. Я мог бы пройтись по С++17 и показать, что половина фич либо нужна очень редко, либо вообще нужна только для исправления костылей других фич, а в нормальной разработке применяться не должна. В результате язык как снежный ком обрастает новыми ключевыми словами и классами, все исключительно ради того, чтобы всегда использовать stl и ни при каких условиях не использовать прямое управление памятью(move-семантика, auto, shared_ptr). В то время как stl, вообще то, изначально задумывался как упрощение программирования, а не замена знания алгоритмов на знание C++17. C++11-17 — это попытка сделать из C++ то, чем он стать не может.
Поэтому знание С++11-17 нужно приветствовать, однако заявлять, что все программы на классическом C++ (или С) плохие, не следует.

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

_>Соответственно если у вас есть где-то под рукой подобная готовая команда, то конечно же лучшим выбором будет C++, просто потому что на нём в итоге получится более качественный продукт. А вот если подобной команды нет, то лучше сразу ориентироваться на C#. Продукт на нём возможно будет не так хорош, как на C++, но он хотя бы в итоге будет, даже при наличие только слабых программистов на C#. В отличие от команды слабых программистов на C++, которая скорее всего вообще завалит проект. Собственно данное отличие и является основным и единственным (но весьма важным для бизнеса) преимуществом C# над C++.

Не являюсь "фанатом" какого-либо языка, но вот этот момент мне не очень понятен. Какой смысл писать что угодно на С++, если это может быть написано на C#? По-моему, абсолютно никакого.

А раз так, то на С++ как раз и следует писать только "реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС" (c), плюс кроссплатформенный и независимый по каким-то причинам от .NET софт.


То есть, у вашего алгоритма достаточно только первого шага:
_>1. Первым и ключевым шагом при выборе языка очевидно должно быть рассмотрение его применимости в данной области. Не в смысле сравнения удобства и т.п. подлежащих дискуссии вопросов, а в теоретической возможности вообще решить на данном языке требуемую задачу. В этом смысле с C++ всё очень просто — он может всё. Естественно не везде он будет самым удобным решением, но принципиальных врождённых ограничений у него нет. В случае C# ситуация принципиально другая, причём это в основном следствие ограничений не самого языка (хотя тут тоже кое-что есть, но это уже чаще актуально для эстетов), а платформы .Net. C# принципиально не способен на решение некоторых задач. Чаще всего это задачи в таких областях как: реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС. Но есть и некоторые другие, более редкие. В общем если ваша задача относится к одной из этих областей (я из ответов в данной дискуссии так и не понял что за ПО вы будете писать), то на этом алгоритм останавливается с очевидным ответом (C++), если же нет, то переходим к шагу номер 2 на этом алгоритм останавливается с не менее очевидным ответом (C#).

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

lpd>Я бы сюда добавил вопрос количества одновременных клиентов у сервера. Если это внутрифирменное приложение с не более чем сотней клиентов, то C# может потянуть. Если одновременных клиентов тысячи, то быстродействия C# не хватит.

Да и С++ тоже не хватит. Только ассемблер, а еще лучше — прямо в двоичных кодах, там самое лучшее быстродействие!

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

I>Да и С++ тоже не хватит. Только ассемблер, а еще лучше — прямо в двоичных кодах, там самое лучшее быстродействие!

Тогда уж схемное решение, в топку софтварь.

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

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

I>>Да и С++ тоже не хватит. Только ассемблер, а еще лучше — прямо в двоичных кодах, там самое лучшее быстродействие!

ARK>Тогда уж схемное решение, в топку софтварь.

Вообщем-то, в некоторых случаях так и поступают. Программирование содержит множество технологий, так что не понимаю иронии. Давайте тогда ОС писать на javascript.

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

lpd>Вообщем-то, в некоторых случаях так и поступают. Программирование содержит множество технологий, так что не понимаю иронии. Давайте тогда ОС писать на javascript.
Ирония в том, что товарисч голословно заявил что для некоего веб-сервера с нагрузкой в несколько тысяч клиентов, C# не подходит потому что "быстродействия не хватает"(с). Ну вправду, так в лоб, противореча сотням фактам и здравому смыслу, и так категорично — смешно.

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

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

lpd>>Вообщем-то, в некоторых случаях так и поступают. Программирование содержит множество технологий, так что не понимаю иронии. Давайте тогда ОС писать на javascript.
I>Ирония в том, что товарисч голословно заявил что для некоего веб-сервера с нагрузкой в несколько тысяч клиентов, C# не подходит потому что "быстродействия не хватает"(с). Ну вправду, так в лоб, противореча сотням фактам и здравому смыслу, и так категорично — смешно.

По тестам(в том числе по моим) код на C#/Java в 2-4 раза медленнее, чем на C++. Я, конечно, понимаю, что основные задержки могут быть в базе данных. Однако, если на сервере производится значительная обработка данных, прийдется устанавливать и админить в 2-4 раза больше серверов — что, очевидно, неудобно.
У C#, вообще, два преимущества перед C++:
1) При переполнении буфера не возникает угроза безопастности.
2) Удобно строить web-приложения.(хотя и на C++ существуют фреймворки)
Оправдывает ли это в 3 раза меньшего быстродействия или совмещения двух языков в одной программе? Мы видим, как тормозит Android на ровном месте(хотя последние телефоны на последнем железе работают уже терпимо, но медленее iPhone).

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

lpd>У C#, вообще, два преимущества перед C++:
lpd>1) При переполнении буфера не возникает угроза безопастности.
lpd>2) Удобно строить web-приложения.(хотя и на C++ существуют фреймворки)

Да ладно, есть и другие. Код на С# не такой угребский с кучей всяких закорючек, как на С++, гораздо проще и чище. В языке меньше подводных камней. Компиляция быстрее. Всякие IDE и рефакторинги работают быстрее.

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

lpd>По тестам(в том числе по моим) код на C#/Java в 2-4 раза медленнее, чем на C++. Я, конечно, понимаю, что основные задержки могут быть в базе данных. Однако, если на сервере производится значительная обработка данных, прийдется устанавливать и админить в 2-4 раза больше серверов — что, очевидно, неудобно.
Это если абстрактных коней в вакууме сравнивать. На практике же, перформанс типичного веб сервера упирается в перформанс базы данных: банальные индексы, оптимизация запросов и кеширование решают проблемы чуть более чем всегда. Ах да, затем упремся в производительность веб сервера(порядка 5-20 тыщ реквестов в секунду в зависимости от юз кейсов и конфигурации, для всех веб серверов отдающих динамический контент)
Ну а потом уж возможно упремся в проблемы .NET как управляемой среды.
lpd>У C#, вообще, два преимущества перед C++:
Ты ничего не понимаешь. Главное преимущество C# и Java — это возможность выдать результат в короткие сроки за небольшие деньги, силами низкоквалифицированной команды. И это будет работать и приносить прибыль бизнесу без привлечений дорогостоящих гуру, шаманства и так далее.

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

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

lpd>>У C#, вообще, два преимущества перед C++:
lpd>>1) При переполнении буфера не возникает угроза безопастности.
lpd>>2) Удобно строить web-приложения.(хотя и на C++ существуют фреймворки)

ARK>Да ладно, есть и другие. Код на С# не такой угребский с кучей всяких закорючек, как на С++, гораздо проще и чище. В языке меньше подводных камней. Компиляция быстрее. Всякие IDE и рефакторинги работают быстрее.
Если в C++ не злоупотреблять шаблонами, то код не сложнее и компиляция быстрая. IDE и рефакторинги — вопрос вкуса: мне хватает Eclipse/vim/Codeblocks.

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

lpd>Если в C++ не злоупотреблять шаблонами, то код не сложнее и компиляция быстрая. IDE и рефакторинги — вопрос вкуса: мне хватает Eclipse/vim/Codeblocks.
Угу, главное расшарить с командой общее понимание что такое "злоупотреблять с шаблонами". А то джуны считают что std::vector<int> — это уже злоупотребление и c упоением пишут свои контейнеры, а матерые сеньоры не стесняются стейт машины в шаблоны загонят и вполне уверены что этот подход рулит.

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

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

lpd>>У C#, вообще, два преимущества перед C++:
lpd>>1) При переполнении буфера не возникает угроза безопастности.
lpd>>2) Удобно строить web-приложения.(хотя и на C++ существуют фреймворки
I>Ты ничего не понимаешь. Главное преимущество C# и Java — это возможность выдать результат в короткие сроки за небольшие деньги, силами низкоквалифицированной команды. И это будет работать и приносить прибыль бизнесу без привлечений дорогостоящих гуру, шаманства и так далее.
Итого, может ты можешь привести причины, почему C# может выдать результат, кроме тех 1.5 причин, что я привел?
Зачем гуру, если не маньячить C++17? Какое шаманство, если нужно подключить один C++ веб-фреймворк? Оправдывает ли автоматическое управление памятью необходимость периодически писать и подключать части программы на C++?
Вот когда Java/C# появились, основным преимуществом называли кросс-платформенность. Сейчас апплеты ушли в прошлое и эта кросс-платфроменность нигде не используется, кроме запуска тормозного Android и на x86, и на Arm
Получается, управляемые языки, по сути, не нужны.

Здравствуйте, lpd, Вы писали:
lpd>Итого, может ты можешь привести причины, почему C# может выдать результат, кроме тех 1.5 причин, что я привел?
Еще раз для тех кто в танке: на C# можно прям взять и педалить бизнес функционал, а на С++ надо сделать 100500 приседаний чтобы выстроить инфраструктуру, договориться про тот как правильно использовать буст....
lpd>Зачем гуру, если не маньячить C++17?
В приведенном мной примере вообще не было ни строчки про С++ 17

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

I>Здравствуйте, lpd, Вы писали:
lpd>>Итого, может ты можешь привести причины, почему C# может выдать результат, кроме тех 1.5 причин, что я привел?
I>Еще раз для тех кто в танке: на C# можно прям взять и педалить бизнес функционал, а на С++ надо сделать 100500 приседаний чтобы выстроить инфраструктуру, договориться про тот как правильно использовать буст....
Ничего не мешает, по уму, создать фреймворк и инфраструктуру на C++, не уступающие C#/Java, и забыть про эти управляемые языки. Но да, учитывая наличие программистов, уже знающих C# и Java, в данный момент реально имеет определенный смысл их использовать для ряда распространенных типов проектов — это я не отрицаю.

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

lpd>Ничего не мешает, по уму, создать фреймворк и инфраструктуру на C++, не уступающие C#/Java, и забыть про эти управляемые языки. Но да, учитывая наличие программистов, уже знающих C# и Java, в данный момент реально имеет определенный смысл их использовать для ряда распространенных типов проектов — это я не отрицаю.

За 30 лет не создали.

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

_>>1. Первым и ключевым шагом при выборе языка очевидно должно быть рассмотрение его применимости в данной области. ... Чаще всего это задачи в таких областях как: реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС. Но есть и некоторые другие, более редкие.
lpd>Я бы сюда добавил вопрос количества одновременных клиентов у сервера. Если это внутрифирменное приложение с не более чем сотней клиентов, то C# может потянуть. Если одновременных клиентов тысячи, то быстродействия C# не хватит.

Безусловно. Там вообще можно ещё много узких областей назвать, где C# и ему подобные языки не подойдут. Я назвал только самые общеизвестные.

_>>2. Вторым шагом будет вопрос наличия в команде или потенциальной возможности нанять команду реальных специалистов по C++. Это не такой простой вопрос как кажется. Дело в том, что наверное 95% программистов заявляющих, что они умеют работать на C++, на самом деле даже близко не являются приемлемыми профессионалами в нём. А этот язык требует именно профессионализма. Даже если ограничиться самым самым минимумом, типа знания современного стандарта (C++17) и библиотек Boost (стандарт де-факто в мире C++), то уже легко отсеивается большинство "претендентов", а это ещё только верхушка айсберга. ... В отличие от команды слабых программистов на C++, которая скорее всего вообще завалит проект.
lpd>Ну вот: наслушались C++17 евангелистов, и теперь на C++ не пишут, только на С++17. Я мог бы пройтись по С++17 и показать, что половина фич либо нужна очень редко, либо вообще нужна только для исправления костылей других фич, а в нормальной разработке применяться не должна.

В С++17 действительно нет особо принципиального, так же как и в C+14, которые по сути получились доработкой революционного стандарта C++11. Хотя иx конечно же тоже желательно знать. А вот незнание всех возможностей C++11 тоже до сих пор встречается и является абсолютно не приемлемым для претензии на знание C++.

lpd>В результате язык как снежный ком обрастает новыми ключевыми словами и классами, все исключительно ради того, чтобы всегда использовать stl и ни при каких условиях не использовать прямое управление памятью(move-семантика, auto, shared_ptr). В то время как stl, вообще то, изначально задумывался как упрощение программирования, а не замена знания алгоритмов на знание C++17. C++11-17 — это попытка сделать из C++ то, чем он стать не может.

Вообще то move-семантика — это как раз реальная киллер-фича, которая принципиально увеличивает эффективность кода. Причём каких-то даже близких аналогов этой фичи нет ни в одном из мейнстрим языков.

lpd>Поэтому знание С++11-17 нужно приветствовать, однако заявлять, что все программы на классическом C++ (или С) плохие, не следует.

Программы то может и не плохие. Но если уж начинать сейчас новый проект, то очевидно, что глупо не использовать возможности современного C++.