Достоинства и недостатки языка C#

[aa_dav]

arseniiv в сообщении #1191778 писал(а):

ак я и не говорил же, будто работа над ними как-то сказалась на опубликованных версиях спецификаций JVM и Java.

О, сама Java как платформа менялась заметно, появлялись новые классы, новые возможности раз за разом, а вот JVM меняется очень неохотно.

[arseniiv]

(Оффтоп)

Опять же, я не говорил, что Java и не менялась. Разумеется, менялась, стали ли бы они повышать версию просто так?

[Munin]

arseniiv в сообщении #1191694 писал(а):

уверен, применение найдётся.

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

[mustitz]

arseniiv в сообщении #1191567 писал(а):

А что там такое в C++ особенное с шаблонами бывает кроме того, что их параметрами могут быть целые числа?

Адские шаблоны допускают в качестве параметра ещё и модуль. Но специализации там нет. Вообще, вариант Ada мне нравиться больше всего — там инстанцирование явное, что позволяет нормально выводить сообщения об ошибках. Ну и в целом можно задавать ограничения для параметров шаблона вроде: любой модульный тип, любой целый тип, любой наследник от типа Parent, и т. п.

[warlock66613]

mustitz в сообщении #1191948 писал(а):

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

Ну и в С++ с этим проблем уже нет: соответствущие "воркэраунды" (в слегка облагороженном виде) теперь часть стандартной библиотеки.

[mustitz]

warlock66613 в сообщении #1191950 писал(а):

mustitz в сообщении #1191948 писал(а):

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

Ну и в С++ с этим проблем уже нет: соответствущие "воркэраунды" (в слегка облагороженном виде) теперь часть стандартной библиотеки.

В C++ как-то нет различия между целыми и модульными типами. Ну и... если Вы имеете в виду static_assert, то он поможет только на этапе инстанцирования шаблона.

[warlock66613]

mustitz в сообщении #1191959 писал(а):

В C++ как-то нет различия между целыми и модульными типами

Поясните, что такое модульный тип? Енум, диапазон, ещё что-то?

-- 12.02.2017, 14:47 --

mustitz в сообщении #1191959 писал(а):

Ну и... если Вы имеете в виду static_assert

Нет, я имею в виду соверешенно другое, а именно type traits, которые в частности позволяют указать конкретные условия, при которых шаблон (или специализация) в принципе может быть инстанцирован. Примеры использования можно посмотреть, например, тут: http://en.cppreference.com/w/cpp/types/enable_if.

[mustitz]

warlock66613 в сообщении #1191963 писал(а):

Поясните, что такое модульный тип? Енум, диапазон, ещё что-то?

А Ada обычные целочисленные типы вызывают исключение при переполнении. Модульные типы в случае переполнения просто записывают остаток от деления по модулю. Например, если у нас тип диапазон от 0 до 15, и модульный тип по основанию 16, то в случае попытки присвоить переменной первого типа значения 17, произойдёт исключение. В случае второго типа будет присвоено 1.

Битовые операции (AND, OR, XOR) разрешается выполнять только над целыми модульного типа.

-- 12.02.2017, 14:49 --

warlock66613 в сообщении #1191963 писал(а):

]Ну и... если Вы имеете в виду static_assert

Нет, я имею в виду соверешенно другое, а именно type traits, которые в частности позволяют указать конкретные условия, при которых шаблон (или специализация) в принципе может быть инстанцирован. Примеры использования можно посмотреть, например, тут: http://en.cppreference.com/w/cpp/types/enable_if.[/quote]

Всё равно выглядит так, что ошибку внутри шаблона можно выловить только при инстанцировании. Например, если мы требуем наследования класса Box, и в шаблоне допустили описку getWidht вемсто getWidth.

[mustitz]

warlock66613 в сообщении #1191990 писал(а):

Да, конечно. Поэтому и хорошо, что дженерики — это не темплейты.

Я бы сказал, что это скорее недостаток. Куда приятнее описать все ограничения и инварианты, накладываемые на тип и обеспечить нормальную однопроходную компиляцию дженерика. Чем иметь расширенную версию препроцессора.

