for (auto i : c)
{
//body
}
for [...]
for (auto i : c)
[ ... ]
I already have txt file with features request and I do filter them before I post them here.Increase the threshold, the filter is not working good enough :lol:
Get used to it:)I'd rather improve something which doesn't work as *I* would like than get use to it. It's just the way I am.
Yes, but seeing which options are enabled would allow me to SEE what I already didI already have txt file with features request and I do filter them before I post them here.Increase the threshold, the filter is not working good enough :lol:
-Wall changes enabled warnings every gcc release, so we can't do what you propose.
The checkboxes are for convenience only.
And:
1. you're supposed to know what you're doing.
@jens fair enough, won't hear any suggestion from me again. No problem.
@smallB:
many (or most) of your suggestions just show, that you are neither an experienced programmer, nor an experienced user of C::B.
6. Debugger doesn't stop on a breakpoint. In project (http://www.mediafire.com/?h34w9ow9ok2wn88) set debug point on line no 15 in main.cpp. This will have no effect. Debugger will exit with code zero. In order to reach this point one have to set another debugging point - i.e. no 12 in main.cpp. This time debugger will skip the first debug point and stop on the second (the wanted one).I just test your project, and I found that it is your fault.
5. While debugging something like VS's "show next statement"(yellow arrow on debugging bar) could prove to be very useful.No idea about your feature request.
Next time you meet such a problem, I suggest you need to post the "full build log" and the "full debugger log".Absolutely agree. Will remember next time. Thanks.
Haha, I've the same problem myself yesterday, I had -O2 and -s and I wanted to debug, stupid me, lost a bit of precious time.I'm not sure about the exact command but it will have something to do with next statement to be executed.
About feature no 5, I doubt, gdb supports this, smallB if you can tell me the command I can probably do something about it.
But I've never used this feature in VStudio...
After you done you would like to continue debugging but you don't remember where was it (which file, which line) the only options at the moment is either find manually the point where you stopped before you decided to check something or press one of: "next line", "go into" or "step out". This isn't always satisfactory because one of those steps may go into fnc which will cause exception and you won't know which line it was so you cannot prepare yourself for that next time. Instead you have to repeat whole debugging process all over, cause exception, remember the exact place and start debugging again.Ok, for this feature request, I always double click on the lowest frame in the "call stack" window, then I return to the "next statement" position. :D
With what I propose you would just press "show next statement" and you'd be brought back to where you left off.
Thanks.
What'yer thinking?IMHO is is possible to save/load breakpoints from a file. At least in trunk.
I'm not really with you. So is the answer yey or ney ;)What'yer thinking?IMHO is is possible to save/load breakpoints from a file. At least in trunk.
I'm not really with you. So is the answer yey or ney ;)
Are you sure ?What'yer thinking?IMHO is is possible to save/load breakpoints from a file. At least in trunk.
Are you sure ?I checked, but you are right. I wanted to commit patch #2775 which implements this and I thought I did, but in favour of the debugger branch I skipped it.
I suggest you submit a patch to add a GUI to make it always do it.No patches for this or similar features, please.
Yeah, this patch Watches and breakpoints persistent (https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2775&group_id=5358) was create by me years ago, but I use a separate file to save the breakpoints. As we have discussed, the best way was to save the breakpoint in the cbp file.Are you sure ?I checked, but you are right. I wanted to commit patch #2775 which implements this and I thought I did, but in favour of the debugger branch I skipped it.
However, this patch could still work on trunk though...
@ollydbg, yes, sure that is good workaround but I think (if it's not to hard to implement) it would be nice to have it on a debugging toolbar.@OBF:
Just a thought.
Regards
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!
I have to disagree with you on that one. How many times did you start and finish debugging a project/part of project in one session? It never happened to me so far, and I think I'm not the only one who has had this experience.I suggest you submit a patch to add a GUI to make it always do it.No patches for this or similar features, please.
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.
It isn't that useful anyways.
It's not about that Tim. If I'd had necessary skills I'd do it myself - much easier route - no need to ask anyone, no need to convince anyone etc. you're getting the general gist. But in view of the fact that I do not posses them (yet, or maybe never) I'm merely suggesting them and is up to devs to either implement them or not. As simple as that. But believe me, when I eventually will be able to do it myself will never ask anyone, for reasons mentioned above.I'm not really with you. So is the answer yey or ney ;)
If your suggestions are NOT worth you doing any work; why do you think it is worth the devs doing any work.
Tim S.
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.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!
Unfortunately C::B doesn't have the infrastructure to do it right, until then (I have a plan for it),So, we are all happy. ;-)
breakpoints and watches won't be saved automatically.
Morten: I know about his patch, but I'm really sick of this files next to the .cbpYes, 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.
My_Class::My_Class(int,double,char)
{
/*e.b.*/
}
My_Class(int,double,char);
My_Class(double,char);
template<class T>
class X
{
/*Lots of very cool fncs decl. in here*/
};
template<class T>
void X<T>::one_of_many_cool_fncs(char*,double)
{
}
template<class T>
class X
{
};
template<class T,class F>
class X
{
};
template<class T,class F>
void X<T,F>::one_of_many_cool_fncs(char*,double)
{
}
then it is only logical that this same happens in .h file with this ctor declaration, so from:This is absolutely not logical. You can have classes that have multiple interfaces for the same method, like:Codewill become:My_Class(int,double,char);
CodeMy_Class(double,char);
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);
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);
3. Checking matching brackets when matters only.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).
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.
Morten: I know about his patch, but I'm really sick of this files next to the .cbpWhat 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?
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 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.
I somewhat cannot see how can you run into ambiguities here. Small code example would surely help ;)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.
Are there any good way to navigate to the "next line" when debugging.@ollydbg, yes, sure that is good workaround but I think (if it's not to hard to implement) it would be nice to have it on a debugging toolbar.@OBF:
Just a thought.
Regards
It looks like run the command "frame 0" will give us the "next line".
BTW: I found a tiny bug in the debugger branch, when I double click on the frame 0 of the call-stack window, I looked at the debugger-log, I see that
1, "frame 0" command was send
2, "bt" command was send
So, I think "bt" command do not need to send, right?