Re[3]: As is или история о том как не надо писать код
От: tarkil Россия http://5209.copi.ru/
Дата: 27.12.04 11:11
Оценка: 10 (1) +2
Здравствуйте, VladD2, Вы писали:

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


Ну, с моей т.з. пояснение пагубности без указания правильного пути практически бесполезно. Как надо было-то поступать разработчикам софта для ракеты? А то у читателя возникает закономерный вопрос: может другие пути-то ничем не лучше?

P.S. Вспоминается один препод. Был у него имидж такого импозантного прилизанного всё знающего и понимающего мужика. Крутого бизнесмена. После вторых выборов Ельцина он нам старательно втирал, что выбор был неправильный, что выбрали не того и последствия будут конченые. При этом заданный несколько раз вопрос — "а кого?" — он деликатно игнорировал. Серьёзно воспринимать его после этого было совершенно невозможно. Цель этого примера: продемонстрировать пагубность указания плохого пути без указания хорошего. А вовсе не наезд, как могло кому-то показаться
--
wbr, Peter Taran
Re[4]: As is или история о том как не надо писать код
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.04 22:00
Оценка:
Здравствуйте, tarkil, Вы писали:

T>Ну, с моей т.з. пояснение пагубности без указания правильного пути практически бесполезно. Как надо было-то поступать разработчикам софта для ракеты? А то у читателя возникает закономерный вопрос: может другие пути-то ничем не лучше?


Правильный путь — не закладываться на частности. Что тут не ясно?

T>Цель этого примера: продемонстрировать пагубность указания плохого пути без указания хорошего.


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

T>А вовсе не наезд, как могло кому-то показаться


А кто-то воспринял твои слова как наезд?
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: As is или история о том как не надо писать код
От: Аноним  
Дата: 28.12.04 03:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Правильный путь — не закладываться на частности. Что тут не ясно?


Неясна расшифровка этой фразы — "закладываться на частности". Это значит считать, что ракета может летать под любыми углами? А если сложность алгоритма от этого увеличивается втрое (а значит время разработки и тестирования — девятикратно)? А возможность полёта вертикально вниз тоже учитывать? Ну мало ли что взбредёт в голову инженерам в следущей версии...

T>>Цель этого примера: продемонстрировать пагубность указания плохого пути без указания хорошего.

VD>Ну, то есть если тебе говорят пальцы в розетку не совать, то ты обшижашся потому, что тебе не дали инструкций куда их девать?

Я никогда и ни на кого не обижаюсь. Но если ребёнку интересна розетка, то его лучше занять чем-то другим, нежели просто говорить "нельзя". Интерес-то никуда не денется. Из моего детства:
— Мама, выйди из комнаты.
— Зачем?
— Я вот это (показываю карандаш) в розетку засуну.

VD>А кто-то воспринял твои слова как наезд?


Могли.
Re[6]: As is или история о том как не надо писать код
От: TK Лес кывт.рф
Дата: 28.12.04 04:22
Оценка: +1 :))) :))) :))
Hello,
>
> Неясна расшифровка этой фразы — "закладываться на частности". Это значит считать, что ракета может летать под любыми углами?

Это значит, что ракета выдала-бы assert и зависла. После этого переключившись в режим отладки можно было-бы изменить траекторию руками.
Posted via RSDN NNTP Server 1.9 delta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[6]: As is или история о том как не надо писать код
От: DuШes  
Дата: 28.12.04 06:36
Оценка:
Здравствуйте, Аноним, Вы писали:

[...]

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

ps: нинакого не хотел наехать, просто накипело....
Re[7]: As is или история о том как не надо писать код
От: Mika Soukhov Stock#
Дата: 28.12.04 08:34
Оценка: :)))
Здравствуйте, DuШes, Вы писали:

DШ>ps: нинакого не хотел наехать, просто накипело....


Э-э-э... а где записываются в космонавтов?
Re[6]: As is или история о том как не надо писать код
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.04 10:02
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Неясна расшифровка этой фразы — "закладываться на частности". Это значит считать, что ракета может летать под любыми углами?


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

А> А если сложность алгоритма от этого увеличивается втрое (а значит время разработки и тестирования — девятикратно)?


Все зависит от крамотности пректирования. Практика показывет, что увеличение сложности обычно связано с отсуствием четкого понимани задачи и видения пути ее рашения. От наличия или отсуствия абстракции ничего меняться не должно. Если меняется, то в пору проанализировать дизайн своего приложения.

Так от замены (x as y) на ((y)x) ничего меняться не должно. При этом (x as y) закладовалось на частность (предпологалось, что х никогда недолжно содежать объект другого типа). Это и была главная мысль.

