cb_release_type and GCV's

[MortenMacFly]

GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values are already at hand; some statements may execute in different places because they have been moved out of loops.

Well this should be the actual warning that comes when you enable optimisations with debugging symbols in the annoying dialog. ;-)

[Biplab]

I just tried to compile C::B by defining -g -O2 together. GCC didn't emit any warnings. I'm using C::B-12.11-MinGW + trunk source.

Code

mingw32-g++.exe -O2 -Wall -g   -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE  -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI    -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\bindings -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Isdk\wxpropgrid\include -Isdk\mozilla_chardet\src  -c D:\DevTools\trunk\src\sdk\cbdebugger_interfaces.cpp -o .objs\sdk\cbdebugger_interfaces.o

What is the actual warning message that you are getting?

[Jenna]

You get a warning, if you set it via build options.

[Biplab]

You get a warning, if you set it via build options.

Sorry, I did that via Project > Build Options. But I'm not getting any warning. Build goes on smoothly.

[Jenna]

I just read, that you use 12.11, but this comes with trunk after the release, as far as I know.
An annoying dialog pops up, immediately when you set the second option.

[Biplab]

I just read, that you use 12.11, but this comes with trunk after the release, as far as I know.
An annoying dialog pops up, immediately when you set the second option.

Ok, I was prompted with that warning. Thanks for showing me the solution.


But I second Thomas' opinion.

But if it does, that is an example of needless stupidity.

I'm always saying: Don't make things too smart, because too fucking smart soon becomes stupid. There is no sane reason for Code::Blocks to complain. It looks like you're trying to write a letter. Do you want to use the letter template? Wait a moment...

So what was I saying... if Code::Blocks complains about that combination, we have a bug that needs to be fixed.

There is no need to make IDE too smart. There are tons of ways to warn users about bad coding / compilation options. Are we going to implement them all?

We can start by warning users who write unnecessarily complex Macros in C by writing a parser to analyze code on the fly and popping up an Annoying Dialog box. How about implementing a warning about the compiler options Jens explained earlier-

What is worse: if you have -g set and also switch -s on (what is in fact an error), -g will be removed silently without any warning (and vice versa).

There could be numerous other examples. Do we need them? In my opinion we do not.

[MortenMacFly]

There could be numerous other examples. Do we need them? In my opinion we do not.

I agree, but: We did that initially for combination of -s and -g to avoid forum noise because people complained they were not able to debug. I think this is a time-safer. So I wouldn't generally never warn, but warn in cases that safe us time. If the combination -02 and -g leads to cases where we are bugged in the forums I'd rather leave it as it is. I never tried to debug optimised code, but I recall that already now we have forum posts saying that the debugger does not stop at a certain BP which may have its roots in optimised code. Also remember: You are allowed to set these flags - if one is silently removed (which I didn't try to reproduce so far) that that is the actual bug to me. And this is also where "too smart" starts for me: At the time the IDE doesn't allow you to do for not good reason and bugs you over an over w/o the ability to turn it off.

So yes - don't make the IDE too smart but also no - don't make it that simple that we need to answer the same stupid questions in the forums over and over again. Remember: A lot AnnoyingDialogs, including this dialog itself were/was implemented to avoid such scenarios.

What I can also imagine is that we extend the AnnoyingDialog for experts: So that in the (global) settings you have one global option to always turn off these messages. Then, assuming AnnoyingDialogs are for noobs only we could make us happy with a single option.

[Jenna]

We did that initially for combination of -s and -g to avoid forum noise because people complained they were not able to debug.

But silently removing options without warning is not a good option in my opinion, even if they can not be used together like -s and -g.
In this case an annoying dialog makes much more sense, than when using -g and -O2 together, which (in general) works.

[MortenMacFly]

But silently removing options without warning is not a good option in my opinion, even if they can not be used together like -s and -g.

I agreed to that already:

You are allowed to set these flags - if one is silently removed (which I didn't try to reproduce so far) that is the actual bug to me.

[MortenMacFly]

In this case an annoying dialog makes much more sense, than when using -g and -O2 together, which (in general) works.

For me it makes sense in both cases, as both can lead to unexpected behaviour which is worth a warning... but one you can easily disable as an expert. Remember: A lot classes / students use our IDE and not many - even way less experts. So again: Lets to a global "never show AnnoyingDialogs" option, and check all AD's if they are really unimportant for experts.
Then - when switching this option to "on", show an AD that you may miss some interesting stuff...

[Biplab]

I agree, but: We did that initially for combination of -s and -g to avoid forum noise because people complained they were not able to debug. I think this is a time-safer.

Thanks for the background.

But silently removing options without warning is not a good option in my opinion, even if they can not be used together like -s and -g.

I agreed to that already:

You are allowed to set these flags - if one is silently removed (which I didn't try to reproduce so far) that is the actual bug to me.

We have few options.

1) Close all such threads with a generic reply. Similar to whenever anybody asks general programming question.
2) Use a ListBox to group such conflicting options, so that only one such option can be selected. I remember some work was done earlier using wxPropGrid which allows us to do that.
3) Add an api (if not present) to mark conflicting options and warning users should they try to select them.

