Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Feature Requests
 Please improve . to -> correction
 New Topic  Reply to Topic
 Printer Friendly
Next Page
Author Previous Topic Topic Next Topic
Page: of 2

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 10 2018 :  11:27:54 AM  Show Profile  Reply with Quote
It is really common to be walking through a collection of pointer elements - such as:

std::vector<std::shared_ptr<T>> items;

for (auto & e : items)
e. <-- when I type that dot - I want VA to apply the "fix . and ->" feature so that I get e-> and can continue typing with appropriate suggestions for what a T element can do...

Currently, VA leaves it as e. which gives me suggestions for what a shared_ptr or a unique_ptr or whatever can do. Close to useless. It's the inversion of the 99:1 - favoring the 1% of times where I need to manipulate the smart pointer compared to the 99% where I need to manipulate the element pointed to by the smart pointer.

I'm sure that other contexts could be improved as well - but the place I keep "stubbing my toe" is auto based for-loops.

Edited by - Mordachai on May 10 2018 11:33:44 AM

accord
Whole Tomato Software

United Kingdom
3287 Posts

Posted - May 10 2018 :  7:53:05 PM  Show Profile  Reply with Quote
The following setting controls that behavior:

Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 11 2018 :  4:52:56 PM  Show Profile  Reply with Quote
That is enabled. It is "working" extremely poorly. Hence this post :)

I agree - however - that it absolutely should be making that change for me...
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 12 2018 :  09:29:30 AM  Show Profile  Reply with Quote
Using VS2017 and VA 2270, I have added the following test code to a .cpp file:

class simpleFelineTestClass
{
public:
	simpleFelineTestClass(int nSizeOne, int nSizeTwo) { }
	void simpleMethodImplementation();
	void simpleMethodTwo();
	void simpleMethodThree();
	void simpleMethodFour();
};

void simpleForLoopCheck()
{
	std::vector<std::shared_ptr<simpleFelineTestClass> > itemsFoo;
	for (auto & eFoo : itemsFoo)
	{
		// test - type dot after "eFoo"
		eFoo;
	}
}

I have double checked that VA is replacing the dot with "->" by turning off the Convert dot feature, and when I do, the dot is left alone. Can you please try the same sample code on your system, and see what happens? I have tried to go with symbol names that should be fairly unique, so should not clash with anything on your system, making this a reasonable test.

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 16 2018 :  4:09:48 PM  Show Profile  Reply with Quote
That fails to fix the dot, and gives me goofy suggestions - as per my complaint:



And that reminds me - I hate it when I choose "operator XX" and I get:

eFoo.operator-> for example. I just want the operator...!

eFoo->

Or

eFoo =

not

eFoo.operator=(...)

...

Lest you think I'm wrong about my settings:





Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 16 2018 :  5:13:37 PM  Show Profile  Reply with Quote
In a way this is good news, it shows that what ever is going wrong here is easy to reproduce, at least on your system. Now we just need to find the trigger.

Can you please try making a new, empty cpp file in your main solution, and then copy and paste in this test code, and see if you still see this problem, or if the dot is correctly converted?

If you still get the problem, can you please try making a new, default C++ solution and try the same test code there? I am looking to see if this is a solution specific or machine specific problem.

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 17 2018 :  08:00:01 AM  Show Profile  Reply with Quote
Added "source.cpp"

Added your code - same results.
Asked VA to include <vector> and <memory> - and the error squiggles resolved - but same results:



I then opened another small unrelated project - some example project from a Japanese manufacturer - and pasted your code into their main.cpp - and I get *correct* behavior - the dot is expanded immediately with appropriate suggestions.

This is a relatively trivial solution - only two project files, with maybe a dozen source files total.

I experimented with switching code generation from default to C++17 as it is in our solution - but it continues to work properly in their project.

So - ideas?

