| Author |
 Topic  |
|
|
nholthaus
Junior Member
20 Posts |
 Posted - Feb 23 2016 : 10:18:40 AM
|
When using `move implementation to source file` on a function which returns a Qt object, the namespace `QT_NAMESPACE` is appended to the object. It's probably getting parsed out from some Qt meta-object, but it's not a proper namespace, and results in the following error in msvc.
ex. QString getString() const {};
-> move to source
QT_NAMESPACE::QString getString()
{
// todo
}
error C2653: 'QT_NAMESPACE' : is not a class or namespace name
I know you probably can't/won't support problems with all 3rd party frameworks, even large ones like Qt, but a simple filter for the QT_NAMESPACE namespace would be an adequate solution. The problem does not seem to affect input arguments. |
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Feb 23 2016 : 3:47:36 PM
|
Which version of Qt are you using? So far I cannot reproduce this effect.
Can you please go to:
VA Options -> System Info -> Copy Info
and paste the details (from the clipboard) into your reply. This will give us the basic information about your setup. |
zen is the art of being at one with the two'ness |
 |
|
|
nholthaus
Junior Member
20 Posts |
Posted - Feb 24 2016 : 09:24:32 AM
|
I'm using Qt 5.5.0. I don't have any of the Qt visual studio add-ins installed.
License: [email protected] (1-user license) Support ends 2016.12.21
VA_X.dll file version 10.9.2089.0 built 2016.02.01
DevEnv.exe version 12.0.40629.0 Ultimate
msenv.dll version 12.0.40629.0
Comctl32.dll version 6.10.7601.18837
Windows 7 6.1 Build 7601 Service Pack 1
24 processors (x86-64, WOW64)
Language info: 1252, 0x409
Platform: Project defined
Stable Includes:
C:\Program Files (x86)\Windows Kits\8.1\Include\winrt;
C:\Program Files (x86)\Windows Kits\8.1\Include\shared;
C:\Program Files (x86)\Windows Kits\8.1\Include\um;
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include;
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include;
Other Includes:
Stable Source Directories:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src;
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\src\atl;
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\src\mfcm;
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\src\mfc;
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Feb 24 2016 : 10:30:09 AM
|
Are you able to reproduce this problem in a new, default project, just adding a very simple class with the Qt function, and any Qt library directories to the C++ include directories that you need?
If so, would you be able to send me the project so I can test it here. I have not been able to reproduce this here, so I am wondering if there is something you are doing differently. Please submit the files via the form:
http://www.wholetomato.com/support/contact.asp
including this thread ID or URL in the description, so we can match it up. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Feb 24 2016 : 11:00:11 AM
|
Nicolas: The email address in your member profile appears to be incorrect. Notifications associated with your topic subscriptions bounce.
Please update your profile and resubscribe to your topics of interest. You can find your recent posts by searching for yourself in the member directory.
Thank you. |
|
|
|
nholthaus
Junior Member
20 Posts |
Posted - Feb 28 2016 : 5:02:01 PM
|
| I submitted the requested project. Qt is too big/complex to include with it, so whoever does the test should just get it via the free open-source installer at http://www.qt.io/download/. The install path for Qt can be set from the QTDIR environment variable (if you generate the project from cmake) or edited in the project file under /build. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Mar 01 2016 : 4:23:30 PM
|
I have the project, many thanks for this. I have a fix that works for me here.
Can you please create a file called "va_stdafx.h" and place it in the same directory as your SLN file, the "\gtest-gui\build\" directory in this case. Edit the file to add the line:
#define QT_NAMESPACE
making sure the file ends with a blank line. Now press the button:
VA Options -> Performance -> Rebuild symbol databases
and restart the IDE. This will take a couple of minutes while VA reparses your stable include directories.
Depending on your environment QT_NAMESPACE can be a proper namespace, and VA is picking it up since it is referenced by some of the Qt header files. The va_stdafx.h file takes priority, and tell's VA to ignore it.
Doing this stops the namespace being applied to QString when doing a Create Implementation for me. |
zen is the art of being at one with the two'ness |
|
|
|
nholthaus
Junior Member
20 Posts |
Posted - Mar 03 2016 : 08:35:20 AM
|
Thanks for checking into the workaround. I have to say though it's a bit unsatisfactory for the following reasons:
- The visual studio projects and 'build' directory are all generated files (from cmake), which are not source controlled and which get deleted constantly, so I'd have to redo the fix every time.
- The only way I could make that tractable would be to add your patched va_stdfax.h file to my source control, and include it in my cmake and add a tool dependency to my project which currently has none. I'd also be dependent on you to keep the fix backwards compatible in future builds.
It's do-able, but unpleasant, and it creates work for my team to be able to use VA, when obviously the reason we like it is because it reduces the workload. As such it may be a non-starter.
It seems to me like the actual problem is that the QT_BEGIN_NAMESPACE macro is supposed to evaluate to nothing (https://wiki.qt.io/Qt_In_Namespace) in cases where the Qt libraries aren't cross-linked (which is probably all windows cases) or where only a single version of Qt is used (my case specifically), but VA is picking it up as QT_NAMESPACE in all cases. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Mar 03 2016 : 12:32:21 PM
|
va_stdafx.h is something we have been supporting for a while now, and it is something we are going to be keeping. Not everyone needs or uses this, but it gets enough use that removing support for this would cause a lot of problems for our users. But clearly this does not work well for you, since the projects are being regenerated frequently.
Do you have a lot of users / computers with this problem? If the number is not to large, can you try the steps under the "Visual Assist build 1908 and older" section here:
https://wholetomato.fogbugz.com/default.asp?W302
copying and editing the StdAfx.h file, adding the line:
#define QT_NAMESPACE
at the end.
To work out what should be done with the QT_BEGIN_NAMESPACE macro we would have to know the state of your pre-processor directives, so we could work out which code was active and which code is inactive. Unless you are actually compiling the code, this is actually hard, especially when debug vs release can be different. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Move implementation to source appends QT_NAMESPACE
