Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>А я и так это знаю. Поэтому Debug режимом не пользуюсь (практически) E>>Компилюсь сразу в Release. Отлаживаюсь либо по unit-тестам, либо анализирую логи.
VD>Ужас какой.
Ну почему же ужас? К этому быстро привыкаешь
E>>Debug обычно использую, только если не удается быстро локализовать место возникновения Access violation по отладочным печатям. Да и то, нужно сказать, что часто обнаруживается только последствия. А вот причину приходится логическим путем обнаруживать совсем в другом месте.
VD>А я вот использую языки которые не дают таких проблем в релизе.
Хорошо тебе.
E>>А уж когда я в последний раз в отладчике пошаговую отладку использовал сейчас уже и не вспомню.
VD>Хорошо тебе.
Да, есть такое дело
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Если в команде разработчиков есть пара тройка ребят с явно низкой квалификацией, то обязательно нарвешся. А вот если повезло и команда состоит из нескольких высококвалифицированных C++ разработчиков, то это вовсе не обязательно.
VD>Практика показыает, что нарвешся в любом случае. Может реже, но все же.
Моя практика показывает, что лучше бывает собрать тестовый стенд на которых падение программы будет повторяться стабильно. После чего на этом стенде ошибка локализуется всеми доступными средствами. Такой подход позволяет не только падения отлавливать, но и утечки ресурсов, а также причины тормозов (которые могут возникать по самым разным причинам).
А креш-дам, имхо, содержит только снимок программы на момент падения. Но не показывает, как программа дошла в такое состояние, а это важнее.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Т>>Снимаем чайник с плиты, выливаем из него воду и сводим задачу к уже решенной.
Д>если это упростит задачу и не приведет к большим потерям — да, именно так
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Трурль, Вы писали:
Т>>Но в данном случае ни капельки не упрощает.
Д>правда? Д>если говорить про объем кода — может быть. но я говорю не про объем
А про что интересно?
то, что нужно будет цифры переводить туда-сюда (сначала число в строку, потом каждую цифру в числовое представление)- это понятней чем то, что цифра — это разряд в 10-чной системе?
Мсьё любитель изысканных извращений?
Я понимаю, что стандартные библиотеки вещь очень необходимая, полезная и т.п., но стоит ли пытаться забивать гвозди видеомагнитофоном?
Здравствуйте, Курилка, Вы писали:
К>то, что нужно будет цифры переводить туда-сюда (сначала число в строку, потом каждую цифру в числовое представление)- это понятней чем то, что цифра — это разряд в 10-чной системе?
Нужно еще понять, как этот разряд извлечь из двоичного числа. Я например наблюдал одного старшекурсника (ныне он уже аспирант), который до этого допереть не смог
К>Мсьё любитель изысканных извращений?
конечно!
К>Я понимаю, что стандартные библиотеки вещь очень необходимая, полезная и т.п., но стоит ли пытаться забивать гвозди видеомагнитофоном?
Шуруп вбитый молотком держится крепче, чем гвозь вкрученный отверткой
Здравствуйте, eao197, Вы писали:
E>Моя практика показывает, что лучше бывает собрать тестовый стенд на которых падение программы будет повторяться стабильно. После чего на этом стенде ошибка локализуется всеми доступными средствами. Такой подход позволяет не только падения отлавливать, но и утечки ресурсов, а также причины тормозов (которые могут возникать по самым разным причинам).
Моя практика показывает что иногда и стенда такого не сделаешь И для решения подобных вещей используется эвристический подход.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
E>>Моя практика показывает, что лучше бывает собрать тестовый стенд на которых падение программы будет повторяться стабильно. После чего на этом стенде ошибка локализуется всеми доступными средствами. Такой подход позволяет не только падения отлавливать, но и утечки ресурсов, а также причины тормозов (которые могут возникать по самым разным причинам). GZ>Моя практика показывает что иногда и стенда такого не сделаешь И для решения подобных вещей используется эвристический подход.
Да, такое бывает.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Моя практика показывает, что лучше бывает собрать тестовый стенд на которых падение программы будет повторяться стабильно. После чего на этом стенде ошибка локализуется всеми доступными средствами. Такой подход позволяет не только падения отлавливать, но и утечки ресурсов, а также причины тормозов (которые могут возникать по самым разным причинам).
E>А креш-дам, имхо, содержит только снимок программы на момент падения. Но не показывает, как программа дошла в такое состояние, а это важнее.
А моя практика показывает, что лучше пользоваться средствами не допускющими подобных проблем. Типобезопасный код + надежные библиотеки (опять же типобезопастные) рулять адназначна. (с) Жирик.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Понимаеш ли. У мастерства тоже есть разные стадии. Знающий ассемблер, разбирающийся с дампами, уситчивый и довольно опытный прграммист конечно напоровшись на трудно уловимую ошибку попытается найти ошибку даже на основании дампа. Но не факт что у него получится. Ну, да это не важно.
Так вот более опытный человект, так же знающий ассемблер, и так же потрахавшийся с дампами просто еще на стадии проектирования выберет такую стратегию, чтобы сделать подобную ошибку настолько маловероятной, что на практике просто никогда с ней не столкнется.
В общем, последняя стратегия мне наравится куда больше.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Т>>Снимаем чайник с плиты, выливаем из него воду и сводим задачу к уже решенной.
Д>если это упростит задачу и не приведет к большим потерям — да, именно так
Думаю, что основная задача олимпиады не решить задачу наиболее простым методом, а заставить людей поднять свой уровень программирования. И тут такие ламерские решения просто вредны. Ведь олимпиада — это подготовка к ней! А значит обучение думать.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали: G>>Плотность дефектов в предрелизной бете в гражданском софте обыкновенно составляет не менее 5 штук на одну тыщу строк.
Д>Очень интересно. Эта цифра для софта какого объема, какого назначения, на каком языке, с какими библиотеками?
У нас так выходило для комплекса серверов, обслуживающего заявки на электронную биржевую торговлю. Язык — С++, в этой подветке речь идет только о С++. Насколько я знаю, эта статистика укладывается в индустриальные средние.
Д>Если уж так сильно хочется замерить метрики — куда точнее будет использовать количество значимых символов в исходниках, а еще точнее — количество лексем. Написать соответствующую утилиту — работы на пару дней, зато будут более-менее точные цифры.
По данным исследований, наиболее стабильные метрики построены на строках кода. За деталями о метриках — добро пожаловать на сайт Карнеги-Меллонского университета.
Д>А мерять код строками — все равно что на кофейной гуще гадать.
Ерунда. Так обычно говорят люди, которые вообще не меряют код ни строками, ни чем другим. Признайся, ты хоть раз считал плотность дефектов для своих проектов?
G>>Часть из ник приводят к крешу. Это после очень хорошего тестирования, с плотным покрытием юнит тестами, и от языка зависит не сильно.
Д>Интересная теория. Даже если этот язык — JavaScript? http://www.rsdn.ru/Forum/Message.aspx?mid=984393&only=1
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Gaperton, Вы писали:
G>>Умные все стали, сил нет. Плотность дефектов в предрелизной бете в гражданском софте обыкновенно составляет не менее 5 штук на одну тыщу строк. Часть из ник приводят к крешу. Это после очень хорошего тестирования, с плотным покрытием юнит тестами, и от языка зависит не сильно. Давай, пиши чтоб не падало. GZ>Что ты имеешь в виду под гражданским, а что под негражданским?
"Гражданский код" — где нет сумасшедших требований к надежности, а-ля пять девяток.
GZ>Кто делал подобные исследования?
Carnegie-Mellon SEI. В рамках работ по PSP/TSP и софтверным метрикам. Также, любая компания, которая применяет софтверные метрики, как например, CQG или Ericsson, имеют возможность регулярно убеждаться в правильности статистики Carnegie-Mellon.
GZ>Что значит очень хорошее тестирование?
Это означает, что каждый класс покрыт unit-тестами, и все они выполняются. И что первая стадия интеграционного тестирования прошла успешно, продукт достаточно стабилен, чтобы отдать его на бета-тестирование.
GZ>С уважением, Gleb. GZ>PS: в цифры "после очень хорошего тестирования, с плотным покрытием юнит тестами" не верю
Можешь проверить сам по своим проектам.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, что основная задача олимпиады не решить задачу наиболее простым методом, а заставить людей поднять свой уровень программирования. И тут такие ламерские решения просто вредны. Ведь олимпиада — это подготовка к ней! А значит обучение думать.
Один из аспектов "умения думать" — это нежелание делать ту работу, которую можно не делать.
Задача олимпиады — может быть, и такая. А задача участника олимпиады — решить максимальное количество задач за ограниченное время. Так что сэкономив 15 минут на написании и отладке кода, их можно применить для решения другой задачи.
Добиваться своей цели могут и вот так, например: http://gzip.rsdn.ru/Forum/Message.aspx?mid=682603&only=1
Traditional metrics, such as Lines of Code (LOC), is no longer valid or useful. Metrics based on interfaces, member functions and their complexity should be used.
G>Ерунда. Так обычно говорят люди, которые вообще не меряют код ни строками, ни чем другим. Признайся, ты хоть раз считал плотность дефектов для своих проектов?
Здравствуйте, Дарней, Вы писали:
A>>Не вижу преимущества в itoa. Д>преимущество — в том, что этот код уже написан и отлажен. Просуммировать цифры в строке — это намного проще, и экономит время — а его на олимпиадах как раз и не хватает.
Мне почему-то не сильно сэкономило.
Д>Я уж не говорю о том, что во многих серьезных фирмах за написание самопального алгоритма перевода тебе бы надавали по рукам
Здесь нет задачи перевода число <-> строка. Есть задача просуммировать цифры числа.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Iscaaro — Fold Your Hands And Pray";
