[Interest] Need argumentative help..... giving qobject copy/assignment constructor and put it in qlist/qmap

[Thiago Macieira]

On Wednesday 22 July 2015 23:11:59 Gunnar Roth wrote:
> Hello Thiago.
> 
> > Of those, C4275, C4514, C4800, C4097, C4786 and C4710 are stupid. I can't
> > see anyone who wants to know those warnings.
> 
> Most are sure, but sometimes you need this diagnostic and you wonder why you
> cannot switch it on.
> > I'll concede we may have gone too far on C4244 and C4355.
> 
> Disabling C4244 /* conversion from 'type1' to 'type2', possible loss of data
> */ is more than going to far. It is kind of sabotage imho.

Note that this does not apply to 64-bit to 32-bit conversions. Those are still 
active, so C4244 does not seem to apply to them. I don't know what it applies 
to.

> And what about C4231?   nonstandard extension used : 'identifier' before
> template explicit instantiation 

I have no clue what this one is complaining about.

> And what about  C4530 C++ exception handler
> used, but unwind semantics are not enabled. Specify /EHsc ignoring that can
> have serous consequences as the stack is not unwound, when an exception is
> thrown. We made this an error to be always. If you use libraries with
> exceptions you should enable exceptions your code.

Agreed. That was a side effect of how we mark exceptional / noexcept functions 
in conjunction with building some modules without exception support.

Maybe we should disable 4530 together with the exception disabling, as a 
compiler argument, not in qglobal.h.

But meh, I neither care for exceptions nor too much for MSVC. I won't 
volunteer to do this work. I already have 115 patches pending review. I don't 
need uninteresting work.

> C4706 assignment within conditional expression
> is actually a life saver. Disabling that is cruel.

I don't know where this one is coming from.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center