Re[7]: Детские ошибки - Коллеги, улыбнитесь

Здравствуйте, <Аноним>, Вы писали:

А>Хм, случай не редкий, но чтоб два дня....

Потому и запомнился.
Я тогда с отладчиком почти не дружил, а когда смотрел листинг этого участка, почему-то видел на одну команду больше

<< точка сборки в — — — Track 4 |>>

Здравствуйте все!

Я вчера вот такое написал. Кто увидит ошибку не подглядывая в репозиторий поднимите руку

        public IList ExecuteScalarList(IList list, Type type, NameOrIndexParameter nip)
        {
            if (_prepared)
                InitParameters(CommandAction.Select);

            //object nullValue = _mappingSchema.GetNullValue(type);

            using (IDataReader dr = ExecuteReaderInternal())
            {
                while (dr.Read())
                {
                    object value = dr.GetValue(nip.ByName ?
                        dr.GetOrdinal(nip.Name) : nip.Index);

                    if (value == null || value.GetType() != type)
                        value = value is DBNull? null: Convert.ChangeType(value, type);

                    list.Add(value);
                }
            }

            return list;
        }

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

Утром сначала поправил, потом только за кофе взялся.

... << RSDN@Home 1.2.0 alpha rev. 642>>

Здравствуйте, ekamaloff, Вы писали:

ZS>>Вам нравятся эти операторы? И же выведет такой код? И почему?
ZS>>

ZS>>    int i = 2;
ZS>>    i += i--;
ZS>>    printf("%d", i);
ZS>>

E>Тут кажись неопределенное поведение — двойная модификация переменной между точками следования. А вообще за такой код руки надо отрывать а не приводить в качестве примера.

Почему неопределённое? Есть чётко прописанный приоритет операторов и порядок их выполнения. Здесь порядок — справа налево: сначала вычисление i, потом уменьшение i на единицу, потом прибавление к новому значению этой переменной её значения старого, перед декрементом. Итого, в результате, получится 3.
А код, да. Не для практики, а из серии задач для олимпиад по информатике.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, fmiracle, Вы писали:

F>Да еще и неправильный коммент?

Коммент-то как раз правильнй, это код не правильный.

Здравствуйте, Xander Zerge, Вы писали:

XZ>Почему неопределённое? Есть чётко прописанный приоритет операторов и порядок их выполнения. Здесь порядок — справа налево: сначала вычисление i, потом уменьшение i на единицу, потом прибавление к новому значению этой переменной её значения старого, перед декрементом. Итого, в результате, получится 3.

Я вообще-то не совсем уверен в своей правоте

, но советую посмотреть здесь:

http://rsdn.ru/search/?q=(UB|undefined behaviour|неопределенное поведение) модификация точки следования&mode=rank&group=N&group=9

Если совсем припрет, можно задать этот вопрос в C/C++, там разберутся

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

F>Причем тут русский?
F>Нахрена коммент к коду, который сам себя документирует?

F>Да еще и неправильный коммент?

В том-то и дело! На русском — значит, индус не поймёт. Как сам коммент, так и (естественно) то, что он — неправильный. Поэтому он не поймёт ничего, кроме этого самодокументированного кода, а в нём ошибки-то как раз нет!

... << RSDN@Home 1.2.0 alpha rev. 651>>

Vi2>Здравствуйте, fmiracle, Вы писали:

F>>Да еще и неправильный коммент?

Vi2>Коммент-то как раз правильнй, это код не правильный.

Ну здрасте!

В приведенном фрагменте есть две части — присвоение Х значения -5 и комметарий, что это не присвоение, а уменьшение. Соответственно, любой и них может быть неправильным!

Признаю — в данном тексте код имеет больше шансов оказаться неправильным, но абсолютно точно это ниоткуда не следует

Так что не надо!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

поднимаю —

Интересная проверка на null

Да лана там — все время от времени чего-нить подобное ляпнут.
Причем на любом языке...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

ZS>На васике нет неоднозначностей, на C++ — есть. Я хотел сказать это. На васике выражение a+++b трактуется всегда однозначно.

Вам уже дважды повторили — что васиков много.
Если рассмотреть, например, VB6

то вот эти конструкции :

w = provider.GetWriter( "test" )
и
SET w = provider.GetWriter( "test" )

довели до безумия немало народу...

Самый обычный пример, случается регулярно.
А вот примеры типа i = --(++i — i++)++ — это все же больше забава, а не реальное использование.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Аноним, Вы писали:

А>

А>    x =- 5; // уменьшаем x на 5
А>

А>Кто видит здесь ошибку без отладчика, поднимите руку.

Насколькоя я знаю, в изначальном C (или B) именно так эти операторы и записывались. Так что, все правильно

Компилятор у тебя просто слишком новый

Здравствуйте, Sergei, Вы писали:

S>Здравствуйте, ZevS, Вы писали:

