Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, StevenIvanov, Вы писали:
SI>>Вот мне эти величины ни о чем не говорят. Хоть и программирую на С/C++ вот почти уже 5 лет (в основном linux+gcc). И печальный опыт сопровеждения проектов в которых есть такие места тоже есть
LMA>Код явно специфичен для MS. Плохо это или хорошо — зависит от проекта. Никаких антипаттернов тут быть не может.
... LMA>Не любой код может быть написан с поддержкой нескольких платформ. Может ли так быть написан этот код — вопрос остается открытым.
Но если код может быть с минимальными усилиями написан в расчете на портабельность, то почему бы и нет?
LMA>Ну и смысл тогда разбрасываться модными словечками вроде "антипаттерн"? В надежде, что даже сломанные часы дважды в сутки показывают правильно время?
Это не модные словечки. Это вполне себе распространенное явление, когда вместо нормального, сопровождаемого кода рожают километры го.на.
А код прежде всего должен документировать сам себя — умные люди (Кнут) советуют писать именно в таком стиле.
Из таких мелочей складывается вся программа и уже по таким местам можно судить о коде в целом. Слышали наверное — "Дьявол обитает в мелочах".
И, безусловно, лично мне гораздо удобнее прочитать DEBUG_ERROR_MARK чем 0xfdfdfdfd.
Не думаю, что дальнейшая дискуссия имеет смысл, все равно мы друг другу вряд ли докажем обратное.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Ну, в общем, я понял основную идею — если ты помнишь, что означает определенная чиселка в программе и думаешь, что остальные тоже должны ее помнить, то ее не обязательно как-либо именовать Все же попробуй с высоты своего кругозора подумать о несчастных, забывших значения этих супер-нужных супер-констант сразу после того, как они научились пользоваться grind'ом или любой другой утилитой автоматического поиска ошибок обращения к памяти.
LMA>Нефига ты не понял! Представь себе, что есть два человека — Вася (В) и Петя (П). Для В понятнее запись 0xcccccccc (а видя UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY он подумает "это 0xcccccccc что ли?"), а для П — не понятно ни 0xcccccccc, ни UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY. И какой смысл в такой ситуации писать в коде UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY? Чтобы всем было одинаково плохо?
Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
Здравствуйте, slavo, Вы писали:
S>много всего писать. Это интерпретатор языка C. Работает на винде и линуксе , в релизе и дебаге.
Мне больше всего "резал" глаза отрицательный индекс [-1]. Теперь, когда стало понятно, что это работа не с системным стеком/кучей, а со "своими" структурами, режет еще больше. Все остальное по сравнению с этим моментом — косметика и легко исправляется. Соответственно, вопрос, кто это придумал? Автор обсуждаемого фрагмента или кто-то другой?
Андрей Ушаков wrote: > Мне больше всего "резал" глаза отрицательный индекс [-1]. Теперь, когда > стало понятно, что это работа не с системным стеком/кучей, а со "своими" > структурами, режет еще больше.
Чем вам это режет глаза отрицательный индекс массива ?
В определённой ситуации — вполне нормально.
Оно конечно, я бы так не делал, но язык вовсе не запрещает.
Так это адреса в вашей виртуальной машине или в реальном адресном пространстве
задачи ? Или они совмещены ?
Тут очень разные варианты могут быть, может быть для этого вашего интерпретатора
это вообще как число Pi — две всемирные константы.
LordMAD wrote:
> Нефига ты не понял! Представь себе, что есть два человека — Вася (В) и > Петя (П). Для В понятнее запись 0xcccccccc (а видя > UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY он > подумает "это 0xcccccccc что ли?"), а для П — не понятно ни 0xcccccccc, > ни UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY. И > какой смысл в такой ситуации писать в коде > UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY? Чтобы > всем было одинаково плохо?
я вот долго колебался, задавать ли мне вопрос. Но теперь
просто напишу, чтобы не говорили, что человека-Пети не бывает.
Я — Петя. Нет, зовут меня по-другому, но я не понимаю ни того, ни другого.
Здравствуйте, StevenIvanov, Вы писали:
SI>Но если код может быть с минимальными усилиями написан в расчете на портабельность, то почему бы и нет?
Безусловно, с этим никто не спорит.
LMA>>Ну и смысл тогда разбрасываться модными словечками вроде "антипаттерн"? В надежде, что даже сломанные часы дважды в сутки показывают правильно время?
SI>Это не модные словечки. Это вполне себе распространенное явление, когда вместо нормального, сопровождаемого кода рожают километры го.на. SI>А код прежде всего должен документировать сам себя — умные люди (Кнут) советуют писать именно в таком стиле. SI>Из таких мелочей складывается вся программа и уже по таким местам можно судить о коде в целом. Слышали наверное — "Дьявол обитает в мелочах".
Тоже очевидный факт. Только если какие-то стили бывают применимы к некоторым видам проектов, при чем тут антипаттерны? Вам будет легче, если будет существовать антипаттерн "использование goto" (потому что это имеет смысл в определенных проектах) и антипаттерн "не использование goto" (потому что это тоже имеет смысл для других проектов)? Антипаттернами называют откровенно плохие решения, а не решения, которые инода бывают полезными, а иногда — вредными.
SI>И, безусловно, лично мне гораздо удобнее прочитать DEBUG_ERROR_MARK чем 0xfdfdfdfd.
Я нахожу имя DEBUG_ERROR_MARK крайне плохим с точки зрения самодокументирования для константы 0xfdfdfdfd.
Здравствуйте, ancient, Вы писали:
A>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>
A>#if defined(_WIN32) && defined(_DEBUG)
A>if((int)ici_os.a_top[-1] == MSVC_CRT_MAGIC_UNINITIALIZED_HEAP || *(int*)ici_os.a_top[-1] == MSVC_CRT_MAGIC_UNINITIALIZED_STACK))
A>{
A> ici_error = "stack error";
A> goto fail;
A>}
A>#endif
A>
Я вижу, что ты даже не понимаешь разницы между UNINITIALIZED_STACK_MEMORY и UNINITIALIZED_STACK или между GUARD_BYTES_BEFORE_AND_AFTER_ALLOCATED_HEAP_MEMORY и UNINITIALIZED_HEAP. Остальные отличия — косметика, а учитывая уточнения автора топика по поводу контекста: #if defined(_WIN32) && defined(_DEBUG) — тут явно лишний. Это только доказывает, что имена для констант тебе не помогают понять о чем тут речь и тебя просто следует держать от такого кода подальше (прав я был, когда о Пете писал).
А по поводу того, что читабельнее и что кто помнит, так скажу просто, что последние 6 с лишним лет для отладки MS не использовал (только прогоняется код через их компилятор, чтобы убедится в совместимости) и, тем не менее, константы не забыл, хотя считаю, что память у меня плохая. Так что про то, что через пол года такое без (само)документирования забывается — чушь это просто, не верь этому — забываются собственные константы, а не такие.
АУ>Мне больше всего "резал" глаза отрицательный индекс [-1]. Теперь, когда стало понятно, что это работа не с системным стеком/кучей, а со "своими" структурами, режет еще больше. Все остальное по сравнению с этим моментом — косметика и легко исправляется.
Ну, да. Если верить Страуструпу, то на некоторых платформах доступ по отрицательному индексу может обломаться из-за какой-нибудь встроенной защиты памяти. Видимо, есть на свете такие архитектуры. Вывод такой — код непереносим, хотя на персоналке в обозримом будущем и настоящем будет работать.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>>
LMA>Я вижу, что ты даже не понимаешь разницы между UNINITIALIZED_STACK_MEMORY и UNINITIALIZED_STACK или между GUARD_BYTES_BEFORE_AND_AFTER_ALLOCATED_HEAP_MEMORY и UNINITIALIZED_HEAP. Остальные отличия — косметика, а учитывая уточнения автора топика по поводу контекста: #if defined(_WIN32) && defined(_DEBUG) — тут явно лишний. Это только доказывает, что имена для констант тебе не помогают понять о чем тут речь и тебя просто следует держать от такого кода подальше (прав я был, когда о Пете писал).
Ты специально тупишь? Я говорил о стиле, а не о логике этого куска и явно написал об этом в предыдущем сообщении. Разуй глаза.
Говорить о логике кода без знания того, что есть ici_os.a_top бессмысленно. Да и не о том речь была.
Учитывая, кстати, что "#if defined(_WIN32) && defined(_DEBUG)" тут, как ты говоришь, лишний, означает лишь, что константы эти не имеют никакого отношения к их использованию в MSVC, а значит и твое понимание этих констант мимо тазика в этом конкретном куске кода. Они просто означают что-то совсем другое, потому что твое понимание основано на их использовании в MSVC, а тут программа, очевидно, сама определяет логику их использования.
LMA>А по поводу того, что читабельнее и что кто помнит, так скажу просто, что последние 6 с лишним лет для отладки MS не использовал (только прогоняется код через их компилятор, чтобы убедится в совместимости) и, тем не менее, константы не забыл, хотя считаю, что память у меня плохая. Так что про то, что через пол года такое без (само)документирования забывается — чушь это просто, не верь этому — забываются собственные константы, а не такие.
Ну, в это трудно поверить и трудно проверить. Я почти уверен, что ты вспомнил об этих константах только когда увидел начальное письмо, и в контексте с "ici_error = "stack error";". Но это не важно, на самом деле, так же как и помнил ли ты их все эти годы или нет.
Здравствуйте, ancient, Вы писали:
A>>>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>>>
LMA>>Я вижу, что ты даже не понимаешь разницы между UNINITIALIZED_STACK_MEMORY и UNINITIALIZED_STACK или между GUARD_BYTES_BEFORE_AND_AFTER_ALLOCATED_HEAP_MEMORY и UNINITIALIZED_HEAP. Остальные отличия — косметика, а учитывая уточнения автора топика по поводу контекста: #if defined(_WIN32) && defined(_DEBUG) — тут явно лишний. Это только доказывает, что имена для констант тебе не помогают понять о чем тут речь и тебя просто следует держать от такого кода подальше (прав я был, когда о Пете писал).
A>Ты специально тупишь? Я говорил о стиле, а не о логике этого куска и явно написал об этом в предыдущем сообщении. Разуй глаза.
Я и пишу, что твой код отличается только косметическими изменениями и твоим непоминанием того, что делает этот код.
A>Говорить о логике кода без знания того, что есть ici_os.a_top бессмысленно. Да и не о том речь была.
Ошибаешься. Но я рад, что ты признаешь, что использование именованных констант не проясняет для тебя смысл кода.
A>Учитывая, кстати, что "#if defined(_WIN32) && defined(_DEBUG)" тут, как ты говоришь, лишний, означает лишь, что константы эти не имеют никакого отношения к их использованию в MSVC, а значит и твое понимание этих констант мимо тазика в этом конкретном куске кода. Они просто означают что-то совсем другое, потому что твое понимание основано на их использовании в MSVC, а тут программа, очевидно, сама определяет логику их использования.
Опять ошибаешься.
LMA>>А по поводу того, что читабельнее и что кто помнит, так скажу просто, что последние 6 с лишним лет для отладки MS не использовал (только прогоняется код через их компилятор, чтобы убедится в совместимости) и, тем не менее, константы не забыл, хотя считаю, что память у меня плохая. Так что про то, что через пол года такое без (само)документирования забывается — чушь это просто, не верь этому — забываются собственные константы, а не такие.
A>Ну, в это трудно поверить и трудно проверить. Я почти уверен, что ты вспомнил об этих константах только когда увидел начальное письмо, и в контексте с "ici_error = "stack error";". Но это не важно, на самом деле, так же как и помнил ли ты их все эти годы или нет.
Не суди по себе.
Так как ты переходишь на откровенное хамство разговор продолжать дальше смысла не вижу.
LMA>более читабельным, чем оригинал. Просто потому, что эти значения люди, которым они действительно нужны, обычно наблюдают в окне дампа, а тем, кто их не имеет привычки наблюдать в окне дампа, и с именованными константами не поймет о чем тут речь идет, IMHO. А при этом какова вероятность, что в реальной программе будут использованы такие длинные наименования, а не менее информативные, но более короткие? IMHO, большая вероятность.
Здравствуйте, Stormblast, Вы писали:
S>>Здравствуйте, slavo.
S>Чужой код вы выставили на всеобщее обозрение ! S>Так может будите любезны показать теперь свой вариант ? или очкуете ?
во-первых, мне некогда этим заниматься. у меня своя работа. во-вторых, этот код надо убирать и искать сам баг. какой код ты от меня требуешь?
Здравствуйте, ancient, Вы писали:
A>Здравствуйте, LordMAD, Вы писали:
LMA>>Здравствуйте, ancient, Вы писали:
A>>>Ну, в общем, я понял основную идею — если ты помнишь, что означает определенная чиселка в программе и думаешь, что остальные тоже должны ее помнить, то ее не обязательно как-либо именовать Все же попробуй с высоты своего кругозора подумать о несчастных, забывших значения этих супер-нужных супер-констант сразу после того, как они научились пользоваться grind'ом или любой другой утилитой автоматического поиска ошибок обращения к памяти.
LMA>>Нефига ты не понял! Представь себе, что есть два человека — Вася (В) и Петя (П). Для В понятнее запись 0xcccccccc (а видя UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY он подумает "это 0xcccccccc что ли?"), а для П — не понятно ни 0xcccccccc, ни UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY. И какой смысл в такой ситуации писать в коде UNINITIALIZED_STACK_MEMORY_UNDER_MS_CPP_DEBUGGING_RUNTIME_LIBRARY? Чтобы всем было одинаково плохо?
A>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>
A>#if defined(_WIN32) && defined(_DEBUG)
A>if((int)ici_os.a_top[-1] == MSVC_CRT_MAGIC_UNINITIALIZED_HEAP || *(int*)ici_os.a_top[-1] == MSVC_CRT_MAGIC_UNINITIALIZED_STACK))
A>{
A> ici_error = "stack error";
A> goto fail;
A>}
A>#endif
A>
Здравствуйте, MasterZiv, Вы писали:
MZ>slavo wrote:
>> for (;) >> { >> if ( >> (ici_os.a_top — ici_os.a_base > 0) && >> ((int)ici_os.a_top[-1] == 0xfdfdfdfd || *(int*)ici_os.a_top[-1] == 0xcccccccc))
MZ>Так это адреса в вашей виртуальной машине или в реальном адресном пространстве MZ>задачи ? Или они совмещены ? MZ>Тут очень разные варианты могут быть, может быть для этого вашего интерпретатора MZ>это вообще как число Pi — две всемирные константы.
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, ancient, Вы писали:
A>>Последняя попытка Я бы предпочел увидеть что-то типа этого (чисто стилистически, безотносительно логики кода):
A>>
LMA>Я вижу, что ты даже не понимаешь разницы между UNINITIALIZED_STACK_MEMORY и UNINITIALIZED_STACK или между GUARD_BYTES_BEFORE_AND_AFTER_ALLOCATED_HEAP_MEMORY и UNINITIALIZED_HEAP. Остальные отличия — косметика, а учитывая уточнения автора топика по поводу контекста: #if defined(_WIN32) && defined(_DEBUG) — тут явно лишний. Это только доказывает, что имена для констант тебе не помогают понять о чем тут речь и тебя просто следует держать от такого кода подальше (прав я был, когда о Пете писал).
LMA>А по поводу того, что читабельнее и что кто помнит, так скажу просто, что последние 6 с лишним лет для отладки MS не использовал (только прогоняется код через их компилятор, чтобы убедится в совместимости) и, тем не менее, константы не забыл, хотя считаю, что память у меня плохая. Так что про то, что через пол года такое без (само)документирования забывается — чушь это просто, не верь этому — забываются собственные константы, а не такие.
имена-дефайны лучше чем константы, потому что они говорят о назначении константы. и любой ламер, увидев это в коде получает больше информации, чем просто 0xfdfdfdfd. И это более документированный код.
