Re[34]: Visual C# vs C++. Надо сравнить перспективы. - Компьютерные священные войны

Здравствуйте, Klikujiskaaan, Вы писали:

K>Здравствуйте, lpd, Вы писали:

lpd>>Ничего не мешает, по уму, создать фреймворк и инфраструктуру на C++, не уступающие C#/Java, и забыть про эти управляемые языки. Но да, учитывая наличие программистов, уже знающих C# и Java, в данный момент реально имеет определенный смысл их использовать для ряда распространенных типов проектов — это я не отрицаю.

K>За 30 лет не создали.

Видимо, дело в том, что все крупные корпорации вложились в Java и C#.

Здравствуйте, lpd, Вы писали:

lpd>Видимо, дело в том, что все крупные корпорации вложились в Java и C#.

Что-то тут не вяжется, ведь "по уму, создать фреймворк и инфраструктуру на C++, не уступающие C#/Java, и забыть про эти управляемые языки".

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, lpd, Вы писали:

lpd>>В результате язык как снежный ком обрастает новыми ключевыми словами и классами, все исключительно ради того, чтобы всегда использовать stl и ни при каких условиях не использовать прямое управление памятью(move-семантика, auto, shared_ptr). В то время как stl, вообще то, изначально задумывался как упрощение программирования, а не замена знания алгоритмов на знание C++17. C++11-17 — это попытка сделать из C++ то, чем он стать не может.

_>Вообще то move-семантика — это как раз реальная киллер-фича, которая принципиально увеличивает эффективность кода. Причём каких-то даже близких аналогов этой фичи нет ни в одном из мейнстрим языков.

move-семантика это интересное нововведенин, но по сути, нужна только чтобы никогда не использовать прямое управление памятью, а всегда использовать stl-классы. Однако, в тех приложениях, где время копирования реально играет роль, все равно обычно используется прямое управление памятью. При этом все эти разные типы ссылок заметно усложняют язык.

Здравствуйте, AlexRK, Вы писали:

ARK>Не являюсь "фанатом" какого-либо языка, но вот этот момент мне не очень понятен. Какой смысл писать что угодно на С++, если это может быть написано на C#? По-моему, абсолютно никакого.

Не что угодно, а десктопное приложение под винду. У автора изначального вопроса речь шла именно об этом.

ARK>А раз так, то на С++ как раз и следует писать только "реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС" (c), плюс кроссплатформенный и независимый по каким-то причинам от .NET софт.

Нет, описанное — это всего лишь относительно узкая область, в которой решением может служить только C/C++ (ну там ещё местами может справляться Ассемблер и Фортран, но это уже тема другого разговора). А большую часть ПО возможно создавать как на C++, так и на C#. И соответственно тут уже возникает вопрос выбора с точки зрения бизнес эффективности. Которая очень разная скажем для IT компаний и для не IT. Поэтому известные "коробочные" продукты на C# являются редкостью, так же как и написание какого-нибудь внутрикорпоративного энтерпрайза на C++.

Здравствуйте, alex_public, Вы писали:

ARK>>Не являюсь "фанатом" какого-либо языка, но вот этот момент мне не очень понятен. Какой смысл писать что угодно на С++, если это может быть написано на C#? По-моему, абсолютно никакого.
_>Не что угодно, а десктопное приложение под винду. У автора изначального вопроса речь шла именно об этом.

Под "что угодно" я имел в виду "произвольное приложение". Перефразирую: если какое-либо приложение может быть написано на C#, то рассматривать С++ нет никакого смысла.

ARK>>А раз так, то на С++ как раз и следует писать только "реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС" (c), плюс кроссплатформенный и независимый по каким-то причинам от .NET софт.

_>Нет, описанное — это всего лишь относительно узкая область, в которой решением может служить только C/C++ (ну там ещё местами может справляться Ассемблер и Фортран, но это уже тема другого разговора).

Ну так я именно это и написал.

_>А большую часть ПО возможно создавать как на C++, так и на C#. И соответственно тут уже возникает вопрос выбора с точки зрения бизнес эффективности.

Вот этот самый выбор, как мне кажется, не имеет смысла. Если именно С++ не требуется, то просто берется C#.