S>++ += и т.п. особенно префиксные иногда полезны (например, для оптимизции), если они работают с пользовательскими объектами (например, string);

Пример такой оптимизации в студию!

PS: я бы 10 (десять) раз подумал прежде чем перегружать какие бы то ни было операторы в пользовательском типе...

Здравствуйте, kan_izh, Вы писали:

_>ZevS wrote:

>> Кстати, почитайте статью Вирта в последнем RSDN-е. Интересная статейка.
_>Странная у него там критика. Теоретик он. Не принимает простое правило "если это глупо, но работает, значит это не глупо".

В ходе этой дискуссии почему-то получается так что я говорю об операторах ++ -- , а мне отвечают в том духе что С++ лучше всех. С++ безусловно круче чем VB, Java, весь .NET, Prolog, Lisp и др. вместе взятые. Закрыли тему — глупая она.

По существу, есть у вас что-либо в защиту именно этих операторов?

зыЖ Я уверен более чем на 90% что если вы загляните в свой собственный код, то не увидите эти операторы где-либо, кроме как в заголовке цикла for.

Здравствуйте, ansi, Вы писали:

A>Насколькоя я знаю, в изначальном C (или B) именно так эти операторы и записывались. Так что, все правильно

Компилятор у тебя просто слишком новый

А как записывалось присвоение отрицательного значения?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, ZevS, Вы писали:

ZS>Здравствуйте, Sergei, Вы писали:

S>>Здравствуйте, ZevS, Вы писали:

S>>++ += и т.п. особенно префиксные иногда полезны (например, для оптимизции), если они работают с пользовательскими объектами (например, string);

ZS>Пример такой оптимизации в студию!

Например, при работе с итераторами

for(<Type>::iterator it=...begin();it!=..end();++it)
...

На самом деле не известно что за объект (какого размера) iterator и делать лишнюю копию незачем(что произошло бы если использовали it=it+1 или it++)...

Здравствуйте, Аноним, Вы писали:

А>

А>    x =- 5; // уменьшаем x на 5
А>

А>Кто видит здесь ошибку без отладчика, поднимите руку.

Я, а дальше что ?

Здравствуйте, Sergei, Вы писали:
...

S>Например, при работе с итераторами

S>

S>for(<Type>::iterator it=...begin();it!=..end();++it)
S>...

S>

S>На самом деле не известно что за объект (какого размера) iterator и делать лишнюю копию незачем(что произошло бы если использовали it=it+1 или it++)...

А чем это лучше чем

  it.Increment();

Здравствуйте, ZevS, Вы писали:

ZS>Здравствуйте, Sergei, Вы писали:
ZS>...

S>>Например, при работе с итераторами

S>>

S>>for(<Type>::iterator it=...begin();it!=..end();++it)
S>>...

S>>

S>>На самом деле не известно что за объект (какого размера) iterator и делать лишнюю копию незачем(что произошло бы если использовали it=it+1 или it++)...

ZS>А чем это лучше чем

ZS>

ZS>  it.Increment();
ZS>

Да это выход, но если iterator вдруг станет int, то придется перелапачивать вес код...

А>>

А>>    x =- 5; // уменьшаем x на 5
А>>

А>>Кто видит здесь ошибку без отладчика, поднимите руку.

AW>Ща запинаете, НО... на Паскале такая хрень даже компиляцию не пройдет!!!

Вот за это я и не люблю паскакаль, что приходится писать

yyval[yypv[p3+p4] + yypv[p1+p2]] = yyval[yypv[p3+p4] + yypv[p1+p2]] + 2;

Vi2>>Коммент-то как раз правильнй, это код не правильный.

F>Ну здрасте!

F>В приведенном фрагменте есть две части — присвоение Х значения -5 и комметарий, что это не присвоение, а уменьшение. Соответственно, любой и них может быть неправильным!

Умникус? Ты сам это разобрал или сначала прочитал все ответы?

F>Признаю — в данном тексте код имеет больше шансов оказаться неправильным, но абсолютно точно это ниоткуда не следует

Это следует из названия темы, в которой расположено письмо.

ZS>По существу, есть у вас что-либо в защиту именно этих операторов?

yyval[yypv[p3+p4] + yypv[p1+p2]] = yyval[yypv[p3+p4] + yypv[p1+p2]] + 2;

ZS>зыЖ Я уверен более чем на 90% что если вы загляните в свой собственный код, то не увидите эти операторы где-либо, кроме как в заголовке цикла for.

	От:	Skleroz
	Дата:	01.06.06 23:19
	Оценка:

	От:	Блудов Павел
	Дата:	02.06.06 02:07
	Оценка:

От:	Xander Zerge	www.zerge.com
Дата:	02.06.06 04:03
Оценка:	-1

От:	Vi2	http://www.adem.ru
Дата:	02.06.06 04:08
Оценка:

	От:	ekamaloff
	Дата:	02.06.06 04:18
	Оценка: