Здравствуйте, Qbit86, Вы писали:
_>>В С++17 действительно нет особо принципиального, так же как и в C+14 Q>Ну, как минимум в Стандарт вошли vocabulary types: `optional<T>`, `any<T>`, `string_view`, etc.
Это всё было давным давно доступно из Boost'a. Я подобные изменения (с переносом кода из пространства имён boost в пространство имён std) даже не рассматриваю. )))
Существенными являются только изменения в самом языке. Например в C++14 это были полиморфные лямбды (которые сразу же сделали лямбды C++ на голову более мощными, чем лямбды в любых других статических меинстрим языках), но это опять же было всего лишь доведение до ума нововведения из C++11.
Действительно принципиальные изменения (типа тех, что были в C++11) ожидались в C++17... Например модули и ещё кое-что важное. Но похоже в этот раз ещё не судьба.
Re[9]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, lpd, Вы писали:
lpd>>>Например, отсутствие копирования было бы полезно при разработке видео-кодеков. Но ffmpeg написан вообще на C, и я не вижу в подобных приложениях применения последним стандартам С++. _>>Ну естественно в ffmpeg написанном на C (и ассемблере) не используются последние новинки C++. ))) А как ты хотел то? ) lpd>Скорость копирования DDR-памяти порядка 10Гбайт/сек, и делать move всех мелких объектов нет никакого смысла. Речь о том, что ffmpeg это тот самый редкий случай, когда затраты времени на копирование могут играть роль. И там простые буфера памяти — даже не классы контейнеров. Мы видим, что в реализациях алгоритмов, где move-семантика может понадобиться, ей нет места, и может не быть места даже ООП.
Если ты хочешь добиться максимально возможной для процессора производительности обработки массивов данных (я кстати работал вот прямо с такими цифрами), то единственный путь — это использование SIMD (кстати в ffmpeg всё как раз на этом и построено). Вне зависимости от используемого языка. Если говорить про C++, то в нём есть несколько интересных оригинальных техник, облегчающих работу с SIMD.
lpd>Я не могу придумать ни одного примера программы, для которой move-семантика была бы реально нужна. lpd>Кроме того, помним, что ООП нужен для моделирования объектов — в основном, для наглядности архитектуры. Понятие указателя наглядно, как наглядно и понятие ссылки. А что такое rvalue-ссылка? Это какой-то синтаксический хак, позволяющий поставить && и изменить поведение программы.
Показываю конкретный и довольно известный случай. У тебя есть некий объект, который содержит некие тяжёлые ресурсы (большой объём памяти или ещё что-то) и автоматически управляет ими (в конструкторе/деструкторе). Так вот, расскажи как ты реализуешь создание и возврат (через return) данного объекта из функции без семантики перемещения? Чтобы и не надо было руками следить за временем жизни указателя и не было бы потери эффективности.
lpd>Может не нужно реализовывать в C++ нереализуемое, и оставить и объекты, и старое доброе ручное управление памятью — для тех случаев, когда оно нужно? C++, в том числе, ценен схожестью c C и близостью к ассемблеру/оборудованию — и в этом его конек с точки зрения эффективности.
Так технически все эти старые возможности оставлены. Просто их рекомендуется применять только в тех случаях, когда без этого уже никак (приблизительно как встроенный ассемблер). А не использовать их как базовый архитектурный принцип.
Re[19]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AlexRK, Вы писали:
ARK>>>Но понятно, что standalone приложения на C# пишутся довольно редко, с этим никто не спорит. _>>Вообще то как раз с этим ты и спорил. Иначе как тогда понять твою фразу "Если именно С++ не требуется, то просто берется C#."? ARK>Я бы не стал смешивать в одну кучу разработку на заказ с целью извлечения прибыли (о чем речь в этой теме) и создание программ энтузиастами "для души". Во втором случае никаких правил нет, кто чего знает или любит, тот на том и пишет, независимо от того, оптимально оно или нет.
Весело с тобой беседовать) В очередной раз твоя последняя фраза противоречит всем предыдущим. Или быть может ты хочешь сказать, что "standalone приложения" пишутся только энтузиастами, а не бизнесом? )
_>>Почти все перечисленные тобой приложения можно написать и на C++ и на C#. Да, на C# они будут более убогими, но всё же работать будут. Так что под указанный мною шаг1 это не подходит. ARK>Если их в принципе можно написать на C#, то они будут не хуже. Не просто "работать будут", а не будет никакой разницы с С++.
Ну-ну) Т.е. ты веришь, что 7zip реализованный на C# сможет запаковать архив с той же скоростью, что и написанный на C++? )))
Re[10]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
_>Показываю конкретный и довольно известный случай. У тебя есть некий объект, который содержит некие тяжёлые ресурсы (большой объём памяти или ещё что-то) и автоматически управляет ими (в конструкторе/деструкторе). Так вот, расскажи как ты реализуешь создание и возврат (через return) данного объекта из функции без семантики перемещения? Чтобы и не надо было руками следить за временем жизни указателя и не было бы потери эффективности.
В большинстве случаев все действительно большие объекты — глобальные, а в функции передается индекс или указатель на элемент. Либо это какие-то вычисления, и там все равно нет никакой инкапсуляции между объектами, а есть массив intов, и просто передается указатель из одной функции в другую.
В любом случае, язык программирования это не столько краткое представление операций, сколько простая их запись. По-моему, проще иногда передать указатель и следить за временем жизни(которое нужно учитывать в любом случае), чем пользоваться rvalue ссылками.
Давай конкретно: вот можешь описать случай с примером приложения и объекта, когда (бы) ты использовал move-семантику? хоть один?
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
_>Если ты хочешь добиться максимально возможной для процессора производительности обработки массивов данных (я кстати работал вот прямо с такими цифрами), то единственный путь — это использование SIMD (кстати в ffmpeg всё как раз на этом и построено). Вне зависимости от используемого языка. Если говорить про C++, то в нём есть несколько интересных оригинальных техник, облегчающих работу с SIMD.
Это есть и в C# Parallelism on a Single Core — SIMD with C# _>Показываю конкретный и довольно известный случай. У тебя есть некий объект, который содержит некие тяжёлые ресурсы (большой объём памяти или ещё что-то) и автоматически управляет ими (в конструкторе/деструкторе). Так вот, расскажи как ты реализуешь создание и возврат (через return) данного объекта из функции без семантики перемещения? Чтобы и не надо было руками следить за временем жизни указателя и не было бы потери эффективности.
Здравствуйте, alex_public, Вы писали:
ARK>>>>Но понятно, что standalone приложения на C# пишутся довольно редко, с этим никто не спорит. _>>>Вообще то как раз с этим ты и спорил. Иначе как тогда понять твою фразу "Если именно С++ не требуется, то просто берется C#."? ARK>>Я бы не стал смешивать в одну кучу разработку на заказ с целью извлечения прибыли (о чем речь в этой теме) и создание программ энтузиастами "для души". Во втором случае никаких правил нет, кто чего знает или любит, тот на том и пишет, независимо от того, оптимально оно или нет. _>Весело с тобой беседовать) В очередной раз твоя последняя фраза противоречит всем предыдущим. Или быть может ты хочешь сказать, что "standalone приложения" пишутся только энтузиастами, а не бизнесом? )
Напомню самое начало разговора:
А раз так, то на С++ как раз и следует писать только "реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС" (c), плюс кроссплатформенный и независимый по каким-то причинам от .NET софт.
Я считаю, что "standalone приложения" часто попадают в одну из последних категорий.
_>>>Почти все перечисленные тобой приложения можно написать и на C++ и на C#. Да, на C# они будут более убогими, но всё же работать будут. Так что под указанный мною шаг1 это не подходит. ARK>>Если их в принципе можно написать на C#, то они будут не хуже. Не просто "работать будут", а не будет никакой разницы с С++.
_>Ну-ну) Т.е. ты веришь, что 7zip реализованный на C# сможет запаковать архив с той же скоростью, что и написанный на C++? )))
Опять вы не читаете.
Если их в принципе можно написать на C#, то они будут не хуже.
Так вот, я считаю, что код самого архиватора на C# в принципе написать нельзя. Ну, то есть наверное можно, но с хаками, которые уже будут выглядеть как С++.
А вот foobar2000, WinCDEmu, iTunes — все это на C# написать можно (если закрыть глаза на кроссплатформенность). И разницы с С++ не будет НИКАКОЙ.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Основной акцент именно на интеграции всех этих фич между собой, на всех стадиях разработки. "Из коробки" думаю можно заменить на установку целым пакетом — главное чтобы не перманентная ручная подгонка отдельных частей. EP>Торчащие уши подобные Open Folder, создания проекта в консольке и т.п. — это как раз про недоинтегрированность. EP>Почитай например что пишут люди из MS: EP>
EP>Visual Studio Code is meant to be a powerful editor, not a full IDE. It does not support projects the way that Visual Studio does, and therefore doesn't understand sln or csproj files. ...
EP>
EP>but it is true that VS Code is meant to be a powerful editor and not an IDE. The way a like to think of the difference is that an IDE (like VS) pulls together all of the pieces of a development tool chain to create a single solution, whereas an editor (like VS Code) is intended to be a part of a development tool chain. Whether or not that is the reason for not being able to open a csproj/sln and run is a different discussion.
EP>
EP>An easy way to think about the difference is Visual Studio or Eclipse vs. Notepad++ or Sublime Text.
ВВ>>Какое-то очень сомнительное в плане полезности разделение на IDE и не IDE. EP>Это разделение на IDE и на DE (то есть Development Environment, без той самой I). И там и там можно успешно разрабатывать, и даже многие фичи пересекаются, отличается исполнение. EP>Если же не проводить такого разделения, а судить только по набору фич вне зависимости от степени их взаимоинтеграции, тогда непонятно зачем нужна аббревиатура I.D.E., пусть было бы просто D.E.
Т.е., я так понял, вы VSCode не пользовались? Соответственно, и ответа на то, чего не хватает интеграции C# в плане фич не будет. Для справки — поддержка C# устанавливается "целым пакетом" — OmniSharp for VSCode — и все работает.
Здравствуйте, alex_public, Вы писали:
_>А по твоему утверждение о том, что в VisualStudio навигация под коду реализуется компилятором C++ можно назвать чем-то иным кроме бреда? )
Ты передёргиваешь и выдираешь из контекста. Проще говоря, до**ался до формулировок. Мне лень это тебе расписывать, а остальным вроде понятно.
Может, ты отождествляешь компилятор с его бэк-eндом/кодогенератором?
_>Вот когда будет так работать, тогда и будешь об этом упоминать.
Visual Studio 2017 Release Candidate уже использует Roslyn не только для компиляции, но и для подсветки синтаксиса и прочих сервисов анализа кода.
_>непонятно какое отношение имеет Roslyn к навигации по коду в C++
Это логично: использовать и для компиляции, и для IDE один и тот же фронт-енд компилятора. Это можно применить к C#, и очень сложно к C++, потому что полноценный анализ будет тормозить на столь криво определённых синтаксисе и семантике языка.
_>про мифические недостатки которой ты тут писал.
Недостатки не мифические, а самые что ни на есть реальные, данные нам в ощущениях.
_>Ну можно конкретный пример кода, который у тебя работает не так как надо? ) И соответственно с описание того, как тебе надо.
Открываем файл «\boost_1_62_0\boost\graph\detail\adjacency_list.hpp», на строке 1832 вызов:
Нажимаем F12 Go To Definition чтобы перейти к сигнатуре и посмотреть, что там за типы. Вполне естественное желание, вроде ничего необычного, в C# такое часто делаю. Но в C++ вместо этого MSVS предлагает список методов, половина из которых вообще функции от четырёх аргументов.
Давай теперь ты рассказывай, какая у тебя IDE, какой компилятор, и как она осуществляет навигацию в этом примере.
_>Netbeans, CLion, Eclipse, QtCreator.
В окружающей меня реальности совокупная база пользователей этих «лидеров» на всех ОС меньше, чем у одной только Visual Studio на Windows. Но, может, в некой альтернативной реальности они стали лидерами, а Eclipse CDT перестал быть кривым **вном.
Здравствуйте, vdimas, Вы писали:
V>Ошибки перегрузки ловятся тестами, а не компилятором, ваш КО.
Это мы уже слышали, от адептов скриптоты типа Python.
V>Такая же ошибка могла быть и не в шаблонном коде, если у целевого Т есть некий baz, помимо bar.
Если в обычном нешаблонном динамически полиморфном коде я реализую функцию `Foo()` в терминах `IBarable` без `Baz()`, то мне компилятор точно так же не даст написать `barable.Baz()`, даже если в пользовательской реализации `IBarable` будет добавлен метод `Baz()`.
V>3. Концепт не спасёт от ошибки перегрузки в твоём примере насчет bar/baz. V>Последнее утверждение раскрывать требуется?
Да нет, понятно дело, не спасёт, в C++ же нет нормальной проверки шаблонов на стадии их написания.
V>При наличии IBarable.Baz не ловится.
А при отсутствии (обычный сценарий типа опечатки) — ловится. И, в отличие от C++, у автора блиотеки, не пользователя.
V>Ну и, в том же дотнете гораздо чаще случаются ошибки, когда вызывается не та сигнатура Bar, что ожидал разработчик.
Это почему чаще?
V>В С++ intellisense уж точно не предложит никакого baz. ))
Естественно, в обобщённом коде на C++ IDE ничего подобного не предложит (в крайнем случае лексические подсказки), надо печатать вручную. Проверок-то на соответствие констрейнтам нет.
V>Ну и, опять повторюсь, что ограничения в стиле C# организовать можно:
:)
#define where(A, Predicate, B) \
static_assert(Predicate<A, B>::value, "Predicate "#A" "#Predicate" "#B" is not satisfied")
template<typename T>
struct A {
void foo() {}
};
template<typename T>
struct B {
where(A<T>, std::is_base_of, T);
void bar(T * t) { t->fuu(); } // ok
// ^^ ^^
};
Здравствуйте, Qbit86, Вы писали:
Q>Если в обычном нешаблонном динамически полиморфном коде я реализую функцию `Foo()` в терминах `IBarable` без `Baz()`, то мне компилятор точно так же не даст написать `barable.Baz()`, даже если в пользовательской реализации `IBarable` будет добавлен метод `Baz()`.
Если, не если...
Это уже частности, т.е. зависит от везения. Может и не повезти.
Тут важно помнить общий принцип: статическая типизация не спасает от ошибок перегрузки сигнатур.
V>>3. Концепт не спасёт от ошибки перегрузки в твоём примере насчет bar/baz. V>>Последнее утверждение раскрывать требуется? Q>Да нет, понятно дело, не спасёт, в C++ же нет нормальной проверки шаблонов на стадии их написания.
В C# тоже нет ср-в поймать ошибки перегрузки.
V>>При наличии IBarable.Baz не ловится. Q>А при отсутствии (обычный сценарий типа опечатки) — ловится.
ЧТД. Дело конкретной ситуации. "Везения".
V>>Ну и, в том же дотнете гораздо чаще случаются ошибки, когда вызывается не та сигнатура Bar, что ожидал разработчик. Q>Это почему чаще?
Потому что правила выбора сигнатуры для вызова слишком свободные. Эти правила рассчитаны на эдакую "семантическую эквивалентность" всех допустимых перегрузок, т.е. прямо в языке предполагается, что не должно быть особой разницы, какую перегрузку взяли. Но разница может быть, ведь это дело конкретной реализации. Т.е., опять и снова, это вопрос "везения".
Q>
Q>#define where(A, Predicate, B) \
Q> static_assert(Predicate<A, B>::value, "Predicate "#A" "#Predicate" "#B" is not satisfied")
Q>template<typename T>
Q>struct A {
Q> void foo() {}
Q>};
Q>template<typename T>
Q>struct B {
Q> where(A<T>, std::is_base_of, T);
Q> void bar(T * t) { t->fuu(); } // ok
Q> // ^^ ^^
Q>};
Q>
Я ждал этого. ))
Ну вот хотелось проверить тебя на честность, т.е. насколько ты способен учитывать очевидные имеющиеся аргументы против твоей позиции, которые (аргументы) ты прекрасно в курсе. Тест ты не прошел.
Тогда я озвучу.
Когда в C# мы пишем ограничения вот таким образом:
class B<T> where T : A<T>
То в С++ строго аналогичный метод bar будет вот такой:
void bar(A<T> * t) { t->fuu(); } // у-у-упс!
Причем, тут и Resharper прекрасно подскажет и все твои ограничения соблюдутся.
И я ведь не поверю, что ты этого не знал...
Здравствуйте, vdimas, Вы писали:
V>Тут важно помнить общий принцип: статическая типизация не спасает от ошибок перегрузки сигнатур.
От каких-то спасает, от каких-то нет. В C# спасает от гораздо большего количества ошибок, чем в C++. Если я вызову перегрузку с неподходящим количеством параметров, или неподходящими типами, я физически не смогу предоставить пользователю библиотеку, потому что компилятор её не соберёт. В C++ компилятор в любом случае почти не задействован — экспорта шаблонов/модулей не завезли же. Хорошо, если IDE в процессе написания библиотечного кода может подсвечивать хотя бы самые тупые ошибки типа опечаток. Но не в C++.
V>В C# тоже нет ср-в поймать ошибки перегрузки.
Ты хватаешься за какие-то перегрузки, как за спасительную соломинку, в стремлении отрицать очевидное: в C++ НЕТ нормальной проверки обобщённого кода компилятором. Как в современных языках типа Scala, C#, F#, Rust, etc. Если это неочевидно, почитай Вандевурда-Джосаттиса, попробуй изучить что-нибудь кроме C++, etc.
V>Дело конкретной ситуации. "Везения". :xz:
Ну да. Например, если не повезло вляпатья в C++ с шаблонами, макросами и восьмиэтажными крипто-сообщениями об ошибках подстановки.
V>Я ждал этого. )) V>Ну вот хотелось проверить тебя на честность, т.е. насколько ты способен учитывать очевидные имеющиеся аргументы против твоей позиции, которые (аргументы) ты прекрасно в курсе. Тест ты не прошел. :xz:
Какой ещё тест, я просто скопипастил твой код в редактор, намеренно внёс ошибку — компилятор съел (тест он не прошёл). В C# он бы выдал ошибку, что не знает ни о какой функции `Fuu`.
V>Тогда я озвучу. V>Когда в C# мы пишем ограничения вот таким образом: V>
V>class B<T> where T : A<T>
V>То в С++ строго аналогичный метод bar будет вот такой: V>
V>void bar(A<T> * t) { t->fuu(); } // у-у-упс!
Пока не вижу связи строки на C# со строкой на C++. Давай ещё раз, полнее. На C# я пишу такую обобщённую библиотечную функцию (а не класс) `Foo`:
public interface IBarable
{
void Bar();
}
...
public static void Foo<T>(T t) where T: IBarable
{
t.Baz(); // Ошибка: Имелось в виду `t.Bar()`. Ловится компилятором автора библиотеки.
}
Как по-твоему должен выглядеть аналогичный обобщённый библиотечный код на C++, чтобы опечатка в имени вызываемого метода подсветилась в hpp-файле, который я набираю в MSVS?
Так ты, действительно, не понимаешь?
Q>Пока не вижу связи строки на C# со строкой на C++. Давай ещё раз, полнее. На C# я пишу такую обобщённую библиотечную функцию (а не класс) `Foo`: Q>
public interface IBarable
Q>{
Q> void Bar();
Q>}
Q>...
Q>public static void Foo<T>(T t) where T: IBarable
Q>{
Q> t.Baz(); // Ошибка: Имелось в виду `t.Bar()`. Ловится компилятором автора библиотеки.
Q>}
Q>Как по-твоему должен выглядеть аналогичный обобщённый библиотечный код на C++
Очевидно, если речь о возможностях, навроде имеющихся C#, то вот так:
void Foo(IBarable * t)
{
t->Baz(); // Ошибка: Имелось в виду `t.Bar()`. Ловится компилятором автора библиотеки.
}
Потому что "параметрический полиморфизм" (якобы параметрический полиморфизм) для ref-типов реализован в C# именно таким образом.
Т.е., нет никакого смысла опираться на некий T, потому что доступен только лишь IBarable. И вся "польза" от такого полиморфизма — в исключении проверок/приведений типов в исходнике пользователя.
Здравствуйте, vdimas, Вы писали:
V>Так ты, действительно, не понимаешь? :facepalm:
у тебя illusion of transparency.
V>Очевидно, если речь о возможностях, навроде имеющихся C#, то вот так: V>
V>void Foo(IBarable * t)
V>{
t->>Baz(); // Ошибка: Имелось в виду `t.Bar()`. Ловится компилятором автора библиотеки.
V>}
V>
V>Потому что "параметрический полиморфизм" (якобы параметрический полиморфизм) для ref-типов реализован в C# именно таким образом. V>Т.е., нет никакого смысла опираться на некий T, потому что доступен только лишь IBarable. И вся "польза" от такого полиморфизма — в исключении проверок/приведений типов в исходнике пользователя.
Во-первых, у пользователя библиотеки интерфейс IBarable может быть реализован value-типом. Если функция `Foo()` динамически полиморфная, то вызов её приведёт к боксингу пользовательской структуры. Если `Foo()` является дженериком, то боксинга не будет.
Во-вторых, в сигнатуре динамически полиморфного метода ты можешь указать только один тип; а в констрейнтах дженерика несколько. Соответственно, пользовательская структура тоже реализует несколько интерфейсов, но без единой иерархии с одним «общим» интерфейсом.
public interface IBarable
{
void Bar();
}
public interface IQuxable
{
void Qux();
}
...
public static void Foo<T>(T t) where T : IBarable, IQuxable
{
t.Qux();
t.Baz(); // Ошибка: Имелось в виду `t.Bar()`. Ловится компилятором автора библиотеки.
}
Покажи, как на C++ будет выглядеть этот более общий вариант.
void Foo(??? * t)
{
t->Qux();
t->Baz(); // Ошибка: Имелось в виду `t.Bar()`. Ловится компилятором автора библиотеки.
}
Здравствуйте, lpd, Вы писали:
lpd>StackOverflow — это просто обработать один запрос и либо положить пост в базу, либо выдать посты из базы. В нагруженных серверах(например, когда клиентами являются мобильные пользователи, VoIP) может быть постоянный обмен обмен пакетами, запросами, обработка данных. В таких случаях быстродействие языка играет роль.
У меня есть замечательный пример зарепорченного бага в Freeswitch, из-за которого бага можно легко потерять уйму денег. Исправляли полгода, еще полгода прошло — до сих пор патч не принят в апстрим. При том, что будь логика той части вынесена в управляемый код — а там нет ничего сложного, обычное диспетчирование, то поправили бы за неделю.
Я надеюсь, что как-нибудь по результатам недавних выборов в США, в которые якобы вмешались "русские хакеры", начнётся движение за чистый и надёжный код. Пусть даже и с просадкой по производительности — но чтобы не взломали. Или например начнут штрафовать владельцев взломанных серверов — а ты не создавай питательную среду для заразы! Не можешь обеспечить надёжность сервиса — сворачивай сервис!
Вот вой-то пойдёт среди высоконагруженных байтогрызов.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, lpd, Вы писали:
lpd>>StackOverflow — это просто обработать один запрос и либо положить пост в базу, либо выдать посты из базы. В нагруженных серверах(например, когда клиентами являются мобильные пользователи, VoIP) может быть постоянный обмен обмен пакетами, запросами, обработка данных. В таких случаях быстродействие языка играет роль.
С>У меня есть замечательный пример зарепорченного бага в Freeswitch, из-за которого бага можно легко потерять уйму денег. Исправляли полгода, еще полгода прошло — до сих пор патч не принят в апстрим. При том, что будь логика той части вынесена в управляемый код — а там нет ничего сложного, обычное диспетчирование, то поправили бы за неделю.
Ты всерьез по одному конкретному случаю с Freeswitch делаешь вывод о всей технологии? Даже если там дело в buffer overflow на C++, такой баг поправляется очень легко. И я представляю, сколько нужно админить серверов и какие писать load-balancerы, чтобы обрабатывать VoIP на C#. Напомню, C# в 2-4 раза медленнее, чем C++, причем на ровном месте.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[10]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:
_>Ну-ну) Т.е. ты веришь, что 7zip реализованный на C# сможет запаковать архив с той же скоростью, что и написанный на C++? )))
Да запросто. unsafe{...} и вперёд.
Кстати, 7zip до сих под андроид не портировали. Почему бы это? Потому что внутри него каша, а не код.
Здравствуйте, lpd, Вы писали:
С>>У меня есть замечательный пример зарепорченного бага в Freeswitch, из-за которого бага можно легко потерять уйму денег. Исправляли полгода, еще полгода прошло — до сих пор патч не принят в апстрим. При том, что будь логика той части вынесена в управляемый код — а там нет ничего сложного, обычное диспетчирование, то поправили бы за неделю.
lpd>Ты всерьез по одному конкретному случаю с Freeswitch делаешь вывод о всей технологии? Даже если там дело в buffer overflow на C++, такой баг поправляется очень легко. И я представляю, сколько нужно админить серверов и какие писать load-balancerы, чтобы обрабатывать VoIP на C#. Напомню, C# в 2-4 раза медленнее, чем C++, причем на ровном месте.
Там не С++, а вообще Си. Столь любимая многими сишечка. Без модулей. Без дженериков.
Выводы я делаю по примерам вроде того же bind, в котором до сих пор баги находят. По mysql с его дырками. Дело не только в языке, а и в культуре разработки. Вот тут весь тред копья ломают — ах, на чём же писать весь проект целиком, только на С++, или только на С#? При том, что в несчастном мобильном стартапе используется три языка и три разных специалиста — C# для Xamarin (и тем не менее для iPhone нужен отдельный специалист), JS и Angular — а это тоже отдельный мир, требующий своих специалистов, и наконец HTML5 c CSS3, который должен единообразно выглядеть везде, на всех устройствах, и для этого требуется специалист-верстальщик, а не просто С#-разработчик "со знанием HTML".
Можно использовать несколько языков в проекте. Только вот выбранный ранее язык определяет идиосинкразию предыдущих разработчиков к чему-то новому и отличному от милого их сердцам make c #DEFINE TRUE FALSE.
Уж казалось бы — HPC. Куда там ffmpeg'у какому-то, или обработке voip, которая вся сводится к манипуляции текстовыми заголовками. И то — людям стало УДОБНЕЕ пользоваться не байтогрызным MPI с его высокомерным сообществом, а написать свой Apache Spark. Фреймворк для ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ вычислений для Яве. На Яве, Карл!
Или вот еще оттуда, оцени уровень удобства байтогрызного фреймворка из 80х родом:
Today, MPI's error handling model is what it has always been; you can assign an errorhandler to be called when an error occurs in an MPI program, and when that happens you can... well, you can print a nice message before you crash, instead of crashing without the nice message.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, lpd, Вы писали:
С>Можно использовать несколько языков в проекте. Только вот выбранный ранее язык определяет идиосинкразию предыдущих разработчиков к чему-то новому и отличному от милого их сердцам make c #DEFINE TRUE FALSE.
Может, в некоторых случаях и можно использовать несколько языков. Только ради чего вообще в проекте C#? Только ради автоматического управления памятью? Утечки памяти в C++ отлично отлавливаются с помощью valgrind. C# сейчас используются исключительно из-за наличия удобного фреймворка веб-приложений — других серьезных причин я не вижу.
С>Вот хороший пример совсем из другой области:
С>...
С>Уж казалось бы — HPC. Куда там ffmpeg'у какому-то, или обработке voip, которая вся сводится к манипуляции текстовыми заголовками. И то — людям стало УДОБНЕЕ пользоваться не байтогрызным MPI с его высокомерным сообществом, а написать свой Apache Spark. Фреймворк для ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ вычислений для Яве. На Яве, Карл!
Я знаком с HPC. Возможно, в будущем и появятся лучшие механизмы, чем MPI. Только реализовать их на Java — это выкинуть 7000 ксеонов из 10000. То, что такие проекты в природе существуют, ни о чем не говорит, тем более, что на практике их не применяют.
С>Или вот еще оттуда, оцени уровень удобства байтогрызного фреймворка из 80х родом:
С>Today, MPI's error handling model is what it has always been; you can assign an errorhandler to be called when an error occurs in an MPI program, and when that happens you can... well, you can print a nice message before you crash, instead of crashing without the nice message.
В HPC никакая обработка ошибок и не нужна. Если узел вышел из строя, или есть баг в программе, то восстанавливаться и никакие другие запросы обрабатывать не надо — весь расчет прийдется начинать сначала. Так что это не может быть претензией к C++ или даже к MPI.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Может, в некоторых случаях и можно использовать несколько языков. Только ради чего вообще в проекте C#? Только ради автоматического управления памятью? Утечки памяти в C++ отлично отлавливаются с помощью valgrind. C# сейчас используются исключительно из-за наличия удобного фреймворка веб-приложений — других серьезных причин я не вижу.
Ради реализации сложной логики без идиотских ошибок. Сложная логика сама по себе сложна, и читаться с экрана она должна легко. Мозг человека ограничен, и если в коде насрано &&&<<><>::->, то чтобы продраться через насранное — требуются немалые мозговые ресурсы.
lpd>Я знаком с HPC. Возможно, в будущем и появятся лучшие механизмы, чем MPI. Только реализовать их на Java — это выкинуть 7000 ксеонов из 10000. То, что такие проекты в природе существуют, ни о чем не говорит, тем более, что на практике их не применяют.
Появились уже давно. Просто MPI-сообщество перешло из стадии развития в стадию окукливания. В этом треде пример подобного мы можем видеть в лице alex_public.
lpd>тем более, что на практике их не применяют.
Да половина всех machine learning контор в силиконовке сидят на этом фреймфорке, и не первый год. Тема очень горячая. Вот, например: http://www.h2o.ai
lpd>В HPC никакая обработка ошибок и не нужна. Если узел вышел из строя, или есть баг в программе, то восстанавливаться и никакие другие запросы обрабатывать не надо — весь расчет прийдется начинать сначала. Так что это не может быть претензией к C++ или даже к MPI.
Господи, ну конечно же, разумеется — нет! Сходи всё же по ссылке из предыдущего поста, прочитай, очень увлекательно.