[Alpha]

For the sake of discussion, here are some of my original thoughts from when I was writing this behaviour.
Options the specifically state in the documentation that they supersede one another (for example -O1 and -O2) will automatically remove the other.  Options that cannot function together (-s and -g, multiple architecture selections) automatically remove the other.
Options that can coexist, but have, on occasion, brought complaints (debugging and optimization) trigger an AnnoyingDialog warning.

I am not saying this was correct reasoning, just that this was why I originally tried.

3) Add an api (if not present) to mark conflicting options and warning users should they try to select them.

From a trunk build, try right-clicking on a flag, and selecting "Modify flag".  Also read about two-thirds down this page.

[thomas]

(quote from GCC documenation)

The only real, observable strange effects are that sometimes you cannot break at a particular line (it will break a few lines further down) and that sometimes, examining a variable will only give "optimized out". Neither is really strange or unexpected in an optimized build. All in all, it works very, very well.

forum noise

That's of course a good reason.

more annoying dialogs, silently dropping options

Maybe a workable solution would be to change the respective option's color in the list view to red if it conflicts with another option. Possibly mark them both red, so one can see where the conflict is. Or, add a small status line at the bottom of the config dialog, which is usually empty/invisible, and shows info such as "Note: -O2 and -g may give unexpected results". No more than a single line, and no more than at most 10-12 words, ever.

In any case, silently dropping an option is something I consider "too smart". This would acceptable only if we add something like "build profiles" (a kind of dumbed down way of selecting options, like "debug build" or "fully optimized build" that lets the exact details of what to do to the IDE). As a general thing, however, it's not really acceptable.

[MortenMacFly]

respective option's color in the list view to red if it conflicts with another option. Possibly mark them both red, so one can see where the conflict is. Or, add a small status line at the bottom of the config dialog, which is usually empty/invisible, and shows info such as "Note: -O2 and -g may give unexpected results". No more than a single line, and no more than at most 10-12 words, ever.

That would be a nice option because it permanent but doesn't affect the work flow.

As a general thing, however, it's not really acceptable.

I think for really stupid combinations like -g and -s it is - NEVER silently (this isn't acceptable, I agree), but with a message dialog and the ability to allow it anyways, even if it may be stupid. It has been similar like that a long time, btw. in terms of a message box appeared with a warning but not an option for an automatic correction - which would be new and not that bad I think.

[Alatar]

The question is, what does C::B ask you to setup? I believe it will ask you to setup the "CB" variable and not cb.cflags. So it is still unclear to the user what needs to be done. IMHO even more unclear than it is now... or if renaming from "cb_release_type" to "cb_cflag" (note the underscore). Its not nice, but now people ask at least what they need to do - exactly what the GCV concept is for. With "cb.cflags" I guess most people will set it to "anything" to silence the message. If we find a way to avoid such mistakes, too - that would be nice.

Ideally we need some way to instruct GCV manager what it should ask (basic self-documentation for GCV). For example this may look like
$(#cb.build_flags:"Specify debug or optimisation flags to build CB")
When macros manager found such definition it should display Global Variable Editor dialog with specified text.
Unfortunately in current realisation macros manager don`t drop invalid part of definition and this string evaluated as
-O2:"Specify debug or optimisation flags to build CB")
So if we add such logic and define variables in this way, this will break building in old CB versions =(.
Second limitation is when macros manager found undefined GCV it prompt user to define it, but if it found undefined GCV`s member it silently replace it with empty string.