cmd/cgo: cgo-generated header incompatible with latest C++ standards in MSVC

[KangJiJi]

Go version

go version go1.23.3 windows/amd64

Output of go env in your module/workspace:

set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\KangJi\AppData\Local\go-build
set GOENV=C:\Users\KangJi\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\KangJi\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\KangJi\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.23.3
set GODEBUG=
set GOTELEMETRY=local
set GOTELEMETRYDIR=C:\Users\KangJi\AppData\Roaming\go\telemetry
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\KangJi\AppData\Local\Temp\go-build1436118867=/tmp/go-build -gno-record-gcc-switches

What did you do?

I fixed an issue where cgo-generated header files were not compatible with MSVC when using ISO C++ 17 or later. The headers only worked with ISO C++ 14 or earlier due to certain constructs that were deprecated or removed in newer C++ standards.

To reproduce the issue:

• Build a DLL using cgo to generate the corresponding header file.
• Try including the generated header in an MSVC project with C++ standard set to ISO C++ 17 or later (e.g., /std:c++17 or /std:c++20).
• Compilation fails due to incompatibility with newer C++ standards.

What did you see happen?

When compiling the cgo-generated header file in an MSVC project with ISO C++ 17 or later, the compiler produced errors due to the use of constructs that are no longer valid in newer C++ standards.

Example error messages:

error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2146: syntax error: missing ';' before identifier 'GoComplex64'
error C4430: missing t¥pe specifier - int assumed. Note: C++ does not support default-int
error C2146: syntax error: missing ';' before identifier 'GoComplex128'

What did you expect to see?

I expected the cgo-generated header file to be compatible with MSVC regardless of the C++ standard version being used. It should compile without errors in projects using ISO C++ 17, C++ 20, and later, just as it does with ISO C++ 14 or earlier.

The current output is incorrect because it prevents projects that use newer C++ standards from integrating with cgo-generated code. This issue limits compatibility and forces users to downgrade their C++ standard or modify the generated header manually, which is not an ideal solution. The header should be generated in a way that ensures compatibility with modern C++ versions.

[gopherbot]

Change https://go.dev/cl/651935 mentions this issue: cgo: generated headers are incompatible with the latest C++ standards in MSVC

[gabyhelp]

Related Issues

• cmd/go: c-shared header does not compile on Visual Studio #36233 (closed)
• cmd/cgo doesn't use CXXFLAGS #26069 (closed)

Related Code Changes

• cgo: generated headers are incompatible with the latest C++ standards in MSVC
• cmd/go: cgo export header to be compatible with MSVC complex types

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[KangJiJi]

@cjungm helped with resolving the issue.

[ianlancetaylor]

cgo header files are used with C code, not C++ code. Is there a problem with C code?

[KangJiJi]

I understand that the header file in cgo is used only in C code.

However, I felt that the #ifdef __cplusplus shows that there is also consideration for C++ compatibility. That's why I created an issue to highlight one of the advantages of Go, which is writing more universal code.

If we only focus on compatibility with C, the BugReport tag might not be the most appropriate.

I left a new code suggestion on Gerrit. Thank you!

[prattmic]

cc @golang/compiler

[ianlancetaylor]

I would expect that MSVC would support some way to write a typedef for a complex number that will work for both C and C++. Are you really sure that can't be done?

[KangJiJi]

It currently works in both C and C++. However, it doesn't work with the latest C++ Language Standard in MSVC, and there is a solution for that.

With the ISO C++ 14 Standard (/std:c++14), it builds correctly.

With the ISO C++ 17 Standard (/std:c++17) or higher, it does not build correctly.

identifier "_Fcomplex" is undefined
identifier "_Dcomplex" is undefined

[ianlancetaylor]

Please paste plain text as plain text. Images are much harder to read. Thanks.

That said, I still don't understand whether there is a way to write this code that will work for both C and C++.

[FedeDP]

FYI i was able to workaround the issue by defining _CRT_USE_C_COMPLEX_H before including the header:

#define _CRT_USE_C_COMPLEX_H
#include <libworker.h>

See the 🟢 CI: https://github.com/FedeDP/container_plugin/actions/runs/13538922159/job/37835554110?pr=20

Info found here: https://developercommunity.visualstudio.com/t/_Fcomplex-and-_Dcomplex-removed-in-Windo/10108779#T-N10301376 and here: microsoft/STL#3280 (comment)

[KangJiJi]

My proposed solution is to modify the code as follows.

#ifdef _MSC_VER
#if !defined(__cplusplus) || _MSVC_LANG <= 201402L
#include <complex.h>
typedef _Fcomplex GoComplex64;
typedef _Dcomplex GoComplex128;
#else
#include <complex>
typedef std::complex<float> GoComplex64;
typedef std::complex<double> GoComplex128;
#endif
#else
typedef float _Complex GoComplex64;
typedef double _Complex GoComplex128;
#endif

Of course, I have also uploaded this change to Gerrit.

Since there is a note at the top of the header file stating that it is automatically generated and should not be modified manually, I tried to avoid making direct changes to it.

// Code generated by cmd/cgo; DO NOT EDIT

However, I made the modification because, without it, the code cannot be built in ISO C++17 or later. I also hope this change helps others who might encounter the same issue.

Appendix

• _MSVC_LANG

[ianlancetaylor]

@KangJiJi Can we simply use the approach suggested by @FedeDP , and add #define _CRT_USE_C_COMPLEX_H before incluing <complex.h>?

[cjungm]

Hello, I am working on resolving this issue together with @KangJiJi . First of all, thank you for sharing your valuable input. @FedeDP

We have reviewed your suggestion regarding #define _CRT_USE_C_COMPLEX_H and confirmed that it functions properly.
Thank you.

However, this approach seems to downgrade the functionality of the new MSVC version to mimic that of an older version.
In the long run, we would recommend handling the MSVC version differences with conditional branching, as we have proposed.

Info found here: https://learn.microsoft.com/en-us/answers/questions/1187748/error-compiling-a-c-file-generated-from-golang-err

[KangJiJi]

Hello, I am working on resolving this issue together with @KangJiJi . First of all, thank you for sharing your valuable input. @FedeDP

We have reviewed your suggestion regarding #define _CRT_USE_C_COMPLEX_H and confirmed that it functions properly. Thank you.

However, this approach seems to downgrade the functionality of the new MSVC version to mimic that of an older version. In the long run, we would recommend handling the MSVC version differences with conditional branching, as we have proposed.

Info found here: https://learn.microsoft.com/en-us/answers/questions/1187748/error-compiling-a-c-file-generated-from-golang-err

SGTM !