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

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

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

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

LMA>>>Правильно ли я понимаю, что Вы считаете, что имя MAGIC_NUMBER_1 лучше, чем 0xfdfdfdfd ?

S>>не MAGIC_NUMBER_1, а осмысленно имя

LMA>Я просто хочу понять: где Вы видите ту грань между какой-то-признак-ошибки-для-отладки и магическое-число-1 ? Оба имени ничего полезного, по сути, не сообщают, но первое имя Вам не нравится, а второе — нравится.

имя какой-то-признак-ошибки-для-отладки говорит хоть что-то, имя MAGIC_NUMBER_1 вообще ничего не говорит и может конфликтовать или быть похожим на другое аналогичное имя для другого значения.
Еще аргумент в пользу именования (дефайнами или константами) таких значений — это то, что наткнувшись в коде на подобное имя, можно посмотреть, где оно объявлено и там же, в одном месте на весь проект, прочитать к этому имени подробное описание на человеческом языке.

В мелких проектах это может быть и не так важно, но это очень удобно и правильно, когда над громадным проектом работают десятки людей и часто приходят новые люди, либо разным людям приходится читать чужой код. Если такая культура именования всяких констант и их подробное описание будет соблюдаться, то новичку будет легче соориентироваться в проекте, кроме того, он будет вынужден соблюдать эту культуру и не засорять код магическими числами, чистота кода будет выше. И если кто-то знает о смысле значения, например, 0xfdfdfdfd, то сделав его дефайном или константой, и описав это значение в месте объявления дефайна, он сэкономит очень много времени тем, кто по каким-то причинам еще не знает о смысле этого значения. И тем самым сделает доброе дело своим сотрудникам. И они ему еще спасибо скажут.

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

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

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

SC>>if( (int)ici_os.a_top[-1] == 0xfdfdfdfd || *(int*)ici_os.a_top[-1] == 0xcccccccc ) )
SC>>3. (int)ici_os.a_top[-1] != 0xfdfdfdfd недостаточно для того, чтобы можно было безопасно * его дальше

C> если выполнилось первое условие — второе не проверяется

Условимся для простоты: ici_os.a_top[-1] — это z

Тогда имеем: if( (int)z == 0xfdfdfdfd || *(int*)z == 0xcccccccc )

Допустим, что z == 0 (к примеру)

Тогда: первое условие ( (int)z == 0xfdfdfdfd ) не выполняется, проверяется следующее: ( *(int*)z == 0xcccccccc ) или ( *(int*)0 == 0xcccccccc )

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

SC>Здравствуйте, carpenter!

SC>>>if( (int)ici_os.a_top[-1] == 0xfdfdfdfd || *(int*)ici_os.a_top[-1] == 0xcccccccc ) )
SC>>>3. (int)ici_os.a_top[-1] != 0xfdfdfdfd недостаточно для того, чтобы можно было безопасно * его дальше

C>> если выполнилось первое условие — второе не проверяется

SC>Условимся для простоты: ici_os.a_top[-1] — это z

SC>Тогда имеем: if( (int)z == 0xfdfdfdfd || *(int*)z == 0xcccccccc )

SC>Допустим, что z == 0 (к примеру)

SC>Тогда: первое условие ( (int)z == 0xfdfdfdfd ) не выполняется, проверяется следующее: ( *(int*)z == 0xcccccccc ) или ( *(int*)0 == 0xcccccccc )

дык это ... а я что против

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

LMA>>Я просто хочу понять: где Вы видите ту грань между какой-то-признак-ошибки-для-отладки и магическое-число-1 ? Оба имени ничего полезного, по сути, не сообщают, но первое имя Вам не нравится, а второе — нравится.

S>имя какой-то-признак-ошибки-для-отладки говорит хоть что-то, имя MAGIC_NUMBER_1 вообще ничего не говорит

А кому нужно имя, которое "говорит хоть что-то"? Вы либо понимаете для чего константа (и в этом случае, можете тестировать, править и т.д. код), либо не понимаете. В последнем случае, Вы будете гарантированно тратить время на то, чтобы разбираться в этом. И Вам такое имя нравится, как Вы писали выше! Вы начали эту ветку с того, что привели пример плохого, как Вам кажется, кода, насколько я понимаю. Вы сами можете видеть по сообщениям в этой ветке, сколько людей сразу поняли назначение констант, и Вы после этого считаете, что имя какой-то-признак-ошибки-для-отладки было бы более понятным вариантом? То есть пусть лучше всем назначение константы будет не понятно (лишь намек в имени такой константы — типа куда копать), чем лишь некоторым оно будет понятно, а другим не понятно и без намеков?

S> и может конфликтовать или быть похожим на другое аналогичное имя для другого значения.

Вы считаете, что имя DEBUG_ERROR_MARK не может конфликтовать или быть похожим на другое имя?

Кстати, интересно, если DEBUG_ERROR_MARK == 0xfdfdfdfd, то какое имя будет для 0xcccccccc ?

