Супер надежный как chrome C++ и портативный - советы - справка - комментарии

Вы не упоминаете, каков целевой проект; наличие процесса для каждой вкладки вовсе не обязательно означает более «надежный» код. Вы должны стремиться писать надежный код с тестами независимо от переносимости - просто прочтите о написании хорошего кода на C++ :)

Что касается раздела о переносимости, убедитесь, что вы тестируете обе платформы с первого дня, и убедитесь, что новый код не написан до тех пор, пока не будут решены проблемы, связанные с конкретной платформой.

Вы действительно, действительно не хотите делать то, что делает Chrome, для этого требуется диспетчер процессов, который, вероятно, является излишним для того, что вы хотите.

Вам следует изучить использование интеллектуальных указателей от Boost или другого инструмента, который обеспечит подсчет ссылок или сборку мусора для C++.

В качестве альтернативы, если у вас часто возникают сбои, возможно, вам стоит подумать о написании критически важных для производительности частей вашего приложения на языке сценариев, который имеет привязки C++.

Вы всегда можете добавить в свою программу обработку исключений, чтобы улавливать подобные ошибки и игнорировать их (хотя детали зависят от платформы) ... но это в значительной степени палка о двух концах. Вместо этого подумайте о том, чтобы программа перехватывала исключения и создавала файлы дампа для анализа.

Если ваша программа вела себя неожиданным образом, что вы знаете о своем внутреннем состоянии? Может быть, рутина / поток, в котором произошел сбой, повредили какую-то структуру ключевых данных? Может быть, если вы поймаете ошибку и попытаетесь продолжить, пользователь сохранит все, над чем он работает, и зафиксирует повреждение на диске?

Эффективный C++ и Более эффективный C++ Скотта Мейерса очень хороши, и их интересно читать.

Код завершен Стива МакКоннелла - фаворит многих, в том числе Джеффа Этвуда.

Библиотеки Boost, вероятно, отличный выбор. Один проект, в котором я работаю, использует их. Я сам использовал только потоки WIN32.

Ответ Chrome больше касается предотвращения сбоев, а не качества кода. Делать то, что делает Chrome, означает признать поражение.

1. Лучшее обеспечение качества - это больше, чем просто тестирование программистом своей работы.
2. Модульное тестирование
3. Регрессионное тестирование
4. Ознакомьтесь с лучшими практиками, которые другие компании используют.

Откровенно говоря, если ваше программное обеспечение часто дает сбой из-за переполнения и неправильной инициализации, то у вас есть очень простая проблема качества программирования, которую нелегко исправить. Это звучит нелепо и означает, что это не мое намерение. Я хочу сказать, что проблема с плохим кодом должна быть вашей главной заботой (я уверен, что это так). Такие вещи, как Chrome или либеральное использование обработки исключений для выявления ошибок программы, только отвлекают вас от реальной проблемы.

Помимо написания более стабильного кода, вот еще одна идея, которая отвечает на ваш вопрос.

Используете ли вы процессы или потоки. Вы можете написать небольшую / простую сторожевую программу. Затем другие ваши программы регистрируются с этим сторожевым псом. Если какой-либо процесс умирает или поток умирает, он может быть перезапущен сторожевым таймером. Конечно, вы захотите провести некоторый тест, чтобы убедиться, что вы не перезапускаете тот же самый поток с ошибками. то есть: перезапустите его 5 раз, затем после 5-го выключите всю программу и войдите в файл / системный журнал.

Создайте свое приложение с символами отладки, затем либо добавьте обработчик исключений, либо настройте Dr Watson для создания аварийных дампов (запустите drwtsn32.exe / i, чтобы установить его в качестве отладчика, без / i, чтобы открыть диалоговое окно конфигурации). Когда ваше приложение выходит из строя, вы можете проверить, где оно пошло не так, в windbg или visual studio, просмотрев стек вызовов и переменные.

Google для сервера символов для получения дополнительной информации.

Очевидно, вы можете использовать обработку исключений, чтобы сделать ее более надежной, и использовать интеллектуальные указатели, но лучше всего исправить ошибки.

Создавайте его с мыслью, что единственный способ выйти - это дать сбой программы и что она может аварийно завершить работу в любой момент. Когда вы построите его таким образом, сбой никогда / почти никогда не приведет к потере данных. Я читал об этом статью год или два назад. К сожалению, у меня нет ссылки на это.

Объедините это с каким-то аварийным дампом и отправьте его вам по электронной почте, чтобы вы могли решить проблему.

Я бы порекомендовал вам скомпилировать версию для Linux и запустить ее под Валгринд.

Valgrind отслеживает утечки памяти, чтение неинициализированной памяти и многие другие проблемы с кодом. Я очень рекомендую это.

