Re: Visual C# vs C++. Надо сравнить перспективы.
От: alex_public  
Дата: 06.01.17 05:23
Оценка: +2 :)))
Здравствуйте, 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. Заранее прошу не обижаться. Но на мой взгляд, человек задающий подобные вопросы не может претендовать на звание архитектора проекта. Архитектор должен иметь хотя бы базовые технические знания в данной области, а судя по вопросам в теме нет даже этого. Так что рекомендую вам всё же найти для этого соответствующего специалиста, а то боюсь иначе проект будет обречён изначально.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.