Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

Requirements / Guidelines for re-writing the Code Completion

(1/6) > >>

rickg22:
Requirements notation:

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY"
   appear capitalized, they are being used to indicate particular
   requirements of this specification. A discussion of the meanings of
   these terms appears in RFC 2119.

For those who want to rewrite CodeCompletion using an existing C++ parser, here's what we should do:

(These guidelines are subject to change without notice)

* It SHOULD be designed around the class browser: Classes, Functions, Variables, Enums, Preprocessor.
* The code completion plugin MUST hold an in-memory structure (maps, arrays, whatever is necessary) to contain all the tokens. For example, a class would include member variables, methods, and the methods would include the local variables.
* This structure MUST be independent from the GUI. It MUST be a container. All code MUST be done by another class, but it MAY include saving, reading / writing from cache, and necessary functions.
* There SHOULD be a structure per development language in the project. It's no use mixing C++ and Perl tokens, it would only create confusion.
* The codecompletion plugin SHOULD have modules for different languages, these modules would consist of thread-safe functions to add the tokens into the main structure.
* The ParserThread (this part we'll keep, but with the necessary adaptations) will call the modules to parse the different files.
* For classes, use of STL classes (like vector and map) is RECOMMENDED, but you MAY NOT use std::string. You MUST use wxString instead. Use of only the std::string compatibility functions is RECOMMENDED.
(Contributions to these ideas are welcome)

David Perfors:
Should it use wxWidgets functions? like wxString and wxArray, etc.?

thomas:
I would use string and abstain from using wx containers to maximum extend possible.

There are three reasons for this:
1. wxString has std::string compatibility functions. If you use string, then you can do:

--- Code: ---#if USE_WXWIDGETS
  #include <wx/wx.h>
  #define string wxString
#else
  #include <string>
#endif
--- End code ---
This will compile anywhere, with wx or without.

2. wx containers suck really bad. You cannot typedef them, you cannot declare them inside a class, they use obscure macros... Standard containers work really well.

Wait... did I say three?  :lol:

Michael:

--- Quote from: thomas on December 21, 2005, 12:04:50 pm ---2. wx containers suck really bad. You cannot typedef them, you cannot declare them inside a class, they use obscure macros... Standard containers work really well.

--- End quote ---

That's interesting :). Just a question. There are not problems by using standard containers with wxWidgets? Otherside, is not the use of std::string not adviced to be used with wxWidgets?

Michael

takeshimiya:
The picture is:

wxWidgets containers sucks.
STL containers are great.

wxString is great.
STL string sucks (written by english people, for english people).

So I agree with thomas: using STL containers, and using wxString, but trying to use the STL string compatible functions.

Navigation

[0] Message Index

[#] Next page