А> А возможность полёта вертикально вниз тоже учитывать? Ну мало ли что взбредёт в голову инженерам в следущей версии...


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

А>Я никогда и ни на кого не обижаюсь. Но если ребёнку интересна розетка, то его лучше занять чем-то другим, нежели просто говорить "нельзя".


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

А> Интерес-то никуда не денется. Из моего детства:

А>- Мама, выйди из комнаты.
А>- Зачем?
А>- Я вот это (показываю карандаш) в розетку засуну.



Я сувал в розетку наушники. 5 раз в раио-розетку и один в 220 вольт. Весело было...

VD>>А кто-то воспринял твои слова как наезд?

А>Могли.

Ну, я вроде не воспринял. Остальные пускай сами разбираются со своими тараканами.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: As is или история о том как не надо писать код
От: tarkil Россия http://5209.copi.ru/
Дата: 28.12.04 10:16
Оценка: :)))
Здравствуйте, VladD2, Вы писали:

VD>Это значит, что не стоит задвавать параметры в виде константы на том лишь основании, что пока не предвидится его изменение. В более общем случае не нужно при проектировании закладываться на частности. Нужно стараться делать код более асбтрактным и универсальным.


VD>Так от замены (x as y) на ((y)x) ничего меняться не должно. При этом (x as y) закладовалось на частность (предпологалось, что х никогда недолжно содежать объект другого типа). Это и была главная мысль.


VD>Мне кажется, ты слишком много внимания уделяешь частностям данной аналогии. Цель ее проведения — проилюстрировать суть ситуации. Если без нее у тебя и так не возникает никаких вопросов, то просто опусти ее.


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

Ха! Вспоминается анекдот: "И не пиши слишком общего алгоритма! Что это у тебя за константа SCREEN_DIMENSION = 2? Размерность экрана монитора?..."

VD>Дык, статья все же рассчитана на разумных, взрослых людей. Пусть уж они сами выбирают куда им совать их пальцы.


А со взрослыми людьми всё то же самое, не обольщайся.
--
wbr, Peter Taran
Re: As is или история о том как не надо писать код
От: Аноним  
Дата: 31.12.04 23:07
Оценка:
Здравствуйте, Владислав Чистяков (VladD2), Вы писали.

А можно ведь было обойтись 2мя абзацами... с тем же кол-вом информации.
Re[2]: As is или история о том как не надо писать код
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.01.05 13:43
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>А можно ведь было обойтись 2мя абзацами... с тем же кол-вом информации.


Вот здесь: Re[2]: Что означает понятие skills в резюме для работодателя
Автор: VladD2
Дата: 07.08.04
я уже отвечал на похожий вопрос.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: As is или история о том как не надо писать код
От: adontz Грузия http://adontz.wordpress.com/
Дата: 16.08.05 21:31
Оценка: 31 (2) :))
Здравствуйте, Владислав Чистяков (VladD2), Вы писали:

Вот сейчас прочитал стать. Странная она какая-то. врорде бы всё правильно, но как вглядишь то там, то тут огрехи.

Ну водичку в начале мы пропустим



int    i = 123;
void*  p = &i;
double d = *(double*)p;
printf("i = %f", d);
При попытке повторить этот код в безопасном режиме C#:
int    i  = 123;
object p  = i;
double d = (double)p;
Console.WriteLine("value = {0}", d);

Надо заметить, что это не идентичные куски кода, хотя так и кажется с певого взгляда. Тип object это не аналог нетипизированного указателя. Собственно C# сообще не позволяет сделать то, что написано на Си++ в приведённом выше коде. Более того, если уж упоминается Си++, то почему не упоминания об операторе dymanic_cast некотором аналоге оператора as?


Довольно странный пример
class A { }

class B : A
{
  public void SomeMethod() { }
}

class Test
{
  static B _b;

  static void Init(A a)
  {
    _b = a as B;
  }

  static void Main()
  {
    Init(new A());
    // ...
    _b.SomeMethod();
  }
}
не ясно что пришло в голову программиста который описал параметр с типом A только для того чтобы потом сделать upcast до типа B. Пример создаёт впечатление весьма надуманного и совершенно не убеждает в чём-либо.


Ещё более странный пример от Ткачёва, не буду его приводить полностью, он довольно крупный.

Естественно, в таком простом коде не составит труда быстро найти настоящую причину. Но представим, что этот класс занимает тысячу строк витиеватого кода, да ещё, может быть, это реализуется не один классом, это может быть целый фреймворк. Найти истинную причину в этом случае может оказаться не совсем просто.

