Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Хм, если пост обращён к C# разработчикам, то он не имеет смысла. Сомневаюсь что кто-то не знает этих скрыто-засекреченых возможностей.
Про большинство этих фич, а также их усовершенствования было на хабре. Можно было бы поискать и найти соответствующие статьи. Тогда хоть какой-то нормальный тематический сборник бы получился.
А так…
Кстати, если уж код не форматируется, то может уберёте великолепные ссылки на Source Code Highlighter.
Всё равно нихрена не работает, а кучу лишних строк занимает.
Про большинство этих фич, а также их усовершенствования было на хабре. Можно было бы поискать и найти соответствующие статьи. Тогда хоть какой-то нормальный тематический сборник бы получился.
А так…
Кстати, если уж код не форматируется, то может уберёте великолепные ссылки на Source Code Highlighter.
Всё равно нихрена не работает, а кучу лишних строк занимает.
Ето не скрытые возможности а стандартные… ничего нового…
Как говорит Самизнаетекто, «Так верстают только м… и». Ну вы поняли, да? :)
Без обид, но читать просто невозможно, уж простите. А статья действительно, очень пригодилась бы новичкам, особенно в присутствии грамотно разжеванных примеров.
Без обид, но читать просто невозможно, уж простите. А статья действительно, очень пригодилась бы новичкам, особенно в присутствии грамотно разжеванных примеров.
Одно дело малоизвестные фишки языка, которыми нечасто пользуются и из-за этого могут быть незнакомы, как yield и reftype. А другое дело стандартные конструкции, без которых никак enum, event, и т. д. А тут намешано все в кучу… Вот вам в коллекцию, может кто не знает:
можно использовать в качестве названия переменной зарезервированные слова, например «int» надо только перед этой переменной всегда ставить собачку:
Пр:
int @int =5;
Console.Write("{0} — это пять!", @int);
можно использовать в качестве названия переменной зарезервированные слова, например «int» надо только перед этой переменной всегда ставить собачку:
Пр:
int @int =5;
Console.Write("{0} — это пять!", @int);
Леша, можно-то оно можно, только за эту «фичу» в коде руки отрывать надо :)
Из полезного могу предложить лямбду без параметров:
() => Console.WriteLine(«Превед хабралюди!»)
Из полезного могу предложить лямбду без параметров:
() => Console.WriteLine(«Превед хабралюди!»)
1. Плохая читабельность — интАвелью. Что за интАвелью? о_О Лично у меня глаз на таком тормозит, хотя, возможно, это и субъективно
2. Фича используется редко, джуниоры будут тупить, пугаться и забиваться в угол
3. value вне свойств не является ключевым словом и здесь использование @ необоснованно ;)
4. если бы пункт 3 был недействительным — чем valueToCheck не устроило бы? Явно лучше @value выглядит.
2. Фича используется редко, джуниоры будут тупить, пугаться и забиваться в угол
3. value вне свойств не является ключевым словом и здесь использование @ необоснованно ;)
4. если бы пункт 3 был недействительным — чем valueToCheck не устроило бы? Явно лучше @value выглядит.
в данном случае это не нужно,
public bool CheckValue(int value) {
…
}
тоже прекрасно скомпилируется.
другое дело, если бы было не value, a, например, string или params.
public bool CheckValue(int value) {
…
}
тоже прекрасно скомпилируется.
другое дело, если бы было не value, a, например, string или params.
про енамы, можно делать даже так:
Догадайтесь сами, какое численное значение будет у Val2 :)
public enum MyEnum
{
Val1 = 1,
Val2,
Val3
}
Догадайтесь сами, какое численное значение будет у Val2 :)
а что такого криминального в том, чтобы проинициализировать только первый элемент?
Согласен, так как при явном задании значений программист показывает точно, каким будет результат компиляции. В приведенном примере будет семантической ошибкой закладываться на то, что компилятор сгенерирует «нужные» значения для Val2 и Val3.
Спасибо, хорошая статья, добавил в избранное.
А верстка, подсветка — это все вторично)
А верстка, подсветка — это все вторично)
А еще, если кто не знает, можно парсить имя поля перечисления, и получить его численное значение, например:
public enum MyEnum: byte
{
First = 1,
Second = 2,
Third
}
…
использование в коде:
MyEnum val = (MyEnum) Enum.Parse(typeof(MyEnum), «First», true);
последний параметр — игнорировать ли регистр, или нет.
public enum MyEnum: byte
{
First = 1,
Second = 2,
Third
}
…
использование в коде:
MyEnum val = (MyEnum) Enum.Parse(typeof(MyEnum), «First», true);
последний параметр — игнорировать ли регистр, или нет.
У вас в самом начале:
оффтоп:
Обилие надписей «This source code was highlighted with Source Code Highlighter» немного раздражает.
Обилие надписей «This source code was highlighted with Source Code Highlighter» немного раздражает.
Хотелось бы добавить, что конструкция List.ForEach() поддерживает удаление элементов во время проходки.
Обычный foreach (не расширение) не позволяет такого делать.
Так же в примере лучше использовать не делегат, а лямбда-функцию, в конечном итоге это одно и то же, но лямбда-функции как раз были созданы для красивой записи параметров расширений.
Обычный foreach (не расширение) не позволяет такого делать.
Так же в примере лучше использовать не делегат, а лямбда-функцию, в конечном итоге это одно и то же, но лямбда-функции как раз были созданы для красивой записи параметров расширений.
В foreach можно удалить элемент, только потом надо вызвать break.
break прервёт цикл. А что делать если надо удалить 2 и более элементов? только for(i=list.Count, .., i--)
Это я и имел ввиду. Криво сформулировал.
Все-таки лучше такого не делать в коде, чтобы не бесить тех, кто потом будет иметь несчастье этот код поддерживать ) Однако фича интересная, интересно было бы узнать, как это работает под капотом foreach.
если необходимо что-то удалять, то лучше использовать Filter с предикатом. Он для этого предназначен. Тем более не очень представляю, как вы реализуете удаление в лямбде? Через замыкание? Не есть гуд, имхо.
Да, через замыкание. Возможно не вполне изящно (для тех кто не любит замыкания), но работает.
Тем более, если использовать фильтр со сложным предикатом (например, производящим для каждого элемента какую нибудь нетривиальную операцию), то все равно будет использование замыкание, а форичем лично мне как то нагляднее. Наверно это дело вкуса и вряд ли принципиально.
Тем более, если использовать фильтр со сложным предикатом (например, производящим для каждого элемента какую нибудь нетривиальную операцию), то все равно будет использование замыкание, а форичем лично мне как то нагляднее. Наверно это дело вкуса и вряд ли принципиально.
ух… еле попал на хабр, никак не мог зайти =(.
Зачем я сделал этот «перевод»?.. Чтоб кто-то закинул его в favorits, чтоб люди здесь продолжили список! Вижу тут уже появляются ожидавшиеся мной коментарии =). Сейчас постараюсь и подправлю статью. Кстати насчет
в старых.
Зачем я сделал этот «перевод»?.. Чтоб кто-то закинул его в favorits, чтоб люди здесь продолжили список! Вижу тут уже появляются ожидавшиеся мной коментарии =). Сейчас постараюсь и подправлю статью. Кстати насчет
Одно дело малоизвестные фишки языка, которыми нечасто пользуются и из-за этого могут быть незнакомы, как yield и reftype. А другое дело стандартные конструкции, без которых никак enum, event, и т. д. А тут намешано все в кучу, вы-правы, но я и не говорил, что это-систематизированный список… Это-просто список полезных/редких фич, по-мнению ребят с stackoverflow.com.
да, еще иногда очень скупые комментарии к фиче и линк ведет на какое-то оглавление :/ не понятно, о чем конкретно шла речьэто ссылки на примеры с stackowerflow к этому вопросу… Если не все они верно работают, то уж вините двиг вышеупомянутого сайта =) я просто постарался раскрыть все подробнее и по-возможности дать скупые( =( ) коментарии и ссылки на русские ресурсы. Всем спасибо за дополняющие коментарии, надеюсь этот пост покажет кому-нибудь «новые» конструкции или поможет напомнить и разобраться
в старых.
Ну и нафиг эта бессистемщина?
да, системы правда нет… Но я и не видел упорядоченные сборки такой информации…
разве что что-то типа:
Кому интересно, можете ознакомится тут: ifolder.ru
разве что что-то типа:
Кому интересно, можете ознакомится тут: ifolder.ru
Системы нету у творцов C# в головах. :)
Яркий пример: Nullable(T) просто реализуется, если в языке есть поддержка алгебраических типов данных. Nullable(T) является монадой, что тоже можно выразить, используя специальный полиморфизм (в C#/C++ делается с помощью subclassing (плохой способ) или перегрузки операторов, в Haskell — классы типов).
Так что система должна быть в голове.
Яркий пример: Nullable(T) просто реализуется, если в языке есть поддержка алгебраических типов данных. Nullable(T) является монадой, что тоже можно выразить, используя специальный полиморфизм (в C#/C++ делается с помощью subclassing (плохой способ) или перегрузки операторов, в Haskell — классы типов).
Так что система должна быть в голове.
С каждой новой версией .NET, программировать под него становится все сложнее. Проблема, на мой взгляд, в том, что слишком много функций возлагается на саму среду и языковые возможности, в то время как их спокойно можно было бы реализовать расширением библиотеками стандартных классов и функций.
Вот взять к примеру, один из самых дьявольских атрибутов — ThreadStaticAttribute. Казалось бы, что плохого, в том что можно легко и быстро сделать переменную уникальной для каждого потока, либо другими словами, из одной переменной сделать хранилище переменных, где каждый поток получает в распоряжение отдельную область из хранилища. А плохо то, что это неявный подход к созданию такого хранилища, и на моем опыте случалась не одна ошибка, что ктото забывал, не замечал, или просто не знал, что некая переменная объявлена как ThreadStatic, сначала долго удивлялся почему все не работает, а потратив порядочно времени на дебаг долго ругался и говорил что «я то думал это обычный статик, в этом потоке запишу, в другом прочитаю». В общем, не знаю как для вас, а для меня ThreadStatic — табу. Я про него знаю (как и о многих других вещах написаных в этой статье) но не использую, и не буду использовать.
Лучше я напишу чуть больше кода, но этот код — явный, его можно открыть и посмотреть как он работает, чем буду использовать мудрености фреймворка со скрытой реализацией. .NET далеко ушел на фронте упрощения и абстракции алгоритмов, но тяжелая виртуальная машина, напичканая встроенными возможностями, сильно усложняет понимание и предсказуемость как будет работать код. В этом плане обычный C++ гораздо проще, где мы имеем дело с простой «реальной» машиной.
Вот взять к примеру, один из самых дьявольских атрибутов — ThreadStaticAttribute. Казалось бы, что плохого, в том что можно легко и быстро сделать переменную уникальной для каждого потока, либо другими словами, из одной переменной сделать хранилище переменных, где каждый поток получает в распоряжение отдельную область из хранилища. А плохо то, что это неявный подход к созданию такого хранилища, и на моем опыте случалась не одна ошибка, что ктото забывал, не замечал, или просто не знал, что некая переменная объявлена как ThreadStatic, сначала долго удивлялся почему все не работает, а потратив порядочно времени на дебаг долго ругался и говорил что «я то думал это обычный статик, в этом потоке запишу, в другом прочитаю». В общем, не знаю как для вас, а для меня ThreadStatic — табу. Я про него знаю (как и о многих других вещах написаных в этой статье) но не использую, и не буду использовать.
Лучше я напишу чуть больше кода, но этот код — явный, его можно открыть и посмотреть как он работает, чем буду использовать мудрености фреймворка со скрытой реализацией. .NET далеко ушел на фронте упрощения и абстракции алгоритмов, но тяжелая виртуальная машина, напичканая встроенными возможностями, сильно усложняет понимание и предсказуемость как будет работать код. В этом плане обычный C++ гораздо проще, где мы имеем дело с простой «реальной» машиной.
Надо внимательнее книги читать. Если всё выносить в библиотеки, то потеряется межязыковая совместимость, одна из основных фич платформы .Net. Поэтому, на мой взгляд, это стоит выносить в CLR.
А можете привести пример про «это», что нельзя вынести в библиотеки по причине потели межязыковой совместимости?
Я всегда думал, что межязыковая совместимость обеспечивается наличием в .NET промежуточного языка MSIL. Отсюда и свойство — неважно, на каком языке написан исходный код, так как он все равно транслируется в MSIL.
Но как это связано с тем, о чем я написал — о избыточной (чисто на мой личный взгляд, конечно) перегрузке виртуальной машины функциями, которые вполне можно реализовать библиотеками?
Я всегда думал, что межязыковая совместимость обеспечивается наличием в .NET промежуточного языка MSIL. Отсюда и свойство — неважно, на каком языке написан исходный код, так как он все равно транслируется в MSIL.
Но как это связано с тем, о чем я написал — о избыточной (чисто на мой личный взгляд, конечно) перегрузке виртуальной машины функциями, которые вполне можно реализовать библиотеками?
Странно, мне с каждой новой версией программировать становится все легче и быстрее.
Ну вообщем то сама CLR не особо то и тяжелая. Почти все классы и прочее и так вынесены в библиотеки (гляньте сколько зависимостей даже в простейшем оконном приложении). Просто эти библиотеки подключены по умолчанию, что весьма приятно.
А уж если хочется иметь полный контоль над кодом, то лучше вообще ничего не подключать и писать все самому, ведь плюсовый stl и прочие библиотеки тоже имеют не всегда открытую реализацию, или их просто влом читать. Тем более все фишки дотнета можно посмотреть через рефлектор, иногда помогает кстати.
А уж если хочется иметь полный контоль над кодом, то лучше вообще ничего не подключать и писать все самому, ведь плюсовый stl и прочие библиотеки тоже имеют не всегда открытую реализацию, или их просто влом читать. Тем более все фишки дотнета можно посмотреть через рефлектор, иногда помогает кстати.
Я говорю о тех примерах, которые как раз то и нельзя рефлектором посмотреть. Тот же ThreadStatic, это простой декларативный атрибут. Он не имеет кода, который можно было бы проанализировать. Он просто «флажок» для CLR, которая реагирует на него изменением поведения.
>> А уж если хочется иметь полный контоль над кодом, то лучше вообще ничего не подключать и писать все самому.
Помоему Вы немного путаетесь. Использование сторонних библиотек совершенно не означает потерю контроля над кодом. Хотел бы объяснить почему, но это оффтопик.
Я говорил лиш о том, что CLR исповедует декларативный метод. Вы просто должны выучить тот немаленький список ее возможностей, и быть счастливым программистом. Но вот беда, если вы завтра перестанете писать программы под .NET, перейдете на другую платформу, а через 10 лет вам попадется под руку код, написанный декларативным методом с использованием всех функций CLR, вам будет очень тяжело понять поведение кода. Нет возможности по месту изучить поведение, надо опять идти читать базовые книги, чтобы вспоимнать устройство машины (runtime).
>> А уж если хочется иметь полный контоль над кодом, то лучше вообще ничего не подключать и писать все самому.
Помоему Вы немного путаетесь. Использование сторонних библиотек совершенно не означает потерю контроля над кодом. Хотел бы объяснить почему, но это оффтопик.
Я говорил лиш о том, что CLR исповедует декларативный метод. Вы просто должны выучить тот немаленький список ее возможностей, и быть счастливым программистом. Но вот беда, если вы завтра перестанете писать программы под .NET, перейдете на другую платформу, а через 10 лет вам попадется под руку код, написанный декларативным методом с использованием всех функций CLR, вам будет очень тяжело понять поведение кода. Нет возможности по месту изучить поведение, надо опять идти читать базовые книги, чтобы вспоимнать устройство машины (runtime).
>>Он просто «флажок» для CLR, которая реагирует на него изменением поведения.
Ну все же это чуть более чем просто флажок. Он имеет какой то код, который можно посмотреть. Правда не факт что там можно почерпнуть что то полезное. Если это не поможет, всегда можно глянуть документацию, или даже понять по названию (благо в дотнете все функции по человечески назвали).
А если не кодить на плюсах 10 лет, то потом тоже вряд ли вспомнишь что к чему.
Какая разница, что забыть: что делает использованный класс на с++ или аттрибут, расширяющий возможности существующего класса? Или не вспомнить что делает какой то метод из библиотеки, код которой куда то пропал (для с++) или из самого языка (c# например)?
Ну все же это чуть более чем просто флажок. Он имеет какой то код, который можно посмотреть. Правда не факт что там можно почерпнуть что то полезное. Если это не поможет, всегда можно глянуть документацию, или даже понять по названию (благо в дотнете все функции по человечески назвали).
А если не кодить на плюсах 10 лет, то потом тоже вряд ли вспомнишь что к чему.
Какая разница, что забыть: что делает использованный класс на с++ или аттрибут, расширяющий возможности существующего класса? Или не вспомнить что делает какой то метод из библиотеки, код которой куда то пропал (для с++) или из самого языка (c# например)?
[Serializable, ComVisible(true), AttributeUsage(AttributeTargets.Field, Inherited=false)]
public class ThreadStaticAttribute: Attribute {}
Это и весь код.
>> А если не кодить на плюсах 10 лет, то потом тоже вряд ли вспомнишь что к чему.
>> Какая разница, что забыть: что делает использованный класс на с++ или аттрибут
Вы немного некорректно выразились. Аттрибут не делает ничего. Делает среда, реагируя на атрибут.
>> Или не вспомнить что делает какой то метод из библиотеки, код которой куда то пропал (для с++) или из самого языка (c# например)?
Давайте оставим C++ в покое. Мы сейчас говорим конкрентно о CLR. И рассматриваем два случая: в первом функция реализована в виде библиотеки, во втором — декларативно. Если код работает, значти библиотека на месте, значит нет труда рефлектором, по месту, посмотреть ее устройство.
Все что я хочу сказать, что я предпочел бы среду с более простой базовой машиной, но более развитой библиотекой. И с этой точки зрения CLR для меня лично — не идеал. Возможно им станет C++0x, ведь уважаемый Бьерн Страуструп ведет активную работу по разведению запрошенных улучшений и функций к новому поколению «плюсов» на то, что должно стать частью языка и то, что лучше включить в состав Standard Library.
public class ThreadStaticAttribute: Attribute {}
Это и весь код.
>> А если не кодить на плюсах 10 лет, то потом тоже вряд ли вспомнишь что к чему.
>> Какая разница, что забыть: что делает использованный класс на с++ или аттрибут
Вы немного некорректно выразились. Аттрибут не делает ничего. Делает среда, реагируя на атрибут.
>> Или не вспомнить что делает какой то метод из библиотеки, код которой куда то пропал (для с++) или из самого языка (c# например)?
Давайте оставим C++ в покое. Мы сейчас говорим конкрентно о CLR. И рассматриваем два случая: в первом функция реализована в виде библиотеки, во втором — декларативно. Если код работает, значти библиотека на месте, значит нет труда рефлектором, по месту, посмотреть ее устройство.
Все что я хочу сказать, что я предпочел бы среду с более простой базовой машиной, но более развитой библиотекой. И с этой точки зрения CLR для меня лично — не идеал. Возможно им станет C++0x, ведь уважаемый Бьерн Страуструп ведет активную работу по разведению запрошенных улучшений и функций к новому поколению «плюсов» на то, что должно стать частью языка и то, что лучше включить в состав Standard Library.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Скрытые» полезности С#