Recent Posts

71

Using Code::Blocks / Version 25.03 won't build any of my previously working programs?

« Last post by bad_terminal on November 05, 2025, 01:38:30 pm »

As topic.

Was using 20.something for years (all developing same program -  a learning excercise) ran into a problem recently I couldnt figure out in my head (I've never used the codeblocks debugger before, and have been troubleshooting in my head these past years) so I thought i'd try codeblocks debugger.

Unfortunatley the one that came with 20.something kept crashing, so I installed 25.03....which wont build any of the 60-odd previously working versions i'd already created.

Anyone have an  idea as to why?

Ta.

72

Using Code::Blocks / Re: Problem with standalone exe

« Last post by bad_terminal on November 05, 2025, 01:32:04 pm »

Surely somebody knows what all those different 'compliers' are and what the difference is?

I know. It is different compilers for the different cases. I have 3 compilers in use: one for Win64 (gcc 14.2, default), one for Win32 (gcc 14.2 for some automation tasks, old hardware has no Win64 drivers) and one for XP (gcc 9.3, really old hardware, no Win7 drivers).

Ok thankyou, that makes sense.

73

Development / Re: AI may help us to create plugins

« Last post by christo on November 04, 2025, 04:57:35 pm »

Generative AI is just a tool now, it is up to the user to use it properly. In my very limited experience, I think code generation via AI is just like an enhanced wizard, user can adapt it to the requirements and for maintainability, basically using it just as a starting point. There is no point in hating generative AI imho.

Regarding the bugs, whenever I see an issue with C::B, I'll try to fix it if I can, or report it. I've seen developers doing a wonderful job of fixing issues if proper details are provided with bugs. Patches are also accepted without any barrier. I think it is the responsibility of the users to report bugs properly so that developers have enough data fix them in their spare time.

For me C::B is quiet stable and runs for days without any issue. Just wanted to post this since I feel there is unjust criticism.

74

Help / Re: Different handling of placeholders

« Last post by rechtsanwaltsteyer on November 04, 2025, 11:16:25 am »

Thank you very much for the suggestions. In all the IDEs (Code::Blocks, KDevelop, and Qt Creator) i use, I have created some snippets/placeholders for different needs and a date snippet/placeholder to document the date of initial creation and subsequent versions in the source code header. Since I'm the only one working on the code, this allows me to avoid using Git and other version control systems.
Greatings Michael

75

General (but related to Code::Blocks) / Re: Welcome Newcomers - PLEASE READ!!!

« Last post by ahashib on November 04, 2025, 08:58:35 am »

Hi,

I am new.  I have just installed Code::Blocks and started learning Fortran.  Thank you for letting me join this forum. 

- Abdullah Al Hashib

76

Using Code::Blocks / Re: Problem with standalone exe

« Last post by nenin on November 04, 2025, 07:47:55 am »

Surely somebody knows what all those different 'compliers' are and what the difference is?

I know. It is different compilers for the different cases. I have 3 compilers in use: one for Win64 (gcc 14.2, default), one for Win32 (gcc 14.2 for some automation tasks, old hardware has no Win64 drivers) and one for XP (gcc 9.3, really old hardware, no Win7 drivers).

77

Development / Re: AI may help us to create plugins

« Last post by HangNickHers on November 03, 2025, 11:44:56 pm »

It's good to see reasonable posts.
Anyway I went to see that website linked there, putting all aversion aside for a moment.
Disgusting. What a bunch of trash. Again, this is the type of thing that actual developers should spend time doing -- proper documentation. Graphs, diagrams, file names, descriptions of classes and methods, are helpful. And so forth. Should have been somewhere since the beginning, or, for a long time anyway.
Anyone wishing to contribute should take the necessary time to study the project, and understand it. Obviously.

Before adding yet more cruft, I'd favour fixing bugs in cb.

This. So, another project I've liked for years, called Lazarus, an excellent free Pascal IDE, had the same garbage discussed for quite some time. A bunch of idiots suggesting AI this, AI that, left and right. Instead of spending energy on what really matters. New releases, same problems.

Despite the slightly agressive response, I fully agree that AI is ruining a lot of things, e.g. localhost being broken in Windows 11 and worse.

I thought it was a joke, but I read about a "copilot" on Windows 11's Notepad, and it's real. Again, it should be clear what their goals are: to turn users into even greater morons. Lazy and dumb and incompetent. The cattle are given slop. And they swallow it all and enjoy it and praise it and tell others how great it all is and how they should eat it as well.

So I got banned without any warnings, and my two posts deleted, because of that post.

It's nothing new. Nothing but garbage to attract lazy, stupid, incompetent people.
It's an often an excuse to be a moron. As blauzahn observed, to flee accoutability as well. I've seen "The AI wrote it" and such. (No, YOU commited low-effort, barely functional garbage.)
You'd expect programmers to know better, but, you see how it is now.

78

Nightly builds / Re: The 25 October 2025 build (13754) is out.

« Last post by blauzahn on November 03, 2025, 08:30:03 pm »

Thank you, Lieven.

79

Development / Re: AI may help us to create plugins

« Last post by blauzahn on November 03, 2025, 08:27:13 pm »

I'd also vote against, regardless of how tempting it might sound.

Using AI as inspiration or as lightning quick "seems to work" hack is fine as long as you resist the huge temptation to cut-copy-paste any single line of code you do not fully understand. Remember: As soon as you change/add anything, the responsability and maintenance becomes essentially yours, not the AI's.

Before adding yet more cruft, I'd favour fixing bugs in cb.

Finding potential memory leaks in cb can be done on Linux with e.g. cppcheck, scan-build, heaptrack or valgrind --- or just look for raw new in the editor and you'll quickly find a few good candidates.
Use a more modern programming style and you put in hardly any leak in the first place. Granted, legacy frameworks may limit its scope.

80

Help / Re: Different handling of placeholders

« Last post by blauzahn on November 03, 2025, 07:55:50 pm »

Maybe because macro expansion is better used reluctantly? Like minimizing the usage of the c-preprocessor.  Currently, I do not use default-code but I would be fine with how it is as you described.

I briefly searched cb-source for default-code. The function that expands placeholders is in trunk/src/sdk/editormanager.cpp:495

Code

cbEditor* EditorManager::New(const wxString& newFileName)
{
//    wxString old_title = Manager::Get()->GetAppWindow()->GetTitle(); // Fix for Bug #1389450
    // create a dummy file
    if (!newFileName.IsEmpty() && !wxFileExists(newFileName) && wxDirExists(wxPathOnly(newFileName)))
    {
        wxFile f(newFileName, wxFile::write);
        if (!f.IsOpened())
            return nullptr;
    }
    cbEditor* ed = new cbEditor(m_pNotebook, newFileName, m_Theme);
//    if ((newFileName.IsEmpty() && !ed->SaveAs()) || !ed->Save())
//    {
//        //DeletePage(ed->GetPageIndex());
//        ed->Destroy();
//        Manager::Get()->GetAppWindow()->SetTitle(old_title); // Though I can't reproduce the bug, this does no harm
//        return 0;
//    }

    // add default text
    wxString key;
    key.Printf(_T("/default_code/set%d"), (int)FileTypeOf(ed->GetFilename()));
    wxString code = Manager::Get()->GetConfigManager(_T("editor"))->Read(key, wxEmptyString);
    // Allow usage of macros
    // TODO (Morten#5#): Is it worth making this configurable?!
    Manager::Get()->GetMacrosManager()->ReplaceMacros(code);
    ed->GetControl()->SetText(code);

    ed->SetColourSet(m_Theme);
    AddEditorBase(ed);

    ed->Show(true);
    SetActiveEditor(ed);

    CodeBlocksEvent evt(cbEVT_EDITOR_OPEN, -1, nullptr, ed);
    Manager::Get()->GetPluginManager()->NotifyPlugins(evt);

    return ed;
}

see the lines:

Code

    // Allow usage of macros
    // TODO (Morten#5#): Is it worth making this configurable?!
    Manager::Get()->GetMacrosManager()->ReplaceMacros(code);

Apart from that snippet, at first glance, I did not find in the source code any further rationale for the decision you asked for.

The code entered into the settings dialog can be found in ~/.config/codeblocks/default.con. Please search for default_code within that file.

Why do you want the creation date of a source file in the first place? I'd rather look up in version control when it was added. With that username, do you do that for legal reasons?