Ambiguous overload error when using /wx/filename.h, depends on wxSIZE_T_IS_UINT. (Issue #23004)
Carlo Bramini
When using wx/filename.h, I'm constantly getting this error:
/usr/i686-w64-mingw32/sys-root/mingw/include/wx-3.2/wx/filename.h: In static member function 'static wxUniChar wxFileName::GetPathSeparator(wxPathFormat)':
/usr/i686-w64-mingw32/sys-root/mingw/include/wx-3.2/wx/filename.h:493:43: error: ambiguous overload for 'operator[]' (operand types are 'wxString' and 'unsigned int')
493 | { return GetPathSeparators(format)[0u]; }
| ^
The error seems to be related to the definition of wxSIZE_T_IS_UINT inside platform.h, which causes this function:
to be not declared.
This error happens when using i686-mingw-w64 compiler, but it is not printed when using x86_64-mingw-w64 compiler, which is what I expected from the definitions inside platform.h.
I had posted a patch for fixing this issue:
but it has been rejected, so the problem still exists in the current MASTER.
Another solution can be to provide this operator (and perhaps other types) indipendently by the presence of wxSIZE_T_IS_UINT, but actually the reasons because this conditional compilation exists are unknown to me.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
What is your compiler version and which compilation flags do you use? It looks like size_t is not defined as unsigned int but this is unexpected, all MinGW versions I know about do have size_t == unsigned.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Carlo Bramini
What is your compiler version and which compilation flags do you use? It looks like
size_tis not defined asunsigned intbut this is unexpected, all MinGW versions I know about do havesize_t == unsigned.
I'm using official MinGW-w64 cross compilers provided by CYGWIN.
However, into platform.h there is this line:
The !defined(__WIN64__) is the tricky part, because it makes the difference between x86_64 and i686 compilers, which doesn't seem to happen elsewhere.
However, in my opinion, here:
the second argument is not a type but a literal. It's different.
And, as the the compiler says in its error message, the 0u is recognized as unsigned int which is not the same thing of size_t even if they have same size and same sign.
This is the cause of the problem that I'm getting.
Besides changing 0u to 0 for recognizing the literal as int, the best solution may be to add for completeness two extra operators using unsigned int and unsigned long, indipendently by the declaration of wxSIZE_T_IS_UINT, but I don't know exactly why this has been done in this way then compiling for Windows.
Perhaps, this is an inheritance for supporting ancient version of W32API, when size_t was defined as a macro rather than using a typedef. In that case, this line:
and this line:
were the same thing and they will cause an error at compile time.
If this is the origin of the choice, and you still would like to support such deprecated stuff, probably it would be worth to evaluate if size_t is a macro or a type at configure time, I think.
However, using an int literal into GetPathSeparator() instead of an unsigned int also solves this issue at the root.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
__WIN64__ shouldn't be defined in Win32 build that you use. If it is defined for you, you need to track down where does it come from and fix this.
For the rest, please try doing what you suggest and you will see that you can't overload a function on size_t/unsigned int. Contrary to what you write, they are the same type.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
github-actions[bot]
Closed #23004 as completed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
github-actions[bot]
This issue has been automatically closed because there has been no response to our request for more information from the original author since 100 days and we're unable to do anything about the problem without more information. Please comment on this issue if you can provide any additional data so that we could investigate it further.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.