[Karan]

Обсуждение работы с БД отделено в тему Инструменты для работы с СУБД в C#

[bondkim137]

rockclimber в сообщении #1191422 писал(а):

виртуальные машины уже давно научились генерировать нативный код и код этот по скорости не уступает С/С++

Да, именно так пишут пропагандисты (и не только решетки). В общем случае это пока еще далеко от правды, хотя и находится в рамках одного десятичного (местами даже двоичного) порядка.

rockclimber в сообщении #1191422 писал(а):

Еще, как я понимаю, может подтормаживать Garbage Collector, но эта проблема возникает только если создавать и уничтожать объекты миллионами.

Работа с кучей в серьезных масштабах - это серьезнейшая, на данный момент универально не до конца решенная задача. А с самоочищающейся кучей (GC) ситуация еще более непростая.

warlock66613 в сообщении #1191452 писал(а):

Что касается сборщика мусора, то он как раз ускоряет работу программы... кроме периодических моментов собственно сборки мусора - и есть области где эта непредсказуемость (а не тормоза как таковые) критична, но их немного

warlock66613 в сообщении #1191461 писал(а):

И оно с GC несопоставимо быстрее, хоят и не сводится к инструкции сложения

Да, но если сервису приходится пропускать через аллокатор огромный поток данных, заметная часть из которых оседает в 'глобальных переменных' и не может быть вынесена в треш по окончании отдельного запроса/подзадачи, он неимоверно начинает тормозить, домножая на ноль все прочие оптимизации и недостатки языка/технологии.

mustitz в сообщении #1191424 писал(а):

Для меня он плох тем, что слабо интегрируется с Linux.

Он отвратительно интегрируется много с чем пока еще.

arseniiv в сообщении #1191605 писал(а):

например, если я напишу параметром какого-то шаблона Typelist<int, Typelist<char, bool> >, неправильно завершив список, или вообще напишу на месте списка не-список

C++ - это полноприводный гоночный автомобиль с тремя свободными дифференциалами, механической коробкой передач с тремя валами и двумя сцеплениями, четырьмя отдельными педалями тормоза на все колеса и двумя рулями на обе оси. Работая с ним - нельзя ошибаться!

[Munin]

bondkim137 в сообщении #1192560 писал(а):

Да, но если сервису приходится пропускать через аллокатор огромный поток данных, заметная часть из которых оседает в 'глобальных переменных' и не может быть вынесена в треш по окончании отдельного запроса/подзадачи, он неимоверно начинает тормозить, домножая на ноль все прочие оптимизации и недостатки языка/технологии.

Можно регулярно убивать и возрождать процесс. У сервисов свои проблемы и свои хитрости, не надо обобщать.

[bondkim137]

В вышеприведенном случае нельзя, т.к.

bondkim137 в сообщении #1192560 писал(а):

заметная часть из которых оседает в 'глобальных переменных' и не может быть вынесена в треш по окончании отдельного запроса

Убийство процесса ничего не даст, эти 'оседающие' структуры придется сохранять (или перманентно полностью хранить в базе данных), что не всегда возможно/удобно/быстро. Регулярная 'реинкарнация' будет работать еще хуже, чем уплотнение средствами GC, если, конечно, память не течет. Подобная проблема свойственна не только сервисам, просто там пример на поверхности.

Можно решать через костлявое использование собственного ручного аллокатора, распиливание процесса на статическую и временные части с набиванием шишек на обмене данных между ними. Но все равно, ассоциированный геморрой тут легко перевешивает бенефиты от использования GC.

[Munin]

Просто ровно те же проблемы у вас будут и без GC.

[bondkim137]

Да, это так. Но речь как раз о том, что шарповый GC далеко не всегда можно использовать влоб, надеясь на то, что он умный и быстрый. И не только из-за недетерминированных задержек, но и общей производительности в некоторых случаях. К тому же, в C# конкретно эта задача похоже решается намного сложнее, чем в C++ из-за недостаточной предоставляемой программисту свободы. По крайней мере, я не знаю, как ее там просто решить :)