C++ comments inside generated C code?

[ToApolytoXaos]

To whom it may concern,

I typed #ifndef DEMO_H_ and press enter, and #endif auto completed with a C++ comment along with preprocessor macro name.

Code

#ifndef DEMO_H_
#endif // DEMO_H_

Should not add or generate a C style comment line

Code

/* DEMO_H_ */

when it's used with C code?

Thank you.

P.S.: It works OK if you compile it as C99, but not as C90.

[oBFusCATed]

C::B is mostly C++ IDE, so this is not unexpected omission
Generally it is better to post it in the bug tracker, because here it will be forgotten.
Better option is to post a patch that fixes it

[ToApolytoXaos]

C::B is mostly C++ IDE, so this is not unexpected omission

OK, that's good to know.

Generally it is better to post it in the bug tracker, because here it will be forgotten.

I don't like having multiple accounts for various projects I'm interested in participating. You could

• either move bug tracker from berlios to trac in a location like, trac.codeblocks.org and allow anonymous reports
• allow registered forum users to submit bug tickets or suggestions accordingly.

Better option is to post a patch that fixes it

That would be brilliant if I knew where to look so I could modify it lol

[oBFusCATed]

I don't like having multiple accounts for various projects I'm interested in participating. You could

• either move bug tracker from berlios to trac in a location like, trac.codeblocks.org and allow anonymous reports
• allow registered forum users to submit bug tickets or suggestions accordingly.

I don't think this is possible, without writing a tool to convert databases, so you'll have to hope someone will fix this bug or keep bugging devs about it, until someone does it.

I don't know where to look to fix it. Probably in the codecompletion plugin, but I don't know where.

[Alpha]

Try: src/plugins/codecompletion/codecompletion.cpp line 1601 and src/plugins/contrib/SmartIndent/SmartIndentCpp.cpp line 566.

[ToApolytoXaos]

Try: src/plugins/codecompletion/codecompletion.cpp line 1601 and src/plugins/contrib/SmartIndent/SmartIndentCpp.cpp line 566.

First of all, Alpha thank you so much for pointing out which files and lines should get implemented; much appreciated mate.

My concept from mixing C code with C++ is to use preprocessor conditionals, but I don't think it would work, as the existing code will compile with C++ and not with C.

For example, at codecompletion.cpp lines 1600-1602 we see the following:

Code

if (!pp.GetMatch(control->GetLine(ppLine), 2).IsEmpty())
    itemText.Append(wxT(" // ") + pp.GetMatch(control->GetLine(ppLine), 2));
break;

Now, even if you try something like the following below, it won't work as it depends on C++ in order to compile wxWidgets:

Code

if (!pp.GetMatch(control->GetLine(ppLine), 2).IsEmpty())
    #if defined(__cplusplus)
    itemText.Append(wxT(" // ") + pp.GetMatch(control->GetLine(ppLine), 2));
    #else
    itemText.Append(wxT(" /* ") + pp.GetMatch(control->GetLine(ppLine), 2) + wxT(" */ "));
    #endif
break;

What would be your way to ask the system to check whether it's C or C++?

Cheers.

[BlueHazzard]

you can't use the preprocessor here, because c::b is always compiled with c++, so your c condition will never be true.
I think you have to check for the file extension, and if it is c use the c style comment and if it is cpp use the c++ comment.
[Edit:] or only check for .c extension and use c++ comment otherwise because c++ has many extensions... In the header files i have no idea...

[oBFusCATed]

The check should ask the editor to see if it has C++ or C lexing, I think there is a global function that can tell what is the language somewhere in the global  headers.

[ToApolytoXaos]

I think I got confused a bit right now.

• Does C::B use two separated parsing mechanisms or just one, that of codecompletion project?
• I have checked the wiki pages and the only parsing mechanism I could find is that of codecompletion. Any suggestions?
• Is Scintilla's lexer mechanism related to this request?

I wish I could find more information...

[Alpha]

There is no good/global way defined (yet) to determine between C and C++.  (Code::Blocks treats them as the same thing most of the time.)  This is how it is currently done:

Code