Но всё-таки после нескольких бессонных ночей я выхожу на A.CreateInstance и выясняю, что проблема в моём собственном коде, и понимаю, что сам дурак. Далее, чтобы избежать длительных поисков подобных ошибок в будущем, я привожу за ухо того, кто писал этот код и прошу его заменить as на cast. Но его аргументы такие: ошибка не в его коде, она уже исправлена мной самим в моём коде, и, главное, он не знает к чему приведут такие изменения, т.к. писал он это давно и уже не помнит, завязана ли его логика на возможный null или нет. Всё остается, как есть, и впоследствии на эти грабли наступают другие разработчики, тратя на борьбу с ними много времени.

Сказать что подобная ситуация странная, значит ничего не сказать. Во-первых, если речь идёт о реальных событиях, а не о надуманых примерах, программист не выйдет на код A.CreateInstance просто потому что его у него не будет. Во-вторых, тут мягко говоря сгущены краски. Проблема тут вовсе не в операторе приведения типа, а в полном отсутствии документации. Если бы разработчик позаботился написать пару страниц на тему "Интерфейсы которые класс-плагин должен реализовать", а программист-жертва имел свободный доступ к этом документу, то проблемы бы просто не было. И если уж такое случилось, то надо не код менять, а писать к нему документацию. А то исходя из подобных идей можно выкинуть всё WinAPI, COM и т.д. Ситуация на самом деле ничем не отличается от передачи нулевого (невалидного) указателя на callback-функцию. И тут нет и не может быть другого правильного решения, чем вовремя писать и читать документацию. Тем более удивительно её отсутствие, что речь шла о некотором фреймворке. Совершенно невозможно контролировать правильность входных данных везде и всегда. И тут замена оператора ничем не поможет. Довольно часто надо сказать, что будешь ждать такие-то данные и точка. Если данные другие, то поведение не определено. Это некоторый внутренний контракт. Следуя подобным принципам гипертрофирования проверок можно будет писать код
a = b;
if (a != b) ReportRAMError();



Использование штатного оператора приведения типов «()» не делает код правильнее автоматически и не защищает от ошибок. С точки зрения функциональности код останется точно таким же. Оператор () позволит локализовать ошибку в месте, наиболее близком к ее появлению. А это в свою очередь позволит сэкономить немало вашего (и не только) драгоценного времени.

Ещё одно странное утверждение. В примере выше ошибка была в коде плагина, который не реализовывал нужный интерфейс. Применение () вместо as всё равно указало бы на код фреймворка как ошибочный. Учитывая, что "этот класс занимает тысячу строк витиеватого кода, да ещё, может быть, это реализуется не один классом, это может быть целый фреймворк" (я уже говорил, что этого кода может вообще не быть?) мы имеем замену шила на мыло. Всё равно ошибка будет в незнакомом участке чужого кода. Скорее всего мы даже не поймём тип чьего указателя приводился, переданного нами и какого-то из используемых внутри. Соответственно никакого полезного вывода вроде "О! Я ведь забыл реализовать интерфейс" тоже не будет сделано.


Среди оснований за использование оператора as забыто самое главное. Он не кидает исключения. А ведь его надо ловить. А это лишняя пара try-catch и, что важнее, головная боль — а что делать внутри catch? С одной стороны очень хочется поймать все свои ошибки, с другой не стоит ловить чужие.
try
{
  ((B)a).SomeMethod();
}
catch(Exception e)
{
}

Как определить когда сгенерированно исключение, при конвертации типа или при вызове метода SomeMethod()? В нём ведь тоже может случиться неудачная конвертация, которую однако надо обрабатывать в другом месте.
Либо же надо заводить отдельную переменную.
B b = null;
try
{
  b = ((B)a);
}
catch(Exception e)
{
}
b.SomeMethod();

и это всё вместо
if (a is B)
{
 (a as B).SomeMethod();
}

Тут речь идёт уже не о красоте отдельного оператора, а о громоздкости кода вообще.


Одним из аргументов в пользу применения оператора as вместо приведения типов, является слова «в этом случая я могу доказать, что приведение всегда будет проходить успешно». Все мы люди и можем ошибиться, не учитывать каких-то еще не известных в данный момент нюансов, да и попросту могут произойти какие-то изменения.