Здравствуйте, itslave, Вы писали:

lpd>>По тестам(в том числе по моим) код на C#/Java в 2-4 раза медленнее, чем на C++. Я, конечно, понимаю, что основные задержки могут быть в базе данных. Однако, если на сервере производится значительная обработка данных, прийдется устанавливать и админить в 2-4 раза больше серверов — что, очевидно, неудобно.
I>Это если абстрактных коней в вакууме сравнивать. На практике же, перформанс типичного веб сервера упирается в перформанс базы данных: банальные индексы, оптимизация запросов и кеширование решают проблемы чуть более чем всегда. Ах да, затем упремся в производительность веб сервера(порядка 5-20 тыщ реквестов в секунду в зависимости от юз кейсов и конфигурации, для всех веб серверов отдающих динамический контент)
I>Ну а потом уж возможно упремся в проблемы .NET как управляемой среды.

Вообще то все топовые веб-сервера (nginx, Apache, IIS и т.п.) и все топовые РСУБД (PostgreSQL, MySQl, SQL Server, Oracle и т.п.) написаны на C/C++. Так что не очень понятно о чём собственно речь. )))

lpd>>У C#, вообще, два преимущества перед C++:
I>Ты ничего не понимаешь. Главное преимущество C# и Java — это возможность выдать результат в короткие сроки за небольшие деньги, силами низкоквалифицированной команды. И это будет работать и приносить прибыль бизнесу без привлечений дорогостоящих гуру, шаманства и так далее.

+1.

Здравствуйте, alex_public, Вы писали:

_>Вообще то все топовые веб-сервера (nginx, Apache, IIS и т.п.) и все топовые РСУБД (PostgreSQL, MySQl, SQL Server, Oracle и т.п.) написаны на C/C++. Так что не очень понятно о чём собственно речь. )))

Э, нет. Никакого С++ в топовых серверах и СУБД. Только С. А это СОВСЕМ другая история.

UPD. Если в контексте производительности, то разницы нет.

Здравствуйте, Klikujiskaaan, Вы писали:

lpd>>Ничего не мешает, по уму, создать фреймворк и инфраструктуру на C++, не уступающие C#/Java, и забыть про эти управляемые языки. Но да, учитывая наличие программистов, уже знающих C# и Java, в данный момент реально имеет определенный смысл их использовать для ряда распространенных типов проектов — это я не отрицаю.
K>За 30 лет не создали.

Вообще то создали и активно используют. ))) См. Яндекс, Гугл и т.п. И надеюсь не надо объяснять почему они ими не делятся? )))

Здравствуйте, lpd, Вы писали:

_>>Вообще то move-семантика — это как раз реальная киллер-фича, которая принципиально увеличивает эффективность кода. Причём каких-то даже близких аналогов этой фичи нет ни в одном из мейнстрим языков.
lpd>move-семантика это интересное нововведенин, но по сути, нужна только чтобы никогда не использовать прямое управление памятью, а всегда использовать stl-классы. Однако, в тех приложениях, где время копирования реально играет роль, все равно обычно используется прямое управление памятью. При этом все эти разные типы ссылок заметно усложняют язык.

Что ты называешь прямым управлением памятью? Например локальная переменная на стеке (самый правильный способ работы с данными в современном C++) — это прямое управление или нет? ) Или ты имеешь в виду вызовы new/delete? Если последнее, то как раз в правильном современном приложение на C++ их может не быть вообще. И при этом производительность будет не хуже ручного ассемблерного кода. )))

Здравствуйте, alex_public, Вы писали:

_>Вообще то создали и активно используют. ))) См. Яндекс, Гугл и т.п. И надеюсь не надо объяснять почему они ими не делятся? )))

Тебе нужно для начала пруфануть, что у них имеются эти фреймворки )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

Здравствуйте, AlexRK, Вы писали:

_>>А большую часть ПО возможно создавать как на C++, так и на C#. И соответственно тут уже возникает вопрос выбора с точки зрения бизнес эффективности.
ARK>Вот этот самый выбор, как мне кажется, не имеет смысла. Если именно С++ не требуется, то просто берется C#.