S>Еще аргумент в пользу именования (дефайнами или константами) таких значений — это то, что наткнувшись в коде на подобное имя, можно посмотреть, где оно объявлено и там же, в одном месте на весь проект, прочитать к этому имени подробное описание на человеческом языке.
S>В мелких проектах это может быть и не так важно, но это очень удобно и правильно, когда над громадным проектом работают десятки людей и часто приходят новые люди, либо разным людям приходится читать чужой код. Если такая культура именования всяких констант и их подробное описание будет соблюдаться, то новичку будет легче соориентироваться в проекте, кроме того, он будет вынужден соблюдать эту культуру и не засорять код магическими числами, чистота кода будет выше. И если кто-то знает о смысле значения, например, 0xfdfdfdfd, то сделав его дефайном или константой, и описав это значение в месте объявления дефайна, он сэкономит очень много времени тем, кто по каким-то причинам еще не знает о смысле этого значения. И тем самым сделает доброе дело своим сотрудникам. И они ему еще спасибо скажут.

Проблема в том, что в данном конкретном случае, именование константы не сделает код читабельнее для всех — оно сделает код читабельнее для одних и менее читабельным для других.

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

Про то, как Вы планируете сказать MS VS, чтобы оно писало в память не эти константы, а другие, потому что в if Вы будете сравнивать его с другим значением — пожалуйста поподробнее. Ваши доводы, возможно, имели бы смысл, если бы в коде эти значения использовались бы несколько раз.

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

LMA>То есть пусть лучше всем назначение константы будет не понятно (лишь намек в имени такой константы — типа куда копать), чем лишь некоторым оно будет понятно, а другим не понятно и без намеков?

LMA>Вы считаете, что имя DEBUG_ERROR_MARK не может конфликтовать или быть похожим на другое имя?

LMA>Кстати, интересно, если DEBUG_ERROR_MARK == 0xfdfdfdfd, то какое имя будет для 0xcccccccc ?

LMA>Проблема в том, что в данном конкретном случае, именование константы не сделает код читабельнее для всех — оно сделает код читабельнее для одних и менее читабельным для других.

Дефаны должны быть такими (либо константы):

// The constant 0xccccccccc is used inside MSVS to indicate........  
// ...
// ...
#define _CCCCCCCC_ 0xcccccccc

// The constant 0xfdfdfdfd is used inside MSVS to indicate........  
// ...
// ...
#define _FDFDFDFD_ 0xfdfdfdfd

все. это решает и проблему читаемости и позволяет описать значение в одном месте и сменить ради экперимента. На 95% это может и не понадобится, но если понадобится, то будет поздно:
S>>Далее, если в какой-то момент вы захотите сменить значение константы, то вы сможете это сделать в одном месте. Даже если это значение всем известное и как-будто бы никогда не меняющееся, может возникнуть необходимость сменить значение ради какого-то эксперимента.
LMA>Про то, как Вы планируете сказать MS VS, чтобы оно писало в память не эти константы, а другие, потому что в if Вы будете сравнивать его с другим значением — пожалуйста поподробнее. Ваши доводы, возможно, имели бы смысл, если бы в коде эти значения использовались бы несколько раз.

LordMAD wrote:

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

Читаю вашу переписку и вспоминается отличный анкедот:

Два приятеля обсуждают программирование. Оба сходятся на том, что все константы в коде должны быть именованы и определены где-то во вне. В качестве примера один из них показывает свою недавнюю работу. Второй справшивает
— А что это за const int N_DIMESSION = 2?
— Размерность дисплея...

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

MZ>Я не понял, почему это "dereference vc1+200 ... is an error".

Видимо, предполагается

some vc1[200];

MZ>И я не понял, почему это они не могут взаимо компенсировать & и *.
Потому что перегрузка?
Можно было бы компенсировать только если нет перегрузки.
Но что если:

some * operator & () throw() { return this; }
some const * operator & () const throw() { return this; }

?

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

S>Что делать с сотрудником, который написал такой код?
S>

S>if((int)ici_os.a_top[-1] == 0xfdfdfdfd || *(int*)ici_os.a_top[-1] == 0xcccccccc))
S>{
S>  ici_error = "stack error";
S>  goto fail;
S>}
S>

Как я понял автор "подсмотрел" код коллеги, который не является его подчинёным, и спрашивает "Что делать с таким сотрудником".
Извините за вопрос — но что вы можете сделать с сотрудником не являющимся в вашем подчинении? Пойти и постучать его начальнику о том какой тот херовый кодер?

Ещё я также понял что автор кода скопировал его изменив 1 символ — а это означает что код был скопипастен с этого-же проекта.
Кто был изначальным автором данного кода?

Я думаю — вы просто злы на хорошего программиста и таким образом удовлетворяете чувство собственного достоинства. Тк паттерны/антипаттерны это всё становится равным нулю когда проект рушится с треском, я видел десятки проектов написанных по паттернам но кривыми руками, когда погоня в борьбе с антипаттернами приводила к краху, и вы мне напоминаете имено того человека который это всё интегрировал(Cedric Templie)

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

V>Читаю вашу переписку и вспоминается отличный анкедот:

V>

V>Два приятеля обсуждают программирование. Оба сходятся на том, что все константы в коде должны быть именованы и определены где-то во вне. В качестве примера один из них показывает свою недавнюю работу. Второй справшивает
V>- А что это за const int N_DIMESSION = 2?
V>- Размерность дисплея...

