Author Topic: smallB's suggestions  (Read 20153 times)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9504
Re: smallB's suggestions
« Reply #45 on: November 09, 2011, 08:14:55 am »
As we have discussed, the best way was to save the breakpoint in the cbp file.
This is even worse, than saving in a separate file in the main project directory! Never do that, never ever think about it!
Agreed. The cbp file is definitely the wrong place. However, ollydbg's approach was to save it in a "layout" file - similar to the project layout file.

This sound good:
Unfortunately C::B doesn't have the infrastructure to do it right, until then (I have a plan for it),
breakpoints and watches won't be saved automatically.
So, we are all happy. ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: smallB's suggestions
« Reply #46 on: November 09, 2011, 08:23:47 am »
That's great news!

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12062
    • Travis build status
Re: smallB's suggestions
« Reply #47 on: November 09, 2011, 09:29:02 am »
Morten: I know about his patch, but I'm really sick of this files next to the .cbp
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9504
Re: smallB's suggestions
« Reply #48 on: November 09, 2011, 09:40:54 am »
Morten: I know about his patch, but I'm really sick of this files next to the .cbp
Yes, but the problem is: If you provide projects to third parties and/or have projects under version control, permanent changes to the project file are a nightmare. In addition: private project stuff (like layout options and BP's are) do not belong to a general project file. the general rule is: Put to the project files only what all devs need too compile the project the same/compatible way.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12062
    • Travis build status
Re: smallB's suggestions
« Reply #49 on: November 09, 2011, 10:10:55 am »
Yes, I know, the plan is to have a directory (.codeblocks for example) somewhere in the tree, next to the project or to the workspace.
And then provide some kind of API to the plugin write for managing these files.
The problem is that I've not sure where to save it, next to the project file or next to the workspace file.
In it is not that simple, unfortunately. But we can start a topic, where we can discuss it if you're interested about this problem.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: smallB's suggestions
« Reply #50 on: November 09, 2011, 01:49:01 pm »
8. If I cannot use is it make it inactive
a) Start cb
b) File/new/ File...
c) Pick any type of file
d) Try to check "Add file to active project" - for obvious reasons it doesn't let you check it but I think it would be nicer if it was inactive at all.
Thanks.

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: smallB's suggestions
« Reply #51 on: November 11, 2011, 11:26:03 am »
9. Signatures must match

Guys, this suggestion/request is based on the fact that it is not allowed (good thing) in order to successfully compile a program for signatures of class, fnc, variable(static) not to match.
So what I'm saying is, if I have classical .h and cpp structure and I'm changing let's say in cpp:


Code: [Select]
My_Class::My_Class(int,double,char)
{
/*e.b.*/
}
and for some reason I remove any element from argument list, let's say int (the first one), then it is only logical that this same happens in .h file with this ctor declaration, so from:
Code: [Select]
My_Class(int,double,char);will become:
Code: [Select]
My_Class(double,char);This should work in both ways - changing .h should be reflected in cpp and vice versa.
Same goes with adding/removing ref, ptr etc etc - they just have to match and this should be automated.
Same goes with templates:
If I have two files in order to simulate classical .h .cpp structure, so I have .h (interface) and *_impl.h (implementation)
and in my implementation file I've got

Code: [Select]
template<class T>
class X
{
/*Lots of very cool fncs decl. in here*/
};
and in my *_impl.h, I've got

Code: [Select]
template<class T>
void X<T>::one_of_many_cool_fncs(char*,double)
{
}
when I decide after some time (week, month) that another template param is needed and instead of:
Code: [Select]
template<class T>
class X
{
};
I want

Code: [Select]
template<class T,class F>
class X
{
};
then all definitions in *_impl.h should also be appropriately updated, so in my case would give me:


Code: [Select]
template<class T,class F>
void X<T,F>::one_of_many_cool_fncs(char*,double)
{
}