Edited by - Mordachai on May 17 2018 08:08:25 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 17 2018 :  3:39:22 PM  Show Profile  Reply with Quote
I suspect that in your main solution there is a macro, or possibly other symbol, that is causing our parser to get confused. Macros are often the cause of odd effects like this. Basically now the idea is to compare what the VA Context and Definition fields show for the relevant symbols in your main solution, compared to my system and your simple solution. Hopefully this will help us to pin down where the problem is coming from.

So, placing the keyboard caret into "eFoo" on the test line, my VA context and definition fields show:

simpleForLoopCheck.eFoo
std::shared_ptr<simpleFelineTestClass>& eFoo

Alt-Shift-G on "eFoo" offers to take me to the declaration, which is the auto line. Types of symbol lists just two types, the shared_ptr and the class. Goto member shows a dialog listing 38 members in total.

With the caret in "vector" from "std::vector" the context and definition fields show:

std.vector
class vector : public _Vector_alloc<_Vec_base_types<_Ty, _Alloc>>{...}

and alt-g takes me directly to:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\include\vector
line 675

for the "shared_ptr" in "std::shared_ptr" the context and definition fields show:

std.shared_ptr
class shared_ptr : public _Ptr_base<_Ty>{...}

alt-g takes me directly to:
c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\include\memory
line 1231

