Pull to refresh
34
0
Сергей Сотник @atepeq

Пользователь

Send message
У меня наблюдение, что особенно «злостно» (я имею в виду, в ущерб удобочитаемости) var используют те, кто одновременно пишет на C# и JavaScript. Ну опять-таки, оговорюсь, что это в моем окружении.
Насчет имени типа — тут как с любым идентификатором. Он должен хорошо читаться. А с быстрым вводом поможет Intellisense.
Насчет вложенных дженериков — вот, как раз за счет того, что нет конструкции type/typedef, то и получаются они длинными. Почему вы считаете, что от typedef/type будет какой-то вред?
Да, но при всем моем уважении к решарперу, читать с его помощью код — это примерно как водить пальцем по страницам книги. Первоклашкам помогает, но очень медленно.
Спасибо за развернутый пример.

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

Но позиция — а давайте добавим в язык это, а потом это (я про комментарии к новым фичам C#7)… Она у меня вызывает вопросы. Хочется проанализировать, что было удачным, а без чего можно было бы обойтись. Кстати, сложность языка также добавляет ограниченности каждому комментатору.

С синтаксисом запросов я конечно же разбирался. Просто привел свой опыт, что в моих задачах мне он оказался излишним. Более того, показалось, что он вообще внес слишком большую сложность в язык (ну согласитесь, что это сложная в общем-то конструкция), не дав взамен больших плюсов. Вполне возможно, что как раз после обсуждения в комментариях я изменю своё мнение на противоположное. Как это произошло к моменту, когда в C# решили ввести локальные функции.

Теперь по сути.

В своем коде я предпочту именно последний вариант — функциональный синтаксис с созданием объекта. Правда… можете назвать меня параноиком, но даже тут я бы предпочел описать класс явно. Моя практика показывает, что в таком коде будет меньше проблем при поддержке, хотя чуть больше времени тратится на первоначальное написание. Кстати, тут бы очень к месту было упрощенное создание классов, описанное в конце поста:

class Person(string First, string Last);

Но в общем, насчет анонимных типов меня почти переубедили. Мне нужно подумать — может будут контраргументы.
Emit и CSharpCodeProvider — это как ассемблер и язык высокого уровня. Честно говоря, тяжело написать серьезный код на Emit. Хотя бы потому, что в случае ошибок разобраться в нем намного сложнее. А вот C#-код вполне можно вытащить и посмотреть, что там так или не так.

Интересно конечно было бы сравнить производительность, но в общем, не думаю, что она будет меньше, чем у обычного кода на C#. А позволяет ли Emit реально ускорить код? Интересно было бы услышать тех, кто сталкивался с этим на практике. У меня же слишком разные применения были — на C# писались и компилировались на лету полноценные классы с определенной логикой. А Emit — тут скорее короткие выражения. И то давно. Последнее время совсем переехал на CSharpCodeProvider.
Добавил сравнение с Marshal.Copy() вариантом в конец статьи. Обновил код в репозитории.
Не совсем. Marshal.Copy просто перенесет данные в другое место в том же порядке. Если мне хочется обрабатывать компоненты отдельно (каждую в своем массиве), то необходимо переставлять. Конечно, не всегда такое нужно, тогда действительно, Marshal.Copy хватит. Более того, в некоторых случаях можно вообще работать с данными Bitmap, никуда их не перенося. Все зависит от того, какая обработка нужна. Например, если нужна обработка с плавающей запятой (как указано в последнем случае), то простым копированием не обойтись.
Да, есть планы продолжить. Но не хотелось смешивать разные вопросы, как, например, алгоритмика и оптимизация отдельного подготовительного шага.
Насчет многомерных массивов — мне в самом начале это было не столь очевидно. Ведь все-таки выполняется не код, скомпилированный в команды процессора, а есть еще промежуточный уровень (MSIL). То, что идет значительная прибавка производительности, также говорит о достаточно высокой эффективности среды исполнения .net. Только в этом случае накладные расходы на проверку выхода за границы размерности и операции вычисления позиции в массиве, будут так сильно сказываться.

Про очевидные вещи — согласен. При накоплении некоторого опыта, это становится очевидно. Собственно, потому в названии статьи и указал «для начинающих». Но пока не пощупаешь сам, что какую выгоду дает, бывает сложно оценить, стоит ли в каком-то случае усложнять код ради этой прибавки. В данном случае хотелось показать как раз не качественно («вот, так быстрее»), а количественно («так быстрее в N раз»).
Интересно. Я попробую на днях.
Да, это просто легенда в обработке изображений. Нужно ей было бы дать почетную степень за вклад в развитие компьютерных технологий…

Если интересно, вот полное изображение. Это из Playboy, так что смотрите на свой страх и риск — http://www.ee.cityu.edu.hk/~lmpo/lenna/len_full.jpg.

А вот так Лена выглядела в 1997-м году:
image

Information

Rating
Does not participate
Location
Днепр, Днепропетровская обл., Украина
Registered
Activity