Здравствуйте, Alexey.Os, Вы писали:
AO>Здравствуйте, Evgeniy Skvortsov, Вы писали: ES>>C++ не завязан на платформу никак.
Да, если применяем Qt библиотеку.
AO>А на ОС завязан? Т.е. Windows как платформа? AO>Я в "Cи" плохо разбираюсь... ES>>Писать современные приложения с "чистой виндой" (WIN API) — это Адъ и Израиль!
Львиная доля клиентов — именно под Windows.
Самый эффективный подход — применение в некоторых случаях WIN API.
Не везде и всюду, не для разработки GUI, но, к примеру, для более гибкого управления потоками.
AO>Но, где Адъ приятнее, в .NET или Win ?
.NET он более как-бы user-friendly.
Но работа в C++ и WIN API — позволяет использовать все ресурсы оборудования.
AO>ПО будет разного типа (и десктопное, и клиентское, и презентационное, и например модель обсчитать)... AO>Т.е. если есть зависимость от типа ПО, то хотелось бы этот вопрос понять.
Для разных целей — разные инструменты:
презентационное — скорее всего .NET и C#
модель обсчитать — где надо большую производительность — надо на C++
остальное — смотрите сами.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, AlexGin, Вы писали:
AG>>Компилит в исполняемый байт-код, который выглядит как файлы (*.exe и *.dll). AG>>Его исполняет .NET Core Run-Time.
Q>Всё-таки не исполняет, а компилирует CIL в машинный код, исполняемый процессором.
да, это точнее — согласен
Re[8]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, velkin, Вы писали: V>>Если это 3D графика QL>Ну вот берете Unity, и пишете на C#
Работали мы — занимались разработкой игровых систем (примерно год назад) —
тогда для НЕ быстрых игровых решений применялось именно Unity и C# — это например: подготовка выбранного героя к бою.
Само же приложение, в котором выполняются действия этого самого боя, разработано на C++ (так как Unity и C# на обеспечивают требуемой производительности).
Разработка на Unity и C# — проще, менее трудозатратно — однако, НЕ даст той динамики игры, как приложение на C++!
Здравствуйте, Alexey.Os, Вы писали:
AO>Здравствуйте, Слава, Вы писали:
С>>Давайте вы немного расскажете о себе и о проекте, чтобы можно было понять, на каком уровне вам следует объяснять. А то всё, что вы пока что написали, напоминает какую-то странную шутку.
AO>Девелоперская команда(в мск) увеличится до 30 чел.(дочка крупной немецкой компании).
Какого класса (без подробностей) будут проекты? AO>Владельцы дали добро(бюджет) на новый проект в следующем году. Плотные обсуждения начнутся уже в середине января.
Из этого пока ничего не очевидно... AO>Я системный аналитик(буду претендовать на роль архитектора). Мне нужно подготовить рекомендации по выбору средств разработки (не только я над этим работаю)
OK! AO>Основная ориентировка продукты — MS. Язык C.
Эти задачи всё-таки:
1) Документооборот?
2) Обработка звуков/изображений?
3) Управление техническими устройствами?
4) Что-либо другое...
Здравствуйте, Alexey.Os, Вы писали:
AO>Всем привет.
AO>В рамках будущего проекта будем создавать ПО под Windows. AO>Решаем, какой инструмент разработки выбрать Visual C++ или Visual C# AO>Какие еще ключевые отличия C++ от C# ?
Если у софта будет меньше 500 пользователей, то C#.
Ключевое отличие — на C++ кодирование обойдется в 5-10 раз дороже. Для мелкосерийного софта возможный выигрыш в производительности С++ не оправдает себя.
Re[7]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, velkin, Вы писали:
V>>Тот же OpenCV
AVK>
AVK>Wrappers in other languages such as C#, Perl, Ch, Haskell and Ruby have been developed to encourage adoption by a wider audience.
В курсе, что OpenCV имеет врапперы.
Только вот все эти врапперы — сжирают производительность!!!
Когда тебе надо обрабатывать картинку или видео, ты будешь просто преобразовывать одни типы данных в другие!
Здравствуйте, AlexGin, Вы писали:
AG>Разработка на Unity и C# — проще, менее трудозатратно — однако, НЕ даст той динамики игры, как приложение на C++!
Не в последнюю очередь, как ни парадоксально, это из-за того, что ядро-то движка Unity написано как раз на C++! Типа, тяжёлые вычисления вынесем в натив, и всё будет ок? А вот **й, накладные расходы на маршаллинг из управляемого кода в неуправляемый в методах Update() тысяч объектов каждый кадр убивают весь профит. Иногда игровой цикл выносят наоборот в управляемый код (маршалит в неуправляемое ядро только один game object, обновляющий все остальные), что в некоторых случаях даёт буст перформанса. Другой, непопулярный кроссплатформенный движок Xenko изначально написан на управляемом языке. Когда я в последний раз сравнивал с Unity на Андроиде, производительность Xenko была выше (я измерял только скрипты, про отрисовку не скажу).
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Alexey.Os, Вы писали:
AO>Здравствуйте, Evgeniy Skvortsov, Вы писали:
AO>>>а как сравнить с теми же(формочками, БД,..) под чистыми Win32 для C++ ? ES>>У С++ ничего этого нет. Всё делается сторонними библиотеками.
AO>Т.е. майкрософт не может предложить собственный фреймворк для Win32 и к Visual C++ придется брать сторонние библиотеки?
Есть вообще-то Microsoft Foundation Classes — MFC: https://ru.wikipedia.org/wiki/Microsoft_Foundation_Classes
средство довольно старое (даже пожалуй древнее), но поддерживаемое и по сей день.
Даже есть MFC Feature Pack (современные контролы и dockabled окошки): https://msdn.microsoft.com/ru-ru/library/bb982354(v=vs.90).aspx https://msdn.microsoft.com/ru-ru/library/bb983962(v=vs.90).aspx
P.S. Я совсем не предлагаю вышеописанное — в качестве критерия выбора для новых проектов (для новых проектов Qt ИМХО предпочтительнее) —
просто указал, что данное направление есть, живёт и даже как-то развивается
Здравствуйте, Alexey.Os, Вы писали:
AO>Всем привет.
AO>В рамках будущего проекта будем создавать ПО под Windows. AO>Решаем, какой инструмент разработки выбрать Visual C++ или Visual C#
AO>Я пытаюсь собрать информацию, оценить ”минусы” и “плюсы” и сравнить перспективу.
Delphi7 без вариантов
Проста как валенок, компонентов как грязи, ole-встраивается за секунды, ресурсов не жрёт, все грабли изучены,
на современном железе летает, требует памяти меньше чем виндовый блокнот, вся справка в комплекте,
результат работает на любой винде хоть на winnt4, не требует microsoft.net
из минусов — перспектив нет
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, AlexGin, Вы писали:
AG>>Разработка на Unity и C# — проще, менее трудозатратно — однако, НЕ даст той динамики игры, как приложение на C++!
Q>Не в последнюю очередь, как ни парадоксально, это из-за того, что ядро-то движка Unity написано как раз на C++! Q>Типа, тяжёлые вычисления вынесем в натив, и всё будет ок? А вот **й, накладные расходы на маршаллинг из управляемого кода в неуправляемый в методах Update() тысяч объектов каждый кадр убивают весь профит.
Для Unity и C# вероятно — причина снижения производительности именно в мостике управляемый<->НЕуправляемый, наличие GC и т.д.
Но в том-то и дело, что для приложений такого рода, написанных на Unity, оптимизация по скорости — задача на мой взгляд НЕ главная.
Там будут прежде всего рассчёты по определённым алгоритмам и формулам, а вот скорость — некритична.
По крайней мере, в нашем проекте было именно так.
Q>Иногда игровой цикл выносят наоборот в управляемый код (маршалит в неуправляемое ядро только один game object, обновляющий все остальные), что в некоторых случаях даёт буст перформанса.
То есть — причина высокого перфоманса — всё-таки "неуправляемое ядро" на старом добром C++
В том проете, в котором мы работали, на НЕуправляемом коде фактически была вся игра.
Только некоторый "предбанничек" был на Unity и C#.
Q>Другой, непопулярный кроссплатформенный движок Xenko изначально написан на управляемом языке. Когда я в последний раз сравнивал с Unity на Андроиде, производительность Xenko была выше (я измерял только скрипты, про отрисовку не скажу).
Не знаю, с Xenko не работал.
Здравствуйте, AlexGin, Вы писали:
AG>В том-то и дело, что для приложений такого рода, написанных на Unity, оптимизация по скорости — задача НЕ главная.
Ну хз, у нас кроссплатформенный нехитрый 3D-шутер на мобилках.
AG>То есть — причина высокого перфоманса — всё-таки "неуправляемое ядро" на старом добром C++
Перформанс не то чтобы высокий, но был бы выше, если часть логики движка вынести из нативного кода в managed.
AG>Не знаю, с Xenko не работал.
Никто не работал, к моему глубокому сожалению. Вокруг хайп вокруг *раного Unity.
Глаза у меня добрые, но рубашка — смирительная!
Re[9]: Visual C# vs C++. Надо сравнить перспективы.
AG>Я в курсе, что это есть, но этим пользуются редко — как правило просто ставят дот-нет нужной версии и всё.
Ну это пока. Так c популярностью UWP будут компилировать. Плюсы это обфускация и скорость. Другое дело, что сейчас магазином мало пользуются.
Посмотрим.
и солнце б утром не вставало, когда бы не было меня
Re[8]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
AVK>>А ты ожидал какой то необычной? EP>Нет, я говорю что навигация и автоматический рефакторинг это разные вещи, точно также как разными вещами являются утечки памяти и висячие указатели.
Т.е. решил перевести на спор о теминах, понятно.
AVK>>>>жизненно важным становится работающий полностью корректно Go to usages. EP>>>Если например будут false positives — это не критично. AVK>>С точи зрения эффективности — весьма критично. EP>В большинстве случаев, даже на древних версиях студии, их не будет
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Evgeny.Panasyuk, Вы писали:
НС>>Это все что ты смог найти? Мощно. EP>Нет, но этого более чем достаточно.
Для чего, для того чтобы убедить себя что ты иногда статистика дает сбой? Ну да, 3 топика за несколько лет это серьезно.
НС>>Ну ок, был неправ, не всегда, а почти всегда. EP>Ещё вдруг окажется что и C# не "гавно", и C++ с Python'ом не лучше всех, и не в лотерею, а в карты, и не выиграл, а проиграл.
Ну вот как окажется, так и поговорим. А пока у тебя очередной ... теперь на тему навигации в студии.
Re[9]: Visual C# vs C++. Надо сравнить перспективы.
AG>Я в курсе, что это есть, но этим пользуются редко — как правило просто ставят дот-нет нужной версии и всё.
При этом рассуждаете о скорости. Net Native как раз и компилируется в чистый натив, только со сборкой мусора.
Значит скорость не нужна.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Qbit86, Вы писали:
H>>>К интерфейсу можно даже не ходить, а сразу выбрать Go To Implementation и вижак выдаст список реализаций EP>>
Q>>>Или вместо простого перехода выдаёт список каких-то методов-кандидатов, их перегрузок, специализаций, или что у них там.
Q>Мне кажется, ты реально не способен удержать нить разговора, или просто тупо троллишь.
Перечитай подветку, ты запутался.
Ты изначально возмутился тем что как так, почему выдаётся список перегрузок/специализаций. Я объяснил что это фича такая — ибо там реально список вариантов. Ты в ответ сказал что такая фича не нужна. Я в ответ тебе привёл аналогичную ситуацию но с обычными виртуальными функциями, где тоже есть список. hardcase ровно это же и подтвердил — "вижак выдаст список реализаций", но правда непонятно зачем, ибо ты и так в параллельной подветке согласился что да есть ситуации где нужен список.
Далее ты уже пытался перескочить с темы именно списка как такового, на наличие в списке false-positives.
Разобрался?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Сложность языка ведёт к false-positives, но для навигации это не критично, критично для рефакторинга.
Кто бы сомневался. Если плюсы лажают, то это некритично.
No way to locate definitions
OK, so before we can parse AA BB(CC);, we need to find out whether CC is defined as an object or a type. So let's locate the definition of CC and move on, right?
This would work in most modern languages, in which CC is either defined in the same module (so we've already compiled it), or it is imported from another module (so either we've already compiled it, too, or this must be the first time we bump into that module — so let's compile it now, once, but of course not the next time we'll need it). So to compile a program, we need to compile each module, once, no matter how many times each module is used.
In C++, things are different — there are no modules. There are files, each of which can contain many different definitions or just small parts of definitions, and there's no way to tell in which files CC is defined, or which files must be parsed in order to "understand" its definition. So who is responsible to arrange all those files into a sensible string of C++ code? You, of course! In each compiled file, you #include a bunch of header files (which themselves include other files); the #include directive basically issues a copy-and-paste operation to the C preprocessor, inherited by C++ without changes. The compiler then parses the result of all those copy-and-paste operations. So to compile a program, we need to compile each file the number of times it is used in other files.
This causes two problems. First, it multiplies the long time it takes to compile C++ code by the number of times it's used in a program. Second, the only way to figure out what should be recompiled after a change to the code is to check which of the #include files have been changed since the last build. The set of files to rebuild generated by this inspection is usually a superset of the files that really must be recompiled according to the C++ rules of dependencies between definitions. That's because most files #include definitions they don't really need, since people can't spend all their time removing redundant inclusions.
Some compilers support "precompiled headers" — saving the result of the parsing of "popular" header files to some binary file and quickly loading it instead of recompiling from scratch. However, this only works well with definitions that almost never change, typically third-party libraries.
And now that you've waited all that time until your code base recompiles, it's time to run and test the program, which is when the next problem kicks in.
