Is it bad coding practice to use #defines for string literals ?

[sanjay vyas]

During a recent code review it was pointed out to me that it is bad to use #define for string literals because :

while making your debug build your compiler makes a separate copy of the string for each use, in your exe, while in your release build it ptimizes this to make just one string

Now if you are passing your string to a function as an argument and that function modifies it, you
are safe in your debug build becoz each usage is a new string however, in your release build you
are dead cause the subsequent uses of that string points to modified/corrupt data

I have therefore been advised to use a global array of const char*s.

Any opinions/alternative solutions will be welcome

Thanx

sanjay

[Michael Decker]

Is this a VC++ project?

If so, put string literals in the string table. This provides for a centralized location to modify strings in the future and is easier for possible localization efforts.

If not, then 'const char *' provides a better solution for type checking anyway.

[Kevin Delgado]

Why in the world would you be modifying a string define???

In terms of internationalization, you would want to put strings into the string table so that you can provide localized resources (putting the strings into CStrings in your code via LoadString() ). So, for me that would be the biggest reason NOT to put them in defines.

For stuff like Registry key information, it isn't a problem since you don't really want that stuff translated anyways.

Global strings just sound icky to me in general

[Mark Messer]

For advice on this question on many like it, see Effective C++, by Scott Meyers. See page 10 for this. He recommends const and inlines instead of #defines.

[Dave Lorde]

> while making your debug build your compiler makes a separate copy of the
> string for each use, in your exe, while in your release build it ptimizes
> this to make just one string

Whether this happens or not is compiler implementation dependent. There is no requirement for compilers to do this. Some compilers make a configurable option.

> Now if you are passing your string to a function as an argument and that
> function modifies it, you are safe in your debug build becoz each usage is a
> new string however, in your release build you are dead cause the subsequent
> uses of that string points to modified/corrupt data

In C++ it is totally unsafe either way. The result of attempting to modify a string literal is undefined (meaning it is not a valid operation). Doing this is *wrong*, and IMO the compiler should give an error.

> I have therefore been advised to use a global array of const char*s.

In C++ the use of global variables is considered very poor practice. Why use char*s when you can use string objects, why use either for literal strings if a string table resource is available?

Dave