Re[8]: Оцените код - C/C++

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

АУ>>Мне больше всего "резал" глаза отрицательный индекс [-1]. Теперь, когда стало понятно, что это работа не с системным стеком/кучей, а со "своими" структурами, режет еще больше. Все остальное по сравнению с этим моментом — косметика и легко исправляется.

N>Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по отрицательному индексу может обломаться из-за какой-нибудь встроенной защиты памяти. Видимо, есть на свете такие архитектуры. Вывод такой — код непереносим, хотя на персоналке в обозримом будущем и настоящем будет работать.

это для embedded

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

S>>>Здравствуйте, slavo.

S>>Чужой код вы выставили на всеобщее обозрение !
S>>Так может будите любезны показать теперь свой вариант ? или очкуете ?

S>во-первых, мне некогда этим заниматься. у меня своя работа.

писать по 20 сообщений в "Оцените код" в день

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

S>какой код ты от меня требуешь?
естественно выполняющий теже ф-ии. Казалось бы это очевидно. Многие спрашивают и не получают ответа. Где Ваш код?

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

LMA>Так как ты переходишь на откровенное хамство разговор продолжать дальше смысла не вижу.

Да ладно, чего не скажешь в пылу спора

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

Но если смысл кода действительно важен для осознания истинности этого высказывания:

Что касается первого из приведенных Вами антипаттернов, то тут мы имеем дело с величинами, знакомыми каждому, поэтому нет смысла использовать именованные константы.

То я с удовольствием послушаю твою трактовку того, что этот код делает.

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

LMA>>Я нахожу имя DEBUG_ERROR_MARK крайне плохим с точки зрения самодокументирования для константы 0xfdfdfdfd.

S>это хорошее имя. любой ассист его подсветит и покажет реальное значение. а 0xfdfdfdfd — это бардак

Тогда поделитесь какой великой смысл Вы видете за именем DEBUG_ERROR_MARK, кроме абстрактного какой-то-признак-ошибки-для-отладки?

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

S>имена-дефайны лучше чем константы, потому что они говорят о назначении константы. и любой ламер, увидев это в коде получает больше информации, чем просто 0xfdfdfdfd. И это более документированный код.

имена-дефайны лучше чем константы, ЕСЛИ они говорят о назначении константы.

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

S>во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?

Простите, но Вы батенька позер. Так дела не делаются, покажите уж будьте любезны мастерство рефакторинга, время думаю у вас есть, как тут заметили (писать по 20 постов в день).

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

S>Здравствуйте, slavo, Вы писали:
S>Простите, но Вы батенька позер. Так дела не делаются

Да, да, да.
Судя по скудным односложным ответам slavo, — ему уже давно стало стыдно за создание этой темы.
И ведь ничего конкретного не сказал! Заэпатировал публику и всё...

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

S>>Чужой код вы выставили на всеобщее обозрение !
S>>Так может будите любезны показать теперь свой вариант ? или очкуете ?

S>во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?

Баг искать надо. Но и отлавливать ненайденные баги тоже не помешает.

Здесь

int main()
{
   try
   {
      MainFun();
   }
   catch(...)
   {
      AddErrorToLog();
   }
}

надо найти баг в MainFun. Но try-catch всё-равно лучше оставить.

LordMAD wrote:

> лишний. Это только доказывает, что имена для констант тебе не помогают
> понять о чем тут речь и тебя просто следует держать от такого кода
> подальше (прав я был, когда о Пете писал).

Безусловно, ты был прав.

А можно для "Пети" озвучить, что же означают эти константы ?
Я, в отличие от тебя, в основном, (если работаю с С++) работаю с VC.
Может и пригодится когда.

Posted via RSDN NNTP Server 2.1 beta

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

MZ>Чем вам это режет глаза отрицательный индекс массива ?

Тем, что это, возможно (см.ниже), выход за его границы.

MZ>В определённой ситуации — вполне нормально.

Ну, тогда и все остальное в этом фрагменте кода — тем более вполне нормально.

MZ>Оно конечно, я бы так не делал, но язык вовсе не запрещает.

Ну, вот одна из "официальных" ссылок:

http://msdn.microsoft.com/en-us/library/59682zc4(VS.80).aspx

P.S. Да, а кто вообще сказал, что речь идет о простом массиве, а не std::vector или std::valarray?

noodles wrote:

> Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по
> отрицательному индексу может обломаться из-за какой-нибудь встроенной
> защиты памяти. Видимо, есть на свете такие архитектуры. Вывод такой —
> код непереносим, хотя на персоналке в обозримом будущем и настоящем
> будет работать.

Чего ? Кто такое сказал-то ?

sometype* base = ...;

base[i];

означает то же, что и

base + i;

Почему же i не может быть отрицательным ?
А будет это работать или нет, зависит целиком от инициализации base.
Никаких правил или ограничений тут быть не может.

Posted via RSDN NNTP Server 2.1 beta

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

if( (int)ici_os.a_top[-1] == 0xfdfdfdfd || *(int*)ici_os.a_top[-1] == 0xcccccccc ) )

1. Константы знакомы

только в "том" окошке буковки большие, 0xFDFDFDFD (друг Федя) и 0xCCCCCCCC (муха ЦеЦе) привычнее
2. Опечатка — скобка лишняя справа
3. (int)ici_os.a_top[-1] != 0xfdfdfdfd недостаточно для того, чтобы можно было безопасно * его дальше

>> Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по
>> отрицательному индексу может обломаться из-за какой-нибудь встроенной
>> защиты памяти. Видимо, есть на свете такие архитектуры.

MZ>Чего ? Кто такое сказал-то ?

Я же написал. The C++ Programming Language, Third Edition, Bjarne Stroustrup. Упоминается такое в паре мест.

