Created attachment 743 [details] Patch I will summarize here the error and how I fixed it. When compiling GEANT4.11.0 on windows using VS2019 v16.11.8 (in fact it will happen with all versions above 16.1), the compiler provides multiple errors C2666 indicating for operator[] from G4String: number overloads have similar conversions. This comes from a change introduced recently in MSVC, according to https://docs.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#ranking-of-enum-conversion-to-its-fixed-underlying-type The way I fixed the problem is detailed below. Please note that I also tried to compile the code with my modifications on Linux and to execute it on a simple example with success. In the different files I mentioned in my previous message above, the problem comes from the use of G4String::operator[] instead of G4String::at() At multiple locations in the code, one can find (for example) if (!(jslash == indx && bpath[indx] == '/')) // Whereas the correct use should be if (!(jslash == indx && bpath.at(indx) == '/')) Please find attached a patch.
Thanks for the patch - we'll take a look.
Created attachment 750 [details] Patch for G4String C2666 errors on MSVC
We've reproduced and identified the heart of the problem, which is down to G4String providing both an implicit conversion operator to const char* and subscript operator. MSVC looks to be the first to be strict about this, or older/other compilers can work around it. The overload that causes confusion is actually the builtin operator[](const char*, int) which is considered due to GString's conversion to const char*. Rather than patch calls to G4String::operator[](size_type) with G4String::at(size_type), an additional overload G4String::operator[](int) is provided, resolving the ambiguity, and is attached here. This is purely a workaround until removal of the const char* conversion operator is removed, but has been tested to work on both latest Visual Studio 2019 and 2022, with no issues identified on other platforms/compilers.
Whoops, forgot to say of course this fix will be in the next patch to 11.0, due in the next couple of weeks!