I suspect you will get the same results for "eFoo", but different results for either std::vector or std::shared_ptr.

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 17 2018 :  3:58:41 PM  Show Profile  Reply with Quote
[Addendum: I'm noticing that in other projects (at least one other) within that same main solution - this is working correctly.]

Right off the bat - eFoo shows simpleForLoopCheck.eFoo in the first context box, but _Ty& eFoo in the second. (I get your results in the small project)
Shift+Alt+g only gives me the option to go to the declaration in main sln, but offers 'types of symbol' and 'goto memeber' in the small sln.

in both - hovering over itemsFoo shows the expected definition 'std::vector<std::shared_ptr<simpleFelineTestClass>>'

eFoo in main sln on declaration line is a HUGE template/template/template expansion - see image:



Searches on "_Vector_val" and "_Vector_iterator" - entire solution including external items & subfolders in .h, .cpp, and .inl files have no results.

shift+alt+g on "eFoo" in declaration results in a VA error dialog "goto related could not identify any ..."

---

Looking at my solution - the entire thing - the only place I augment the std namespace is in "StringUtilities.h" - as follows:

namespace std {

	//////////////////////////////////////////////////////////////////////////
	// CString iterator support
	//
	// we place it in std to force it to have the same visibility and viability 
	// of any other standard overload of begin/end, and not to hide anything in std,
	// but merely be visible
	//
	// we could put it in its own NS, and then require users to bring that into visibility
	// but that NS could not be inside of Toolbox, or it will still be preferred by any
	// of our Toolbox NS algorithms (e.g. contains)
	//
	// so it has to be equal to std - either by being in std (as I'm doing here) or
	// by putting it in its own NS, and then requiring users to "using CStringIterators" or whatever...
	//

	// CStringT<T>

	template <typename T>
	typename std::enable_if<std::is_same<T, CStringA>::value, const char *>::type
		begin(const T & str) { return str.GetString(); }

	template <typename T>
	typename std::enable_if<std::is_same<T, CStringA>::value, const char *>::type
		end(const T & str) { return str.GetString() + str.GetLength(); }

	template <typename T>
	typename std::enable_if<std::is_same<T, CStringW>::value, const wchar_t *>::type
		begin(const T & str) { return str.GetString(); }

	template <typename T>
	typename std::enable_if<std::is_same<T, CStringW>::value, const wchar_t *>::type
		end(const T & str) { return str.GetString() + str.GetLength(); }

} // std

Edited by - Mordachai on May 17 2018 4:02:25 PM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 18 2018 :  08:38:02 AM  Show Profile  Reply with Quote
I am really puzzled by the fact that this works in one project, yet fails in another project. File specific and solution specific both make sense, I can easily see how this could happen, but I am not sure what could cause a problem like this to be project specific. Are the two projects both C++? Are the code files in both projects using the same file extensions?

I am just wondering if one project might be C++ while the other C++/CLR, or something else, that would clearly mark the projects as different in VA's eyes.

I have tried adding your "namespace std" code to my test project, and even after a full VA symbol database rebuild, this did not make any difference for me. So I am starting to wonder if something else is triggering the problem, but I am not sure what.

First some questions to make sure I understand everything correctly.

When you are testing this code in the different projects in your solution, are you testing in an EMPTY code file? So just the sample code and the two required header files:

#include <vector>
#include <memory>

I ask because another header file being included in the code file might explain why this seems to be project specific.

I cannot reproduce the very long type for "eFoo" in the for statement, and the error message from Alt-Shift-G on "eFoo" in the for statement suggests the problem is with VA's understanding of either auto or the for loop, rather than the template types, which is really quite unexpected.

OK, as a sanity check, can you place the caret into "for" and see what is shown in the VA context and definition fields, and also check what alt-g does? I am getting both fields showing nothing, and nothing happens when I press alt-g. I am expecting the same for you.

The keyword "auto" in the for statement is a bit more interesting. When I place the caret into auto the context and definition fields show:

std.shared_ptr<simpleFelineTestClass>
class : public _Ptr_base<simpleFelineTestClass>{...}

and alt-g takes me to:

c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include\memory
line 1317

which is the declaration for shared_ptr. So VA has worked out the type of auto here. Given your tooltip I suspect you will see something different here.

Another sanity check, partly for my own piece of mind, can you try this extended test case please. I have just added the required include files and a very simply pointer test function to the existing code sample. I would like to know that VA can convert dot to -> in a very simple test case in your main solution:

#include <vector>
#include <memory>

class simpleFelineTestClass
{
public:
	simpleFelineTestClass(int nSizeOne, int nSizeTwo) { }
	void simpleMethodImplementation();
	void simpleMethodTwo();
	void simpleMethodThree();
	void simpleMethodFour();
};

void simpleForLoopCheck()
{
	std::vector<std::shared_ptr<simpleFelineTestClass> > itemsFoo;
	for (auto & eFoo : itemsFoo)
	{
		// test - type dot after "eFoo"
		eFoo;
	}
}

void sanityCheckPointerHandling()
{
	simpleFelineTestClass localVar(1, 3);
	simpleFelineTestClass *pLocalPtr = &localVar;
	// test - here dot is left alone
	localVar;
	// test - here dot is converted to ->
	pLocalPtr;
}

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 18 2018 :  10:08:47 AM  Show Profile  Reply with Quote
quote:
Originally posted by feline

I am really puzzled by the fact that this works in one project, yet fails in another project. File specific and solution specific both make sense, I can easily see how this could happen, but I am not sure what could cause a problem like this to be project specific. Are the two projects both C++? Are the code files in both projects using the same file extensions?

All of our projects are C++ - and I've enabled C++ 17 in VS2017 in all of them, though I believe that this issue predates my change to C++ 17 (but memory is often fickle).

quote:
Originally posted by feline

When you are testing this code in the different projects in your solution, are you testing in an EMPTY code file?

Yesterday I tested it in two places - once in one of the libraries in the main solution simply at the end of the .cpp (outside of any namespaces).

I also created a blank .cpp in the main project itself with just your test code (and had removed the other copy). This had the exact same results - and I made sure NOT to #include ANYTHING AT ALL initially, and then only <vector> and <memory> - but not the StdAfx.h.

quote:
Originally posted by feline

OK, as a sanity check, can you place the caret into "for" and see what is shown in the VA context and definition fields, and also check what alt-g does? I am getting both fields showing nothing, and nothing happens when I press alt-g. I am expecting the same for you.

I get no tooltip for the 'for' and alt-g does nothing and shift-alt-g issues an error '...not available...' (all perfectly reasonable)

quote:
Originally posted by feline

Another sanity check, partly for my own piece of mind, can you try this extended test case please.


The extended sanity check works - dot is left as-is for the reference, and converted to a -> for the raw pointer.
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 18 2018 :  10:13:43 AM  Show Profile  Reply with Quote
You mention it could be file-specific but not project-specific?

I only mentioned that it was working in at least one other project in that solution (MFC Toolbox Library) based on seeing it work in some code I was editing yesterday. However, that could be file-specific and not project-specific? I only just noticed it and said something - but I can't say exactly what its scope really is, nor even if I happened to notice this on a smart pointer in a for loop - or merely some pointer somewhere.

I just now added your extended test case to an arbitrary .cpp file in my MFC Toolbox Library - and in fact it fails in the same ways as it fails in the main project. So perhaps I did simply notice a . to -> expansion on a raw pointer (or some other pointer type or that the context is different or... ???)

I didn't think much of it yesterday - but when it "works" again - I'll be sure to take very clear notes of when & where exactly!
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 18 2018 :  1:56:12 PM  Show Profile  Reply with Quote
File specific is easy, basically anything further up the file that causes a cascade error for our parser. Sometimes this is in a header file, so it comes about via a #include line.

Solution specific tends to come about because of something in the solution, e.g. a macro that has the same name as one of the symbols you are working with, and so can encourage parser confusion.

Project specific makes sense for aspects of VA that are interested in the project grouping, e.g. Find References and Alt-g, and if something is in your current project or not. Library directories and global symbols are shared across projects, so project specific seems to count these out, but does not suggest any obvious mechanism for the problem.

I hope this makes sense.

I have updated the test code, adding a default constructor to the class, but more importantly adding a set of new tests to the final testing function. Can you please try these tests and see what happens? I am trying to separate out the components at work here. What is the trigger? Using a STL class? A for loop? An auto variable?

#include <vector>
#include <memory>

class simpleFelineTestClass
{
public:
	simpleFelineTestClass() { }
	simpleFelineTestClass(int nSizeOne, int nSizeTwo) { }
	void simpleMethodImplementation() { }
	void simpleMethodTwo() { }
	void simpleMethodThree() { }
	void simpleMethodFour() { }
};

void simpleForLoopCheck()
{
	std::vector<std::shared_ptr<simpleFelineTestClass> > itemsFoo;
	for (auto & eFoo : itemsFoo)
	{
		// test - type dot after "eFoo"
		eFoo;
	}
}

void sanityCheckPointerHandling()
{
	simpleFelineTestClass localVar(1, 3);
	simpleFelineTestClass *pLocalPtr = &localVar;
	// test - here dot is left alone
	localVar;
	// test - here dot is converted to ->
	pLocalPtr;

	simpleFelineTestClass testFelineArray[10];
	for (int n = 1; n < 10; ++n)
	{
		auto *felinePtr = &(testFelineArray[n]);
		felinePtr->simpleMethodTwo();
		// TEST THREE - what does typing dot here do?  Is the dot converted to -> or not?
		felinePtr;
	}

	std::vector<simpleFelineTestClass *> itemsSimplePtr;
	for (auto iterPtr : itemsSimplePtr)
	{
		// TEST FOUR - what does typing dot here do?  Is the dot converted to -> or not?
		iterPtr;
	}

	std::shared_ptr<simpleFelineTestClass> simpleSharedPtr;
	auto autoShared = simpleSharedPtr;
	auto & autoRefShared = simpleSharedPtr;
	// TEST FIVE - what does typing dot here do?  Is the dot converted to -> or not?
	autoShared;
	autoRefShared;
}

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 18 2018 :  3:16:45 PM  Show Profile  Reply with Quote
For sanity, I redid the checks as I went.
The original tests are: left alone, converted, [fail] left alone.

now the new ones:
THREE: converted.
FOUR: [fail] - it doesn't convert - but it doesn't suggest anything at all. It just sits there!
FIVE: both convert.

in TEST FOUR - the iterPtr is tipped as being 'simpleFelineTestClass *' exactly as it should.
but the tooltip for the auto in that case - is insane:




Edited by - Mordachai on May 18 2018 3:17:05 PM
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 18 2018 :  3:19:01 PM  Show Profile  Reply with Quote
I do use boost.

What I find the oddest is that I can find no references to _Vector_iterator or _Vector_val or _Vec_base_types etc. Where might they be coming from?
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 19 2018 :  05:20:37 AM  Show Profile  Reply with Quote
Based on this latest set of tests it looks like the problem is "std::vector" in your main solution, but why? Boost should not have any effect here, especially since we are actually testing with "std::vector", and I have boost installed here on my test system, where I am not seeing any of these problems.

Still, just to be sure, which version of Boost are you using?

Can you please do a search of your solution directory tree for any files called "va_stdafx.h". VA will look for this helper file, so there is no need for it to be part of the solution for it to work. This is a way of helping our parser out, but it is also a way of adding new symbols to the solution, that only VA considers, that you won't necessarily find without knowing where to look for them.

There is a default helper file, that is found at:

%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\<IDE version>_<random hash>\Extensions\<random hash>\Misc\stdafx.h

however this file should be safe, because it is global, and effects all solutions you open on your machine.

The other place to look is VA's Find Symbol dialog, and make sure you turn Off both "Show only symbols defined in current solution" and "Only classes, structs & namespaces". Do you see any sign of these vector symbols when you filter the dialog? When I do this, filtering the dialog with "_vector_iterator" I am left with 19 matching symbols, and the first symbol "std._Vector_iterator" takes me to:

c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\include\vector
line 274

if you get a different number of results this might be a useful clue.

Can you please open two instances of the IDE at the same time. In the first IDE open your main solution, and in the second IDE open the small solution where none of these problems happen. Now in both IDE's please show VA View, then place keyboard focus back into the editor, and now hover the mouse over "std::vector", specifically the "vector" part. What VA knows about the class should now be shown in the bottom section of VA View. Since this is fairly long, it is easier to simply compare the two IDE's, and see if VA seems to be showing the same information in both IDE's and solutions.

std::vector is standard, should be the same in both IDE's, but it is starting to look like somehow it isn't working like that here.

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 21 2018 :  11:32:56 AM  Show Profile  Reply with Quote
Windows indicates I have no files with name va_ anything in my solution tree.

I was using boost 1.66, but just switched to 1.67 on Friday, to see if that would help at all (there are also warnings about the compiler version being unknown in 1.66).

Looking at these projects side-by-side - I'm finding some very interesting / bizarre results!
This is the "simple solution" - where I (still) get the correct result when typing eFoo. (expands to -> correctly offering appropriate member functions) - yet - look at the tooltip for the eFoo here (whereas the auto is sensible):



And here you can verify that we get both the appropriate type of "iterPtr" in the simpler case, and yet the auto makes no sense:







Maybe it is a global cache file issue...?

(Note: the three images above are from the simpler solution - which does not include any of our libraries, nor boost - it's a simple library API example of its own - with no external dependencies beyond standard C++ and Windows).

---
EDIT: I am looking at the global files - and they're all timestamped as 5/8/18 @ 10:11 - presumably my installation time or your publishing time?

I have never edited those, and they seem innocuous.

Here's the section on vectors (line 369 in ..\Misc\StdAfx.h):
	template<class _Ty, class _A>
	class vector 
	{
	public:
		typedef _Ty& reference;
		typedef const _Ty& const_reference;
		typedef _Ty* pointer;
		typedef const _Ty* const_pointer;
		typedef std::iterator<_Ty> iterator;
		typedef std::iterator<_Ty> const_iterator;
		typedef std::iterator<_Ty> reverse_iterator;
		typedef std::iterator<_Ty> const_reverse_iterator;

		iterator begin();
		iterator end();
		const_iterator cbegin() const;
		const_iterator cend() const;
		reverse_iterator rbegin();
		reverse_iterator rend();
		const_reverse_iterator rbegin() const;
		const_reverse_iterator rend() const;
	};

Edited by - Mordachai on May 21 2018 11:58:09 AM
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 21 2018 :  12:20:50 PM  Show Profile  Reply with Quote
More enticing results -

I just went to our build-server - where I do our real builds to assemble our product for distribution (internal builds as well as beta and release builds).

I do very little work on the server - and zero editing / development work - only run scripts that call VS to build our solutions. VA is not - NOT - installed there.

Looking at your initial "reality check" code there, Feline, and I see:

eFoo is a 'std::shared_ptr<simpleFelineTestClass>'

auto is the same screen-shotted 'using std::_Vector...'

So it isn't just VA that is getting this wrong - rather VS is somehow the culprit - or something? lol - I don't know how VA and VS interact to deal with intellisense and so on...
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 21 2018 :  2:16:01 PM  Show Profile  Reply with Quote
This is getting stranger by the moment.

It's probably worth doing a couple of symbol database rebuilds here, before we try anything else, just to see if this fixes things.

First up, with just one instance of the IDE open, please press the button:

VA Options -> Performance -> Rebuild symbol databases

and then restart the IDE. This will tell VA to re-parse everything, including your stable include directories, which should only take a few minutes. Does this make any difference?

I did not suggest this earlier simply because I did not think it would help, when one solution is working and another solution on the same machine, with the same VA symbol database, has a problem. But it's definitely worth a try.

To rebuild the IDE symbol database, set:

IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> Recreate Database = True

and now restart the IDE and reload your solution.

As for how the IDE and VA intellisense interact, it partly depends on your settings. Which is why I tend to ask about the VA context and navigation fields, since we can be sure these are showing information from VA's database, allowing us to just focus on VA.

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 21 2018 :  4:00:26 PM  Show Profile  Reply with Quote
I already cleared the cache and rebuilt the databases several times - including after swapping out the boost version and in isolation after forcing the small project to use default language output (instead of calling for C++17).

No dice.

And again, VisualStudio on our server doesn't have VA installed - that's pure VS intellisense. So Intellisense seems to be generating that crazy template from hell that is sometimes throwing the VA parser or VS's own tooltip (actually, I assume it is VS that is generating those tooltips from intellisense, no?)

I double checked my prefs and looked at my registry on my local PC that is running VA. Nothing there except the override of 'CompletionOverwriteBehavior (1)'

So - to recap:

I get the odd auto tooltip from vanilla VS and VS+VA.
That oddity sometimes interferes with VA's ability to do . to -> expansion, but not always (simple solution seems to always work despite seeing the strange vector-template; whereas the complex full solution always seems to fail for a std::vector containing any pointer at all - shared_ptr or raw pointer; but works for expansion of literal arrays and other contexts having auto or non-auto smart or raw pointers.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 21 2018 :  6:08:33 PM  Show Profile  Reply with Quote
Rebuilding the symbol databases is sensible, so it makes sense you tried this a while ago.

If you compare the two solutions side by side, and the simple std::vector code sample, are you seeing the same or different information in the VA context and definition fields? If we just focus on these for now hopefully this will help a bit.

My current working theory / wild guess, is that one of the base classes for std::vector has a different definition in your problem solution. This would help to explain why this happens across several STL classes, but is still solution specific. Now if we could just start getting some useful clues to help prove this theory right... especially since I am not sure what the next theory is going to be yet

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 22 2018 :  08:42:48 AM  Show Profile  Reply with Quote
I hope I didn't come off as rude or dismissive of your idea! I just meant to let you know that this is something I've done throughout ;)

I guess I'm confused now as to whether it is project-specific?

My big project always seems to get a pointer within a vector wrong.
But my small project seems to get the auto type just as wrong - even if that doesn't always interfere with VA's . to -> expansion...

So - I was previously thinking that "all was well in little project" - but isn't that incorrect? Shouldn't the little project show auto to be std::vector<std::shared_ptr<simpleFelineTestClass>> ?!
Instead, it shows that weird _Vector ... CLASS TEMPLATE ... nonsense.

And what's even weirder to me - that nonsense shows up on our server in plain vanilla VS - without VA installed at all. Like this is a new glitch or "feature" of Intellisense that is throwing VA off?
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 22 2018 :  09:13:34 AM  Show Profile  Reply with Quote
This is frustrating for both of us, and sooner or later I am going to end up going over the same ground, either because I have lost track, or we have thought up a new test

The VA bug is project specific, that much we are sure of and clear on. The "problem" is that we are starting to dig into template code, and how deeply the intellisense parsers are parsing it, which gets "complex", if not down right messy. When the code gets compiled all of this complexity disappears, since the templates are created for each required type, and all of the macros are expanded.

In theory the IDE intellisense parser should have no effect on VA. Since something is clearly breaking somewhere I will try and avoid absolute certainty about anything here

Going back to the code block we are both looking at, test 4 fails, but tests 3 and 5 work. So the problem here is tied to how the for loop syntax interacts with the auto keyword. To me this looks like an "iterator loop", start at the beginning and keep going till you hit the end. So some complex tooltips make sense, since the long hand version of this is going to be fairly long.

Just looking at test 4, and also just looking at the VA context and definition fields, to try and eliminate the IDE as a consideration, I am going to list the results I get when placing the caret at different point in the code:

	std::vector<simpleFelineTestClass *> itemsSimplePtr;
	for (auto iterPtr : itemsSimplePtr)
	{
		// TEST FOUR - what does typing dot here do?  Is the dot converted to -> or not?
		// FAILS for user, nothing suggested, dot not converted
		iterPtr;
	}

can you please compare this and see what you get in your two solutions? In theory the small solution, where dot to -> is working will mirror my results, and your main solution will show a different result somewhere...

caret in "itemsSimplePtr" where it is declared, the first line of this block, I have:
sanityCheckPointerHandling.itemsSimplePtr
std::vector<simpleFelineTestClass *> itemsSimplePtr

caret in "for" keyword, the second line of the block, both fields are blank.

caret in "auto" keyword, the second line of the block, I have:
simpleFelineTestClass
class simpleFelineTestClass{...}


caret in "iterPtr", the second line of the block, I have:
sanityCheckPointerHandling.iterPtr
simpleFelineTestClass * iterPtr


caret in "itemsSimplePtr", the second line of the block, I have:
sanityCheckPointerHandling.itemsSimplePtr
std::vector<simpleFelineTestClass *> itemsSimplePtr


caret in "iterPtr" inside the for loop, where we are testing, I have:
sanityCheckPointerHandling.iterPtr
simpleFelineTestClass * iterPtr


zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 22 2018 :  2:21:09 PM  Show Profile  Reply with Quote
Feline - I can't investigate further just now - but I wanted to make clear that - at least for myself - I am not frustrated.

I appreciate the excellent feedback and support.

I hope to be able to revisit this either later today or tomorrow.

Thank you!
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 22 2018 :  3:10:51 PM  Show Profile  Reply with Quote
Get back to me when you can. I do want to get to the bottom of this, I am just not sure how sometimes.

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 24 2018 :  10:31:09 AM  Show Profile  Reply with Quote
quote:
Originally posted by feline
caret in "itemsSimplePtr" where it is declared, the first line of this block, I have:
sanityCheckPointerHandling.itemsSimplePtr
std::vector<simpleFelineTestClass *> itemsSimplePtr



same

quote:
Originally posted by feline
caret in "for" keyword, the second line of the block, both fields are blank.


same

quote:
Originally posted by feline
caret in "auto" keyword, the second line of the block, I have:
simpleFelineTestClass
class simpleFelineTestClass{...}



nope!

context: std.numeric_limits<long double>._Ty
definition: typedef long double _Ty
tooltip: using std::_Vector... (very long)

quote:
Originally posted by feline
caret in "iterPtr", the second line of the block, I have:
sanityCheckPointerHandling.iterPtr
simpleFelineTestClass * iterPtr


nope!

context: sanityCheckPointerHandling.iterPtr
definition: _Ty iterPtr
tooltip: simpleFelineTestClass *

quote:
Originally posted by feline
caret in "itemsSimplePtr", the second line of the block, I have:
sanityCheckPointerHandling.itemsSimplePtr
std::vector<simpleFelineTestClass *> itemsSimplePtr


same

quote:
Originally posted by feline
caret in "iterPtr" inside the for loop, where we are testing, I have:
sanityCheckPointerHandling.iterPtr
simpleFelineTestClass * iterPtr


nope!

context: sanityCheckPointerHandling.iterPtr
definition: _Ty iterPtr
tooltip: simpleFelineTestClass *
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 24 2018 :  10:37:14 AM  Show Profile  Reply with Quote
I just noticed one other thing -

With my mouse on "auto" in the for-loop expression:

in my simple project (which does agree with your findings) - the icon in the context box looks like a document window with two vertically arranged icon-blocks in left lower corner (not sure what that is telling me - project scope?),

whereas in my main project, that location gives a globe icon in the context box.

So the small project sees that auto as being not-as-global as my main project..?

And where the hell does std::limits come into all of this???
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 24 2018 :  10:39:28 AM  Show Profile  Reply with Quote
If I press ALT+G on the auto in the for loop in my main project - it takes me to <limits> at line 1207:

		// CLASS numeric_limits<long double>
template<> class numeric_limits<long double>
	: public _Num_float_base
	{	// limits for type long double
public:
	typedef long double _Ty;
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 24 2018 :  10:44:51 AM  Show Profile  Reply with Quote
#include <limits> in my simple project does not alter the outcomes.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18750 Posts

Posted - May 24 2018 :  3:23:56 PM  Show Profile  Reply with Quote
Um... yep, um. I was hoping for a difference in behaviour, and this is clearly a difference in behaviour. But like you, I am struggling to see where limits comes into this.

My best guess is that here the problem with "auto" is a symptom of a problem with STL iterators, since the for loop is basically a STL iterator loop. So, I have extended this simple test a little bit, this is the new version of this simple block:

	std::vector<simpleFelineTestClass *> itemsSimplePtr;
	for (auto iterPtr : itemsSimplePtr)
	{
		// TEST FOUR - what does typing dot here do?  Is the dot converted to -> or not?
		// FAILS for user, nothing suggested, dot not converted
		iterPtr;
	}
	// place caret into "auto" and what is shown in Context and Definition fields?  expecting:
	// std.vector<simpleFelineTestClass *>.iterator 
	// typedef std::iterator<simpleFelineTestClass *> iterator
	auto beginIterator = itemsSimplePtr.begin();
	// type dot after "beginIterator", expecting dot to be converted to ->
	// and listbox showing members of class "simpleFelineTestClass"
	beginIterator;

I have included the expected results in the comments, to make it easier for both of us to try and see what is happening here. Can you please try this on your main solution, and see what results you get? Something to do with "limits" would be "nice", since it would explain what is happening with auto, but why?

zen is the art of being at one with the two'ness
Go to Top of Page

Mordachai
Tomato Guru

USA
224 Posts

Posted - May 24 2018 :  4:42:41 PM  Show Profile  Reply with Quote
beginIter is:
sanityCheckPointerHandling.beginIter
std::vector<simpleFelineTestClass *>::iterator beginIter = itemsSimplePtr.begin()

But when I type . although it DOES expand to -> I get no suggestions, and the context / definition are:
std.iterator<_Ty>.->
_Ty* operator->()

Go to Top of Page
Page: of 2 Previous Topic Topic Next Topic  
Next Page
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000