Супернадежный, как Chrome C++ и портативный - советы - помощь - комментарии [закрыто]

Question

Мы создаем переносимый код (win+macOs) и ищем способ сделать его более надежным, поскольку он время от времени дает сбой...(обычно переполнение или неправильная инициализация):-(

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

Поэтому мне было интересно, есть ли у кого-нибудь какие-нибудь советы, помощь, список для чтения, комментарии или что-то еще, что может помочь мне создать больше кода Rubust C++ (портативный вариант всегда лучше).

В той же теме мне также было интересно, есть ли портативная библиотека для процессов (например, boost)?

Ну большое спасибо.

Answer 1

Я разрабатывал множество мультиплатформенных приложений на 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 для изучения.
   • Изолировать, изолировать, изолировать.По возможности избегайте встроенных #ifdefs для разных платформ.Вместо этого вставьте код, специфичный для платформы, в его собственный заголовок/исходный код/класс и используйте свою систему сборки и #includes, чтобы получить правильный код.Это помогает сохранить код чистым и читаемым.
   • Используйте целочисленные типы C99, если это возможно, вместо «long», «int», «short» и т. д. — иначе это укусит вас, когда вы перейдете с 32-битной платформы на 64-битную, и длинные длины внезапно изменятся. от 4 байт до 8 байт.И если это когда-либо будет записано в сеть/на диск/и т. д., вы столкнетесь с несовместимостью между платформами.

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

Вы действительно, действительно не хотите делать то, что делает Chrome, для этого требуется диспетчер процессов, который, вероятно, СЛИШКОМ излишен для того, что вы хотите.

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

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

Answer 5

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

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

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

Answer 6

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

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

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 ошибки, которая подходит вам (исключения, отладочная взрыва, утверждение и т. Д.), Но использовать его, чтобы остановить момент, когда код знает, что что -то не так.

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

И т. д..

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

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

Answer 11

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

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

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

Answer 12

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

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