| Author |
 Topic  |
|
|
rpalma
Junior Member
Belgium
23 Posts |
 Posted - Sep 21 2017 : 03:57:54 AM
|
Hello
When VA option 'convert dot to -> in C/C++' is enabled, it always seems to work incorrectly with std::string here:
#include <string>
{
std::string aString;
aString-> // . is automatically replaced by -> here
}
void fun(const std::string& s)
{
s-> // . is automatically replaced by -> here
}
When disabling VA completely or option 'convert dot to -> in C/C++' is disabled, the dot is not being replaced by ->.
This behavior can be reproduced on multiple PC's.
According to the documentation this shouldn't be happening as it states: 'A conversion is not made if Visual Assist has any doubt about its certainty.' ;)
/////////////////////////////////////////////////////////////
VA_X.dll file version 10.9.2231.0 built 2017.08.15
DevEnv.exe version 14.0.25420.1 Professional
msenv.dll version 14.0.25431.1
Comctl32.dll version 6.10.10586.839
Windows 10 10.0 Build 10586
8 processors (x86-64, WOW64)
Language info: 1252, 0x813
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)\Windows Kits\10\Include\10.0.10240.0\ucrt;
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include;
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include;
D:\[Development]\Dev_C2m_2015\Most Recent\Dependencies\ATLServer\include;
Other Includes:
Stable Source Directories:
C:\Program Files (x86)\Windows Kits\10\Source\10.0.10240.0\ucrt;
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src;
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\src\atl;
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\src\mfcm;
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\src\mfc;
|
|
|
feline
Whole Tomato Software
United Kingdom
18750 Posts |
Posted - Sep 21 2017 : 10:58:57 AM
|
The fact that this happens on multiple machines is very interesting. Does the setting:
VA Options -> Correction -> Convert dot to -> if operator -> is overloaded
have any effect on this? For what it's worth, I cannot reproduce the problem here, but since it's not machine specific the trigger is obviously shared.
If you create a new, empty .cpp file in your main solution, do you still see this problem?
Can you please try creating a new, default C++ solution, and see if you get the problem in this solution?
I am trying to find if the problem is file, solution or machine specific. Most of your include directories look standard, so there is nothing madly obvious here.
If you press backspace the conversion should be undone, taking you back to the dot. At this point, are you seeing the correct and expected members of std::string listed?
If you show VA View, then place keyboard focus back into the editor, and now hover the mouse over the type "std::string" or the variable "aString" is the correct information displayed? You should see the members of std::string listed. |
zen is the art of being at one with the two'ness |
 |
|
|
rpalma
Junior Member
Belgium
23 Posts |
Posted - Sep 22 2017 : 04:29:19 AM
|
Hello,
Disabling option 'VA Options -> Correction -> Convert dot to -> if operator -> is overloaded' doesn't change the effect, dot is still replaced by -> for std::string variables.
The correct and expected members of std::string are listed by VA, even after the conversion to ->. Also after undoing the conversion, reverting to dot, the correct members are listed.
The problem doesn't occur when starting from a new solution.
Now for the more interesting part:
When hovering over a std::string variable, VA displays two known types: first 'std::string' and second 'typedef oratext *string'.
This second typedef is defined in Oracle Pro*C header file ORATYPES.h as:
#if !defined(MOTIF) && !defined(LISPL) && !defined(__cplusplus) && !defined(LUSEMFC)
typedef oratext *string;
#endif
The typedef is added to the global namespace.
Strange thing is: the header file containg the typedef is listed only as an external dependency in one specific subproject, but is not included in the file being edited.
The typedef also isn't accessible from the point where the code was being edited.
Trying to compile next code fragment, omitting the std namespace, the compiler will complain:
{
string sTest1; // error C2065: 'string': undeclared identifier
std::string sTest2; // ok
sTest2-> // . being replaced by ->
}
So it seems that VA is being confused by a typedef added to the global namespace in an externally referenced header file in a different subproject, even when a type in a specific namespace is being referenced. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18750 Posts |
Posted - Sep 22 2017 : 07:04:59 AM
|
This makes sense, and explains why this is happening on several different machines. VA is designed to parse all of the solution, partly so we can help you with the members of a class even before you have included this class in the current file. So in this sense this behaviour is by design, but it can lead to unhelpful side effects like this.
Can you please make a new text file called "va_stdafx.h" and place it in the same directory as your .SLN file. Edit the file to add the text:
typedef oratext oratext
make sure the file ends with a blank line, and now you can close the file. There is no need to add this file to the solution, VA automatically looks for this file, and uses it to help understand complex code, or work around code that can cause problems.
Now please go into the IDE and press the button:
VA Options -> Performance -> Rebuild symbol databases
and restart the IDE. This will do a full rebuild of the VA symbol database, which should only take a few minutes. Does this fix the problem with std::string? If so, it will be safe to add the va_stdafx.h file to source control, since it is not actually part of the solution. |
zen is the art of being at one with the two'ness |
|
|
|
rpalma
Junior Member
Belgium
23 Posts |
Posted - Sep 22 2017 : 09:30:24 AM
|
Unfortunately this didn't solve the problem.
I also tried adding va_stdafx.h to the directory of the project that references the Oracle header, and to the directory of the project that contains the code that is being edited. Both didn't help.
Is there maybe a possibility to exclude the Oracle header file from the VA parsing? |
|
|
|
feline
Whole Tomato Software
United Kingdom
18750 Posts |
Posted - Sep 23 2017 : 10:31:04 AM
|
Odd, I had expected the va_stdafx.h file to fix this, but I am seeing the same effect here. Is editing the file where "ORATYPES.h" an option? Either directly, or indirectly, to hide this specific #include from VA's parser?
Replacing the #include statement with the following code:
#ifndef VA_IGNORE_THIS_FILE
#define VA_INCLUDE_HIDDEN "ORATYPES.h"
#else
#define VA_INCLUDE_HIDDEN ""
#endif
#include VA_INCLUDE_HIDDEN
and then doing a VA symbol database rebuild hides this #include, and thus the typedef from VA, without needing to edit the library header its self. Not really the elegant solution I was hoping for, but hopefully this will work well for you. |
zen is the art of being at one with the two'ness |
|
|
|
rpalma
Junior Member
Belgium
23 Posts |
Posted - Sep 25 2017 : 04:49:45 AM
|
This workaround seems to work, by decorating the #include "OCI.H", which in turn #includes "ORATYPES.H'.
Although it remains puzzling why VA insisted to replace the . by -> when there was a doubt, which VA seems to know about as the correct std::string members were displayed after the ->.
But I can live with this solution for now.
Thanks. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18750 Posts |
Posted - Sep 25 2017 : 06:32:15 AM
|
| Thank you for the update. I am not quite sure why this typedef is having this effect either, but at least this is a working solution for you. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
std::string unwanted . to -> conversion
