Что является некоторыми причинами, Сборка конечных версий работала бы по-другому, чем [закрытая] Отладочная сборка
Как отмечали другие, lxml имеет красивый принтер.
Помните, что по умолчанию он изменяет разделы CDATA на обычный текст, который может иметь неприятные результаты.
Вот функция Python, которая сохраняет входной файл и только изменяет отступ (обратите внимание на strip_cdata=False). Кроме того, он гарантирует, что на выходе используется UTF-8 в качестве кодировки вместо ASCII по умолчанию (обратите внимание на encoding='utf-8'):
from lxml import etree
def prettyPrintXml(xmlFilePathToPrettyPrint):
assert xmlFilePathToPrettyPrint is not None
parser = etree.XMLParser(resolve_entities=False, strip_cdata=False)
document = etree.parse(xmlFilePathToPrettyPrint, parser)
document.write(xmlFilePathToPrettyPrint, pretty_print=True, encoding='utf-8')
Пример использования:
prettyPrintXml('some_folder/some_file.xml')
10 ответов
Выживание Версии выпуска дает хороший обзор.
Вещи я встретился - большинство уже упоминается
Переменная инициализация безусловно наиболее распространенное. В Visual Studio отладка создает explicitely, инициализируйте выделенную память к данным значениям, посмотрите, например, Значения Памяти здесь. Эти значения обычно легко определить, вызвать за пределы ошибка, когда используется в качестве индекса или нарушения прав доступа, когда используется в качестве указателя. Неинициализированная булевская переменная верна, однако, и может вызвать неинициализированные ошибки памяти, идущие необнаруженный в течение многих лет.
В Сборках конечных версий, где память не является explicitely, инициализировал его, просто сохраняет содержание, которое это имело прежде. Это приводит к "забавным значениям" и "случайным" катастрофическим отказам, но как часто к детерминированным катастрофическим отказам, которые требуют, чтобы по-видимому несвязанная команда была выполнена перед командой, которая на самом деле отказывает. Это вызывается первой командой, "создающей" ячейку памяти с определенными значениями, и когда ячейки памяти переработаны, вторая команда рассматривает их как инициализации. Это более распространено с неинициализированными переменными стека, чем "куча", но последний произошел со мной, также.
Необработанная инициализация памяти может также отличаться в сборке конечных версий, начинаете ли Вы с Visual Studio (присоединенный отладчик) по сравнению с запуском с проводника. Это делает "самый хороший" вид ошибок сборки конечных версий, которые никогда не появляются под отладчиком.
Допустимая Оптимизация приходит второй в моем exeprience. Стандарт C++ позволяет большой оптимизации происходить, который может быть удивительным, но совершенно допустим, например, когда два указателя искажают ту же ячейку памяти, порядок инициализации не рассматривают, или несколько потоков изменяют те же ячейки памяти, и Вы ожидаете определенный порядок, в котором поток B видит изменения, внесенные потоком A. Часто, компилятор обвинен в них. Не настолько быстрый, молодой yedi! - видят ниже
Синхронизация , Сборки конечных версий только "работают быстрее" по ряду причин (оптимизация, регистрируя функции, обеспечивающие точку синхронизации потока, код отладки как утверждает не выполняемый и т.д.), также относительная синхронизация между операциями изменяется существенно. Наиболее распространенная проблема, раскрытая этим, является условиями состязания, но также и заходит в тупик и простой "различный порядок" выполнение кода message/timer/event-based. Даже при том, что они синхронизируют проблемы, они могут быть удивительно стабильными через сборки и платформы с воспроизведением, которое "всегда работает, за исключением ПК 23".
Байты охраны . Сборки отладки часто помещают (больше) защитные байты вокруг выбранных экземпляров и выделений, для защиты от индексного переполнения, и иногда теряет значимость. В редких случаях, где код полагается на смещения или размеры, например, сериализацию необработанных структур, они отличаются.
Другие различия в коде Некоторые инструкции - например, утверждают - не оценивают ни к чему в сборках конечных версий. Иногда у них есть различные побочные эффекты. Это распространено с макро-обманом, как в классике (предупреждение: несколько ошибок)
#ifdef DEBUG
#define Log(x) cout << #x << x << "\n";
#else
#define Log(x)
#endif
if (foo)
Log(x)
if (bar)
Run();
, Который, в сборке конечных версий, оценивает к если (нечто & & панель) Этот тип ошибки очень очень редок с нормальным кодом C/C++ и макросами, которые правильно записаны.
Ошибки Компилятора Этого действительно никогда не происходит. Хорошо - это делает, но Вы имеете по большей части Вашу карьеру более обеспеченное предположение, что это не делает. В десятилетие работы с VC6 я нашел тот, где я все еще убежден, что это - незакрепленная ошибка компилятора, по сравнению с десятками шаблонов (возможно, даже сотни экземпляров) с недостаточным пониманием священного писания (иначе стандарт).
Переменные, которые не инициализируются явно, будут или не могли бы быть обнулены в Сборке конечных версий.
В отладочной версии часто включены утверждения и/или отладочные символы. Это может привести к различному расположению памяти. В случае неверного указателя переполнения массива или подобного доступа к памяти Вы получаете доступ в одном случае к критической плохой памяти (например, указатель функции) и в другом случае, возможно, просто некоторая некритическая память (например, просто строка документа повреждается)
Я имел подобная проблема недавно , который закончил тем, что был вызван стеком, который рассматривают по-другому в сборках конечных версий. Другие вещи, которые могут отличаться:
- Выделение памяти обрабатывается по-другому со сборками отладки в компиляторе VS (т.е., пишущий 0xcc по очищенной памяти, и т.д.)
- Развертывание цикла и другая оптимизация компилятора
- Alightment указателей
Сборка конечных версий (надо надеяться), работала бы быстрее, чем Ваша отладочная сборка. При использовании больше чем одного потока Вы могли бы видеть больше чередования, или просто один поток, работающий быстрее, чем другие, которых Вы не могли заметить в отладочной сборке.
Это зависит и в поставщике компилятора и в библиотеках, которые Вы компилируете с флагами ОТЛАДКИ. В то время как код ОТЛАДКИ никогда не должен влиять на рабочий код (не должен иметь никаких побочных эффектов), это иногда делает.
, В частности, переменные могут быть инициализированы только в Режиме отладки и оставлены неинициализированные в режиме RELEASE. STL в компиляторах Visual Studio отличается в режимах DEBUG и RELEASE. Идея состоит в том, что итераторы полностью проверяются в ОТЛАДКЕ для обнаружения возможных ошибок (использующий делаемые недействительным итераторы, например, итератор в вектор делается недействительным, если вставка происходит после того, как итератор получен).
то же происходит со сторонними библиотеками, первым, о котором я могу думать, является QT4, который завершит Вашу программу с утверждением, если поток, отличающийся от того, который создал графический объект, выполнит операции рисования.
Со всеми изменениями, Ваш код и объем потребляемой памяти будут отличаться в обоих режимах. Указатель (читающий положение одна передача конец массива) проблема может передать необнаруженный, если то положение читаемо.
Утверждения предназначены, чтобы уничтожить приложение во время ОТЛАДКИ и исчезнуть из Сборок конечных версий, таким образом, я не думал бы на утверждениях, как являющихся Вашей проблемой. Указатель жулика или доступ к одному прошлому конец были бы моими первыми подозреваемыми.
Некоторое время назад были проблемы с некоторой оптимизацией компилятора, повреждающей код, но я не считал жалобы в последнее время. Там могла быть проблема оптимизации, но это не будет моим первым подозреваемым.
Сборки конечных версий обычно компилируются с оптимизацией, включенной в компиляторе, в то время как сборки отладки обычно не.
На некоторых языках или при пользовании многими различными библиотеками это может вызвать неустойчивые катастрофические отказы - особенно, когда выбранный уровень оптимизации очень высок.
я знаю, что дело обстоит так с gcc компилятором C++, но я не уверен в компиляторе Microsoft.
http://www.debuginfo.com/tips/userbpntdll.html
Из-за того, что защитные байты добавляются в отладочные сборки, вы можете иметь «безопасный» доступ память, которая находится за пределами массива (особенно динамических массивов), но это вызовет нарушение прав доступа в сборке выпуска. Эта ошибка может остаться незамеченной, что приведет к повреждению кучи и, возможно, нарушению прав доступа в месте, не связанном с исходной ошибкой.
Используйте PageHeap (или, если у вас установлены инструменты отладки, вы можете использовать gflags) для обнаружения ошибок, связанных с поврежденными кучами .
По моему опыту, наиболее распространенной причиной является то, что конфигурации различаются во многих отношениях, чем настройки выпуска / сборки. Например, включены различные библиотеки или сборка отладки имеет размер стека, отличный от размера стека выпуска.
Чтобы избежать этого в наших проектах Visual Studio 2005, мы широко используем листы свойств. Таким образом, конфигурации выпуска и отладки могут иметь общие настройки.
Этот пост вместе со ссылками очень полезен в исправлении связанной с ним ошибки. добавление к приведенному выше списку, разница в соглашениях о вызовах также может привести к такому поведению - это не удалось в сборке релиза только с оптимизацией для меня. я объявлен как __stdcall и определен как __cdecl (по умолчанию). [странно, что это предупреждение не выбрано даже в MSVC уровня предупреждения 4?]