Здравствуйте, Alexey.Os, Вы писали:
AO>P.S. AO> очень полезный форум; со вчерашнего дня уже собрано несколько десятков ключевых пунктов, по которым делается сравнение C++ и С# AO>
Странно, что вам здесь еще ни разу не посоветовали managed C++, он же C++/CLI. Он бесшовно соединяется с обычным С++. На С++, а то и на С имеет смысл писать разные части системы, для которых критически важно быстродействие. Наконец, у C# очень хороший интероп с C++ и простым С.
В том же Яндексе используют комбинации Java/C++, когда в одном процессе С++ держит преогромную кучу на 120 ГБ, и к ней обращается код на Java через C++ прослойку.
Re[4]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Katyr, Вы писали:
K>1) разве, генератор кода у C# называется компилятором?
C:\Program Files (x86)\Microsoft Visual Studio 14.0>csc
Microsoft (R) Visual C# Compiler version 1.3.1.60616
Copyright (C) Microsoft Corporation. All rights reserved.
K>2) разве, ПО на C# знает что текущая ОС — это Windows?
Аналогично плюсам: если надо узнать — узнает, если нет — нет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
V>>В дотнете плохо то, что мало готовых библиотек алгоритмов, в этом плане больше всего их на C/C++, то есть С++ покрывает весь диапазон. Я, к примеру, могу задействовать в С++ алгоритмы, которые мне в жизнь не написать, а для дотнета их просто нет.
AVK>Чего за алгоритмы?
По мне так не хватает:
STXXL (http://stxxl.sourceforge.net/ Standard Template Library for Extra Large Data Sets) алгоритмы работы с большими объемами данных (TB). Контейнеры, алгоритмы STXXL мало чем отличаются от стандартных stl-евских. Матричные вычисления на всё тех же Extra Large Data Sets. Весьма внушительный труд сообщества.
boost::graph не хватает, на C# есть graph переписанный boost::graph, но весьма ограниченный в возможностях
не хватает boost::geometry — геометрические алгоритмы
Не хватает, как здесь уже сказали, OpenCV и легковесных настроек для работы библиотеки с GPU
О матричной математике вообще умолчу, там 99% фортрана переписанного на C. Я с этим не работаю, но думаю, что на другие языки это добро никто переписывать не будет.
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, _Raz_, Вы писали:
_R_>Здравствуйте, Katyr, Вы писали:
K>>1) разве, генератор кода у C# называется компилятором?
_R_>
_R_>C:\Program Files (x86)\Microsoft Visual Studio 14.0>csc
_R_>Microsoft (R) Visual C# Compiler version 1.3.1.60616
_R_>Copyright (C) Microsoft Corporation. All rights reserved.
_R_>
он компилит в машинный код или байт-код, как в JVM?
Re[4]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, peterbes, Вы писали:
P>О матричной математике вообще умолчу, там 99% фортрана переписанного на C. Я с этим не работаю, но думаю, что на другие языки это добро никто переписывать не будет.
Ну и что мешает дёргать эти библиотеки через interop? Пиши какие угодно структуры, хоть побитово, да вызывай библиотечные функции из C#.
Re[4]: Visual C# vs C++. Надо сравнить перспективы.
С>Странно, что вам здесь еще ни разу не посоветовали managed C++, он же C++/CLI. Он бесшовно соединяется с обычным С++. На С++, а то и на С имеет смысл писать разные части системы, для которых критически важно быстродействие. Наконец, у C# очень хороший интероп с C++ и простым С.
Сейчас вектор развития MS это .Net Core. А в нем C++/CLI нет и вроде не будет.
и солнце б утром не вставало, когда бы не было меня
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Слава, Вы писали:
С>>Странно, что вам здесь еще ни разу не посоветовали managed C++, он же C++/CLI. Он бесшовно соединяется с обычным С++. На С++, а то и на С имеет смысл писать разные части системы, для которых критически важно быстродействие. Наконец, у C# очень хороший интероп с C++ и простым С.
S> Сейчас вектор развития MS это .Net Core. А в нем C++/CLI нет и вроде не будет.
Здравствуйте, Sinix, Вы писали:
S>>>удобную навигацию по коду EP>>Например? S>Почитай стартовое сообшение темы,
Я читал
S>флеймить тут — это совсем уж злостный оффтопик.
Мне действительно интересно что за удобная навигация такая — вполне онтопик, но можно и отдельную тему создать.
S>Не нравится часть про плюсы — не вопрос.
Отбрось эту часть, ответь хотя бы про удобную навигацию.
S>Распиши топикстартеру своё видение, я свой ответ подправлю, чтобы не провоцировать на холивар.
Здравствуйте, Alexey.Os, Вы писали:
AO>P.S. AO> очень полезный форум; со вчерашнего дня уже собрано несколько десятков ключевых пунктов, по которым делается сравнение C++ и С# AO>
Лучше один раз увидеть, чем сто раз услышать. Есть Qt 4, а есть Qt 5, другие не рассматриваем. Проще скачать 4.8.6 и посмотреть демо. Тогда и поймёте подходит оно вам или нет. Всё равно ведь хоть даже на Visual C++ с подводной лодки никуда не денетесь.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Почитай стартовое сообшение темы, флеймить тут — это совсем уж злостный оффтопик. НС> НС>А по другим причинам он сюда и не пишет. У него пунктик какой то по поводу дотнета и CodeJam,
Опять соврал.
НС>можно уже генератор ответов от EP написать.
Да можно вообще всю тему генерировать:
C#'ист: [мифы о C++, нет yield ...]
EP: [контрпримеры]
C#'ист: [легенды о C++ ...]
EP: [разоблачение]
НС: [враньё]
Re[7]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Мне действительно интересно что за удобная навигация такая — вполне онтопик, но можно и отдельную тему создать.
А. AndrewVK скрины прикладывал. В общем примерно то, что умеет clion/решарпер для плюсов, только без особых тормозов, ложных срабатываний и из коробки для всех разработчиков.
S>>Распиши топикстартеру своё видение, я свой ответ подправлю, чтобы не провоцировать на холивар. EP>Я уже расписал
Если собираетесь писать программу сложных математических вычислений или программирование на низком уровне, с работой с железом--то выбирайте C++.
Если собираетесь писать программу, больше расcчитанную на графический пользовательский интерфейс (GUI) или же для работы с базами данных или с Интернетом (например, обработка Интернет-запросов), то выбирайте C#. Или Java.
1613 г. = 2024 г.
Re[2]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, DreamMaker, Вы писали:
DM>но тем не менее попробую ответить. ключевое отличие C# от C++ в том, что C# лучше чем C++. особенно на этом форуме
Смотря что понимать под словом "лучше". Всё зависит от того, какую задачу решает программист.
Здравствуйте, Alexey.Os, Вы писали:
AO>Я пытаюсь собрать информацию, оценить ”минусы” и “плюсы” и сравнить перспективу.
Общий ответ — пишите на том, что лучше знаете. Если надо подробнее — надо конкретику.
От себя же добавлю что:
1. Лучше писать кроссплатформенно сразу, что бы потом не пришлось подпрыгивать. Вдруг через несколько лет очередной клиент захочет ваш софт под другую ось? Фишка в том, что ничего сложного в написании кроссплатформы нет, а вот переписывать потом кроссплатформенно может оказаться жопой.
2. Не стоит гнаться за новыми возможностями, не используйте нестабильные версии инструментов, держитесь только стабильных релизов даже если "вау, у новейшей версии чегототам есть то что нам позарез пригодиццо!"
3. Не стоит завязываться на строго определённую среду разработки. Дайте программистам свободу в этом отношении. Регламентируйте правила оформления кода, но не среду.
4. Если софт достаточно сложный, требует правильной установки, тонкой настройки после, требует развёртывания БД и тем более подразумевает наличие у клиента серверной части — распространяйте софт сразу в образах виртуальных машин, развёрнутым и готовым к использованию после небольшой донастройки, для чего можно даже нарисовать дополнительную run-once утилиту.
Matrix has you...
Re[2]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, uncommon, Вы писали:
U>Здравствуйте, Alexey.Os, Вы писали:
AO>>Какие еще ключевые отличия C++ от C# ?
U>В C++ два плюсика, а в C# — четыре.
Восемь! Четыре локальных и четыре enlarged!
Re[7]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, bazis1, Вы писали:
EP>>Консервативные сборщики мусора это всё разруливают, для этого не нужны никакие макросы и прочие "ManagedObject" (они нужны для точных библиотечных GC). EP>>Смотри например Boehm GC. B>
it must scan parts of storage (most notably the execution stack) where there are words of storage that MIGHT be an object address and make the CONSERVATIVE assumption that if it looks like a valid address, and there is an object that has that address, then the object should not be collected.
B>Не-не-не-не-не, Девид Блейн.
Я сразу сказал про консервативность.
B>Такой магии нам не надо. Получается, что если случайное 32-битное слово внутри какого-нибуть сжатого блока, хранящегося в памяти, вдруг совпало с адресом внутри другого блока, то второй блок никогда не удалится?
Да. Но есть механизмы для информирования GC что вот в этом большом массиве нет никаких указателей — это снижает вероятность такого события. В том числе такой интерфейс даже стандартизировали в C++11 — std::declare_no_pointers.
B>Я понимаю, почему этим никто не пользуется. Потому что worst case здесь — это вылетание с OutOfMemoryException, и кастомеру нафиг не впырилось слушать ваши оправдания о крутости сброщика мусора.
Такой worst case крайне маловероятен. Например у хэш-таблиц линейный худший случай, что приводит к вырождению многих алгоритмов в квадратичные — тем не менее хэш таблицы используются повсеместно, потому что такой исход маловероятен.
Основные проблемы консервативных GC от того что трудно перемещать объекты по памяти, так как неизвестно какие ссылки на эти объекты можно обновлять, а какие нет (потому что это на самом деле не ссылки, а какие-то данные).
EP>>Во-первых GC не спасает от утечек. Во-вторых утечка памяти это минорная проблема, особенно по сравнению с утечкой ресурсов (которую на C# получить проще). B>В C# просто немного другая парадигма: B>1. Там, где реально надо, чтобы оно освободилось, как только стало ненужным, используется IDisposable и using.
using это лишь полумера. Например при добавлении ресурса в один из классов, все классы напрямую или косвенно его использующие сами становятся ресурсами, транзитивно — и нужно по всей цепочке делать Dispose, и во всех местах использования ставить using — локальное изменение влечёт цепочку глобальных. В Nemerle ЕМНИП это как-то пытались улучшить через AutoDispose.
EP>>Здесь никакого ref-counting и прочего, все значения имеют простой life-time привязанный к scopes — как и >90% всех объектов в программе. B>Ага, вот только если я хочу заполнить массив из фонового потока, а потом результат отобразить в GUI, то в C# я добавлю Task.Create() и await и дальше это не моя проблема. А в C++ придется городить огород.
Await реализуется на тех же механизмах что и yield. Даже отсутствие await конкретно в этом примере погоды не делает — будет просто явный .then с одной лямбдой.
EP>>GUI обычно не является какой-то огромной частью кода C++, более того для формочко-ориентированной разработки я именно C# и советовал в соседнем сообщении. B>Часто бывают, что формочки переплетены с хитроумной логикой и выбор языка для логики автоматически определяет язык для формочек.
Бывает, несомненно. А бывает что эту хитроумную логику можно разрулить декларативно, с помощью соответствующего DSL.
А что часто, а что нет — ещё вопрос, ибо много типовых задач — отсюда и появляются Access'ы, LightSwitch'и и прочие 1С-ы.
