Problems encountered when the project moved from Mingw to MSVC 2017
- 
@jsulm I try to fix it.and I have clean and rebuild the project.
In my .pro file :
* INCLUDEPATH += $$PWD/include
and $$PWD/include/stdlib.h is for Mingw,so I use C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\stdlib.h to replace $$PWD/include/stdlib.h.
The First error is :
D:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.16.27023\include\cstddef:101: error: C2874: using 声明导致“std::max_align_t”的多次声明@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:
$$PWD/include/stdlib.h
Why?!
Do you really have this header in your project folder? - 
@jsulm I try to fix it.and I have clean and rebuild the project.
In my .pro file :
* INCLUDEPATH += $$PWD/include
and $$PWD/include/stdlib.h is for Mingw,so I use C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\stdlib.h to replace $$PWD/include/stdlib.h.
The First error is :
D:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.16.27023\include\cstddef:101: error: C2874: using 声明导致“std::max_align_t”的多次声明 - 
@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:
$$PWD/include/stdlib.h
Why?!
Do you really have this header in your project folder?@jsulm of course,the origin folder is in the picture left,and the stdlib.h is right.

I noted the stdlib.h seems like prepared for mingw,and I replaced the stdlib.h with C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\stdlib.h.The folder now is:

Also I deleted the build folder,then clean and rebuild the project,the first is:
D:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.16.27023\include\cstddef:101: error: C2874: using 声明导致“std::max_align_t”的多次声明 - 
@jsulm of course,the origin folder is in the picture left,and the stdlib.h is right.

I noted the stdlib.h seems like prepared for mingw,and I replaced the stdlib.h with C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\stdlib.h.The folder now is:

Also I deleted the build folder,then clean and rebuild the project,the first is:
D:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.16.27023\include\cstddef:101: error: C2874: using 声明导致“std::max_align_t”的多次声明 - 
@kgsbt clean is not enough. Try to do it from command line. Do:
make distclean
in the build dir or
delete the whole build dir
then
rerun qmake
and build - 
@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:
but it's not working
Same problem or something else?
What Qt version do you use? - 
@kgsbt You should not copy any part of your toolchain files into your project. Between your CMakeLists.txt/project PRO file and your tool chain's default behaviour they should all be found at build time in standard locations outside your project.
@ChrisW67 said in Problems encountered when the project moved from Mingw to MSVC 2017:
@kgsbt You should not copy any part of your toolchain files into your project. Between your CMakeLists.txt/project PRO file and your tool chain's default behaviour they should all be found at build time in standard locations outside your project.
Thanks to @ChrisW67 and @jsulm . I removed "INCLUDEPATH += $$PWD/my_include" in .pro file, and move some MATLAB dependency header file to my folder.Then it success!
But there is a new- error:D:\QtProjects\autotest\1026msvc\autotestsystem\AutoTestSystem\AcBoard\AcBoardEntity.h:304: error: C1060: 编译器的堆空间不足
And the AcBoardEntity.h looks like:

 
I try to :
- 
add "QMAKE_CXXFLAGS += /Zm1000" to .pro file (tryed10-1000)
 - 
add "CONFIG += resources_big" to .pro file
it didn't work. 
How can I fix this problem? Is it because the array is too big? I did run out of memory during compilation
 - error:D:\QtProjects\autotest\1026msvc\autotestsystem\AutoTestSystem\AcBoard\AcBoardEntity.h:304: error: C1060: 编译器的堆空间不足
 - 
@ChrisW67 said in Problems encountered when the project moved from Mingw to MSVC 2017:
@kgsbt You should not copy any part of your toolchain files into your project. Between your CMakeLists.txt/project PRO file and your tool chain's default behaviour they should all be found at build time in standard locations outside your project.
Thanks to @ChrisW67 and @jsulm . I removed "INCLUDEPATH += $$PWD/my_include" in .pro file, and move some MATLAB dependency header file to my folder.Then it success!
But there is a new- error:D:\QtProjects\autotest\1026msvc\autotestsystem\AutoTestSystem\AcBoard\AcBoardEntity.h:304: error: C1060: 编译器的堆空间不足
And the AcBoardEntity.h looks like:

 
I try to :
- 
add "QMAKE_CXXFLAGS += /Zm1000" to .pro file (tryed10-1000)
 - 
add "CONFIG += resources_big" to .pro file
it didn't work. 
How can I fix this problem? Is it because the array is too big? I did run out of memory during compilation
@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:
C1060
This is indeed a compiler out of space error. I am not sure why allocating large arrays would affect the compiler rather than just runtime, but there you are. See https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/fatal-error-c1060?view=msvc-170, which does include:
Eliminate unnecessary global variables, for example, by allocating memory dynamically instead of declaring a large array.
 - error:D:\QtProjects\autotest\1026msvc\autotestsystem\AutoTestSystem\AcBoard\AcBoardEntity.h:304: error: C1060: 编译器的堆空间不足
 - 