HighlightLanguage EditorColourSet::Apply(cbEditor* editor, HighlightLanguage lang)
{
    if (!editor)
        return HL_NONE;

    if (lang == HL_AUTO)
        lang = GetLanguageForFilename(editor->GetFilename());

    const bool isC = (   Manager::Get()->GetConfigManager(wxT("editor"))->ReadBool(wxT("no_stl_in_c"), true)
                      && lang == GetHighlightLanguage(wxT("C/C++"))
                      && editor->GetFilename().Lower().EndsWith(wxT(".c")) );

    Apply(lang, editor->GetLeftSplitViewControl(),  isC);
    Apply(lang, editor->GetRightSplitViewControl(), isC);

    return lang;
}

Code

void CodeCompletion::UpdateEditorSyntax(cbEditor* ed)
{
    if (!Manager::Get()->GetConfigManager(wxT("code_completion"))->ReadBool(wxT("/semantic_keywords"), false))
        return;
    if (!ed)
        ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
    if (!ed || ed->GetControl()->GetLexer() != wxSCI_LEX_CPP)
        return;

    TokenIdxSet result;
    int flags = tkAnyContainer | tkAnyFunction;
    if (ed->GetFilename().EndsWith(wxT(".c")))
        flags |= tkVariable;
    m_NativeParser.GetParser().FindTokensInFile(ed->GetFilename(), result, flags);
[...]
}

Code

void EditorManager::CollectDefines(CodeBlocksEvent& event)
{
[...]
    defines.Add(wxT("__cplusplus"));
    for (FilesList::iterator it = lst->begin(); it != lst->end(); ++it)
    {
        if ((*it)->relativeFilename.EndsWith(wxT(".c")))
        {
            defines.RemoveAt(defines.GetCount() - 1); // do not define '__cplusplus' if even a single C file is found
            break;
        }
    }
[...]
}

[ToApolytoXaos]

OK, fair enough.

Any thoughts for future improvements with SDK in general?
Any plans to separate UI elements from core logic of project?

[oBFusCATed]

Any thoughts for future improvements with SDK in general?
Any plans to separate UI elements from core logic of project?

Patches welcome and be more exact what you need improved.
Generally the SDK quality goes up, not down with almost every commit:)

Edited: replaced are with and...

[Alpha]

The check should ask the editor to see if it has C++ or C lexing, I think there is a global function that can tell what is the language somewhere in the global  headers.

For reference purposes, the related global is:

Code

FileType FileTypeOf(const wxString& filename)

[ToApolytoXaos]

Patches welcome and be more exact what you need improved.

What I would love to see is a mechanism that would permit a user to open a file within C::B and offered the option to parse the current file's directory (while placing it in a temporary project), so it can enable auto-completion (if it's C or C++ code that is) and any available feature exists in IDE. This approach is what Sublime Text actually offers by default and I find it brilliantly convenient.

By the way, the parsing mechanism still produces duplicates, triplicates, and quadruplicates without offering further information about available candidates; only with mouse hover on the class or function et al. you get the info you need which is wrong IMO.

Another idea would be to separate C::B in multiple logical layers, in such way that would allow any interested developer to port project's *core* in ncurses (UNIX-like systems) or PDCurses (Windows), so users could use it from a terminal application.

I often work from terminal using vim, another powerfully brilliant editor, and honestly there are moments where I wish C::B was available, so I could use for example, debugger (valgrind actually) with the help of hot-keys.

Another idea would be the separation of auto-version from SVN into a more generic auto-version mechanism, like that of hashing key signature. I know that nightly builds use svn to generate the necessary version schema, but this bounds the user to use svn, while he or she could easily download the source code from a GitHub mirror and simply compile it without the hassles of VCS.

Last, but not least is the issue with wxSmith GUI Designer's size. When I'm using it via laptop, I have limited available space and I have to scroll up or down within C::B in order to view my generated user interface. I think, IMHO, a popup mechanism that unpins the entire wxSmith UI Design, (NOT the entire GUI mechanism, only the tab window) as a popup window (wxDialog's logic? IDK), would be much more convenient. (GIMP's docking mechanism maybe?)

Even though I suggest such ideas, it does not mean it's feasible or plausible to do such thing. Nevertheless, it's just food for thoughts I would say that could generate new ideas from such feedback.

Generally the SDK quality goes up, not down with almost every commit:)

Yes, I have already noticed that, and that is an amazing progression

[BlueHazzard]

By the way, the parsing mechanism still produces duplicates, triplicates, and quadruplicates without offering further information about available candidates; only with mouse hover on the class or function et al. you get the info you need which is wrong IMO.

Have you tried Settings->Editor->Documentation->Parse Documentation and Show token's details even....