Ну вот возьми набор ПО на своём домашнем компьютере (хотя конечно комп разработчика далёк от среднего, но для простейшей прикидки пойдёт) и посчитай какой процент написан на C#. А получив эту цифру обдумай кто является не прав, ты со своей позицией или вся остальная IT индустрия. )))

Здравствуйте, AlexRK, Вы писали:

_>>Вообще то все топовые веб-сервера (nginx, Apache, IIS и т.п.) и все топовые РСУБД (PostgreSQL, MySQl, SQL Server, Oracle и т.п.) написаны на C/C++. Так что не очень понятно о чём собственно речь. )))
ARK>Э, нет. Никакого С++ в топовых серверах и СУБД. Только С. А это СОВСЕМ другая история.

IIS, MySQL, Oracle, SQL Server — это всё как раз C++. Но даже если бы и был только C, это всё равно никак не меняло бы аргумента, т.к. в любом случае не C#. )))

Здравствуйте, Klikujiskaaan, Вы писали:

_>>Вообще то создали и активно используют. ))) См. Яндекс, Гугл и т.п. И надеюсь не надо объяснять почему они ими не делятся? )))
K>Тебе нужно для начала пруфануть, что у них имеются эти фреймворки )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

Тебе нужны пруфы на то, что поисковые движки в Яндексе и Гугле написаны на C++? Это же давным давно общеизвестная информация. Ты совсем не интересуешься происходящем в индустрии? )

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, lpd, Вы писали:

_>>>Вообще то move-семантика — это как раз реальная киллер-фича, которая принципиально увеличивает эффективность кода. Причём каких-то даже близких аналогов этой фичи нет ни в одном из мейнстрим языков.
lpd>>move-семантика это интересное нововведенин, но по сути, нужна только чтобы никогда не использовать прямое управление памятью, а всегда использовать stl-классы. Однако, в тех приложениях, где время копирования реально играет роль, все равно обычно используется прямое управление памятью. При этом все эти разные типы ссылок заметно усложняют язык.

_>Что ты называешь прямым управлением памятью? Например локальная переменная на стеке (самый правильный способ работы с данными в современном C++) — это прямое управление или нет? ) Или ты имеешь в виду вызовы new/delete? Если последнее, то как раз в правильном современном приложение на C++ их может не быть вообще. И при этом производительность будет не хуже ручного ассемблерного кода. )))

Под прямым управлением памятью я имею ввиду new/delete и указатели, которые пытаются исключить. Но ценой этого оказывается усложнение языка разными типами ссылок и правилами их преобразования.
Например, отсутствие копирования было бы полезно при разработке видео-кодеков. Но ffmpeg написан вообще на C, и я не вижу в подобных приложениях применения последним стандартам С++.
Вот лямбды и потоки — да, полезны. Было бы лучше, если бы C++ развивался не в сторону теоретического улучшения языка, как краткой записи абстрактных операций над абстрактными данными, а в сторону расширения области применения и сближения по удобству всего процесса разработки с Java-фреймворками и инфраструктурой, без излишнего усложнения.

Здравствуйте, alex_public, Вы писали:

_>Тебе нужны пруфы на то, что поисковые движки в Яндексе и Гугле написаны на C++? Это же давным давно общеизвестная информация. Ты совсем не интересуешься происходящем в индустрии? )

Пруфы на "Ничего не мешает, по уму, создать фреймворк и инфраструктуру на C++, не уступающие C#/Java, и забыть про эти управляемые языки" неси. ))))))))))))))))))))))))))))))))))))))))

Здравствуйте, alex_public, Вы писали:

_>Ну вот возьми набор ПО на своём домашнем компьютере (хотя конечно комп разработчика далёк от среднего, но для простейшей прикидки пойдёт) и посчитай какой процент написан на C#. А получив эту цифру обдумай кто является не прав, ты со своей позицией или вся остальная IT индустрия. )))

Из того, что помню:

C++: Firefox, foobar2000, Media Player Classic, частично Skype, WinCDEmu, JPEGView, Audacity, 7zip, iTunes
C#: Paint.NET, KeePass, MonoDevelop
Delphi: Total Commander, частично Skype

С++ 65%, C# 20%

