Problem 2463

Summary:	Building G4.11 on Windows with VS2019 above v16.1
Product:	Geant4	Reporter:	Thomas Frosio <thomas.frosio>
Component:	global	Assignee:	Ben Morgan <Ben.Morgan>
Status:	CLOSED FIXED
Severity:	normal
Priority:	P4
Version:	11.0
Hardware:	PC
OS:	Windows
URL:	https://geant4-forum.web.cern.ch/t/building-g4-11-on-windows-with-vs2019-v16-11-8/6762/2
Attachments:	Patch Patch for G4String C2666 errors on MSVC

Description Thomas Frosio 2022-01-07 19:30:42 CET

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.

Comment 1 Ben Morgan 2022-01-31 16:12:39 CET

Thanks for the patch - we'll take a look.

Comment 2 Ben Morgan 2022-02-19 14:27:39 CET

Created attachment 750 [details]
Patch for G4String C2666 errors on MSVC

Comment 3 Ben Morgan 2022-02-19 14:35:05 CET

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.

Comment 4 Ben Morgan 2022-02-19 14:35:56 CET

Whoops, forgot to say of course this fix will be in the next patch to 11.0, due in the next couple of weeks!