Бьёрн Страуструп (Bjarne Stroustrup), создатель языка C++, опубликовал возражения против выводов, сделанных в отчёте АНБ, в котором организациям было рекомендовано отойти от использования языков программирования, таких как Си и Си++, перекладывающих управление памятью на разработчика, в пользу языков, таких как C#, Go, Java, Ruby, Rust и Swift, обеспечивающих автоматическое управление памятью или выполняющих проверки безопасной работы с памятью во время компиляции.
По мнению Страуструпа упомянутые в отчёте АНБ безопасные языки на деле не превосходят C++ в важных с его точки зрения применениях. В частности, развиваемые последние годы базовые рекомендации по использованию C++ (C++ Core Guidelines) охватывают методы безопасного программирование и предписывают применение средств, гарантирующих безопасную работу с типами и ресурсами. При этом разработчикам, которым не требуются подобные строгие гарантии безопасности, оставляется возможность продолжения использования старых методов разработки.
Страуструп считает, что хороший статический анализатор, соответствующий рекомендациям C++ Core Guidelines, может обеспечить необходимые гарантии безопасности C++ кода, требуя значительно меньше затрат, чем переход на новые безопасные языки программирования. Например, большинство рекомендаций Core Guidelines уже реализованы в статическом анализаторе и профиле безопасной работы с памятью из состава Microsoft Visual Studio. Часть рекомендаций также учтена в статическом анализаторе Clang tidy.
Объектом критики также стало акцентирование отчёта АНБ только на проблемах работы с памятью, оставляя без внимания многие другие проблемы языков программирования, влияющие на безопасность и надёжность. Страуструп рассматривает безопасность как более широкое понятие, различные грани которого могут быть достигнуты комбинацией стиля написания кода, библиотек и статических анализаторов. Для управления включением правил, обеспечивающих безопасность работы с типами и ресурсами, предлагается использовать аннотации в коде и опции компиляторов.
В приложениях, в которых производительность важнее безопасности, подобный подход даёт возможность выборочного применения средств, гарантирующих безопасность только там, где это необходимо. Инструменты повышения безопасности также можно применять частично, например, вначале ограничиться правилами проверки диапазонов и инициализации, а затем постепенно адаптировать код для более строгих требований.