Re: [Development] msvc warning policy in qt
Well after some tests I learned that my original prolog is best. Adding#define QT_CC_WARNINGS #include qglobal.h actually lead to warnings as is inlcuding a lot more than i thought. But this warnins are swicth off only later in the file. There is not any benefit in my changes so i simplke removed them and all is well again. just to let you know... Regards, Gunnar Roth Gesendet:Montag, 09. Mrz 2015 um 10:08 Uhr Von:Gunnar Roth gunnar.r...@gmx.de An:development@qt-project.org development@qt-project.org Betreff:[Development] msvc warning policy in qt Hello, we have an in-house policy to use warning level 4 and warnings-as-errors with our projects. The problem is that qt headers are generating warnings when using this level. We switch off some silly warnings likeunreferenced inline function has been removed, which are just informal and cant be removed by us. I created a Qt_prolog.h and an Qt_epilog.h which have to be included before and after every Qt Header. prolog is this: # pragma warning (push) # pragma warning( disable : 4201 ) // nonstandard extension used : nameless struct/union # pragma warning( disable : 4127 ) // conditional _expression_ is constant # pragma warning( disable : 4510 ) // default constructor cannot be generated # pragma warning( disable : 4512 ) // assignment operator could not be generated # pragma warning( disable : 4244 ) // conversion from int/double/float/long to qreal, possible loss of data # pragma warning( disable : 4251 ) // class needs to have dll-interface to be used by clients of class # pragma warning( disable : 4800 ) // BOOL : forcing value to bool true or false (performance warning) # pragma warning( disable : 4245 ) // initializing : conversion from int to unsigned short, signed/unsigned mismatch # pragma warning( disable : 4251 ) // class QExplicitlySharedDataPointerT needs to have dll-interface to be used by clients of class # pragma warning( disable : 4231 ) // nonstandard extension used : extern before template explicit instantiation # pragma warning( disable : 4275 ) // non dll-interface class x used as base for dll-interface class y # pragma warning( disable : 4995 ) // method name was marked as #pragma deprecated # pragma warning( disable : 4718 ) // recursive call has no side effects, deleting epilog is just # pragma warning (pop) actually there are some warnings i would myself never switch off like conversion from int/double/float/long to qreal, possible loss of data orinitializing : conversion from int to unsigned short, signed/unsigned mismatch,but without that i get a warning ( and an error)# now i found out that qglobal.h does disable warnings in its own globally, so it pollutes my warning level by that. it even disables the imho very important warnings assignment within conditional _expression_ andC++ exception handler used, but unwind semantics are not enabled. Specify /EHsc . Especiallyassignment within conditional _expression_ is a live saver. you can easyly suppress it by writing if((a=open()) if the = is your real intent. C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc is a strong idication you are using exceptions but in case of one thrown you are not unwinding stack getting memory leaks and other problems. Luckily you can disable the warnings disabling, by definingQT_CC_WARNINGS so i added #define QT_CC_WARNINGS #include qglobal.h after the# pragma warning (push) and added all warning disabling from qglobal.h to the end of the prolog file, whiuch are: // copied from qglobale.h # pragma warning(disable: 4251) /* class type needs to have dll-interface to be used by clients of class type2 */ # pragma warning(disable: 4244) /* conversion from type1 to type2, possible loss of data */ # pragma warning(disable: 4275) /* non - DLL-interface classkey identifier used as base for DLL-interface classkey identifier */ # pragma warning(disable: 4514) /* unreferenced inline function has been removed */ # pragma warning(disable: 4800) /* type : forcing value to bool true or false (performance warning) */ # pragma warning(disable: 4097) /* typedef-name identifier1 used as synonym for class-name identifier2 */ # pragma warning(disable: 4706) /* assignment within conditional _expression_ */ # if _MSC_VER = 1310 // MSVC 2003 # pragma warning(disable: 4786) /* identifier : identifier was truncated to number characters in the debug information */ # endif # pragma warning(disable: 4355) /* this : used in base member initializer list */ # if _MSC_VER 1800 // MSVC 2013 # pragma warning(disable: 4231) /* nonstandard extension used : identifier before template explicit instantiation */ # endif # pragma warning(disable: 4710) /* function not inlined */ # pragma warning(disable: 4530) /* C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc */ additionallyi found includeQtCoreqfunctions_wince.h(224):#pragma warning(disable: 4273) which disables
Re: [Development] msvc warning policy in qt
-Original Message- From: development-bounces+kai.koehne=theqtcompany.com@qt- [...] My problems are solved this way ,but i would rather like that qt takes care of this itself, meaning allowing setting warninglevel to 4 and warnings as errors and applications compile out of the box, maybe by using my prolog/epilog approach. Just a minor remark: The pushing/popping of the warnings stack sometimes doesn't work, e.g. when it comes to API deprecation warnings. The warning has to be disabled the moment the deprecated method is declared, not when it's used. Depending on your coding style the system headers might be included before Qt headers ... This is why we e.g. change the warnings level of the infamous This function or variable may be unsafe warning C4996 globally to warning level 4 in 5.5: We don't want to pollute the Qt headers with the MSVC specific 'secure' counterparts, but we can't just disable the warning for Qt headers only, either. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCore missing check for memory allocation
On Mon, Mar 9, 2015 at 12:57 AM, Knoll Lars lars.kn...@theqtcompany.com wrote: Yes, the best solution IMO is still to use your own malloc and operator new replacements. In addition, OOM handlers on the OS level can help. Except that dynamically linked Windows Qt applications (read: most) don't work this way, so Windows users are left out in the cold. DLLs do not allow you to simply replace one new operator across link boundaries. See the comments in this Qt bug: https://bugreports.qt.io/browse/QTBUG-37395 Is there any strategy for the large body of Qt developers targeting Windows, or is statically linking the only supported method for replacing Qt allocators on Windows? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] compilation of qt5.5 examples with qt creator with visual studio 2012 (msvc2012) fails
Hi I used the following configure options and commands to build qt5.5: *configure -developer-build -opensource -confirm-license -platform win32-msvc2013 -opengl desktop -nomake examples -nomake tests nmake* QT is built successfully. After this, I installed QT creator 3.4.0 beta and configured qmake for qt5.5 and using Microsoft Visual studio C++ compiler 12.0 . Now when i try to build the qt3D examples using the QT creator, I am getting the following compile errors: *cpp.exe.2968.1625.jom qtmain.lib(qtmain_win.obj) : error LNK2019: unresolved external symbol __imp__CommandLineToArgvW@8 referenced in function _WinMain@16 release\cylinder-cpp.exe : fatal error LNK1120: 1 unresolved externals jom: C:\qt5.5\build-qt3d-Desktop-Release\examples\cylinder-cpp\Makefile.Release [release\cylinder-cpp.exe] Error 1120 jom: C:\qt5.5\build-qt3d-Desktop-Release\examples\cylinder-cpp\Makefile [release] Error 2 12:57:27: The process C:\Qt\qtcreator-3.3.81\bin\jom.exe exited with code 2. Error while building/deploying project qt3d (kit: Desktop) When executing step Make 12:57:27: Elapsed time: 00:03.* I understand that this error is because of winmain function missing which is required by visual studio compiler for any windows applications, However how does qt take care of it? What are the header files to be included to avoid this error for qt examples? Please help me with your suggstions and let me know if I am missing any steps also. Thanks Regards Arjun ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] compilation of qt5.5 examples with qtcreator with visual studio 2012 (msvc2012) fails
On Monday 09 March 2015 23:44:08 Arjun Das wrote: *cpp.exe.2968.1625.jom qtmain.lib(qtmain_win.obj) : error LNK2019: unresolved external symbol __imp__CommandLineToArgvW@8 referenced in function _WinMain@16 I understand that this error is because of winmain function missing which is required by visual studio compiler for any windows applications, However how does qt take care of it? What are the header files to be included to avoid this error for qt examples? Please help me with your suggstions and let me know if I am missing any steps also. That has nothing to do with headers. The problem is linking and it seems to be missing at least one DLL. According to MSDN (the first hit on Google when you search for CommandLineToArgvW), the function has been in shell32.dll since Windows 2000. So the question is: was shell32 listed in the list of libraries to link to? I tried to link the shell32.dll as follows in my .pro file : *HEADERS = hello.h* *SOURCES = hello.cpp \* * main.cpp* *win32:LIBS += C:\Windows\System32\shell32.dll* However I got the following error : On Monday 09 March 2015 23:44:08 Arjun Das wrote: *cpp.exe.2968.1625.jom qtmain.lib(qtmain_win.obj) : error LNK2019: unresolved external symbol __imp__CommandLineToArgvW@8 referenced in function _WinMain@16 I understand that this error is because of winmain function missing which is required by visual studio compiler for any windows applications, However how does qt take care of it? What are the header files to be included to avoid this error for qt examples? Please help me with your suggstions and let me know if I am missing any steps also. That has nothing to do with headers. The problem is linking and it seems to be missing at least one DLL. According to MSDN (the first hit on Google when you search for CommandLineToArgvW), the function has been in shell32.dll since Windows 2000. So the question is: was shell32 listed in the list of libraries to link to? I tried to link the shell32.dll as follows in my .pro file : win32:LIBS += shell32.lib I still get the same error. I am not sure how to link a dll file with QT.I was trying to follow an old thread : http://forum.qt.io/topic/6804/using-an-existing-dll-lib-with-qt/9 Moreover, I was expecting the examples to work right away without the user needing to add any extra library.As a beginner, i wanted a good example for reference and go ahead with that. Thanks Regards Arjun ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] compilation of qt5.5 examples with qt creator with visual studio 2012 (msvc2012) fails
On Monday 09 March 2015 23:44:08 Arjun Das wrote: *cpp.exe.2968.1625.jom qtmain.lib(qtmain_win.obj) : error LNK2019: unresolved external symbol __imp__CommandLineToArgvW@8 referenced in function _WinMain@16 I understand that this error is because of winmain function missing which is required by visual studio compiler for any windows applications, However how does qt take care of it? What are the header files to be included to avoid this error for qt examples? Please help me with your suggstions and let me know if I am missing any steps also. That has nothing to do with headers. The problem is linking and it seems to be missing at least one DLL. According to MSDN (the first hit on Google when you search for CommandLineToArgvW), the function has been in shell32.dll since Windows 2000. So the question is: was shell32 listed in the list of libraries to link to? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] = 5.3 bug? GraphicsView and mouse event doubleclick flag
Hi Trolls! The documentation said that the Qt::MouseEventCreatedDoubleClick flag of Qt::MouseEventFlags Indicates that Qt has created a MouseButtonDblClick event from this event. The flag is set in the causing MouseButtonPress, and not in the resulting MouseButtonDblClick. It is marked as since Qt 5.3, and the corresponding issue ticket is actually https://bugreports.qt.io/browse/QTBUG-25831 I'm am trying to use this feature (w/ Qt 5.4) for a QGraphicsView (placed on a QtDesigner based MainWindow) and i've traced the event calls when doing a double click: - mouse press event w/ empty flags - mouse release event with empty flags - mouse double click event with empty flags - mouse release event with empty flags So basically my view never receive the event with the MouseEventCreatedDoubleClick falg set. In the description of QTBUG-25831, it seems that only QWidgetWindow receive the event with the falg set, but not the QWidget. Is this a bug, a feature, or am I missing something? Regards, Chris ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] compilation of qt5.5 examples with qtcreator with visual studio 2012 (msvc2012) fails
On Tuesday 10 March 2015 01:10:38 Arjun Das wrote: I tried to link the shell32.dll as follows in my .pro file : win32:LIBS += shell32.lib win32: LIBS += -lshell32 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCore missing check for memory allocation
On Monday 09 March 2015 07:57:18 Knoll Lars wrote:
The problem is that a non throwing new can’t reliably detect OOM issues.
Even if we did check the return value of every 'operator new’ call in Qt,
this would leave us with one big problem that’s more or less impossible to
solve. The main problem is that we call new inside other constructors (ie.
Inside another call to operator new).
The fundamental issue that can’t be solved without exceptions is that this
should cause the outer operator new to fail (as the inner object didn’t
get constructed, thus the outer object is not fully constructed and
usable). But without exceptions there’s no way we can report this back
through the outer constructor call.
You will be glad to know that the compiler is required to add a null check
before calling the constructor in case of a noexpect or non-throwing operator
new.
[C++11 5.3.4 13]
Other than that, if an user of Qt wants a different behavior for malloc and
new, it is easy enough to use the facilities C++ provides, such as providing a
global operator new, or overriding malloc.
If the application provides its own symbol 'malloc', that one will be used.
So Qt does not need to do anything.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org#include QtCore/QtCore
extern C void *__libc_malloc(size_t s);
extern C void __libc_free(void *s);
extern C {
void *malloc(size_t s) {
printf(malloc: %d\n, int(s));
return __libc_malloc(s);
}
}
void *operator new(size_t s) {
printf(new: %d\n, int(s));
return __libc_malloc(s);
}
void operator delete(void *v) {
__libc_free(v);
}
struct Test { double a,b; };
int main() {
printf(main\n);
Test t;
QListTest() t t t;
QVectorchar v(88);
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCore missing check for memory allocation
On 03/03/15 22:10, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com wrote: On Mon, Mar 02, 2015 at 10:11:33AM -0800, Thiago Macieira wrote: On Monday 02 March 2015 11:21:10 Oswald Buddenhagen wrote: I am actively against it while it's a huge burden on us for little perceived benefit. You have to convince me of the benefit against the cost. i still don't see that huge burden. i see introducing a few (inline) functions in two alternative #ifdef branches, and a global search replace operation. You need to replace all the new too for this to be effective. this aims at the reliably failing builds without exception support, so the non-throwing new's return value would have to be checked to complement the malloc wrapper. The problem is that a non throwing new can’t reliably detect OOM issues. Even if we did check the return value of every 'operator new’ call in Qt, this would leave us with one big problem that’s more or less impossible to solve. The main problem is that we call new inside other constructors (ie. Inside another call to operator new). The fundamental issue that can’t be solved without exceptions is that this should cause the outer operator new to fail (as the inner object didn’t get constructed, thus the outer object is not fully constructed and usable). But without exceptions there’s no way we can report this back through the outer constructor call. while this would be reasonably simple (just replace new with qNew or something like that), it would be a) kinda ugly and b) would expand to lots of code. the other case is a build with exceptions where new throws as normal and qMalloc (used from c++ code) throws as well. malloc calls from c code would obviously need to handle and propagate malloc failures up to a point where we can see them and throw, which isn't much effort for our own code. however, there is a serious problem: stack unwinding resulting from an exception being thrown (even if it just aborts in the end because nobody catches it) requires all objects on the stack to keep their internal state consistent enough so that invoked d'tors won't crash - even when a c'tor throws before initialization finishes. this is clearly at least partially the exception safety which we have deemed out of scope so far because of an unreasonable cost/benefit ratio. i presume we're not going to change our opinion on that point. No. We will not change this. We have tried to get some partial exception safety for some of our code during the Symbian days and it was extremely error prone, a huge pain to maintain and caused an incredible amount of bloat in the created binaries. Doing this (and maintaining it) for all of Qt would require a development team a couple of times the size we currently have, and still would bring new feature development almost to a standstill. regarding 3rd party libraries: some would need to be excluded from the support entirely (because they are uncooperative), while others may need fixes inside or around the libs. generally, whether they return null or throw (while being exception-safe) doesn't matter, as the mechanisms can be translated into each other. i don't think the effort for that would be prohibitive if we had a serious interest in it, but it certainly wouldn't come for free. so to summarize ... color me convinced. replacing malloc it is. Yes, the best solution IMO is still to use your own malloc and operator new replacements. In addition, OOM handlers on the OS level can help. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] msvc warning policy in qt
Hello, we have an in-house policy to use warning level 4 and warnings-as-errors with our projects. The problem is that qt headers are generating warnings when using this level. We switch off some silly warnings likeunreferenced inline function has been removed, which are just informal and cant be removed by us. I created a Qt_prolog.h and an Qt_epilog.h which have to be included before and after every Qt Header. prolog is this: # pragma warning (push) # pragma warning( disable : 4201 ) // nonstandard extension used : nameless struct/union # pragma warning( disable : 4127 ) // conditional _expression_ is constant # pragma warning( disable : 4510 ) // default constructor cannot be generated # pragma warning( disable : 4512 ) // assignment operator could not be generated # pragma warning( disable : 4244 ) // conversion from int/double/float/long to qreal, possible loss of data # pragma warning( disable : 4251 ) // class needs to have dll-interface to be used by clients of class # pragma warning( disable : 4800 ) // BOOL : forcing value to bool true or false (performance warning) # pragma warning( disable : 4245 ) // initializing : conversion from int to unsigned short, signed/unsigned mismatch # pragma warning( disable : 4251 ) // class QExplicitlySharedDataPointerT needs to have dll-interface to be used by clients of class # pragma warning( disable : 4231 ) // nonstandard extension used : extern before template explicit instantiation # pragma warning( disable : 4275 ) // non dll-interface class x used as base for dll-interface class y # pragma warning( disable : 4995 ) // method name was marked as #pragma deprecated # pragma warning( disable : 4718 ) // recursive call has no side effects, deleting epilog is just # pragma warning (pop) actually there are some warnings i would myself never switch off like conversion from int/double/float/long to qreal, possible loss of data orinitializing : conversion from int to unsigned short, signed/unsigned mismatch,but without that i get a warning ( and an error)# now i found out that qglobal.h does disable warnings in its own globally, so it pollutes my warning level by that. it even disables the imho very important warnings assignment within conditional _expression_ andC++ exception handler used, but unwind semantics are not enabled. Specify /EHsc . Especiallyassignment within conditional _expression_ is a live saver. you can easyly suppress it by writing if((a=open()) if the = is your real intent. C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc is a strong idication you are using exceptions but in case of one thrown you are not unwinding stack getting memory leaks and other problems. Luckily you can disable the warnings disabling, by definingQT_CC_WARNINGS so i added #define QT_CC_WARNINGS #include qglobal.h after the# pragma warning (push) and added all warning disabling from qglobal.h to the end of the prolog file, whiuch are: // copied from qglobale.h # pragma warning(disable: 4251) /* class type needs to have dll-interface to be used by clients of class type2 */ # pragma warning(disable: 4244) /* conversion from type1 to type2, possible loss of data */ # pragma warning(disable: 4275) /* non - DLL-interface classkey identifier used as base for DLL-interface classkey identifier */ # pragma warning(disable: 4514) /* unreferenced inline function has been removed */ # pragma warning(disable: 4800) /* type : forcing value to bool true or false (performance warning) */ # pragma warning(disable: 4097) /* typedef-name identifier1 used as synonym for class-name identifier2 */ # pragma warning(disable: 4706) /* assignment within conditional _expression_ */ # if _MSC_VER = 1310 // MSVC 2003 # pragma warning(disable: 4786) /* identifier : identifier was truncated to number characters in the debug information */ # endif # pragma warning(disable: 4355) /* this : used in base member initializer list */ # if _MSC_VER 1800 // MSVC 2013 # pragma warning(disable: 4231) /* nonstandard extension used : identifier before template explicit instantiation */ # endif # pragma warning(disable: 4710) /* function not inlined */ # pragma warning(disable: 4530) /* C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc */ additionallyi found includeQtCoreqfunctions_wince.h(224):#pragma warning(disable: 4273) which disables the warningfunction : inconsistent DLL linkage Two definitions in a file differ in their use ofdllimport. so i added #ifdef UNDER_CE #include qfunctions_wince.h #endif // UNDER_CE to my prolog after my#include qglobal.h My problems are solved this way ,but i would rather like that qt takes care of this itself, meaning allowing setting warninglevel to 4 and warnings as errors and applications compile out of the box, maybe by using my prolog/epilog approach. Regards, Gunnar Roth ___ Development
Re: [Development] [RFC] more gerrit codereview scores?
On 07/03/15 04:03, Thiago Macieira thiago.macie...@intel.com wrote: On Friday 06 March 2015 17:42:00 Oswald Buddenhagen wrote: 1) i'd like to propose the introduction of the code review score -3. -1: I would prefer this is not merged as is, advisory, non-sticky -2: This shall not be merged as is, blocking, non-sticky -3: This shall not be merged [at all], blocking, sticky Agreed, this makes sense. The -1 means if someone approves, ignore me, whereas -2 means this needs to change, can't be merged. The -3 is just to indicate an approach that can never work, such as a feature we cannot accept or a patch submitted to the wrong branch. -2 are already rather rare, so I expect -3 to be used only once in a blue moon. Agree, it would be nice to have a non sticky -2, so the sticky -3 makes sense. 2) i'd like to propose the introduction of the code review score +3. let's start with the scores: +3: Looks good to me, approved, enabling +2: Looks good to me, but someone else must approve, advisory +1: Someone else must review this, advisory possible uses: - non-approvers (specifically, not-yet-approvers) would have two levels to express their opinion You mean four levels, since they also get -1 and 0. - the new +1 gives the possibility to explicitly give a neutral score (substitute for +0, which gerrit does not permit) - *maybe* some approvers would feel less inclined to approve changes they don't fully understand (yes, this is actually a problem), simply because of the psychological effect of the possibility to express the opinion with more numerical nuance. i don't feel very strongly about this one, but i think it would add value. I don't like this one. If you don't want to express an opinion, leave your score at 0. I don't see the need to have a value saying I've reviewed but have no opinion. I also don't see why approvers are giving +2 if they don't fully understand it. Not only should they be using the right value for that, this change wouldn't help in any way since they could just turn around and give +3 to changes they don't fully understand. As a drawback, it would make Qt's Gerrit behave very differently from everyone else, where a +2 does mean approval. In my opinion, this change has no pros and has cons. While I see the reasoning behind, I think this overcomplicates things. A non-sticky -2 that balances a +2 should be enough to solve most of the issues, and the proposed +1 sounds very much like the current +0 to me, so we can IMO just as well leave it out. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