Я согласен с Торлаком.

Плохая инициализация или переполнение - признаки некачественного кода.

Google поступил так, потому что иногда не было возможности контролировать код, который выполнялся на странице (из-за неисправных плагинов и т. д.). Так что, если вы используете плагины низкого качества (такое бывает), возможно, решение Google вам подойдет.

Но программа без плагинов, которая часто дает сбой, просто плохо написана, или очень сложна, или очень старая (и ей не хватает времени на обслуживание). Вы должны остановить разработку и исследовать каждый сбой. В Windows скомпилируйте модули с PDB (программными базами данных) и каждый раз, когда он выйдет из строя, присоедините к нему отладчик.

Вы также должны добавить внутренние тесты. Избегайте шаблона:

doSomethingBad(T * t)
{
   if (t == NULL) return ;

   // do the processing.
}

Это очень плохой дизайн, потому что ошибка есть, и вы просто избегаете ее, в это время. Но следующая функция без этого охранника выйдет из строя. Лучше раньше рухнуть, чтобы быть ближе от ошибки.

Вместо этого в Windows (в MacOS должен быть аналогичный API)

doSomethingBad(T * t)
{
   if (t == NULL) ::DebugBreak() ; // it will call the debugger

   // do the processing.
}

(не используйте этот код напрямую ... Поместите его в определение, чтобы не доставить его клиенту ...) Вы можете выбрать API ошибок, который вам подходит (исключения, DebugBreak, assert и т. д.), Но использовать его, чтобы остановить, когда код узнает, что что-то не так.

По возможности избегайте C API. Используйте идиомы C++ (RAII и т. д.) И библиотеки.

Так далее..

P.S .: Если вы используете исключения (что является хорошим выбором), не прячьте их внутри ловушки. Вы только усугубите свою проблему, потому что там есть ошибка, но программа будет пытаться продолжить и, вероятно, иногда выйдет из строя, и тем временем повредит все, к чему она прикасается.

Я разработал множество многоплатформенных приложений C++ (самые большие из них составляют 1,5 миллиона строк кода и работают на 7 платформах - AIX, HP-UX PA-RISC, HP-UX Itanium, Solaris, Linux, Windows, OS X). . На самом деле в вашем посте есть две совершенно разные проблемы.

1. Нестабильность. Ваш код нестабилен. Почини это.

   • Используйте модульные тесты, чтобы найти логические проблемы, прежде чем они вас убьют.
   • Используйте отладчики, чтобы выяснить, что вызывает сбои, если это неочевидно.
   • Используйте boost и подобные библиотеки. В частности, типы указателей помогут избежать утечек памяти.

2. Кросс-платформенное кодирование.

   • Опять же, по возможности используйте библиотеки, предназначенные для этого. Особенно для любых битов графического интерфейса.
   • По возможности используйте стандарты (например, ANSI против gcc / MSVC, потоки POSIX против моделей потоков, специфичных для Unix и т. д.), Даже если для этого потребуется немного больше работы. Сведение к минимуму кода, специфичного для вашей платформы, означает меньше общей работы и меньше API для изучения.
   • Изолировать, изолировать, изолировать. По возможности избегайте встроенных #ifdef для разных платформ. Вместо этого вставьте код, специфичный для платформы, в его собственный заголовок / исходный код / ​​класс и используйте свою систему сборки и #includes, чтобы получить правильный код. Это помогает сохранять код чистым и читаемым.
   • По возможности используйте целочисленные типы C99 вместо long, int, short и т. д. - иначе он укусит вас, когда вы перейдете с 32-битной платформы на 64-битную, и longs внезапно изменится. от 4 байтов до 8 байтов. И если это когда-либо будет записано в сеть / диск / и т. д., Вы столкнетесь с несовместимостью между платформами.

Лично я бы сначала стабилизировал код (без добавления дополнительных функций), а затем решал бы кроссплатформенные проблемы, но это зависит от вас. Обратите внимание, что в Visual Studio есть отличный отладчик (упомянутая выше база кода была перенесена в Windows именно по этой причине).

После более чем 15 лет разработки Windows я недавно написал свое первое кроссплатформенное приложение на C++ (Windows / Linux). Вот как:

• STL
• Способствовать росту. В частности, файловая система и библиотеки потоков.
• Пользовательский интерфейс на основе браузера. Приложение выполняет HTTP, а пользовательский интерфейс состоит из XHTML / CSS / JavaScript (стиль Ajax). Эти ресурсы встроены в код сервера и при необходимости передаются браузеру.
• Обильное модульное тестирование. Не совсем TDD, но близко. Это фактически изменило способ моего развития.

Я использовал NetBeans C++ для сборки Linux и получил полный порт Linux в кратчайшие сроки.