Здравствуйте, Alexey.Os, Вы писали:
AO>ПО будет разного типа (и десктопное, и клиентское, и презентационное, и например модель обсчитать)...
Считать удобнее на плюсах.
"По-быстрому" сделать GUI или прототип серверной части легче на дотнете.
Из своего опыта — хорошо заходит одновременное использование этих технологий, когда под винду. Дотнет сопрягается с нейтивом почти за бесплатно в смысле трудозатрат.
AO>Т.е. если есть зависимость от типа ПО, то хотелось бы этот вопрос понять.
На дотнете быстрее сделаете GUI и быстрее отладите всякую "бизнес-логику", т.е. когда много условных ветвлений или хождений автоматов по состояниям. А если еще и в базу при этом лезть надо, то для таких задач несомненно дотнет.
А на плюсах быстрее и удобнее реализовать любые вычисления или эффективную работу с файлами и/или сетью. Произвольное медиа, опять же, в шаговой доступности. Под дотнетом вопрос с медиа можно смело сказать что не обстоит никак.
Re[3]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Marty, Вы писали:
DM>>но тем не менее попробую ответить. ключевое отличие C# от C++ в том, что C# лучше чем C++. особенно на этом форуме M>C# хорош тем, что на волне хайпа за него неплохо платят.
Вообще на волне хайпа программистов на C# существенно больше чем C++ и зп в среднем в C# ниже.
Re[6]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Serginio1, Вы писали:
AG>>Я в курсе, что это есть, но этим пользуются редко — как правило просто ставят дот-нет нужной версии и всё. S> При этом рассуждаете о скорости. Net Native как раз и компилируется в чистый натив, только со сборкой мусора. S>Значит скорость не нужна.
Да в любом случае — по скорости (точнее — производительности) на .NET мы не выйдем на тот уровень, что даёт C/C++;
просто для приложений документооборота это совсем даже НЕ КРИТИЧНО.
Конечно же, NGEN даст прирост производительности, но не такой, как даёт "неуправляемый" код.
А собирая в "чистый натив" через NGEN — мы прежде всего убираем зависимость от установленных у клиента .NET фраймворков.
Здравствуйте, Dair, Вы писали:
D>А ещё есть notepad, который даже скачивать не надо!!! D>(VS Code — это же просто редактор же)
Это не просто редактор. Это платформа для экстеншнов, с помощью которых он неплохо интегрируется с... да с чем угодно, под что написаны экстеншны. Встроенный notepad тебе синтаксис не подсветит, Go To Definition не перейдёт и проект не соберёт.
Здравствуйте, Dair, Вы писали:
D>Вообще на волне хайпа программистов на C# существенно больше чем C++ и зп в среднем в C# ниже.
Зарплата C++-программистов была бы выше, если бы в языке было ещё больше нелепой фигни, требующей тупой зубрёжки. Например, пусть бы функции стандартной библиотеки назывались на китайском. Мне кажется, осиляторам всего мира стоит объединиться и подать петицию в комитет по стандартизации. Чтобы было ещё более сложно превозмогать, а потом гордиться своим осиляторством и высокой зарплатой, почти как у кобольщиков.
Здравствуйте, Qbit86, Вы писали:
D>>Вообще на волне хайпа программистов на C# существенно больше чем C++ и зп в среднем в C# ниже. Q>Зарплата C++-программистов была бы выше, если бы в языке было ещё больше нелепой фигни, требующей тупой зубрёжки.
AG>Да в любом случае — по скорости (точнее — производительности) на .NET мы не выйдем на тот уровень, что даёт C/C++; AG>просто для приложений документооборота это совсем даже НЕ КРИТИЧНО. AG>Конечно же, NGEN даст прирост производительности, но не такой, как даёт "неуправляемый" код.
AG>А собирая в "чистый натив" через NGEN — мы прежде всего убираем зависимость от установленных у клиента .NET фраймворков.
.NET Native использует то же сервер, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.
.NET Native способна обеспечить повышение производительности для C++ разработчиков управляемого кода, так как она использует такие же или аналогичные средства, что и C++ за кулисами, как показано в следующей таблице.
и солнце б утром не вставало, когда бы не было меня
S>.NET Native использует то же сервер, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.
S>.NET Native способна обеспечить повышение производительности для C++ разработчиков управляемого кода, так как она использует такие же или аналогичные средства, что и C++ за кулисами, как показано в следующей таблице.
Здравствуйте, Sinix, Вы писали:
S>Если и смотреть, то на вещи, которые позволяют облегчить разработку в целом. Для шарпа есть отличная инструментальная обвязка, включая студию, средства тестирования вплоть до UI-тестов, удобную навигацию по коду, средства автоформатирования и контроля за качеством кода и тыды и тыпы.
Уже пол-года как окончательно переехал на Resharper C++ в своей ежедневной разработке. И другим категорически советую.
Недавно вышло обновление Resharper, так совсем хорошо под плюсы стало.
S>Очень многое из этого отдельные специалисты по плюсам считают вообще ненужным и предпочитают консоль+блокнотик.
Таких разработчиков всё меньше и они работают обязательно над выделенной и очень ограниченной по размерам (исходников) задачей.
Там же, где одновременно надо ворочать огромными массивами исходников, без ср-в поддержки разработки не обойтись.
S>Тут конечно каждому своё, но меня не покидает подозрение, что при таком раскладе на бесплатные для типового разработчика под шарп вещи приходится тратить очень много усилий.
Обратное тоже верно. Причем, из многолетнего опыта — на бесплатные в С++ вещи из дотнета приходится тратить совсем много усилий. Причем, если потраченные из С++ усилия обычно означают небольшие изменения в коде (чаще всего — коррекция графа владения, т.е. изменения типов с указателей на смарт-поинтеры или одного смарт-поинтера на другой), то в C# усилия начинают тратится на разработку кучи собственного сугубо утилитного кода. Особенно обидно, когда такой код по функциональности дублирует уже имеющийся в фреймворке, но по каким-то причинам не подходит в конкретном месте.
Последнее для C# вообще задница, потому что все типы из библиотек прибиты гвоздями друг к другу или к неким базовым интерфейсам. Шаг вправо-влево — и начинаешь много делать ручками. В С++ такой проблемы нет совсем, т.к. львиная доля "базовых библиотек" работают с произвольными типами, необходимо лишь наличие неких методов у таких типов или переопределённых операций над ними в области видимости.
В общем, сравнивать C++ и C# разработку в плане гибкости бесполезно. Когда периодически работаешь одновременно на С++ и на C#, то всегда возникает одно и то же устойчивое ощущение, что на C# ты связан по рукам и ногам.
Здравствуйте, vdimas, Вы писали:
V>Когда периодически работаешь одновременно на С++ и на C#, то всегда возникает одно и то же устойчивое ощущение, что на C# ты связан по рукам и ногам.
У меня возникает ощущение, что на C++ ты пытаешься бежать в воде или каком-то желе.
Глаза у меня добрые, но рубашка — смирительная!
Re[10]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
AVK>А оно и есть киллер-фича кумулятивно, потому что я могу запустить автоматический рефакторинг на огромном проекте, и с высокой вероятность оно сделает все идеально. В плюсах же глобальный рефакторинг — штука весьма вероятностная, то ли пройдет, то ли ручками потом дочинивай из-за того что оно на макрос где нибудь наткнулось или особо хитрый шаблонный выверт.
Любые шаблонные выверты уже рефакторятся без проблем в сколь угодно больших проектах.
Проблемы бывают с макросами, когда тот же Resharper C++ "не видит" некоторых макроопределений (подаваемых при компиляции извне, например), и именно от таких макроопределений зависят определениях других макросов или ветвления условной компиляции.
Если же предоставить файлам-проектам С++ всю необходимую для сборки информацию, то проблема почти всегда исчезает.
Здравствуйте, Qbit86, Вы писали:
Q>Как это «особых проблем нет»? Вот прямо сейчас я читаю исходники Boost 1.62 (а C++ не создан для чтения не-автором, это write-only-язык). F12 для Go To Definition работает криво и через раз.
Попробуй Resharper C++.
Q>Навигация в одной и той же Студии 2017 RC для C# и C++ — экспириенс совершенно различный, доложу я вам.
В студии только с VS 2012 опять решили повернуться лицом к С++, т.е. отставание от C# лет на 10, да.
Visual Assist или Resharper в помощь.
Здравствуйте, Qbit86, Вы писали:
Q>Не только Boost, но и STL. В .NET, когда мне надо уточнить поведение стандартного класса, я вбиваю в поисковый запрос «coreclr SomeClass» или «corefx SomeClass». Обычно по первой ссылке — исходник класса на GitHub в майкрософтовском репозитории. Я читаю его прямо в браузере без всяких навигаций, и о чудо — понимаю! С заголовочными файлами Стандартной Библиотеки Шаблонов такое не прокатывает, там по крупицам надо выдирать смысл из мешанины type_trait'ов, typedef'ов и прочего итераторного шлака.
Так-то можно и на С++ писать в стиле C#, оно же "С с классами". Отчего же базовые библиотеки редко пишут в такой манере?
Хотя, если заглянуть в некоторые потроха Буста (в тот же asio), где идёт реализация под конкретные сетевые технологии, то там обычный такой ООП-код.
Q>Спасибо, такой фичи не надо. Нужна такая фича, чтобы варианты проверялись/энфорсились в момент чтения/написания обобщённого кода, а не когда-то потом при инстанцировании пользователем в непонятном месте.
Тогда это будет не совсем обобщённый код, а так, обманка, типа генериков. Т.е. прибитие гвоздями к конкретным интерфейсам.
Здравствуйте, vdimas, Вы писали:
V>Попробуй Resharper C++.
Может быть. Дождусь RTM'а Visual Studio 2017, потом апдейта РеШарпера. Посмотрю, что там с ценами и вариантами поставок. Мне-то в принципе C++ редко нужен, но если будет не особо дорого в комплекте с ReSharper C#, то почему не купить.
Здравствуйте, vdimas, Вы писали:
Q>>Спасибо, такой фичи не надо. Нужна такая фича, чтобы варианты проверялись/энфорсились в момент чтения/написания обобщённого кода, а не когда-то потом при инстанцировании пользователем в непонятном месте.
V>Тогда это будет не совсем обобщённый код, а так, обманка, типа генериков. Т.е. прибитие гвоздями к конкретным интерфейсам.
Констрейнты и описания параметров «шаблонов» — это абсолютно нормальная практика во всех современных ЯП: Rust, Scala, Ceylon, Haxe, etc. Это как типы в строго и статически типизированном языке: ты же не говоришь, что типы ослабляют настоящую мощь void* или динамической типизации? Параметрический полиморфизм — обширная область в computer science и в частности теории типов, по ней пишут много книжек и пейперов. А ты говоришь «обманка типа генериков».
Здравствуйте, Qbit86, Вы писали:
D>>А ещё есть notepad, который даже скачивать не надо!!! D>>(VS Code — это же просто редактор же) Q>Это не просто редактор. Это платформа для экстеншнов,
Расширяемый редактор.
Q>с помощью которых он неплохо интегрируется с... да с чем угодно, под что написаны экстеншны.
Также как и в других расширяемых редакторах а-ля Emacs, Vim, Sublime, Atom и даже отчасти Notepad++.
От IDE отличается отсутствием первой буквы I, то есть Development Environment но недостаточно Integrated, хотя местами грань совсем размыта.
Re[11]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexGin, Вы писали:
AG>Да в любом случае — по скорости (точнее — производительности) на .NET мы не выйдем на тот уровень, что даёт C/C++;
Всяко бывает. Бывает и так что нормальный linq провайдер генерит запросы в разы более быстрые, чем рукопашный сиквел, вызываемый в коде на С++.
Или, как уже упоминалось, компилятор безобразно спроектированного С++, написанный на С++, самый медленный из всех когда либо существовавших компиляторов промышленных языков.
