Одному мне показалось, что в приведенной формулировке задачи об остановке не все в порядке?
Алгоритм-то должен не доказывать факт остановки при конкретных данных, а проверять возмонжость не остановки при любых данных.
При этом он, как я понимаю, может работать с входным алгоритмом как с белым ящиком.
Я не утверждаю, что разработка такого алгоритма возможна, просто показываю, что доказательство, приведенное в статье явно упрощено до некорректности.
Один глупый вопрос — а почему бы не использовать UnicodeString из icu, раз уж эта библиотека применена? У меня в проекте (который очень сильно завязан на работу со строками) именно этот класс в основном и используется. Он использует какую-то UTF-16 кодировку. Из приятных особенностей — хранение коротких строк прямо в классе, copy-on-write со счетчиком ссылкок.
У Розетки есть немаловажный плюс — прием на гарантийный ремонт она осуществляет у себя в офисе в нормальное время (кажется, с 10 до 19), что гораздо лучше, чем ехать непонятно куда в сервисный центр производителя, который еще и рабоает ровно с 10 до 18 (в лучшем случае). Впечатления о сервисных центрах — на основе СЦ iRiver, если что
Я бы попробовал-таки его переустановить. У меня на этой неделе после принудительного выключения ноута из-за разряда батареи он себя стал вести просто отвратительно. Все рекомендуемые очистки кешей не помогли (вообще-то она вообще зависала!), помогла только полная переустановка.
Вероятно, профиль запоролся каким-то образом.
Подобное было еще несколько месяцев назад, когда карты Яндекса вместо карта начали показывать какие-то другие картинки из кеша. Тогда обошелся малой кровью — просто почистил все кеши.
Ну, в VC11 будет несколько приятных фич.
Что особенно порадовало — обещали промежуточный релиз компилятора Visual C++, не привязанный к новому релизу Студии именно для еще большей поддержки стандарта.
А я за немного другой подход.
Warning'и можно отключить локально — только в том месте, где мы о нем знаем.
Итак, отключаем локально все ворнинги (да, работа еще та, но любой скриптовый язык в этом поможет), проверяем, что ничего не сломали (на всякий случай — код-то не менялся), а потом начинаем жизнь с чистого листа — не допускаем появления новых предупреждений и можем даже на радостях поменять настройки проекта — включить treat warnings as errors.
По мере рефакторинга отдельных частей можно будет возвращатсья к игнорированным предупреждениям и вычищать их «по правильному»
Ну, автор статьи уже выше ответил, что даже если изменится один проект из восьмидесяти, то на этот проект будет достаточная пачка warning'ов, чтобы отпугнуть делать такие эксперименты.
Хотя я еще попробую как-то оптимизировать этот процесс, когда буду прикручивать PGO к проекту :)
Я сейчас планирую попробовать PGO на VC и GCC на реальном проекте. Изначально думал о том, чтобы данные для профиля собрать один раз, хранить в репозитории, и, скажем, обновлять раз в месяц (проект не сильно активно изменяется).
Получится ли такое? Или это как файлы с символами — должно быть абсолютное совпадение?
Если нету контекста — то (в терминах C++) получаем неопределенное поведение. Ну а при наличии контекста — с учетом его.
К этому я и писал — на следующий этап контекстного анализа стоит забрасывать все (ну или хотя бы лучшие) варианты разбора, а потом уже разрешать неоднозначности.
Вот неплохая статья по поводу синтаксического разбора: www.cs.cmu.edu/~alavie/papers/thesis.pdf. В частности, рассматриваются проблемы неоднозначности и прочее.
Конечно, они там решают более сложную проблему — распознавание смысла предложений, полученных после распознавания речи, но, думаю, будет познавательно.
Простите, а как ваш парсер разберет предложение «еду на стол»? Как «едУ на стол» или как «Еду на стол»?
Это я к тому, что «алгоритм анализа предложения достаточно прост и может быть описан в виде состояний конечного автомата». Если подразумевается, что достаточно LR-разбора, то это не так.
Как минимум нужен GLR-парсер для того, чтобы парсер мог обрабатывать ветвления, а потом еще и лучшие варианты нужно вписывать в контекст (чему вообще только один абзац посвящен).
Ну, разница между freeware и trialware все-таки есть, хотя если трактовать термин «бесплатный» в отрыве от этих общепринятых определений — то можно прийти и к тому, что триал — бесплатная программа
А я правильно понимаю, что SetThreadPriority(h, THREAD_MODE_BACKGROUND_BEGIN) устанавливает приоритет в минимальный, а SetThreadPriority(h, THREAD_MODE_BACKGROUND_END) возвращает IoPriorityNormal?
Также интересно, влияет ли еще на какие-то приоритеты THREAD_MODE_BACKGROUND_BEGIN — в документации упомянуто про «resource scheduling priorities», что намекает на несколько уровней приоритета
Спасибо за статью!
Можно поподробнее про приоритеты ввода \ вывода (в статье такая формулировка, как будто их много, а я встречал только два — нормальный и низкий).
А также про регулирование приоритета памяти? Не встречал такого API
Алгоритм-то должен не доказывать факт остановки при конкретных данных, а проверять возмонжость не остановки при любых данных.
При этом он, как я понимаю, может работать с входным алгоритмом как с белым ящиком.
Я не утверждаю, что разработка такого алгоритма возможна, просто показываю, что доказательство, приведенное в статье явно упрощено до некорректности.
Вероятно, профиль запоролся каким-то образом.
Подобное было еще несколько месяцев назад, когда карты Яндекса вместо карта начали показывать какие-то другие картинки из кеша. Тогда обошелся малой кровью — просто почистил все кеши.
Что особенно порадовало — обещали промежуточный релиз компилятора Visual C++, не привязанный к новому релизу Студии именно для еще большей поддержки стандарта.
Warning'и можно отключить локально — только в том месте, где мы о нем знаем.
Итак, отключаем локально все ворнинги (да, работа еще та, но любой скриптовый язык в этом поможет), проверяем, что ничего не сломали (на всякий случай — код-то не менялся), а потом начинаем жизнь с чистого листа — не допускаем появления новых предупреждений и можем даже на радостях поменять настройки проекта — включить treat warnings as errors.
По мере рефакторинга отдельных частей можно будет возвращатсья к игнорированным предупреждениям и вычищать их «по правильному»
Хотя я еще попробую как-то оптимизировать этот процесс, когда буду прикручивать PGO к проекту :)
Получится ли такое? Или это как файлы с символами — должно быть абсолютное совпадение?
К этому я и писал — на следующий этап контекстного анализа стоит забрасывать все (ну или хотя бы лучшие) варианты разбора, а потом уже разрешать неоднозначности.
Конечно, они там решают более сложную проблему — распознавание смысла предложений, полученных после распознавания речи, но, думаю, будет познавательно.
Это я к тому, что «алгоритм анализа предложения достаточно прост и может быть описан в виде состояний конечного автомата». Если подразумевается, что достаточно LR-разбора, то это не так.
Как минимум нужен GLR-парсер для того, чтобы парсер мог обрабатывать ветвления, а потом еще и лучшие варианты нужно вписывать в контекст (чему вообще только один абзац посвящен).
Также интересно, влияет ли еще на какие-то приоритеты THREAD_MODE_BACKGROUND_BEGIN — в документации упомянуто про «resource scheduling priorities», что намекает на несколько уровней приоритета
Можно поподробнее про приоритеты ввода \ вывода (в статье такая формулировка, как будто их много, а я встречал только два — нормальный и низкий).
А также про регулирование приоритета памяти? Не встречал такого API