smallB's suggestions

[MortenMacFly]

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. ;-)

[smallB]

That's great news!

[oBFusCATed]

Morten: I know about his patch, but I'm really sick of this files next to the .cbp

[MortenMacFly]

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.

[oBFusCATed]

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.

[smallB]

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.

[smallB]

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

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

My_Class(int,double,char);

will become:

Code

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

template<class T>
class X
{
/*Lots of very cool fncs decl. in here*/
};

and in my *_impl.h, I've got

Code

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

template<class T>
class X
{
};

I want

Code

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

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.

[MortenMacFly]

then it is only logical that this same happens in .h file with this ctor declaration, so from:

Code

My_Class(int,double,char);

will become:

Code

My_Class(double,char);

This is absolutely not logical. You can have classes that have multiple interfaces for the same method, like:

Code

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

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.

[smallB]

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?

[Alpha]

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?

[MortenMacFly]

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.

[MortenMacFly]

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.

[smallB]

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

[ollydbg]

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.

[smallB]

@ollydbg, thanks