MZ>Никаких правил или ограничений тут быть не может.

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

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

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

>>> Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по
>>> отрицательному индексу может обломаться из-за какой-нибудь встроенной
>>> защиты памяти. Видимо, есть на свете такие архитектуры.

MZ>>Чего ? Кто такое сказал-то ?

N>Я же написал. The C++ Programming Language, Third Edition, Bjarne Stroustrup. Упоминается такое в паре мест.

ты бы цитату привел, Старуструп большой

вот пример корректного отрицательного индекса

int a[10];
int *b = &a[1];
int x = b[-1];

это нельзя a[-1]; но по тексту неясно как псе это описано. так что выводы делать рано

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

MZ>base[i];
MZ>означает то же, что и
MZ>base + i;

Вот что говорит об этом д-р Страуструп (это его ответ Сергею Деревяго):

It is a surprise to most experienced C and C++ programmers that &vc1[200] isn't completely equivalent to vc1+200. In fact, it was a surprise to the C committee also and I expect it to be fixed in the upcoming revision of the standard. (also resolved for C9x — bs 10/13/98)

Так в чем же нарушается эквивалентность? По стандарту C++ мы имеем следующие эквивалентные преобразования:

&vc1[200] -> &(*((vc1)+(200))) -> &*(vc1+200)

Действительно ли равенство &*(vc1+200) == vc1+200 неверно?

Страуструп (там же):

It is false in C89 and C++, but not in K&R C or C9x. The C89 standard simply said that &*(vc1+200) means dereference vc1+200 (which is an error) and then take the address of the result, and the C++ standard copiled the C89 wording. K&R C and C9x say that &* cancels out so that &*(vc1+200) == vc2+200.

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

MZ>А можно для "Пети" озвучить, что же означают эти константы ?
MZ>Я, в отличие от тебя, в основном, (если работаю с С++) работаю с VC.
MZ>Может и пригодится когда.
Memory Debug Codes

Microsoft Visual C++ Runtime library
0xFD, 0xFDFDFDFD — No-man's land memory. Extra bytes that belong to the internal block allocated, but not the block you requested. They are placed before and after requested blocks and used for data bound checking.

Compiler initialisations
0xCC, 0xCCCCCCCC — The /GX Microsoft Visual C++ compiler option initialises all local variables not explicitly initialised by the program. It fills all memory used by these variables with 0xCC, 0xCCCCCCCC.

N>>The C++ Programming Language, Third Edition, Bjarne Stroustrup. Упоминается такое в паре мест.

СМ>ты бы цитату привел, Старуструп большой

Стр.92

"Taking a pointer to the element one beyond the end of an array is guaranteed to work. This is
important for many algorithms (§2.7.2, §18.3). However, since such a pointer does not in fact point
to an element of the array, it may not be used for reading or writing. The result of taking the
address of the element before the initial element is undefined and should be avoided. On some
machine architectures, arrays are often allocated on machine addressing boundaries, so ‘‘one before
the initial element’’ simply doesn’t make sense."

Интересно, что это учитывается в реализации обратных итераторов reverse_iterator<Iter>, стр.557.

СМ>это нельзя a[-1]; но по тексту неясно как псе это описано. так что выводы делать рано

Согласен. Делать выводы по тому куску кода скорополительно. Признаю. Но проверять нужно.

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

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Здравствуйте, slavo, Вы писали:

S>>во-первых, мне некогда этим заниматься. у меня своя работа.

СМ>писать по 20 сообщений в "Оцените код" в день

ты чо, думаешь, что писать в форум и писать код это одно и то же?

S>>во-вторых, этот код надо убирать и искать сам баг.
СМ>Как я понимаю, это интерпритатор, и может он так интерпретирует стек выполнения, только сообщение должно быть "использование неиниц. переменной". Без знания задачи можер говорить только о стиле.

S>>какой код ты от меня требуешь?
СМ>естественно выполняющий теже ф-ии. Казалось бы это очевидно. Многие спрашивают и не получают ответа. Где Ваш код?

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

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

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

LMA>>>Я нахожу имя DEBUG_ERROR_MARK крайне плохим с точки зрения самодокументирования для константы 0xfdfdfdfd.

S>>это хорошее имя. любой ассист его подсветит и покажет реальное значение. а 0xfdfdfdfd — это бардак

LMA>Тогда поделитесь какой великой смысл Вы видете за именем DEBUG_ERROR_MARK, кроме абстрактного какой-то-признак-ошибки-для-отладки?

Это имя хорошо уже тем, что оно — имя. И это имя можно поменять. Я не говорю, что DEBUG_ERROR_MARK идеально.

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

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

S>>имена-дефайны лучше чем константы, потому что они говорят о назначении константы. и любой ламер, увидев это в коде получает больше информации, чем просто 0xfdfdfdfd. И это более документированный код.

LMA>имена-дефайны лучше чем константы, ЕСЛИ они говорят о назначении константы.

я не спорю. не надо меня учить.

	От:	slavo
	Дата:	09.09.08 03:24
	Оценка:

	От:	Сергей Мухин
	Дата:	09.09.08 04:05
	Оценка:	4 (1) +2

	От:	ancient
	Дата:	09.09.08 05:07
	Оценка:

	От:	LordMAD
	Дата:	09.09.08 05:12
	Оценка:

	От:	LordMAD
	Дата:	09.09.08 05:13
	Оценка:

От:	Stormblast	http://www.myspace.com/stormblastblack
Дата:	09.09.08 05:17
Оценка:	+1

	От:	Андрей Ушаков
	Дата:	09.09.08 07:47
	Оценка:

От:	SergeCpp	http://zoozahita.ru
Дата:	09.09.08 08:07
Оценка: