Если вы считаете, что ключеове слово byte перед числом -4 правомерно превращает его в -3, объясните пожалуйста, почему я должен считать такое поведение правильным? Вполне допускаю, что мои знания ассемблера не достаточно полны.
На всякий случай предупрежу.
в исходниках VirtualDub есть такой файл: a_resample_mmx.asm (этот код используется при изменении разрешения изображения).
В этом файле несколько раз встречается такая строчка:
and esi,byte -4
Так вот, в 2010 студии (имеется ввиду компилятор ml.exe) эта строчка компилировалась правильно, а вот в 2013 — ошибочно (только что проверил на update4 — ошибка на месте).
2013 студия компилирует эту строчку в следующие опкоды: 0152EBDC, что эквивалентно команде:
and esi,0FFFFFFFDh
или, если записать в знаковом виде:
and esi,byte -3
Упс.
Пришлось заменить явно на
and esi,0FFFFFFFCh ;byte -4
Повторюсь: сей баг проявляется, если использовать компилятор ассемблера ml.exe, который идет в составе Visual Studio 2013.
Честно говоря, я уже и не помню, почему я просто не поменял порядок линковки. Возможно потому что линковщик от ms всегда ищет сначала в своих библиотеках. Не могу точно сказать. Может просто плохо пытался. Эксперименты с подменой я начал проделывать еще на 2008-й студии и, помню, тогда ее линковщик выдавал предупреждение на появление дублей. Может быть это предупреждение показалось мне тогда неприемлемым. А может просто хотелось избавиться от стандартного аллокатора с гарантией (все же порядок линковки не кажется мне надежной штукой, т.к. обычно все должно линковаться в любом порядке с одинаковым результатом).
В конце концов, эти вещи из разряда «блажь перфекциониста». Скорее всего работа программы без полной замены аллокатора ничем не будет отличаться от той же программы с полной заменой. Однако хочется идеала, даже если его никто не видит кроме тебя.
Формально вы, конечно, правы.
Я выложил код, который использую у себя. Так получилось, что в своих программах я предпочитаю исключения C++ отключать вообще. Я сторонник такого подхода, что таких исключений в программе быть не должно, краши же ловятся с помощью SEH.
Что же касается исключения по причине нехватки памяти, то, согласитесь, в современных системах памяти столько, что ситуация, когда программе ее не хватило, говорит о какой-то фундаментальной проблеме приложения. В любом случае bad_alloc — это в 99% случаев гарантированное падение.
Резюмируя:
да, по хорошему я должен был написать в коде бросок исключения. Вообще я должен был написать еще много чего, например проверку на то, в C или C++ файл включают мою заглушку, удобный способ замены dlmalloc'а на что-то еще, комментариев побольше, и т.п.
Это всё так, но всё дело в том, что у меня не было такой задачи. Я не задавался целью написать универсальную заглушку на все случаи жизни. Я задавался целью познакомить программистов со способом подмены аллокатора. Просто воспринимайте этот код в качестве… м… учебного, чтоли.
О, это для меня вообще больной вопрос.
Я покупаю все приложения, которыми пользуюсь больше месяца постоянно.
И вот с недавнего времени у некоторых приложений стала слетать лицензия.
Как оказалось, эти приложения негативно воспринимают наличие в системе LuckyPatcher'а.
Самое смешное, что проверку слетевшей лицензии приходится выключать этим же самым LuckyPatcher'ом. Где логика?
> Однако, при наличии исходников можно поиском/заменой переименовать все malloc/free на что-то свое.
А вот это как раз варварский способ. Этим мы сразу сильно усложняем себе дальнейшее обновление используемых библиотек.
Хорошо, если библиотека позволяет подменять аллокатор (например pnglib), а если не позволяет, то подмена стандартной библиотеки видится мне единственным способом.
new и delete — да, malloc и free — нет.
Большинство полезных сторонних библиотек написаны на C, а значит new и delete, очевидно, там не используются.
Простой пример — sqlite.
Ну и я бы не назвал этот способ варварским. Обрезанная библиотека создается один раз и далее просто используется. Кроме того, использовать ее можно только в конфигурации Release, а в Debug все оставить как было.
в исходниках VirtualDub есть такой файл: a_resample_mmx.asm (этот код используется при изменении разрешения изображения).
В этом файле несколько раз встречается такая строчка:
Так вот, в 2010 студии (имеется ввиду компилятор ml.exe) эта строчка компилировалась правильно, а вот в 2013 — ошибочно (только что проверил на update4 — ошибка на месте).
2013 студия компилирует эту строчку в следующие опкоды: 0152EBDC, что эквивалентно команде:
или, если записать в знаковом виде:
Упс.
Пришлось заменить явно на
Повторюсь: сей баг проявляется, если использовать компилятор ассемблера ml.exe, который идет в составе Visual Studio 2013.
В конце концов, эти вещи из разряда «блажь перфекциониста». Скорее всего работа программы без полной замены аллокатора ничем не будет отличаться от той же программы с полной заменой. Однако хочется идеала, даже если его никто не видит кроме тебя.
Я выложил код, который использую у себя. Так получилось, что в своих программах я предпочитаю исключения C++ отключать вообще. Я сторонник такого подхода, что таких исключений в программе быть не должно, краши же ловятся с помощью SEH.
Что же касается исключения по причине нехватки памяти, то, согласитесь, в современных системах памяти столько, что ситуация, когда программе ее не хватило, говорит о какой-то фундаментальной проблеме приложения. В любом случае bad_alloc — это в 99% случаев гарантированное падение.
Резюмируя:
да, по хорошему я должен был написать в коде бросок исключения. Вообще я должен был написать еще много чего, например проверку на то, в C или C++ файл включают мою заглушку, удобный способ замены dlmalloc'а на что-то еще, комментариев побольше, и т.п.
Это всё так, но всё дело в том, что у меня не было такой задачи. Я не задавался целью написать универсальную заглушку на все случаи жизни. Я задавался целью познакомить программистов со способом подмены аллокатора. Просто воспринимайте этот код в качестве… м… учебного, чтоли.
Я покупаю все приложения, которыми пользуюсь больше месяца постоянно.
И вот с недавнего времени у некоторых приложений стала слетать лицензия.
Как оказалось, эти приложения негативно воспринимают наличие в системе LuckyPatcher'а.
Самое смешное, что проверку слетевшей лицензии приходится выключать этим же самым LuckyPatcher'ом. Где логика?
А вот это как раз варварский способ. Этим мы сразу сильно усложняем себе дальнейшее обновление используемых библиотек.
Хорошо, если библиотека позволяет подменять аллокатор (например pnglib), а если не позволяет, то подмена стандартной библиотеки видится мне единственным способом.
Большинство полезных сторонних библиотек написаны на C, а значит new и delete, очевидно, там не используются.
Простой пример — sqlite.
Ну и я бы не назвал этот способ варварским. Обрезанная библиотека создается один раз и далее просто используется. Кроме того, использовать ее можно только в конфигурации Release, а в Debug все оставить как было.