@ChrisW67 said in Problems encountered when the project moved from Mingw to MSVC 2017:
@kgsbt You should not copy any part of your toolchain files into your project. Between your CMakeLists.txt/project PRO file and your tool chain's default behaviour they should all be found at build time in standard locations outside your project.
Thanks to @ChrisW67 and @jsulm . I removed "INCLUDEPATH += $$PWD/my_include" in .pro file, and move some MATLAB dependency header file to my folder.Then it success!
But there is a new- error:D:\QtProjects\autotest\1026msvc\autotestsystem\AutoTestSystem\AcBoard\AcBoardEntity.h:304: error: C1060: 编译器的堆空间不足
And the AcBoardEntity.h looks like:

 
I try to :
- 
add "QMAKE_CXXFLAGS += /Zm1000" to .pro file (tryed10-1000)
 - 
add "CONFIG += resources_big" to .pro file
it didn't work. 
How can I fix this problem? Is it because the array is too big? I did run out of memory during compilation
Here are some common stack size limits for different versions of Windows:
32-bit Windows: In 32-bit versions of Windows, the default stack size limit is typically 1 MB. This means that each thread in a 32-bit Windows process has a 1 MB stack by default.
64-bit Windows: In 64-bit versions of Windows, the default stack size is usually larger, often around 4 MB or more. The specific size can depend on the version and configuration.Try to use 2/3D pointers to allocate memory to your arrays. You are using too much stack memory.
 - error:D:\QtProjects\autotest\1026msvc\autotestsystem\AutoTestSystem\AcBoard\AcBoardEntity.h:304: error: C1060: 编译器的堆空间不足
 - 
Here are some common stack size limits for different versions of Windows:
32-bit Windows: In 32-bit versions of Windows, the default stack size limit is typically 1 MB. This means that each thread in a 32-bit Windows process has a 1 MB stack by default.
64-bit Windows: In 64-bit versions of Windows, the default stack size is usually larger, often around 4 MB or more. The specific size can depend on the version and configuration.Try to use 2/3D pointers to allocate memory to your arrays. You are using too much stack memory.
 - 
Hi,guys!I have a new error :
- C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\complex.h:221: error: C2872: “clog”: 不明确的符号
 
There is no "clog" in my project. I just include <complex.h> .why this error?
@kgsbt
Don't know because you have not translated the message from Chinese for us to comment on....
You do not have to include a header file in your project for it to be included, and you do not have to use a token likeclogfor it to cause an error when included. - 
@kgsbt
Don't know because you have not translated the message from Chinese for us to comment on....
You do not have to include a header file in your project for it to be included, and you do not have to use a token likeclogfor it to cause an error when included. - 
@JonB
it's:- C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\complex.h:221: error: C2872: “clog”: ambiguous symbol
 
I only include complex.h here:

@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:
error: C2872: “clog”: ambiguous symbol
Google:
error: C2872: “clog”: ambiguous symbol
https://stackoverflow.com/questions/54972981/how-can-i-resolve-the-occuring-ambiguity-when-using-clog-for-computing-the-natur ?I haven't been able to reproduce this with gcc 7.3 without
using namespace stdbut in general all functions from C headers reside in the global namespace. Therefore you should be able to resolve the ambiguity by prefixing clog with:::Agreed, you must have a
using namesapce stdelsewhere - maybe in an included header?This solved it, thanks. Yes, in one header I'm including it was used.
Can this apply to you?
I only include
complex.hhere:Once again, this is not enough to show you will not have the problem. You show a header/include file,
AcBoardWorkspace.h. That goes#include <complex.h>. But that does not tell us the whole story. It will#included somewhere, and that may be preceded by other#includes and/orusing namespacestatements, etc. You cannot keep looking atcomplex.hin isolation, you must look at it in the context of where it is being included. - 
@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:
error: C2872: “clog”: ambiguous symbol
Google:
error: C2872: “clog”: ambiguous symbol
https://stackoverflow.com/questions/54972981/how-can-i-resolve-the-occuring-ambiguity-when-using-clog-for-computing-the-natur ?I haven't been able to reproduce this with gcc 7.3 without
using namespace stdbut in general all functions from C headers reside in the global namespace. Therefore you should be able to resolve the ambiguity by prefixing clog with:::Agreed, you must have a
using namesapce stdelsewhere - maybe in an included header?This solved it, thanks. Yes, in one header I'm including it was used.
Can this apply to you?
I only include
complex.hhere:Once again, this is not enough to show you will not have the problem. You show a header/include file,
AcBoardWorkspace.h. That goes#include <complex.h>. But that does not tell us the whole story. It will#included somewhere, and that may be preceded by other#includes and/orusing namespacestatements, etc. You cannot keep looking atcomplex.hin isolation, you must look at it in the context of where it is being included.@JonB
I searched "clog" in my project.
It's no found in my project:

so I can't use this way,I don't kown where to add "::" .
@JonB said in Problems encountered when the project moved from Mingw to MSVC 2017:Therefore you should be able to resolve the ambiguity by prefixing clog with ::
 - 
