const wxChar array shouldn't be a structure member

[Richard Lloyd]

In FileZilla Client 3.1.6, src/interface/Options.cpp declares a t_default_option structure containing a const wxChar array (name[30] - see line 132). However, such a const array can never be initialised, so HP's C++ compiler in HP-UX 11.X refuses to compile the source code. I removed the const keyword and this fixed the problem.

[Tim Kosse]

Are you sure it's invalid C++ and not merely a bug in your compiler? In the latter case, you need to upgrade to a better compiler.

[Richard Lloyd]

I think it's invalid C++ - aren't const char arrays only ever supposed to be initialised at declaration time (e.g. with = "This is a string"; or something like that)? Otherwise, why make the char array const if you're intending to modify it later in the code?

I think the HP C++ compiler is right that trying to put a const array inside a structure is invalid code, because it's impossible to ever legally assign a value to such an array (I don't even think the declaration-time assignment of a string I suggested above is legal in this context, which is why the compiler flagged it as an error).

It's no big deal, because the fix is simply to remove the const keyword, but I wouldn't be surprised if other non-g++ C++ compiler took a dislike to it too. I'm wondering if gcc just simply ignores the const keyword silently and just makes it behave like a normal char array (in which case, gcc is the "worse" compiler in this case :-) ). The recent 3.2.0rc1 release still has this issue, but as I said, there's an easy workaround, so I'm not fussed either way.

[Tim Kosse]

A variable declaration is just that, a declaration. A variable only gets a value assigned when it gets defined (or instanciated). Initializer lists can be used at definition of a structure instance to give all members a value, even the const ones.

Note that wxChar is just a typedef for either char or wchar_t (depending if wxWidgets got compiled with Unicode support or not).

You said that the t_default_option instance makes problems, but didn't mention the instance of t_Option as making problems. In both cases there's a const array, once of type char and once of type wxChar.

So it shouldn't make a difference. A proper compiler should either accept both or reject both, depending on what the C++ standard says. But just failing one of the cases looks to me like a compiler error.

[Alexander Schuch]

I guess the problem is "solved"?

I am closing this case. If there are still compiling problems with non-GCC compilers for the mentioned case, please feel free to re-open this issue.