Смешно, потому что правда

Предлагаю проголосовать в специально созданном по этой теме голосовании.

А вы заметили что минусы в пред постах поставил один свало, он похоже обиделся тут на всех ))
не обижайся свало, ты крутой оценщик кода а главное на все посты ответил железными аргументами ))

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

А>А вы заметили что минусы в пред постах поставил один свало, он похоже обиделся тут на всех ))
А>не обижайся свало, ты крутой оценщик кода а главное на все посты ответил железными аргументами ))

а ты точно хорошо посмотрел?

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

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

А>>А вы заметили что минусы в пред постах поставил один свало, он похоже обиделся тут на всех ))
А>>не обижайся свало, ты крутой оценщик кода а главное на все посты ответил железными аргументами ))

А>а ты точно хорошо посмотрел?

Да, всем кто был против него поставил минусы только он. (Может быть и есть где то исключения, я глянул в 15 последних)

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

А>Как я понял ...
А>Ещё я также понял...
А>Я думаю ...

угомони свое воспаленное воображение
отлаживать прострел стека — заоблачный успех

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

D>Предлагаю проголосовать в специально созданном по этой теме голосовании.

А чего же не дали возможности свой вариант ответа вводить?

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

M>Ну на счёт мэджиков понятно — "слышал звон, да не знает где он", "главное успеть к релизу", ... .
M>Интересно вот что: почему [-1] ??? Ведь там же что угодно может быть без всяких расстрелов. Или там ДОЛЖНЫ лежать нормальные данные?
Ничего ты не понял насчет мейджиков Этими магическими числами студийный компилятор заполняет память ДО выделенного куска, причем только в ДЕБАГЕ. Надеюсь теперь про -1 понятно?

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

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

D>>Предлагаю проголосовать в специально созданном по этой теме голосовании.

LMA>А чего же не дали возможности свой вариант ответа вводить?

Думал, что постановка вопроса не предполагает вариаций Исправил.

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

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

D>>>Предлагаю проголосовать в специально созданном по этой теме голосовании.

D>Думал, что постановка вопроса не предполагает вариаций Исправил.

вопрос не очень корректный "Является ли строгой необходимостью использование в программах, создаваемых и поддерживаемых усилиями значительного числа людей, именованных сущностей вместо любых константных выражений в исходном коде?"

1. что такое константное выражение?
const float pi = 3 + 0.14;
это pi 3 или 3+0.14

2. Что делать со строками? false/true и тп. т.е. я бы говорил об использовании числовых литералов,
3. обычно 0 и 1 исключают

и уж если придираться, то "значительное число" абсолютно не понятно

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

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

M>>Ну на счёт мэджиков понятно — "слышал звон, да не знает где он", "главное успеть к релизу", ... .
M>>Интересно вот что: почему [-1] ??? Ведь там же что угодно может быть без всяких расстрелов. Или там ДОЛЖНЫ лежать нормальные данные?
А>Ничего ты не понял насчет мейджиков Этими магическими числами студийный компилятор заполняет память ДО выделенного куска, причем только в ДЕБАГЕ. Надеюсь теперь про -1 понятно?

Непонятно. Почему тогда ici_error = "stack error"; ? Это же должно быть нормальным состоянием. Во-вторых, кто гарантирует, что перед ici_os.a_top ничего нет? Если ici_os — структура, то перед a_top вполне может быть что-то осмысленное. ici_os целиком может лежать сразу за какими-то данными.

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

M>>>Ну на счёт мэджиков понятно — "слышал звон, да не знает где он", "главное успеть к релизу", ... .
M>>>Интересно вот что: почему [-1] ??? Ведь там же что угодно может быть без всяких расстрелов. Или там ДОЛЖНЫ лежать нормальные данные?
А>>Ничего ты не понял насчет мейджиков Этими магическими числами студийный компилятор заполняет память ДО выделенного куска, причем только в ДЕБАГЕ. Надеюсь теперь про -1 понятно?
M>Непонятно. Почему тогда ici_error = "stack error"; ? Это же должно быть нормальным состоянием. Во-вторых, кто гарантирует, что перед ici_os.a_top ничего нет? Если ici_os — структура, то перед a_top вполне может быть что-то осмысленное. ici_os целиком может лежать сразу за какими-то данными.
Потому, что
http://forum.antichat.ru/showpost.php?p=238561&postcount=7

7. Отладочные значения в различных областях памяти программы
0xCDCDCDCD Память выделена в куче, не инициализирована
0xDDDDDDDD Память, выделенная в куче, уже освобождена
0xFDFDFDFD Заполнитель NoMansLand записывается у границ участка памяти для контроля распространенного типа ошибки выхода за границы массива и переполнения. После затирании это указатели при освобождлении этой памяти free/delete выдаст диалоговое окно: DAMAGE: after ТИП block (#номер) at 0xадрес., где ТИП — обычно Normal — тип освобождаемого участка, номер — номер блока.

P.S. Что с кывтом случилось? 7 страниц флейма, а по делу аноним пишет.