Аргумент мимо кассы. Я уже говорил о некоторых внутрених контрактах. Я ничего не могу доказать, когда речь идёт о входных данных, но я могу сказать "Либо давайте мне корректные данные, либо идите на фиг".
Если as может вызвать NullReferenceException, то () InvalidCastException. В целом же, если вернутся к теме фреймворка и плагинов, то дело обстоит так. Сперва пишется приложение хостер и 1-2 важных плагина, потом уже все остальные. На момент написания большинства плагинов основное приложение уже написано. Так что это проблема плагина чтобы он был написан корректно и не валил основное приложение. Как я уже говорил поменять as на () в смысле удобства отладки шило на мыло. Зато любое непойманое исключение в готовой программе явно не вызовет восторга пользователя.


Расследование показало, что в данном программном модуле присутствовало целых семь переменных, вовлеченных в операции преобразования типов. Оказалось, что разработчики проводили анализ всех операций, способных потенциально генерировать исключение, на уязвимость. И это было их вполне сознательным решением – добавить надлежащую защиту к четырем переменным, а три – включая BH – оставить незащищенными. Основанием для такого решения была уверенность в том, что для этих трех переменных возникновение ситуации переполнения невозможно в принципе. Уверенность эта была подкреплена расчетами, показывающими, что ожидаемый диапазон физических полетных параметров, на основании которых определяются величины упомянутых переменных, таков, что к нежелательной ситуации привести не может. И это было верно – но для траектории, рассчитанной для модели Ariane 4. А ракета нового поколения Ariane 5 стартовала по совсем другой траектории, для которой никаких оценок не выполнялось. Между тем она (вкупе с высоким начальным ускорением) была такова, что "горизонтальная скорость" превзошла расчетную (для Ariane 4) более чем в пять раз.

Это мягко говоря неверная информация, хотя и достаточно популярная версия.
http://www.cs.unibo.it/~laneve/papers/ariane5rep.html
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[2]: As is или история о том как не надо писать код
От: dshe  
Дата: 17.08.05 07:44
Оценка: +2
Здравствуйте, adontz, Вы писали:

A>... Во-вторых, тут мягко говоря сгущены краски. Проблема тут вовсе не в операторе приведения типа, а в полном отсутствии документации. Если бы разработчик позаботился написать пару страниц на тему "Интерфейсы которые класс-плагин должен реализовать", а программист-жертва имел свободный доступ к этом документу, то проблемы бы просто не было. И если уж такое случилось, то надо не код менять, а писать к нему документацию.


К сожалению, документация -- не панацея. Просто потому, что часто она не адекватна; потому, что проверить ее адекватность так же сложно как и написать ее заново. Конечно, проблем бы не было, если бы в адекватной документации четким языком было написано что-то вроде: "Внимание, если вы используете этот код, то там, там и вот там у вы слокнетесь с такими граблями. Других граблей в коде нет." Но такое не пишут, потому что разработчики еще не знают о граблях, которые они расставляют. А если бы знали, то часто им было бы проще их убрать и ничего в документации не писать.

Что касается операторов as и (), то ошибки в обоих подходах проявляются в виде исключений. В одном случае в виде NullReferenceException, а в другом InvalidCastException. Но InvalidCastException проявится раньше и ближе к источнику ошибки, и, следовательно, ошибку легче будет исправить.
--
Дмитро
Re[2]: As is или история о том как не надо писать код
От: fuurin  
Дата: 17.08.05 08:52
Оценка: 1 (1)
A>и это всё вместо
A>
A>if (a is B)
A>{
A> (a as B).SomeMethod();
A>}
A>


Неправильные, дядя Фёдор, у вас бутерброды. Испокон веков fxcop учит нас писать
B b = a as B;
if( b != null )
  b.SomeMethod();


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

Предлагаю внести в фак и забыть:

Правила:
1. Если необходимо реализовать дополнительную логику работы с объектом, приведеным к другому типу, то используется оператор as:

X x = o as X;
if( x == null )
  return;
x.DoWork();

2. Если необходимо проверить, является ли объект определённого типа, но нет необходимости работать с приведеным объектом, то используется оператор is:
if( o is X )
  SomeLogic();

3. И наконец, если с объектом нужно работать только как с объектом определённого типа, то используется оператор приведения ():
X x = (X)o;
x.DoWork();


Исключения:
4. Value-типы не поддерживают оператор as, поэтому вместо (1) используется комбинация (2) и (3):
if( v is X )
  ((X)v).DoWork();

5. Оператор as не поддерживает приведения типов, определённые пользователем.


Все доводы по эстетике, читабельности и быстродействию идут лесом. И попробуйте меня сбить с пути истинного
Garbage In Garbage Out
Re[3]: As is или история о том как не надо писать код
От: adontz Грузия http://adontz.wordpress.com/
Дата: 17.08.05 09:57
Оценка: 1 (1) -1 :)
Здравствуйте, fuurin, Вы писали:

