User forums > General (but related to Code::Blocks)
smallB's suggestions
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.*/
}
--- End code ---
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);
--- End code ---
will become:
--- Code: ---My_Class(double,char);
--- End code ---
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*/
};
--- End code ---
and in my *_impl.h, I've got
--- Code: ---template<class T>
void X<T>::one_of_many_cool_fncs(char*,double)
{
}
--- End code ---
when I decide after some time (week, month) that another template param is needed and instead of:
--- Code: ---template<class T>
class X
{
};
--- End code ---
I want
--- Code: ---template<class T,class F>
class X
{
};
--- End code ---
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)
{
}
--- End code ---
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:
--- Quote from: smallB on November 11, 2011, 11:26:03 am ---then it is only logical that this same happens in .h file with this ctor declaration, so from:
--- Code: ---My_Class(int,double,char);
--- End code ---
will become:
--- Code: ---My_Class(double,char);
--- End code ---
--- End quote ---
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);
--- End code ---
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);
--- End code ---
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:
--- Quote from: smallB on November 08, 2011, 08:58:18 am ---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.
--- End quote ---
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).
--- Quote from: oBFusCATed 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
--- End quote ---
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.
--- Quote from: MortenMacFly on November 12, 2011, 12:10:37 pm ---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.
--- End quote ---
I have not looked very much into Code::Blocks' refactoring abilities; is it currently possible to refactor function/constructor/etc. arguments?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version