Hi guys,

I'm trying to convert a char** to a const char**, but my compiler is giving me grief. Is this conversion possible??

I have 2 methods, like this:

const char** Console::getConsoleOutput() {
return this->prevInputs_;
}

const char* Console::getCurrentInput() {
return this->curInput_;
}


prevInputs_ is a char** (i.e. array of char*'s) and curInput_ is a char*.

The second method, getCurrentInput(), compiles fine. However, the first method, getConsoleOutput() gives me the error:
error: invalid conversion from ‘char**’ to ‘const char**’

Is there some way this can be done? I basically don't want any other objects changing the prevInputs_ data.

Thanks guys! I appreciate any help you can offer.

Jarrett

[color=#1C2837]

[color=#000088]const[color=#000000] [color=#000088]char[color=#666600]**[color=#000000] [color=#660066]Console[color=#666600]::[color=#000000]getConsoleOutput[color=#666600]()[color=#000000] [color=#666600]{[color=#000000]
[color=#000088]return[color=#000000] (const char**)[color=#000088]this[color=#666600]->[color=#000000]prevInputs_[color=#666600];[color=#000000]
[color=#666600]}

You need to add an additional level of const to your return value.

<pre>char const * const *Console::getConsoleOutput() {...}</pre>

When automatically adding const to a type of char **, you get char const * const *, not char const **. If you don't protect the first layer of pointers, you can indirectly change the second layer, which is what you're supposed to protect with the first const. Consider this (if the second const wasn't necessary, that is):

<pre>
char const **foo = myConsole.GetConsoleOutput();
foo[0] = "bar";
</pre>

Even though the values of foo was protected by const, I could change it via a non-const pointer.

Thanks Brother Bob and marius1930 for your replies.

Hmm, interesting..I thought about that Brother Bob, but I had no idea what the syntax would be. I thought that in order to make the value that is being pointed to constant, you had to put the 'const' before the variable type? As in
const char* const* Console::getConsoleOutput() {...}
?

Wouldn't what you have make the pointers that point to the char*'s const, but allow you to change the value they point to? haha I dunno, const confuses me sometines. Still learning c++.

I got the above to compile, but don't have time right now to test it. I'll do that in a bit and hopefully it works out

Thanks again guys!

You need to add an additional level of const to your return value.

<pre>char const * const *Console::getConsoleOutput() {...}</pre>

When automatically adding const to a type of char **, you get char const * const *, not char const **. If you don't protect the first layer of pointers, you can indirectly change the second layer, which is what you're supposed to protect with the first const. Consider this (if the second const wasn't necessary, that is):

<pre>
char const **foo = myConsole.GetConsoleOutput();
foo[0] = "bar";
</pre>

Even though the values of foo was protected by const, I could change it via a non-const pointer.

The placement of the const around the type makes no difference, T const and const T are idenical. I'm just used to writing T const, as it is typically consistent with how const is applied when you have multiple levels of indirections, like your double pointer. It's just an academic difference though.

Yes, you are correct that putting const in front of it will make it so that you cannot change it. So if you have const char ** foo, then foo[0][0] is const and you cannot write to it. That's fine, and just what you wanted. But the point is that foo[0] is not const, so you can change it. Thus, you can do foo[0] = "bar", because foo[0] is not const. Therefore, to protect the content, you need to make not only the characters of the strings constant, you need to make the pointers constant also, or you can change the content indirectly via the non-const pointers. That is why the language force const onto all levels of pointers if you make it const.

Oh. Thanks makes a lot of sense.

Thanks Brother Bob

Perhaps you got enough of an answer already, but I find this explanation particularly useful, so I thought I would post it.