Recent Posts

1

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by Grit Clef on Today at 12:51:43 pm »

Then maybe Xaviou's build can be suitable?

2

Plugins development / Re: Code completion using LSP and clangd

« Last post by MaxGaspa on Today at 11:24:34 am »

I see that you're not clicking either inside a class or a function.
Do this, after the clicked file has parsed, click inside a function, not at the top of an editor file.

Yes, clicking inside a function or class works. Thanks

3

General (but related to Code::Blocks) / Re: CB C++ Issue with GNU C++ 17 (ISO)

« Last post by Miguel Gimenez on Today at 09:39:57 am »

Spam reported to moderator.

4

General (but related to Code::Blocks) / Re: CB C++ Issue with GNU C++ 17 (ISO)

« Last post by Markelov69 on Today at 09:08:55 am »

Hi.  Would a more recent compiler version fix the compiling issue ??
This upgrade seems a difficult process.
And where do you locate the correct "compile" files and what version to choose??
Regards JC.......

Recent mingw-w64 gcc are  definetly better in standard implementations.
Fresh one can be found here:
https://winlibs.com/
and here:
https://github.com/niXman/mingw-builds-binaries/releases/web
In my humble opinion proper version is
x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev0.7z
or
i686-13.2.0-release-win32-dwarf-ucrt-rt_v11-rev0.7z
which using ucrt and native win32 threads in standard libs.

Thank you!

5

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by nenin on Today at 07:43:50 am »

Never mind I ve figured it out turns out these nightly versions do not support 13.2 yet. So I have switched to 13.1 and now it works.

I have nighties (including last one) running with 13.2 gcc (nixman) without such problems. 

6

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by nenin on Today at 07:41:48 am »

Recent GDB introduced some changes in the output so parsing failed. This was fixed in r13162 a year ago, try the last nightly.

Here is potential other issue: The 01 April 2024 build (13496) is actually built with gcc 13.2, all its dlls- with gcc 13.1. At my experience  mixing of the c++ libraries is a lottery.

7

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by mckl on Today at 07:16:26 am »

Never mind I ve figured it out turns out these nightly versions do not support 13.2 yet. So I have switched to 13.1 and now it works.

8

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by mckl on Today at 02:08:51 am »

Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\Users\mstar\Desktop\CPP_AIO4\BookIV\Chapter02\BuggyProgram\
Adding source dir: C:\Users\mstar\Desktop\CPP_AIO4\BookIV\Chapter02\BuggyProgram\
Adding file: C:\Users\mstar\Desktop\CPP_AIO4\BookIV\Chapter02\BuggyProgram\bin\Debug\BuggyProgram.exe
Changing directory to: C:/Users/mstar/Desktop/CPP_AIO4/BookIV/Chapter02/BuggyProgram/.
Set variable: PATH=.;C:\mingw64\bin;C:\mingw64;C:\Program Files (x86)\Common Files\Oracle\Java\java8path;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Program Files\Intel\WiFi\bin;C:\Program Files\Common Files\Intel\WirelessCommon;C:\Program Files\Git\cmd;C:\Program Files\dotnet;C:\Users\mstar\AppData\Local\Programs\Python\Python38\Scripts;C:\Users\mstar\AppData\Local\Programs\Python\Python38;C:\Users\mstar\AppData\Local\Microsoft\WindowsApps;\;C:\Program Files\JetBrains\PyCharm Community Edition 2020.3\bin

[debug]Command-line: C:\mingw64\bin\gdb.exe -nx -fullname -quiet  -args C:/Users/mstar/Desktop/CPP_AIO4/BookIV/Chapter02/BuggyProgram/bin/Debug/BuggyProgram.exe
[debug]Working dir : C:\Users\mstar\Desktop\CPP_AIO4\BookIV\Chapter02\BuggyProgram

Starting debugger: C:\mingw64\bin\gdb.exe -nx -fullname -quiet  -args C:/Users/mstar/Desktop/CPP_AIO4/BookIV/Chapter02/BuggyProgram/bin/Debug/BuggyProgram.exe
done

[debug]terminate called after throwing an instance of 'std::system_error'
[debug]terminate called recursively
[debug]  what():  Invalid argument
[debug]> set prompt >>>>>>cb_gdb:

Setting breakpoints
Debugger finished with status 1

9

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by mckl on Today at 12:05:49 am »

Yeah it is already in full

10

Plugins development / Re: Code completion using LSP and clangd

« Last post by Pecan on Yesterday at 11:16:15 pm »

hey @Pecan
sorry to bother you again but I have encounter an unusual behavior.
I was trying to use a large single file libraryhttps://github.com/mackron/miniaudio.
It has a single headerfile: miniaudio.h <--- 62k lines

when I try to open the header file or search for declaration through the main.c, whole code blocks freezes for solid 1-2 mins, weanwhile the mouse gradually becomes unresponsive until it's completely frozen and the screen turns black. Throws an error that Clangd_Cliet has stopped at the end.

I not sure if it's because my laptop isn't powerful enough. because the plugin usually worked smooth with other large libraries.

Apart from this single instance the plugin works fine and it has been very helpful.

I'll have a look at it.
Please attach your .cbp file for the project and your main.c  to a forum reply, so I can mirror what's happening.
Thanks for the report.

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.

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.