News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

Code completion and smart pointer

Started by Denis, September 29, 2007, 02:08:25 PM

Previous topic - Next topic

Denis

Code completion shows only fields of smart pointer, not of managed object. For example for code:

std::auto_ptr<std::string> a;
a->

I see only auto_ptr, element_type, get etc fields.

thomas

Hmm well... how is code completion supposed to know? std::auto_ptr changes the meaning of operator->, and maps it to some class given as template parameter.

This is a tough challenge for code completion to figure out, as it can't guess by mere divination that operator-> in this particular template is meant to map to the template parameter, there would have to be a special code path that identifies std::auto_ptr specifically (and boost::scoped_ptr, boost::shared_ptr, and all the 350 other smart pointer implementations).
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Denis

But there are source code editors which can recognize reloaded operator-> and show correct code completion (borland c++ builder for example). I thing it is possible to make C::B code completion more smarter.

aurisc4

QuoteBut there are source code editors which can recognize reloaded operator-> and show correct code completion (borland c++ builder for example). I thing it is possible to make C::B code completion more smarter.
Borland C++ Builder (at least version 6), seems to compile the code during code completion, that why it doesn't work, if there are syntax errors before the position, where cc is invoked. Also, this makes cc extremely slow on large projects.

thomas

Quote from: Denis on September 29, 2007, 07:09:13 PMBut there are source code editors which can recognize reloaded operator-> and show correct code completion (borland c++ builder for example). I thing it is possible to make C::B code completion more smarter.
Code completion has a lot more issues than just that. Feel free to contribute a better code completion engine.
Seriously, the development team would forever be in your debt.

As pointed out by aurisc4, the Borland C++ Builder solution (as the Microsoft one, too) uses the compiler for such tasks, and clearly, this is superior. However, the downside is that those programs only work with exactly one revision of one specific compiler (their own).
We don't have the luxury of being able to load gcc (or whatever compiler the user configures) as a DLL either, nor are there any provisions (to my knowledge) to offer the parse tree to another application.
At the very best, gcc can be asked to run a file through the preprocessor (substituting #include and #define, and evaluating #if), but again, this is a feature of one particular compiler, there's no guarantee that another compiler will work the same.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Sensei

Hi,
I reply to this thread because it's concerning the code completition but the problem I want to describe is an other one.
I discovered that sometimes (maybe most times) the code completition will not suggest parts of an union after typing a dot.

For example:
union SOMEDATA {
  unsigned long l_comp[2];
  unsigned short s_comp[4];
  unsigend char b_comp[8];
};

// defining a variable of the union SOMEDATA
SOMEDATA  message;

Then after typing message.   I would like that the code completion would give me the possibility to select the members of the union but most times it doesn't.

Did I something wrong or isn't it implemented yet?

Greetings
Frank

mariocup

Hi,

codeblocks does not support command completion for unions at the moment. Another problem is that the name of typedef struct or unions are not displayed in the symbol browser.

typedef struct {
    int Test;
} Data_t;

Data_t Data;


will not show the item Data but unamed in the symbol view.

Game_Ender

Quote from: thomas on September 30, 2007, 03:54:46 PM
At the very best, gcc can be asked to run a file through the preprocessor (substituting #include and #define, and evaluating #if), but again, this is a feature of one particular compiler, there's no guarantee that another compiler will work the same.

Nope, at its very best GCC can give you all the information you need on all platforms Code::Blocks runs on (oh, and so can Doxygen's XML output ): Meet GCC-XML.

These won't solve the context aware help, but would at least remove bugs from header parser.

thomas

Quote from: Game_Ender on October 02, 2007, 03:19:25 AMNope, at its very best GCC can give you all the information you need on all platforms Code::Blocks runs on (oh, and so can Doxygen's XML output ): Meet GCC-XML.

These won't solve the context aware help, but would at least remove bugs from header parser.
Well, that's not gcc, it's some program built on top of it. Either way, it's impractical, a because it is an external program just like the compiler. This means that for a project containing 1000 source files, we have to create 1000 processes, which is expensive at best under Linux and outright ridiculous under Windows.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Game_Ender

GCC-XML is actually a modification of the GCC internals that essentially dumps the AST generated internally by GCC after it processes the header files to XML.  Since its done in this fashion, it like GCC, can handle as many files at once as you request.  For example this is perfectly valid with g++ and gcc-xml:g++ one.cpp two.cpp main.cpp -o myprogIn fact sometimes its faster to do builds like this for just the reason you mention.  Its commonly accomplished by creating a single file which #include's all your source then feeding that to the compiler.

Doxygen also works the same way, one program on a single run can (and does) parse a whole project.

thomas

You'll be laughing now, but I never thought about passing more than one source file at a time to gcc, which of course works just fine.

I'm thinking that this could be used for a substantial optimisation for the build system under Windows (maybe, some day, not tomorrow). When compiling a project with many small files, creating processes plus piping and updating the wxTextCtrl with the output consumes nearly as much CPU as the compilation. It's insane how much it costs you to create a process under Windows.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."