что-то в субботу вечером ерунда кажется особенно ерундой :)
>Хеш функция это отображение множества строк в множество хешстрок.
с этим, пожалуй согласен, кроме новообразования «хешстрока»
>Это отображения сюръективно, потому как одной хешстроке может соответствовать не одна исходная строка.
Это не сюръективность, это отсутствие инъективности.
Сюръекция, это когда f: X -> Y и f (X) = Y
>Качество хеш функции в этом и заключается, чтобы выбрать наиболее качественное отображение, чтобы коллизия была редкая.
«Редкость коллизии» само по себе бесмысленное понятие, т.к. мы отображаем бесконечное множество строк в конечное множество хеш-значений, и количество коллизий всегда бесконечное.
>Отсюда вывод, что за хеш функцию можно так же считать и длину строки и количество гласных/согласных и тд
из двух ошибочных утверждений можно вывести абсолютно все что угодно (простое правило импликации), но данное — еще и бессодержательно. Может поясните тогда?
Если стек вызова растет из MessageBoxW то можете смело игнорировать, но это не ошибка WTL (про это я уже задавал вопрос представителям Microsoft на конференции по совместимости с Vista). Хотелось бы каких-то частностей, чтобы можно было исследовать вопрос.
Быть может проблема все-таки в дефолтных настройках телефонов. Кроме цифровых классов GPRS, есть еще буквенные, отвечающие за режим работы:
Class А
В классе «А» есть возможность передачи голосового трафика во время приема/передачи данных по GPRS.
Class B
Мобильный телефон с GPRS класса «В» может автоматически переключать GPRS и GSM сервисы, т.е. при включенном GPRS соединении при входящих или исходящих SMS — связь временно прерывается, после окончания звонка – GPRS соединение автоматически возобновляется. Также происходит с входящими и исходящими звонками.
Class С
Невозможно использовать одновременно GSM и GPRS сервис, т.е. при активной GPRS сессии, например, если вы подключены к сети Интернете невозможно принимать звонки или послать SMS.
собственно, если режим работы C — то возникает описанная Вами проблема.
Вы очень упорны, но я все же советую обратить внимание на слова о «коллизии первого рода» и их прямое отношение к задаче о точном дне рождения. И это не парадокс дней рождения.
Как бы честнее сказать, тут и так некоторый подвох заключен, ибо разрядность хеш значения — константа, а O(константы) = O(1). Делить на два, или нет, не суть. Правильно читается это так — что за какое-то константное время можно перебрать все значения, но это константное время очень велико, и будет очень велико, даже если поделить его на 2, 22, и 2^64.
Ни одного Error'а. Просто некоторые из Warning'ов уже к следующей версии AppVerifier'а могут превратиться в Error'ы, особенно, скажем, связанные с DangerousAPI (функция может стать deprecated). Но, поскольку сейчас проверка выполняется стороной самих разработчиков, достаточно просто убедиться что нет Errors перед отправкой лога.
Если тема Вас заинтересовала могу посоветовать документ от майкрософт.
Хорошо, обязательно про это расскажу в продолжении. Это действительно вопрос не тривиальный — благодаря хитрому выбору функции редукции можно сильно повысить эффективность алгоритма, так что внимания заслуживает однозначно.
Могут, и скорее всего на них есть какие-то дополнительные требования, но проверки AppVerifier'ом никто не отменяет — и да, группа Basics заведомо проходится любым приложением на C# без unmanaged (а для unmanaged имеют смысл почти все тесты кроме Exceptions), но от ошибок LuaPriv не застраховано не одно приложение имеющее доступ к файлам, реестру, ShellExecute.
Это так, пока разработка самого AppVerifier'а ведется в сторону увеличения функциональности и покрытия тестами потенциальных проблем, но тулза всё равно остается удобной только программистам в силу специфики использования. А на этапе бета-тестирования уже поздно узнавать о неправильном вызове CloseHandle…
Хотя мы внедрили применение тулзы в отделе тестирования, и результат в скором времени очень порадовал :)
И это тоже возможно средствами debug CRT, за счет более хитрого переопределения new. От способа веет «велосипедностью», и я боюсь, что любители внешних анализаторов совсем разозлятся — но, если кому-то интересно, могу рассказать, как это делается.
Это реализуется при помощи _CrtMemCheckpoint, _CrtMemDumpAllObjectsSince (про это было) и _CrtMemDifference, про которую не упомянул, наверное зря.
А вообще идеология простая, перед открытием проекта/сцены/модели делаем _CrtMemCheckpoint, после закрытия — _CrtMemDumpAllObjectsSince. Все новосозданные и не удаленные объекты являются подозрительными на утечку (но не обязаны ей быть).
Субъективно очень даже снижает. Вообще надо бы взяться и оттестить, а то тезис
>Он, оказывается, работает быстрее, чем ручные delete. Раза в полтора.
немного удивляет и, быть может, подвох в чем-то другом.
_CrtDumpMemoryLeaks может врать только в одном ключе — он пропускает объекты выделенные вручную через HeapAlloc, GlobalAlloc. Как отсечь глобальные и статические объекты я написал, и да, их использованием MFC, увы, славится. Строку и имя файла определяет, если переопределить new, но «прыгать» по ней не будет. Но и время анализа и исправления утечки обычно больше, чем навигации по коду, всё-таки.
В данном случае необходимость переопределения new имеет исторические корни, не в этом смысл. А Debug CRT тоже имеет средства обнаружения неициализированных данных (и обращений к уже освобожденным), выходов за границы массива. В сочетании с AppVerifier можно обрабатывать и попытки чтения/записи по неверным адресам. А вообще, Windows-программисты тоже должны как-то жить :)
>Хеш функция это отображение множества строк в множество хешстрок.
с этим, пожалуй согласен, кроме новообразования «хешстрока»
>Это отображения сюръективно, потому как одной хешстроке может соответствовать не одна исходная строка.
Это не сюръективность, это отсутствие инъективности.
Сюръекция, это когда f: X -> Y и f (X) = Y
>Качество хеш функции в этом и заключается, чтобы выбрать наиболее качественное отображение, чтобы коллизия была редкая.
«Редкость коллизии» само по себе бесмысленное понятие, т.к. мы отображаем бесконечное множество строк в конечное множество хеш-значений, и количество коллизий всегда бесконечное.
>Отсюда вывод, что за хеш функцию можно так же считать и длину строки и количество гласных/согласных и тд
из двух ошибочных утверждений можно вывести абсолютно все что угодно (простое правило импликации), но данное — еще и бессодержательно. Может поясните тогда?
Class А
В классе «А» есть возможность передачи голосового трафика во время приема/передачи данных по GPRS.
Class B
Мобильный телефон с GPRS класса «В» может автоматически переключать GPRS и GSM сервисы, т.е. при включенном GPRS соединении при входящих или исходящих SMS — связь временно прерывается, после окончания звонка – GPRS соединение автоматически возобновляется. Также происходит с входящими и исходящими звонками.
Class С
Невозможно использовать одновременно GSM и GPRS сервис, т.е. при активной GPRS сессии, например, если вы подключены к сети Интернете невозможно принимать звонки или послать SMS.
собственно, если режим работы C — то возникает описанная Вами проблема.
Если тема Вас заинтересовала могу посоветовать документ от майкрософт.
А FxCop решает немного другую задачу, но у managed кода и другие цели. Но инструмент более чем достойный внимания.
Хотя мы внедрили применение тулзы в отделе тестирования, и результат в скором времени очень порадовал :)
new. От способа веет «велосипедностью», и я боюсь, что любители внешних анализаторов совсем разозлятся — но, если кому-то интересно, могу рассказать, как это делается.А вообще идеология простая, перед открытием проекта/сцены/модели делаем _CrtMemCheckpoint, после закрытия — _CrtMemDumpAllObjectsSince. Все новосозданные и не удаленные объекты являются подозрительными на утечку (но не обязаны ей быть).
>Он, оказывается, работает быстрее, чем ручные delete. Раза в полтора.
немного удивляет и, быть может, подвох в чем-то другом.
В качестве оптимизации можно тащить с собой base64 от gif (ну или lzw от bmp) а рендерить в div'ы джаваскриптом через DOM, да и много как ещё можно.
А вообще, забавно.