Здравствуйте, Alexey.Os, Вы писали:
AO>Всем привет.
AO>В рамках будущего проекта будем создавать ПО под Windows. AO>Решаем, какой инструмент разработки выбрать Visual C++ или Visual C#
AO>Я пытаюсь собрать информацию, оценить ”минусы” и “плюсы” и сравнить перспективу.
AO>Например, C# требует .NET. Что здесь хорошего, а что плохого?
AO>Какие еще ключевые отличия C++ от C# ?
Если отталкиваться от требований бизнеса, то параметры примерно следующие:
1. Стоимость написания приложения приемлемого качества.
2. Стоимость поддержки.
3. Стоимость внесения изменений.
При прочих равных на C# в разы дешевле по затратам. Вопросы максимальной эффективности кода и прочего предлагаю все же вынести за скобки как малозначительные.
Re[11]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>а не например на висячие указатели которые во-первых имеют на порядки более серьёзные последствия, а во-вторых GC именно эту проблему успешно решает.
т.е замазать проблему с освобождением ресурсов утечкой памяти это теперь называется успешное решение? ну-ну
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[14]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
TK>>Зачем на себя то все переводить?
AVK>Что значит переводить? Он постоянно и совершенно неабстрактно переходит к обсуждению моей личности. Ты, конечно, можешь считать что это нормально, но я в этом фестивале демагогии участвовать не хочу.
Расскажи в чем хамство то? Вот про кругозор например — у меня системный софт что по виндой, что под линуксом написан на плюсах (и на чем-то еще но, не на .net) и каких-то утечек я в нем не вижу. А вот студия и resharper с managed кодом регулярно могут сожрать всю память... и тут как не крути — если оно через какое-то время сжирает всю память и падает / тормозит то это обычно и называют утечкой.
И вообще, обычно под что разрабатываешь то скорее и течет (если конечно исключить ситуацию с манией величия)
реально каких-то больших проблем с утечками именно в с++ нет. так же как и особых проблем паузами и использованием в realtime системах
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[15]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, TK, Вы писали:
TK>Расскажи в чем хамство то?
Я уже отвечал на этот вопрос.
TK> А вот студия и resharper с managed кодом регулярно могут сожрать всю память...
В пререлизном решарпере гарды стоят, утечки до релиза должны вылавливаться. А в студии и плюсового кода более чем, так что кто и по чьей вине там течет — большой вопрос.
TK>реально каких-то больших проблем с утечками именно в с++ нет.
Да понятно что нет, иначе бы оно давно ушло на помойку. Но усилий приходится больше, даже если ты за много лет к ним уже и привык. У меня вот тоже проблем с утечками ресурсов в дотнете не было никогда, однако ж я не утверждаю что с этим все идеально.
И остается еще переполнение буфера, постоянно проскакивающее в security bulletins в том числе и в плюсовом софте.
Здравствуйте, Doc, Вы писали:
V>>А у дотнета нет отдалённой перспективы, то есть на десятки лет как у С++, но пока майкрософт его не убил и ладно. Doc>А не подскажете праздник "виндекапец" какой в этом году юбилей отмечает? :D
Сейчас нулевой. Дальше, ждем как linux subsystem выйдет из беты и будет официально добавлена в серверные редакции.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[8]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
EP>>ReSharper / VisualAssist есть и для C++ AVK>Я в курсе. Только это несколько иной уровень — функционала поменьше, точность меньше (много эвристик и догадок), легко анализ сломать.
Возможно, даже скорей всего, я думал имелись в виду какие-то уникальные киллер-фичи.
EP>>А вот всякие инсинуации вида "ОТДЕЛЬНЫЕ программисты C++ используют консоль+блокнотик, зато ТИПОВОЙ разработчик C# ОГОГО" это действительно непонятно к чему AVK>Это, видимо, к тому, что использование VS в случае шарпа абсолютная норма, а вот с С++ далеко не все так однозначно. Потому что и динозавров, боящихся всего нового там по понятным причинам больше, и язык разработчикам тулов позволяет сильно меньше.
Видимо, но формулировка там странная (причём вместо C++ и C# там можно подставить X и Y), поэтому я спросил.
AVK>Не стоит это воспринимать как наезд и бросаться в бой.
Я не воспринял это как наезд. Я не понял вот этого:
AVK>P.S. а вообще правильно тебе советуют — с флеймом лучше в КСВ, не надо топик засорять
почему ты именно мне это говоришь, типа я топик засоряю, а потом тебе ещё мерещится что я где-то тебе хамлю и на личности постоянно перехожу
А на счёт флейма — так тема одна из самых флеймовых — конечно наверное уютней и без-флеймовей было бы без оппонентов
Re[10]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, TK, Вы писали:
EP>>а не например на висячие указатели которые во-первых имеют на порядки более серьёзные последствия, а во-вторых GC именно эту проблему успешно решает. TK>т.е замазать проблему с освобождением ресурсов утечкой памяти это теперь называется успешное решение? ну-ну
Решение именно проблемы висячих указателей. Другие проблемы — да, не решает, и даже привносит новые. Но конкретно этой проблемы нет.
Конечно это не идеальный вариант, а компромисс, тем не менее для многих задач оправданный.
Re[9]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Возможно, даже скорей всего, я думал имелись в виду какие-то уникальные киллер-фичи.
А оно и есть киллер-фича кумулятивно, потому что я могу запустить автоматический рефакторинг на огромном проекте, и с высокой вероятность оно сделает все идеально. В плюсах же глобальный рефакторинг — штука весьма вероятностная, то ли пройдет, то ли ручками потом дочинивай из-за того что оно на макрос где нибудь наткнулось или особо хитрый шаблонный выверт.
EP>А на счёт флейма — так тема одна из самых флеймовых — конечно наверное уютней и без-флеймовей было бы без оппонентов
С вопросами уютности не ко мне. Для флеймов у нас есть КСВ, поэтому если тебе не надоело постоянно ездить по одному и тому же — у тебя есть все возможности там продолжить.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>а не например на висячие указатели которые во-первых имеют на порядки более серьёзные последствия, а во-вторых GC именно эту проблему успешно решает. EP>Решение именно проблемы висячих указателей.
В Си это, конечно, фейл. Но висячие указатели можно и без сборщика мусора решать, системой типов пытаться обойтись. Как в Rust, например.
Глаза у меня добрые, но рубашка — смирительная!
Re[10]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
EP>>Возможно, даже скорей всего, я думал имелись в виду какие-то уникальные киллер-фичи. AVK>А оно и есть киллер-фича кумулятивно, потому что я могу запустить автоматический рефакторинг на огромном проекте, и с высокой вероятность оно сделает все идеально. В плюсах же глобальный рефакторинг — штука весьма вероятностная, то ли пройдет, то ли ручками потом дочинивай из-за того что оно на макрос где нибудь наткнулось или особо хитрый шаблонный выверт.
Речь в этой ветке шла про навигацию, и вопрос мой был про киллерф-фичи навигации.
Про рефакторинг я полностью согласен (и даже думал написать о нём в предыдущем сообщении). Это как раз в копилку примеров "не о том" — когда в контексте сложности языка говорят про навигацию, с которой особых проблем нет (даже в не-IDE), вместо реальных проблем с рефакторингом.
Рефакторинг-то есть, и даже есть глобальный программируемый рефакторинг на базе AST Matchers из Clang, но в целом много нюансов, и за исключением простых случаев нужно перепроверять вручную — тут VCS и тесты в помощь.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>когда в контексте сложности языка говорят про навигацию, с которой особых проблем нет (даже в не-IDE), вместо реальных проблем с рефакторингом.
Как это «особых проблем нет»? Вот прямо сейчас я читаю исходники Boost 1.62 (а C++ не создан для чтения не-автором, это write-only-язык). F12 для Go To Definition работает криво и через раз. Й пойми, почему. Например, потому что вызывается метод аргумента типа параметра шаблона, а концепты до сих пор не завезли. Или вместо простого перехода выдаёт список каких-то методов-кандидатов, их перегрузок, специализаций, или что у них там.
Навигация в одной и той же Студии 2017 RC для C# и C++ — экспириенс совершенно различный, доложу я вам.
Здравствуйте, Qbit86, Вы писали:
EP>>>>а не например на висячие указатели которые во-первых имеют на порядки более серьёзные последствия, а во-вторых GC именно эту проблему успешно решает. EP>>Решение именно проблемы висячих указателей. Q>В Си это, конечно, фейл. Но висячие указатели можно и без сборщика мусора решать,
Безусловно.
Q>системой типов пытаться обойтись. Как в Rust, например.
Саттер на одной из презентаций где-то год назад рассказывал о чём-то подобном для C++ — специальные аннотирующие типы, определение safe-subset, выдача ошибок при выходе из этого subset, возможность подавить эти ошибки аннотацией (а-ля unsafe). Плюс показывалась демка реализации этого (proof-of-concept?) на базе MSVS. Не знаю в каком это сейчас состоянии.
Здравствуйте, Qbit86, Вы писали:
EP>>когда в контексте сложности языка говорят про навигацию, с которой особых проблем нет (даже в не-IDE), вместо реальных проблем с рефакторингом. Q>Как это «особых проблем нет»?
Сложность языка ведёт к false-positives, но для навигации это не критично, критично для рефакторинга.
Q>Вот прямо сейчас я читаю исходники Boost 1.62 (а C++ не создан для чтения не-автором, это write-only-язык).
В Boost много write-only кода потому что во многих местах поддерживаются старые стандарты. Например эмуляция variadic templates макросами.
Помимо этого там много сложного кода самого по себе.
Q>F12 для Go To Definition работает криво и через раз. Й пойми, почему. Например, потому что вызывается метод аргумента типа параметра шаблона, а концепты до сих пор не завезли. Q>Или вместо простого перехода выдаёт список каких-то методов-кандидатов, их перегрузок, специализаций, или что у них там.
Так это не баг, а фича — у тебя в том месте скорей всего возможны разные варианты, поэтому и список.
И конечно же Boost это самый экстремальный случай. Например по проектам над которыми работал не испытывал никаких проблем с навигацией даже на древних VS.
Re[11]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Речь в этой ветке шла про навигацию, и вопрос мой был про киллерф-фичи навигации.
Это связано. Потому что когда ты делаешь рефакторинг вручную жизненно важным становится работающий полностью корректно Go to usages. Когда в коде разбираешься — переходы в один шаг на определение вызываемого метода, даже если метод в бинарнике. Сложно это объяснить в двух словах, но код в итоге воспринимается совсем иначе.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>И конечно же Boost это самый экстремальный случай. Например по проектам над которыми работал не испытывал никаких проблем с навигацией даже на древних VS. EP>Помимо этого там много сложного кода самого по себе.
Не только Boost, но и STL. В .NET, когда мне надо уточнить поведение стандартного класса, я вбиваю в поисковый запрос «coreclr SomeClass» или «corefx SomeClass». Обычно по первой ссылке — исходник класса на GitHub в майкрософтовском репозитории. Я читаю его прямо в браузере без всяких навигаций, и о чудо — понимаю! С заголовочными файлами Стандартной Библиотеки Шаблонов такое не прокатывает, там по крупицам надо выдирать смысл из мешанины type_trait'ов, typedef'ов и прочего итераторного шлака.
EP>Так это не баг, а фича — у тебя в том месте скорей всего возможны разные варианты, поэтому и список.
Спасибо, такой фичи не надо. Нужна такая фича, чтобы варианты проверялись/энфорсились в момент чтения/написания обобщённого кода, а не когда-то потом при инстанцировании пользователем в непонятном месте.
Глаза у меня добрые, но рубашка — смирительная!
Re[12]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
EP>>Речь в этой ветке шла про навигацию, и вопрос мой был про киллерф-фичи навигации. AVK>Это связано. Потому что когда ты делаешь рефакторинг вручную жизненно важным становится работающий полностью корректно Go to usages.
"Рефакторинг вручную" это по сути обычная разработка.
AVK>Когда в коде разбираешься — переходы в один шаг на определение вызываемого метода
"Разбираешься в коде" это тоже обычная разработка, не так часто приходится писать ни в чём не разбираясь.
Да, для обычной разработки нужна навигация, кто ж спорит-то.
AVK>жизненно важным становится работающий полностью корректно Go to usages.
Если например будут false positives — это не критично. Рефакторить какой-нибудь замудрённый мета-шаблонно-макросный код (на котором ломаются анализаторы) требуется очень редко.
В крайнем случае "Go to usages" легко эмулируется с помощью компилятора — принудительно добавляешь статическую ошибку (или например static_assert) в используемый код, и компилятор сам выдаёт весь список usages. Более того, есть такой трюк — записываешь макрос который по этому списку ошибок автоматом делает необходимые правки. Плохо что из самой студии макросы выпилили.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В крайнем случае "Go to usages" легко эмулируется с помощью компилятора — принудительно добавляешь статическую ошибку (или например static_assert) в используемый код, и компилятор сам выдаёт весь список usages. Более того, есть такой трюк — записываешь макрос который по этому списку ошибок автоматом делает необходимые правки.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
Q>>Или вместо простого перехода выдаёт список каких-то методов-кандидатов, их перегрузок, специализаций, или что у них там. EP>Так это не баг, а фича — у тебя в том месте скорей всего возможны разные варианты, поэтому и список.
Вот, опять. Жму F12 по вызову функции, применяемой к четырём аргументам. В .NET, даже если у меня несколько перегрузок по типам/количеству аргументов, компилятор C# в этой точке знает, какая вызывается. Компилятор же C++ выдаёт мне список из 8 вариантов, среди которых функции от трёх аргументов.
Это сложно воспринимать как фичу, но мы справимся!