F>Предлагаю внести в фак и забыть:

F>Правила:
F>1. Если необходимо реализовать дополнительную логику работы с объектом, приведеным к другому типу, то используется оператор as:
F>2. Если необходимо проверить, является ли объект определённого типа, но нет необходимости работать с приведеным объектом, то используется оператор is:
F>3. И наконец, если с объектом нужно работать только как с объектом определённого типа, то используется оператор приведения ():
F>4. Value-типы не поддерживают оператор as, поэтому вместо (1) используется комбинация (2) и (3):

F>Все доводы по эстетике, читабельности и быстродействию идут лесом. И попробуйте меня сбить с пути истинного

Вот будь в статье написано что-то вроде этого она была бы полезной. А так получился наезд на as с попутным унижением С++ Идея на пять, а вот реализация на трояк.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: As is или история о том как не надо писать код
От: adontz Грузия http://adontz.wordpress.com/
Дата: 17.08.05 10:06
Оценка: +1 -1
Здравствуйте, dshe, Вы писали:

D>Что касается операторов as и (), то ошибки в обоих подходах проявляются в виде исключений. В одном случае в виде NullReferenceException, а в другом InvalidCastException. Но InvalidCastException проявится раньше и ближе к источнику ошибки, и, следовательно, ошибку легче будет исправить.


К сожалению это миф. На деле это будет ближе, но как 999 и 1000 метров. Один хрен киллометр шагать надо.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: As is или история о том как не надо писать код
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.08.05 11:16
Оценка:
Здравствуйте, fuurin, Вы писали:

F>2VladD:

F>Статью прочитал и забыл, уж много там воды не по теме. Но разобраться в вопросе использования операторов она таки заставила, спасибо.

Пожалуй это главное. Значит цель достигнута. Просто верить авторитету — это не верный подход. Нужно именно что вникать.

F>Предлагаю внести в фак и забыть:...


+1
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: As is или история о том как не надо писать код
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.08.05 11:16
Оценка:
Здравствуйте, adontz, Вы писали:

A>Вот будь в статье написано что-то вроде этого она была бы полезной. А так получился наезд на as с попутным унижением С++ Идея на пять, а вот реализация на трояк.


Творички мыслящий челове скорее воспротивится от такого запихивания правил без объяснений. Но одно другому не мешает. Можно сделать ФАК и дать на него ссылку из статьи (и на оборот).
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: As is или история о том как не надо писать код
От: Soul Россия  
Дата: 20.09.06 11:57
Оценка: +1
Здравствуйте, Владислав Чистяков (VladD2), Вы писали:

ВЧV>Статья:

ВЧV>As is или история о том как не надо писать код
Автор(ы): Владислав Чистяков (VladD2)
Дата: 18.12.2004
Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.




ВЧV>Авторы:

ВЧV> Владислав Чистяков (VladD2)

ВЧV>Аннотация:

ВЧV>Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.


Вопрос: по-моему, оператор is возможно применять не только к ссылочным типам или я не права?
"Следует упомянуть, что операторы as и is предназначены для приведения типов ссылок, т.е. для работы исключительно со ссылочными типами данных."

Спасибо за статью.
Soul
Re[2]: As is или история о том как не надо писать код
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.09.06 13:59
Оценка:
Здравствуйте, Soul, Вы писали:

S>Вопрос: по-моему, оператор is возможно применять не только к ссылочным типам или я не права?


Прав. Это я тут по контексту нечаяно написал. "is" прекрасно работает с влэью-типами если они забоксены. Чего нельзя сказать о as.

S>"Следует упомянуть, что операторы as и is предназначены для приведения типов ссылок, т.е. для работы исключительно со ссылочными типами данных."


S>Спасибо за статью.


Пожалуйста.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: As is или история о том как не надо писать код
От: Константин Л. Франция  
Дата: 20.09.06 16:46
Оценка:
Здравствуйте, Владислав Чистяков (VladD2), Вы писали:

ВЧV>Статья:

ВЧV>As is или история о том как не надо писать код
Автор(ы): Владислав Чистяков (VladD2)
Дата: 18.12.2004
Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.




ВЧV>Авторы:

ВЧV> Владислав Чистяков (VladD2)

ВЧV>Аннотация:

ВЧV>Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

ну ниче статейка, только можно было покороче. Еще смущает обложка журнала — неужели такая банальность заслуживает чтобы красоваться на обложке, да еще и зачеркнутой?
Ничего серьезнее не нашел?
А вообще тут
Автор: fuurin
Дата: 17.08.05
товарисчь привел хорошую инструкцию по этому поводу.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.