Может я что-то недопонимаю, но «Android на C#» звучит так, будто ОС написана на этом языке. Наверное, лучше «Android с поддержкой C#» или «Android с C# вместо Java».
В оригинале, кстати: «porting Android 4.0 from Java/Dalvik to C#»
По-моему, главная проблема встроенной навигации — отсутствие показа пробок. Ежедневные маршруты и так известны, а путешествовать каждый день почему-то не получается.
Тут два утверждения, которые противоречат друг другу: «показ assert'ов — это плохо» и «делайте assert'ы на исключениях с транзакционным поведением и обработкой ошибок» (обработка = показ пользователю и восстановление работы?).
Имхо, перехватив исключение, нужно всё-таки показать пользователю ошибку и не пытаться её маскировать. Неопределённое поведение всем выйдет дороже, а протестировать всё — утопия. И да, исключения и транзакционность — это правильно, +1.
Кстати, да — полезная в реализации (своего) assert'а функция: ::DebugBreak() — иммитирует break-point и останавливает отладчик в месте вызова. На других платформах, думаю, есть что-то похожее.
> Когда нельзя использовать assert'ы?
В деструкторах C++ объектов.
Вылет исключения при размотке стека (в деструкторе автоматического объекта) из-за срабатывания другого исключения (например, проверка как-то условия) приводит к аварийному завершению изделия вообще без диагностики.
В Интернет-помошнике есть услуга "запрет смс с коротких номеров". Для корпоративных тарифов можно подключить только через заявление в офисе обслуживания (что удалось выяснить в результате долгих прений со службой поддержки).
И самая «логичная» — через один чередуются въезды, где налево окажешься то на внутренней, то на внешней (направо — соответственно, наоборот). А документация часто висит там, где уже поздно что-то решать.
На навигатор, кстати, не смотрю, ибо поворотам может вообще не оказаться.
Добавил, где искать макросы в офисе.
Пример — создаём текстовый файл text.js и записываем код из первого листинга. Потом создаём пустую книгу excel и перетаскиваем на text.js. Открываем книгу и проверяем, что она уже не такая пустая.
В оригинале, кстати: «porting Android 4.0 from Java/Dalvik to C#»
Проект ещё жив?
(yylloc есть в справке bison'а)
Можно пару примеров из тех миллиардов?
Имхо, перехватив исключение, нужно всё-таки показать пользователю ошибку и не пытаться её маскировать. Неопределённое поведение всем выйдет дороже, а протестировать всё — утопия. И да, исключения и транзакционность — это правильно, +1.
В деструкторах C++ объектов.
Вылет исключения при размотке стека (в деструкторе автоматического объекта) из-за срабатывания другого исключения (например, проверка как-то условия) приводит к аварийному завершению изделия вообще без диагностики.
И т.д., и т.п.
На навигатор, кстати, не смотрю, ибо поворотам может вообще не оказаться.
Пример — создаём текстовый файл text.js и записываем код из первого листинга. Потом создаём пустую книгу excel и перетаскиваем на text.js. Открываем книгу и проверяем, что она уже не такая пустая.