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.
#ifndef DEMO_H_
#endif // DEMO_H_
Should not add or generate a C style comment line /* 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.
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 :)
Quote from: oBFusCATed on October 15, 2013, 10:11:37 AM
C::B is mostly C++ IDE, so this is not unexpected omission :)
OK, that's good to know.
Quote from: oBFusCATed on October 15, 2013, 10:11:37 AM
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.
Quote from: oBFusCATed on October 15, 2013, 10:11:37 AM
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 :D
Quote from: ToApolytoXaos on October 15, 2013, 03:18:03 PM
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.
Try: src/plugins/codecompletion/codecompletion.cpp line 1601 and src/plugins/contrib/SmartIndent/SmartIndentCpp.cpp line 566.
Quote from: Alpha on October 15, 2013, 04:56:54 PM
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:
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:
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.
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...
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.
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...
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:
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;
}
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);
[...]
}
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;
}
}
[...]
}
OK, fair enough.
Any thoughts for future improvements with SDK in general?
Any plans to separate UI elements from core logic of project?
Quote from: ToApolytoXaos on October 16, 2013, 03:21:39 PM
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...
Quote from: oBFusCATed on October 16, 2013, 12:13:55 PM
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:
FileType FileTypeOf(const wxString& filename)
Quote from: oBFusCATed on October 16, 2013, 05:28:34 PM
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.
Quote from: oBFusCATed on October 16, 2013, 05:28:34 PM
Generally the SDK quality goes up, not down with almost every commit:)
Yes, I have already noticed that, and that is an amazing progression :)
Quote from: ToApolytoXaos on October 17, 2013, 08:27:11 AM
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....
Blimey! I thought this was not ported to C::B. I remember reading it somewhere in the forum.
This is so awesome, thank you very much BlueHazzard :D