Author Topic: new plugin idea  (Read 6264 times)

msk4web

  • Guest
new plugin idea
« on: July 12, 2006, 02:35:53 am »
Class completion code
A class completion code is a plugin designed to complete your class that you create in a header ("header.h") file in the source code file (.cpp). It generate header.cpp and implement the lcode. It will help to save a lot of time
For example lets:
header.h
==========
#ifndef HEADER_H
#define HEADER_H

class Header{
public:
   void function1();
   void function2();
   void function3();
private:
};
#endif

the plugin generate the header.cpp file and the class implementation:

#include "header.h"
void Header::function1(){
}
void Header::function2(){
}
void Header::function3(){
}
« Last Edit: July 12, 2006, 02:37:39 am by msk4web »

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: new plugin idea
« Reply #1 on: July 12, 2006, 03:24:36 am »
Since the idea is to redisign/remake the current code-completion plugin that feature could be included in it instead of writing another plugin, but writing another plugin that uses the parser just for that could also be possible :)

I suggest you to add it as a feature request in berliOS so we don't forget about it.

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: new plugin idea
« Reply #2 on: July 12, 2006, 09:59:51 pm »
The idea is interesting, could there be a window that shows the class content (class browser) with different colored icons or text for implemented and not implemented functions, giving a way (button, right click or other) to create an empty implementation (in file .cpp).
Moreover it could do the reverse work: for implemented functions still not in the class add the declaration in the header (in file .h).
It would be nice if we could also change the parameters of the function (or other things like renaming it) using the same window and get .cpp and .h files automatically updated.
Can I add more? :-)
We could do the same with member variables: renaming a variable in all the class (both in the declaration and in all the implemented functions that use it), this would be VERY useful.

If the parser of the code-completion is well featured and is easily reusable, theese things should not be too difficult to implement.
Is someone interested?
I don't know code::blocks code, but I could help implementing this if someone could address me in the code...

Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: new plugin idea
« Reply #3 on: July 13, 2006, 07:54:30 am »
The idea is interesting, could there be a window that shows the class content (class browser) with different colored icons or text for implemented and not implemented functions, giving a way (button, right click or other) to create an empty implementation (in file .cpp).
Moreover it could do the reverse work: for implemented functions still not in the class add the declaration in the header (in file .h).

Why stop there?  Why not also include the option to export a method's implementation to the .cpp file?

That feature alone could save me A LOT of time when writing and testing new classes.  I tend to save the export step for the very end (design-wise) of the class development.

However, the reverse method you suggest may be a bit difficult to implement.  What if you want the method declared private or protected?  Or in a different place than after previous function foo()?
3 years until google knows more than god.

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: new plugin idea
« Reply #4 on: July 13, 2006, 04:13:15 pm »
Sorry, but I don't understand the export you are talking about: can yoy explain it better, please?
(May be you are talking about a C++ feature that I don't know).

For the reverse work: yes, I thought about the problems you mentioned and my solution was
1) when it is asked to add the declaration, show a little window with a combobox where you can choose between public, private, ecc.
2) add it to the first (or last) good line, then you can move it with your mouse (better a drag-drop than writing it yourself)
Do you agree?

Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: new plugin idea
« Reply #5 on: July 14, 2006, 01:26:26 am »
Sorry, but I don't understand the export you are talking about: can yoy explain it better, please?
(May be you are talking about a C++ feature that I don't know).

When I'm writing a new class, I include the implementation in the header file for speediness.  This way I don't have to always switch between the .h and .cpp files to add members and methods, I just stay in the .h file until I am done with the testing phase for the class.

Code
class foo
{
    ...
    void bar()
    {
        ...
    }
};

What I am suggesting for an export feature is to right click on the method in the .h file and click "export/move implementation" to have it automatically copy the method to the .cpp file (maintaining the order of declarations in the class), and then just leave the declaration in the header file.

Code
foo.h:
class foo
{
    ...
    void bar();
};

foo.cpp:
#include "foo.h"

...

void foo::bar()
{
   ...
}

Does it make sense, now?  Or am I the only person who works like this?

For the reverse work: yes, I thought about the problems you mentioned and my solution was
1) when it is asked to add the declaration, show a little window with a combobox where you can choose between public, private, ecc.
2) add it to the first (or last) good line, then you can move it with your mouse (better a drag-drop than writing it yourself)
Do you agree?

Seems a bit complicated.  Almost as much work as just copy/pasting the function definition.
3 years until google knows more than god.

Offline iw2nhl

  • Multiple posting newcomer
  • *
  • Posts: 116
  • BASIC, C, C++, Qt, bash
Re: new plugin idea
« Reply #6 on: July 15, 2006, 02:54:31 pm »
Quote
Does it make sense, now?  Or am I the only person who works like this?
I don't know, I never worked like that, but may be other people do!
This could be done, but depends on how the parser works: it could be easy or not.
Quote
Seems a bit complicated.  Almost as much work as just copy/pasting the function definition.
I don't think so, you have to remove the 'Clas::' code and add a ';' -> this could be done automatically!

Raijinsetsu

  • Guest
Re: new plugin idea
« Reply #7 on: July 15, 2006, 03:31:00 pm »
kidmosey: with gcc, you can use #pragma to define implementation and definition in the same file, and leave them there. This is not compatible with Visual Studio, and probably not compatible with other compilers either.

Example:
foo.h:
Code
#pragma interface
class foo
{
    ...
    void bar()
    {
        ...
    };
};

foo.c:
Code
#pragma implementation
#include "foo.h"

Here's a link to the official gcc page for a full explanation: http://www.delorie.com/gnu/docs/gcc/gcc_96.html
In short: files with "#pragma interface" are only compiled when a "#pragma implementation" is found first. Otherwise, that file is just used as a definition.


Code
foo.h:
class foo
{
    ...
    void bar();
};

foo.cpp:
#include "foo.h"

...

void foo::bar()
{
   ...
}

Does it make sense, now?  Or am I the only person who works like this?


Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: new plugin idea
« Reply #8 on: July 16, 2006, 03:35:44 am »
kidmosey: with gcc, you can use #pragma to define implementation and definition in the same file, and leave them there. This is not compatible with Visual Studio, and probably not compatible with other compilers

Well, I believe if you leave all the methods defined inside the class (in the header), the compiler will only compile it once, anyway, so that isn't really a problem.  I was just looking for an easier way to clean up the code and put declarations in the header and implementation in the source.  It is poor practice to leave all your code in headers (I only do it during testing).

Also, I like to have all the code in the cpp file, otherwise I will have to recompile all the dependent objects anytime I change anything.  I don't think the #pragma's can prevent that.

But I did read through that link and learned a few things, so thank you for that.  I don't know that I'd ever use it, though, for the aforementioned reasons.
3 years until google knows more than god.