Analysis of String Literal to char* Conversion Differences Between C and C++

Nov 23, 2025 · Programming · 11 views · 7.8

Keywords: C++ | String Literal | Type Conversion | Type Safety | C++11 Standard

Abstract: This article provides an in-depth analysis of the differences in string literal to char* pointer conversion between C and C++ programming languages. It examines the historical evolution of these conversion rules, explains the rationale behind the removal of implicit conversion in C++11, discusses safety concerns with explicit casting, and offers proper type declaration recommendations. The article also demonstrates real-world type conversion issues through practical DeepStream framework case studies.

Historical Evolution of String Literal Types

Throughout the development of programming languages, C and C++ have undergone significant changes in their treatment of string literal types. String literals such as "abc" are typically stored in read-only memory regions, where any modification attempts result in undefined behavior. In the C language, string literals are implicitly converted to <code>char*</code> type, a design primarily based on historical compatibility considerations that allows extensive existing C code to continue functioning.

Major Changes in C++11 Standard

The C++11 standard represents a significant advancement in type safety. According to section C.1.1 of the ISO/IEC 14882:2011 standard, implicit conversion from string literals to <code>char*</code> has been formally removed. The core reason for this change is to enhance type safety—the content of string literals is inherently immutable and should therefore be correctly marked as <code>const char*</code> type.

The standard clearly distinguishes the legality of two scenarios:

char* p = "abc";        // Invalid in C++11
char* p = (char*)"abc";  // Valid in C++11

Safety Risks of Explicit Casting

Although explicit casting <code>(char*)"abc"</code> is syntactically permitted, this does not imply it represents safe programming practice. Explicit casting merely bypasses the compiler's type checking without altering the read-only nature of string literals. Any write operations through pointers obtained via such casting will still cause program crashes or undefined behavior.

Proper Type Declaration Approaches

To ensure code safety and portability, the recommended approach is to use correct type declarations:

const char* p = "abc";  // Valid and safe in both C and C++

This declaration method explicitly indicates that the pointed-to content is immutable, complying with language specifications while providing complete compiler protection.

Type Conversion Issues in Real Projects

In DeepStream framework development, we frequently encounter similar type conversion issues. As illustrated in the referenced article's error case:

deepsteam_nvdsanalytics_test.cpp:132:45: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
txt_params->font_params.font_name = "Serif";

This warning directly reflects the type safety requirements of the C++11 standard. Developers must pay attention to type matching when assigning string literals to target pointers.

Compatibility Considerations and Best Practices

Standard committees face the challenge of balancing compatibility with safety when establishing specifications. The continued legality of explicit casting primarily provides migration paths for existing code while encouraging developers to gradually adopt safer programming patterns.

In practical development, we recommend:

Conclusion

The modification of string literal conversion rules in C++11 demonstrates modern programming languages' emphasis on type safety. Although explicit casting remains syntactically possible, the correct approach is to use appropriate <code>const</code> qualifiers. This change not only improves code safety but also promotes clearer expression of programming intent. Following these best practices in actual project development can effectively prevent potential memory access errors while enhancing code quality and maintainability.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.