You are here:

C++/Converting char to const char?


Is there any possible way to change a char to a const char? Okay. The problem is that I have a char variable, which I need it to be char because the user enters the value of it. Now, I also need to know the length of what the user entered into it, and the only way to figure that out that I have seen is strlen(variable), and for that to work, it needs to be a const char.

Maybe this will make more sense:
I have a char that once someone enters a value it could look like this:
char word[] = "dogs";

Now, I need to know the lengths of the text they entered. As I said before, the only way I know how to do this would be strlen(variable). If I can convert word[] to a const char, I should be able to use that. If I can't... is there a different way to figure out the number of letters in that text? I am pretty new to this. :)

Did you try to use strlen with your pointer to non-const char?

If you had you would have found that the compiler would have performed the conversion for you. This is because if strlen only requires a pointer to a constant char (implying it only requires read-only access) then passing it a pointer to char (which has read/write access) will just mean that your data will not be modified. That is strlen requirements are a subset of what you have already.

The reverse however is _not_ true. The compiler will _not_ convert a constant value into a non-constant value. This is because such an operation would increase the access to the variable from what the object already has, that is from read-only (i.e. const) to read/write (i.e. non-const). This may not even work if the variable is truly read-only because it is in ROM (Read Only Memory) or memory marked read-only.

This is why it is important to make parameters and member functions const do not modify the objects (variables) in question. Such items can be used with both const and non-const objects. In the case of reference parameters it also allows the passing of temporary objects by (const) reference.

Note that the above does not include parameters passed by value because a copy of the original object is passed to the function so the original can never be modified. Making such parameters const is usually overkill. It does apply to parameters passed by reference (i.e. by pointer or C++ reference). In such cases what is referenced (or pointed to) should be const if possible (i.e. the function does not modify the referred/pointed to object).

You can force the issue if you really need to by using const_cast<T>(o), where T is the type with added or removed const (or volatile), such as char * or char const * and o is the object (i.e. variable) which needs its type modified.

However I _stongly_ advise _not_ doing so. Using casts is usually an indication that something does not quite fit. You are trying to fit a round peg into an oval hole or worse. This is why the C++ cast operators are so ugly and cumbersome and easy to spot in the code. It is like waving a red flag.

You should examine why the compiler is complaining and see if the fix should be elsewhere - e.g. you have a const value and are passing it via a non-const parameter or using a non-const member function of the object. Should the parameter or member function be const, rather than casting away the constness of your object?

Oh, and note that while using a const_cast may keep the compiler quiet if the object really is const because it is in ROM or a memory area marked read only then your program is not going to work as expected - the compiler cannot turn ROM into RAM! Lying to the compiler is a _very_ _bad_ idea.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.