GCC 4.3 complains about deprecated conversion from string constant to char*

[Peter]

I get the following warning when compiling with gcc 4.3.1

commandline_test.cc:641: error: deprecated conversion from string constant to char*

[Peter]

fixed in r2191

[Peter]

It turned out that the fix in r2191 did not only change the ABI but also the API. I thought that code written against yat 0.5.x would work against 0.6 as well, but that is not the case.

I have the following (slimmed down) piece of code:

int main(int argc, char* argv[])
{
    yat::utility::CommandLine cmd;
<snip>
    try {
        cmd.parse(argc, argv);
    }
<snip>

which gives the following compilation error:

g++ -DHAVE_CONFIG_H -I. -I../../mot -I..     -Wall -pedantic -MT datafile.o -MD -MP -MF .deps/datafile.Tpo -c -o datafile.o ../../mot/datafile.cc
../../mot/datafile.cc: In function ‘int main(int, char**)’:
../../mot/datafile.cc:28: error: no matching function for call to ‘theplu::yat::utility::CommandLine::parse(int&, char**&)’
/usr/local/include/yat/utility/CommandLine.h:141: note: candidates are: void theplu::yat::utility::CommandLine::parse(int, const char**) <near match>

The obvious fix would be as below:

-int main(int argc, char* argv[])
+int main(int argc, const char* argv[])

But I dislike this fix for two reasons. 1) I have to modify my code. I think when updating to a new yat there should be no (or minimial) need for modifications in my code. 2) According to Josutti, the standard has two versions of main:

int main(void);
int main(int, char**)

which means that in my fix above, I use some kind of non-standard version of main. That is ugly.

I suggest that we revert r2191. If possible fix the compiler warnings described in the description, but if we cannot find a quick alternative solution I don't think we should postpone the release of 0.6 but rather postpone the fix for 0.7 (or 0.6.x perhaps).

Thoughts?

[Jari Häkkinen]

I tried a few ways to fix the issue but failed. One solution would be to have two parse functions. I am not sure if I like that so I suppose we should revert the change and move the issue to 0.7 or later.

[Peter]

OK, I'll revert and move the ticket to a later milestone

[Peter]

(In [2194]) refs #572. revert r2191

[Peter]

(In [2195]) fixes #572