ambiguous overload for 'operator[]' during compilation of Code::Blocks

User forums > Using Code::Blocks

(1/4) > >>

KirkD:
I just pulled down the latest SVN for Code::Blocks (6857) and have started building it on a 64-bit CentOS box. I've gotten a number of errors of this sort during build:

uservarmanager.cpp: In member function 'void UsrGlblMgrEditDialog::Sanitise(wxString&)':
uservarmanager.cpp:120: error: ambiguous overload for 'operator[]' in 's'
uservarmanager.cpp:120: note: candidates are: operator[](const wxChar*, long int) <built-in>
/usr/include/wx-2.8/wx/string.h:822: note: wxChar& wxString::operator[](int)
/usr/include/wx-2.8/wx/string.h:824: note: wxChar& wxString::operator[](size_t)

The first was associated with /usr/include/wx-2.8/wx/filename.h and I found the fix was to change the [0u] in line 393 to [(size_t)0u].

Now, I've gotten the same error for for /src/sdk/cbeditor.cpp and also /src/sdk/uservarmanager.cpp (above). I'm hoping there's a compiler switch that can be set to let this go, but I have yet to find it.

Any tips are appreciated.

-Kirk

As I'm looking a little closer I see that I could probably get the same result by converting to (int) rather than (size_t). The index to the wx string::operator[] is a long int, but the operator function expects either size_t or int.

UPDATE: I can get this error to pass if I set CXXFLAGS and CFLAGS to -m32 prior to running ./configure. I then get errors due to 32-bit vs. 64-bit GCC libraries. I haven't yet tried pushing the 32-bit libraries.

Jenna:
Where did you get your wyWidgets from.

There should be a a third overload for operator[] in string.h (and array.h), if size_t is not unsigned int:

--- Code: --- // operator versions of GetWriteableChar()
wxChar& operator[](int n)
{ return wxStringBase::at(n); }
wxChar& operator[](size_type n)
{ return wxStringBase::at(n); }
#ifndef wxSIZE_T_IS_UINT
wxChar& operator[](unsigned int n)
{ return wxStringBase::at(n); }
#endif // size_t != unsigned int

--- End code ---

So I think our code should be valid in any cases.

KirkD:
The wxWidgets that I am using is a package associated with CentOS 5.5, x86_64. It may have come from rpmfusion, but I'm not certain of that. It is version 2.8.11, the current stable release from wxWidgets.

The odd part is that the original error arose from one of wx's own source files - /usr/include/wx-2.8/wx/filename.h. I found the fix to this through a simple Google search - described in my first post.

I looked into the wx string.h file and I see the same code section that you posted, specifically

--- Code: ---// operator versions of GetWriteableChar()
   wxChar& operator[](int n)
   { return wxStringBase::at(n); }
   wxChar& operator[](size_type n)
   { return wxStringBase::at(n); }
#ifndef wxSIZE_T_IS_UINT
   wxChar& operator[](unsigned int n)
   { return wxStringBase::at(n); }
#endif // size_t != unsigned int

--- End code ---

I'm compiling with GCC 4.4.5 - not sure if that has any impact as I didn't check to see how or where wxSIZE_T_IS_UINT is or isn't defined.

The alternative that I am just beginning to try is to add another function to string.h:

--- Code: ---wxChar& operator[](long n)
{ return wxStringBase::at(n); }
wxChar& operator[](unsigned int n)
{ return wxStringBase::at(n); }

--- End code ---
Seems easier that changing all the instances where a long is passed in the Code::Blocks source.

Edit:

This seemed to fix the symptom and Code::Blocks is compiling nicely now. I'm unsure as to why this should occur to begin with. I haven't dug deep into the wx code or addressed that community just yet - that is my next task. From what I can find, this is a 64-bit issue, but again, I can't wrap my head around why it should be an issue. It seems that long, unsigned int, and size_t are all expected to exist as different function signatures.

Edit:

I verified that my wx package came from the epel repo, the Fedora/RedHat Enterprise Linux repository.

KirkD:
Interestingly, I just tried the same process on a Fedora 14 x86_64 installation and the code change was not necessary. The same version of wxWidgets (v2.8.11) is present. GCC v4.1.2 is on that system.

Jenna:
I tried it on CentOs 5.5 with wxGTK 2.8.10 from rpmforge and it works fine.
You can look into /usr/lib64/wx/include/gtk2-unicode-release-2.8/wx/setup.h to see whether wxSIZE_T_IS_UINT is defined or not.
It should be:

--- Code: ---/* Define if size_t on your machine is the same type as unsigned int. */
/* #undef wxSIZE_T_IS_UINT */

/* Define if size_t on your machine is the same type as unsigned long. */
#define wxSIZE_T_IS_ULONG 1

--- End code ---
on 64-bit systems.
It looks like the package is not configured or build correctly or the setup.h is from a 32-bit build (or a build on a 32-bit machine).

Navigation

[0] Message Index

[#] Next page

Go to full version