And again, if after some time I decide that over all it wasn't good decision at all and I decide to remove the second param (class F), again, all definitions should be appropriately updated.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9504
Re: smallB's suggestions
« Reply #52 on: November 12, 2011, 12:10:37 pm »
then it is only logical that this same happens in .h file with this ctor declaration, so from:
Code: [Select]
My_Class(int,double,char);will become:
Code: [Select]
My_Class(double,char);
This is absolutely not logical. You can have classes that have multiple interfaces for the same method, like:
Code: [Select]
void my_method(int i, float f);
void my_method(int i, float f, bool b);
int  my_method(int i, float f, bool b, double d);
Also, you can have optional parameters:
Code: [Select]
void my_method(int i, float f = 0.0);
void my_method(int i, float f, bool b = false);
int  my_method(int i, float f, bool b = false, double d = 0.0);
So, changing an interface in the CPP file does absolutely not logically mean to change the interface in the H file, too. It might simply mean you are implementing another method / want to use a different method or it may be an user error.
In addition, if you do something automatically, you might create conflicts that you have suddenly two methods with the same interface which is invalid.

Sorry, but the common way to deal with this is:
1.) Design the interface (H file)
2.) Implement the methods (CPP file)
...in case you need re-factoring, you
3.) Re-design the interface
4.) Re-implement what has changed.

Any auto-foo here will bring you in hell, sooner or later, so we won't do it. An exception are the re-factoring possibilities we have. But this is on behalf and under full control of the user and not something automagically.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: smallB's suggestions
« Reply #53 on: November 12, 2011, 12:23:07 pm »
Fair enough (it could be done, but I agree that at the moment it would require too much work), but what about template's params? You cannot have ambiguities there, can you?

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: smallB's suggestions
« Reply #54 on: November 12, 2011, 03:19:32 pm »
3. Checking matching brackets when matters only.
I don't think that checking for matching braces in either:
a) comments
b) as a string
c) as a char
is the right thing to do.
Personally, I like it that all the braces can be matched.  I can see, however, why this might be annoying (if I get the chance, I will create a patch with an option to enable/disable this).

Morten: I know about his patch, but I'm really sick of this files next to the .cbp
What about having only a single file - like FileName.state or FileName.activestate - that contains all the information about the user preferences of the current project/workspace.  Another option would be to have a hidden folder, for example .ProjectState, which allows all the various files that are currently written to be organized into a single spot.

An exception are the re-factoring possibilities we have. But this is on behalf and under full control of the user and not something automagically.
I have not looked very much into Code::Blocks' refactoring abilities; is it currently possible to refactor function/constructor/etc. arguments?

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9504
Re: smallB's suggestions
« Reply #55 on: November 12, 2011, 04:07:21 pm »
You cannot have ambiguities there, can you?
Sure you can, why not? It can be seen as an abstraction of a class! In addition it gets more complex, as you need to really do a good and complete parsing before.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9504
Re: smallB's suggestions
« Reply #56 on: November 12, 2011, 04:11:03 pm »
I have not looked very much into Code::Blocks' refactoring abilities; is it currently possible to refactor function/constructor/etc. arguments?
I don't know. We have some capabilities but I'll never use. I never trust any automisation when it comes to that kind of stuff... no matter what IDE. In the end you usually don't need it if you put software design before implementation.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: smallB's suggestions
« Reply #57 on: November 12, 2011, 06:55:59 pm »
You cannot have ambiguities there, can you?
Sure you can, why not? It can be seen as an abstraction of a class! In addition it gets more complex, as you need to really do a good and complete parsing before.
I somewhat cannot see how can you run into ambiguities here. Small code example would surely help ;)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5230
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: smallB's suggestions
« Reply #58 on: November 13, 2011, 03:36:25 am »
The code-refactoring feature in the currently CC is not good, I don't believe it will be good. Unless we have a compiler level parser.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline smallB

  • Almost regular
  • **
  • Posts: 193
Re: smallB's suggestions
« Reply #59 on: November 13, 2011, 11:57:43 am »
@ollydbg, thanks