@JonB thanks. I resolved this problem!
I put#include <complex.h>in The first line of AcBoardWorkspace.h. And put#include “AcBoardWorkspace.h”on the first line of the file that needs it.And it works!@kgsbt
You were not supposed to be able to findclogin your own code --- it's incomplex.h. And you were not supposed to deploy the solution to prefix it with::as that would be in that file which you do not want to change.I put #include <complex.h> in The first line of AcBoardWorkspace.h. And put #include “AcBoardWorkspace.h” on the first line of the file that needs it.And it works!
This is right. Something you have now moved it before in your
#includefiles will haveusing namespace std. That will have madeclog(without the::) go wrong whencomplex.hgot included. Nowcomplex.hwill be included before thatstdstatement, and will allow it to work.As a general guide: this does not always avoid any problems, but I arrange my
#includes as far as possible:- First any "system" includes, which have nothing to do with Qt.
 - Next any third-party includes, which have nothing to do with Qt.
 - Qt's includes.
 - My own project's includes.
 
In my experience this hopefully leads to the least interference between them.
 - 
@kgsbt
You were not supposed to be able to findclogin your own code --- it's incomplex.h. And you were not supposed to deploy the solution to prefix it with::as that would be in that file which you do not want to change.I put #include <complex.h> in The first line of AcBoardWorkspace.h. And put #include “AcBoardWorkspace.h” on the first line of the file that needs it.And it works!
This is right. Something you have now moved it before in your
#includefiles will haveusing namespace std. That will have madeclog(without the::) go wrong whencomplex.hgot included. Nowcomplex.hwill be included before thatstdstatement, and will allow it to work.As a general guide: this does not always avoid any problems, but I arrange my
#includes as far as possible:- First any "system" includes, which have nothing to do with Qt.
 - Next any third-party includes, which have nothing to do with Qt.
 - Qt's includes.
 - My own project's includes.
 
In my experience this hopefully leads to the least interference between them.
@JonB said in Problems encountered when the project moved from Mingw to MSVC 2017:
As a general guide: this does not always avoid any problems, but I arrange my #includes as far as possible:
First any "system" includes, which have nothing to do with Qt.
Next any third-party includes, which have nothing to do with Qt.
Qt's includes.
My own project's includes.This is a very useful guide!
 - 
@kgsbt
You were not supposed to be able to findclogin your own code --- it's incomplex.h. And you were not supposed to deploy the solution to prefix it with::as that would be in that file which you do not want to change.I put #include <complex.h> in The first line of AcBoardWorkspace.h. And put #include “AcBoardWorkspace.h” on the first line of the file that needs it.And it works!
This is right. Something you have now moved it before in your
#includefiles will haveusing namespace std. That will have madeclog(without the::) go wrong whencomplex.hgot included. Nowcomplex.hwill be included before thatstdstatement, and will allow it to work.As a general guide: this does not always avoid any problems, but I arrange my
#includes as far as possible:- First any "system" includes, which have nothing to do with Qt.
 - Next any third-party includes, which have nothing to do with Qt.
 - Qt's includes.
 - My own project's includes.
 
In my experience this hopefully leads to the least interference between them.
@JonB I have a new problem:

I useQFutureWatcher<void> *watcher = new QFutureWatcher<void>(this);as usual.
AcBoardEntity does inherit from QObject.But it get an error:- AcBoardEntity.cpp:423:41: error: no matching constructor for initialization of 'QFutureWatcher<void>'
qfuturewatcher.h:184:7: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'AcBoardEntity *' to 'const QFutureWatcher<void>' for 1st argument
qfuturewatcher.h:187:14: note: candidate constructor not viable: no known conversion from 'AcBoardEntity *' to 'QObject *' for 1st argument 
I also used
QFutureWatcher<void> *watcher = new QFutureWatcher<void>(this);in another file:

and it works as usual.
I don't kown what's wrong. - 
@JonB I have a new problem:

I useQFutureWatcher<void> *watcher = new QFutureWatcher<void>(this);as usual.
AcBoardEntity does inherit from QObject.But it get an error:- AcBoardEntity.cpp:423:41: error: no matching constructor for initialization of 'QFutureWatcher<void>'
qfuturewatcher.h:184:7: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'AcBoardEntity *' to 'const QFutureWatcher<void>' for 1st argument
qfuturewatcher.h:187:14: note: candidate constructor not viable: no known conversion from 'AcBoardEntity *' to 'QObject *' for 1st argument 
I also used
QFutureWatcher<void> *watcher = new QFutureWatcher<void>(this);in another file:

and it works as usual.
I don't kown what's wrong.@kgsbt
I don't see where the difference is too. Start by deleting all your intermediate generated file and re-run a build from scratch, to make sure everything is correctly up-to-date (no artefacts left over from a previous compile).Yes, note something "odd" in your screenshot:
class SignalGeneratorhasSignalGeneratorwritten in bold & purple --- just likeQObjectis written in purple. But yourclass AcBoardEntityis not written that way. This implies to me it is not recognising something about theAcBoardEntityclass which it is recognising forSignalGenerator....You show a "vertical red line warning symbol" at line #19 of
AcBoardEntity.h. This may be affecting the interpretation of the subsequentclass AcBoardEntity. What is that about, can that be resolved first? - AcBoardEntity.cpp:423:41: error: no matching constructor for initialization of 'QFutureWatcher<void>'