User forums > Help

-std=c++11 not working (CB12.11)

<< < (5/7) > >>

oBFusCATed:

--- Quote from: MortenMacFly on April 23, 2013, 08:31:28 am ---And we do no magi here at all - we just decided that the checkable list over-rules "other options". It has been like that since the beginning and only a very few people complained. Most were happy when we told how it is working behind the scenes. So I still don't see any need for change here, sorry.

--- End quote ---
Sorry to say it, but this is a magic and it is a bit unexpected.
I guess users (including me) think that the list compiler flags and other options are combined together using and/sum operation.
Is there a technical reason behind this behaviour or this is just a decision?

MortenMacFly:

--- Quote from: oBFusCATed on April 23, 2013, 09:08:22 am ---I guess users (including me) think that the list compiler flags and other options are combined together using and/sum operation.

--- End quote ---
Yes - and thats how its done - using AND. "on" AND "off" equals "off". Thats how it is - no magic. 8)


--- Quote from: oBFusCATed on April 23, 2013, 09:08:22 am ---Is there a technical reason behind this behaviour or this is just a decision?

--- End quote ---
You have to make a decision here.

scarphin:

--- Quote from: MortenMacFly on April 23, 2013, 08:31:28 am ---I'm afraid osdt still fails to see the full picture:
if you hit OK and "-Wall" in the checkable list is off, but you have -Wall in "other options" defined to be "on", then you tell C::B on the one hand "do not use -Wall" and on the other hand "do use -Wall".

--- End quote ---
I have a different case here. First of all I didn't know there was a flag for '-std=c++11' in 'compiler flags'. What I did was to read gcc documentation, decide that I need a '-std=c++11' option and add it to 'other options'. So I DIDN'T tell cb to disable '-std=c++11' in the 'compiler flags' and enable it in 'other options', it's just the consequence of cb's design. And most of the novice will just copy the required options from a website or somewhere else and paste them into the 'other compiler options' without knowing about the flags. And then what? In case they see some options are missing from the command string, maybe they will fill this as a bug, which actually isn't.

Also there is the other case. Suppose one has defined some compiler option in 'other options'. Then cb gets updated and a compiler flag is added for that very option defined in 'other options'. What will be the behavior of cb in that case?

I think both settings (compiler flags and other options) must be mixed in the resulting command or 'other options' must be automatically added to 'compiler flags' if available.

oBFusCATed:

--- Quote from: MortenMacFly on April 23, 2013, 09:11:34 am ---Yes - and thats how its done - using AND. "on" AND "off" equals "off". Thats how it is - no magic. 8)

--- End quote ---
My mistake here -> I though about OR.

Could we change it? What would be the downsides, because there are plenty of examples where this decision will break things.
For example scarphin's case of a flag used in old C::B and in the new C::B version it is added to the list of flags? Would this still work?

MortenMacFly:

--- Quote from: oBFusCATed on April 23, 2013, 09:49:28 am ---For example scarphin's case of a flag used in old C::B and in the new C::B version it is added to the list of flags? Would this still work?

--- End quote ---
What happens is: If you open a project all compiler flags are being parsed (they are a list of flags). If found in the "checkbox based" settings the checkbox is enabled and if a flag is not in that list its being put to "other options". So, what happens in this specific case of a compiler option being made "official" is that this flag is being applied in the UI, but its now in a different place - in the checklist box.

So nothing gets lost, its just being visualised differently.

I think the only feasible way of handling this would be that in case we realise a difference between the checklist based and the other options we issue a warning asking what to do. The issue here is that you can use scripting (?) but at least macros in "other options" - so its not so easy to implement! And there is no automatism that will work reliable.

But if you decide to go for such a dialog - make it an annoying dialog. Because still: The overall goal is to use the checklist based list of compiler options in the first place and in case you don't find there what you are looking for use "other options" as a last resort.

If people just "copy and paste" from the internet w/o trying to understand what they are doing I don't know if its helpful to them if we account for such laziness. Its a very bad thing to do in the end.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version