В принципе, для шарпа это еще много. Наверняка я что-то забыл. Но понятно, что standalone приложения на C# пишутся довольно редко, с этим никто не спорит. Но, ИМХО, в данном случае вполне уместно говорить, что требования к упомянутым мной приложениям исключают применение C#, т.к. в большинстве из них нужна приличная скорость.

Здравствуйте, lpd, Вы писали:

lpd>Ничего не мешает, по уму, создать фреймворк и инфраструктуру на C++, не уступающие C#/Java, и забыть про эти управляемые языки.
Когда создашь — возвращайся, обсудим твое поделие.

Здравствуйте, alex_public, Вы писали:

_>Вообще то все топовые веб-сервера (nginx, Apache, IIS и т.п.) и все топовые РСУБД (PostgreSQL, MySQl, SQL Server, Oracle и т.п.) написаны на C/C++. Так что не очень понятно о чём собственно речь. )))
Речь, как заметил аффтар выше по треду, о сферических веб приложениях в вакууме. Ессна же использующих и субд и веб сервера, написанные н С/С++, равно как операционные системы, написанные на С, драйвера, возможно написанные на ассемблере, схемотехнические решения (компы) и так далее.
И так, конкретные веб приложения проще, быстрей и дешевле педалить на управляемых языках, вне зависимости от количества конкурентных пользователей — перфоманс языка программирование ничто по сравнению с перфомансом используемых компонентов.

Здравствуйте, vdimas, Вы писали:

V>Похоже, что ты забываешь, что речь всё еще о стадии компиляции и такое несоответствие "констрейнам" (возникни оно в коде) в С++ в любом случае именно на этой стадии обнаруживается.

Стадии компиляции у пользователя, а не у автора библиотечного кода — огромная разница. Более того, даже там ошибка может не обнаружиться. Например:

// template <typename T>
// concept bool Barable = requires(T t)
// {
//     { t.bar() } -> void;
// };

template <typename T>
// requires Barable<T>
void foo(T t)
{
    t.baz(); // Ошибка: имелось ввиду `t.bar()`. Не ловится компилятором автора библиотеки.
}

Стадия компиляции не выявит ошибку даже в пользовательском коде, если у пользователя есть свой метод `baz()`, вызова которого из библиотечного кода он не ожидает. Ведь он ожидает, что согласно документации будет вызываться `bar()`.

V>Более того, в С++ легко проверить наличие нужного метода/методов даже в декларативном стиле уже имеющимися ср-вами языка (т.е. ср-в языка достаточно для разработки библиотечных приблуд требуемой функциональности).

Это ты не мне расскажи, а Страуструпу. А то он не в курсе, что концепты не нужны: http://www.stroustrup.com/good_concepts.pdf

V>В общем, когда речь идёт о реализации параметрического полиморфизма в C# vs C++ — то тут что-либо обсуждать сложно, т.к. у этих языков явно разные весовые категории в плане такого полиморфизма.

Да, выражать констрейнты номинативно через типы — не лучший подход. Конечно, шаблоны в C++ мощнее (в этом же смысле генерация через T4 ещё «мощнее»). Но они непроверяемые. Вот код на C#, аналогичный приведённому выше плюсовому:

interface IBarable
{
    void Bar();
}
...
static void Foo<T>(T t) where T: IBarable
{
    t.Baz(); // Ошибка: Имелось в виду `t.Bar()`. Ловится компилятором автора библиотеки.
}

Тут ошибка не только будет сразу подчёркнута в IDE, но ещё и по точке intellisense выдаст список допустимых ограничениями методов. Могут ли такое в C++ упомянутые «имеющиеся ср-ва языка в декларативном стиле, с полтыка найденные на этом сайте»?

	От:	lpd
	Дата:	06.01.17 19:53
	Оценка:

	От:	Klikujiskaaan
	Дата:	06.01.17 19:54
	Оценка:	+1

	От:	lpd
	Дата:	06.01.17 19:58
	Оценка:	-1

	От:	alex_public
	Дата:	06.01.17 20:19
	Оценка:	+1

	От:	AlexRK
	Дата:	06.01.17 20:24
	Оценка:	1 (1)

От:	Qbit86	https://twitter.com/qbit86
Дата:	07.01.17 11:56
Оценка:	+1