51
General (but related to Code::Blocks) / Re: g++.exe what -std=c++ <what version>
« Last post by Miguel Gimenez on April 22, 2024, 06:37:10 pm »You can print the __cplusplus macro, see this link for more information.
The new Release 20.03 is out! You can download binaries for Windows and many major Linux distros here .
-------------- Clean: Debug in ThreadNames (compiler: GNU GCC Compiler)---------------
Cleaned "ThreadNames - Debug"
-------------- Build: Debug in ThreadNames (compiler: GNU GCC Compiler)---------------
g++.exe -Wall -fexceptions -g -IC:\WxWidgetsSetup\include -IC:\WxWidgetsSetup\lib\gcc_dll -c C:\u\CodeBlock_C++\EasyLoggingpp_ThreadNames\ThreadNames\easylogging++.cc -o obj\Debug\easylogging++.o
g++.exe -Wall -fexceptions -g -IC:\WxWidgetsSetup\include -IC:\WxWidgetsSetup\lib\gcc_dll -c C:\u\CodeBlock_C++\EasyLoggingpp_ThreadNames\ThreadNames\main.cpp -o obj\Debug\main.o
g++.exe -o bin\Debug\ThreadNames.exe obj\Debug\easylogging++.o obj\Debug\main.o C:\WxWidgetsSetup\lib\gcc_dll\libwxmsw32ud.a C:\WxWidgetsSetup\lib\gcc_dll\libwxmsw32u.a
C:\u\CodeBlock_C++\EasyLoggingpp_ThreadNames\ThreadNames\easylogging++.cc: In member function 'el::Logger* el::base::RegisteredLoggers::get(const std::string&, bool)':
-------- Run: Debug in Comanche051 (compiler: AGC YaYUL assembler)----------
Checking for existence: /home/pi/virtualagc/Comanche051/Comanche051.bin
Executing: /home/pi/virtualagc/Comanche051/Comanche051.bin (in /home/pi/virtualagc/Comanche051/.)
Process terminated with status -1 (0 minute(s), 0 second(s))
/home/pi/VirtualAGC/bin/yaAGC /home/pi/virtualagc/Comanche051/Comanche051.bin
check if mingw directory exist inside your CB install dir. if so, then
1) go to menu Settings->Compiler
2) In settings window move to toolchain executables tab
3) Remove 'mingw32-' prefix for upper 4 apps
4) Check mingw path
5) enjoy
After testing and tracing clangd_client and the miniAudio source I believe it will not be possible to pass that 4meg miniAudio.h file to clangd.yea that makes sense I guess. I think I'll have to break the miniaudio.h in like miniaudio1.h miniaudio2.h miniaudio3.h... for the plugin to not crash, no?
I have a relatively fast system, but clangd never finished parsing the header file before it crashed attempting to create a response file which would have been many times the size of the source file (about 24meg or more) after it formatted a response containing line/col/symbol/diagnostics/fix suggestions, etc.
If it didn't give out of memory, it sure would have caused Clangd_client to.
That header file will have to be broken up into multiple headers in order for clangd to handle it.
Note from opinionated self: I really do not consider creating a 4meg header file as acceptable software design. It's just going to create grief for anyone using it. If not now, certainly in the future.
After testing and tracing clangd_client and the miniAudio source I believe it will not be possible to pass that 4meg miniAudio.h file to clangd.yea that makes sense I guess. I think I'll have to break the miniaudio.h in like miniaudio1.h miniaudio2.h miniaudio3.h... for the plugin to not crash, no?
I have a relatively fast system, but clangd never finished parsing the header file before it crashed attempting to create a response file which would have been many times the size of the source file (about 24meg or more) after it formatted a response containing line/col/symbol/diagnostics/fix suggestions, etc.
If it didn't give out of memory, it sure would have caused Clangd_client to.
That header file will have to be broken up into multiple headers in order for clangd to handle it.
Note from opinionated self: I really do not consider creating a 4meg header file as acceptable software design. It's just going to create grief for anyone using it. If not now, certainly in the future.