| T O P I C R E V I E W |
| Mordachai |
Posted - May 10 2018 : 11:27:54 AM
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. |
| 30 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jun 07 2018 : 3:22:23 PM
Thank you both for the samples, and the very happy update! I will have a look at the code samples anyway, if we are lucky I will be able to reproduce this here, which might just allow us to pin down what is going wrong, and where.
This has been quite a trial, and getting dot to arrow working again reliably in your code is going to be a big relief and helper!  |
| Mordachai |
Posted - Jun 07 2018 : 10:56:38 AM
Update: I tried a few things yesterday to restore the problem - and like many situations such as this - my attempts failed. I'm plum out of desire to follow up for now.
Thank you for your continuing support. You guys/gals are great! |
| Mordachai |
Posted - Jun 06 2018 : 1:31:01 PM
EUREKA!
Okay - so after sending you that example - I went ahead and altered it to not use boost - plus I changed one other usage of boost - from our MFC Iterator.h which was using boost::iterator_facad
Having removed them both - I no longer have the dot to arrow failure. :D
Next would be to see which of those was the real culprit...
|
| feline |
Posted - Jun 06 2018 : 11:43:56 AM
Don't push to hard on this just because of VA, we don't actually know that this will help! It is a good working theory, but that's all it is at the moment, a theory, and when we get down to a bug in VA we can look for a short term work around, before the core bug is fixed. |
| Mordachai |
Posted - Jun 06 2018 : 10:44:25 AM
I sent you a fairly short and straight-forward example use case for boost::iterator_adaptor<> - and I'm trying to figure out how to implement a solution that doesn't use boost::iterator_adaptor with help at stackoverflow now.
!@#$!@#$! I hate many choices made by the STL and thence from the standards body that makes using inner types very close to impossible >:(
(enclosed classes and templates so rarely work in my actual production code - outside of cutesy examples that are quite useless)
see:
https://stackoverflow.com/questions/50723196/how-to-correctly-define-a-partial-specialization-for-a-member-struct-of-a-templa |
| feline |
Posted - Jun 05 2018 : 2:50:36 PM
The first few were easy to find good examples for, but iteratpr_adaptor and iterator_facade are quickly getting a lot more technical, and a lot less clear. If you have some use case example code that you are OK to share purely for testing purposes this would be very helpful.
Like you I have now moved over to boost 1.67, to try and make sure my situation closely mirrors yours, so no need to worry about different boost versions.
Please submit the code sample 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. |
| Mordachai |
Posted - Jun 05 2018 : 12:18:44 PM
Thanks Feline.
I have trimmed our use of boost as much as I can for now. However, those above uses are staying for the time being - just because each is non-trivial to replace (mostly that - a couple are just more elegant than I want to give up on! :D )
I've tested to see if what I've done has eliminated the issue with VA - and sadly it has not.
I was pretty thorough about looking for all uses of boost - and the above are all that are left - so it should be one of those cases! (I also removed ALL #include of boost from stdafx.h - though maybe it's still indirectly there - my library's .h which #include's a boost header? Yes, I think that's likely - but far fewer than before).
I can supply example use-cases for each as well, if you're not seeing a problem in your simplified example - which may or may not!
---
Just fyi - we just encountered a crazy issue with our dongle drivers and versions and - like you - this is one of those "works here" cases. *Sigh* |
| feline |
Posted - Jun 05 2018 : 11:09:34 AM
I am going to get a simple C++ test project up and running here, and make sure that it uses each of these classes, and does something with them. At least this will tell us if including the header files and using these iterators is actually a factor or not.
I have one other user reporting a similar problem to you, but VA is getting confused at a different point with a std::vector iterator. But other than this, no other reports that I am aware of, and Boost is widely used. |
| Mordachai |
Posted - Jun 04 2018 : 10:51:55 AM
I started to remove boost from our project - many of the things I used boost for have since been subsumed into std.
Sadly, this is a PITA in some places - and I noticed that I have a number of uses of boost's iterator extensions / utilities - which do not seem to have been integrated into std, such as:
boost::make_iterator_range // this is brilliant for making a sub-range into a for (auto e : ) type loop
boost::make_indirect_iterator // another super useful iterator adaptor
boost::adaptors::keys // doable other ways, but makes for more elegant code than for(auto & [key, value] : mymap)
boost::iterator_adaptor // very useful for adding iterator tags to user iterator type
boost::iterator_facade // same idea as iterator_adaptor - adds necessary tags and default interfaces to a custom iterator...
boost::partially_ordered // this and others like it simplify implementation of classes that adhere to such requirements...
There are I'm sure ways to achieve solutions for each of the above - but they're all so damn elegant an useful. It would be nice to be able to support these elegantly - or maybe I need to understand an equally more elegant alternative to each? |
| feline |
Posted - Jun 02 2018 : 09:56:24 AM
This is interesting. The good news is that I can reproduce this new Alt-Shift-G behaviour by opening the file "boost\detail\container_fwd.hpp" in the IDE, so if something somewhere is including this file, thus prompting VA to parse it, this explains what is happening here. Alternatively the file has been opened, so its in VA's symbol database, but is no longer included by your project. If so a VA symbol database rebuild will remove this reference.
Renaming the "container_fwd.hpp" file and recompiling should help you to track down where the include is coming from.
This does not stop dot being converted to -> though, but at least we have now found an actual difference. It is possible another "odd" include file is behind this problem, but tracking down that file is still the issue. |
| Mordachai |
Posted - Jun 01 2018 : 12:08:02 PM
Those dialogs appear to be identical (113 of 113) in both. Visual inspection shows first page of results to be the same.
What is different - in the simple project - that first ALT+SHIFT+G dialog - has Definition 'vector:675' and Declaration 'vector:2071'
But in my main project, Definition is also 'vector:675' BUT Declarations is plural & a fly-out - 'container_fwd.hpp:135' (boost\detail), and the same 'vector:2071'
I wonder why the hell 'container_fwd.hpp' is getting included into my project?
Something for me to explore at least... |
| feline |
Posted - May 31 2018 : 4:33:46 PM
That's probably not going to help then. Lots of results, but no immediately obvious way of narrowing down to just one or two classes that seem relevant.
Can you please open two instances of the IDE, and open your main solution in one instance and the small test solution where dot to -> is working correctly in the second instance.
If you now place the caret into "std::vector", specifically into "vector" and use Alt-Shift-G to show Goto Related, and now open the "Goto member..." option dialog, are you seeing the same members of the vector class in these two solutions?
In theory you should be, but somewhere something is different... |
| Mordachai |
Posted - May 31 2018 : 2:33:35 PM
quote:
Originally posted by feline
That's not the answer I was expecting. Shared_ptr not being shown in italics is a little odd, but I am not sure if this is actually related or not.
Let's try a different approach. Can you please open VA's Find Symbol dialog, and set:
Find Symbol dialog -> Show only symbols defined in current solution = True
Find Symbol dialog -> Only classes, structs & namespaces = False
and now search for .iterator.
so a dot before and after iterator, to tell VA to search for this full word only. Is anything listed?
124 of 68592...
Yes, tons. I would show them - but the uploader is too limited to even handle 1 page worth of them (filesize too big - and I can't copy names - the interface only allows 1 selection at a time)
|
| feline |
Posted - May 30 2018 : 04:22:04 AM
You mean that isn't an official tech support response? I can show you dot to arrow working here |
| Mordachai |
Posted - May 29 2018 : 3:06:05 PM
Heh - no doubt!
Or the infamous
Everyone: "It's broken!"
Developer: "It works fine on my machine!"
|
| feline |
Posted - May 29 2018 : 2:15:19 PM
Ouch! This is a nasty day.
Once you have the build server fixed, since that comes first, it might be worth getting the full compile command from the project settings on the different machines, to compare it. I am thinking about things like library paths being different, any flags that are picked up from the environment rather than from the project settings.
Sadly I am all to familiar with "its identical, but it works differently". Sometimes the smallest and strangest things matter. |
| Mordachai |
Posted - May 29 2018 : 1:49:27 PM
Today's a mess on my end. Our build server required a reboot for a windows update - and now is incapable of booting. >:(
That was the thing about the difference: Since we're talking about the same projects and solution files - absolutely identical (I rebuilt the entire vault solution tree fresh - so no local files could exist - and reinstalled Visual Studio 2017 - and uninstalled VA - so that I had absolutely no user settings nor cache files nor nothing whatsoever - yet it builds differently on my PC - go figure!!!) |
| feline |
Posted - May 29 2018 : 11:27:21 AM
The error / warning makes sense. Have you tracked down the setting difference at work here? |
| Mordachai |
Posted - May 29 2018 : 08:54:01 AM
That code in particular issues a warning "may result in loss of data" - going from a QWORD to a double - and our projects all have "treat warnings as errors" enabled. |
| feline |
Posted - May 29 2018 : 08:43:12 AM
It is tempting to call this noise, but at the same time... it is actually a "firm" difference in identical code between two machines. Does the compiler error give any useful clues as to why this is failing?
I wonder if something like library or SDK versions being different between the machines could be a factor. It's also the sort of odd effect that might be involved with what we are seeing here. |
| Mordachai |
Posted - May 29 2018 : 08:22:54 AM
I will do that shortly. But I have another oddity on this PC!
This has to be unrelated... but... I added a statement in some code that boils down to:
QWORD y; double x = y; On my PC, that compiles without warnings. With that same project / solution, it errors on that line on two other PCs (neither of those happen to run VA fwiw, though that cannot possibly have any relevance, right?!)
I uninstalled VS 2017 last week (after doing a clean - then completely renaming my source tree and pulling a new one down from vault server) - none of which worked any differently - in all cases my code compiled on my machine without warnings or errors.
I know that this is probably pure 'noise' - but what the hell - if you can see some rhyme or reason to any of it - there it is! |
| feline |
Posted - May 25 2018 : 6:07:36 PM
That's not the answer I was expecting. Shared_ptr not being shown in italics is a little odd, but I am not sure if this is actually related or not.
Let's try a different approach. Can you please open VA's Find Symbol dialog, and set:
Find Symbol dialog -> Show only symbols defined in current solution = True
Find Symbol dialog -> Only classes, structs & namespaces = False
and now search for .iterator.
so a dot before and after iterator, to tell VA to search for this full word only. Is anything listed? |
| Mordachai |
Posted - May 25 2018 : 1:43:51 PM
Same exact list on begin() - same exact line numbers as shown in your cap.
same jump to vector:693 - using iterator = typename _Mybase::iterator;
The italics are subtle enough in my font that I can barely see the difference (though it seems obvious in your cap).
I don't have locals bolded, but toggling those two features seems to work entirely as expected - with the same sorts of visuals you're showing - the same symbols italicized or bolded.
The one place we differ there is shared_ptr is not italicized for me - though alt-g takes me directly to <memory> at the correct definition, so ... okay? |
| feline |
Posted - May 25 2018 : 11:42:34 AM
Well, you are definitely getting different results to me!
Can you go up to the line:
auto beginIterator = itemsSimplePtr.begin();
and do alt-g on "begin" please? This is what I am getting:
accepting the top entry in the menu is taking me to the vector header. In this header "iterator" is shown in italics for me. This is because I have:
VA Options -> Fonts and Colors -> Stable symbols in Italic
turned On. Alt-g on "iterator" takes me directly to the line:
using iterator = typename _Mybase::iterator;
which is still the "vector" header file, now line 693.
I am assuming you are going to get a different result for alt-g on iterator. Hopefully what ever VA suggests will make some form of sense. |
| Mordachai |
Posted - May 25 2018 : 10:12:56 AM
Here's what I get for Alt+Shift+G for beginIter->
(again - ctrl+shift for the -> results in no response) |
| Mordachai |
Posted - May 25 2018 : 10:10:00 AM
I have those icons set to "show tomatoes"
Ctrl+Space does nothing in our problem cases (I use Ctrl+Space constantly in normal work to force it when I want it)
I'm confused though - mostly I see list boxes of members which have icons relating to VS intellisense (I think) with a set of controls at the bottom for filtering scope - but often with one extra seemingly random tooltip-ish looking thing that does have a tomato icon, as seen here:
(You can see the _Diff weirdness)
|
| feline |
Posted - May 25 2018 : 07:15:13 AM
We might be closing in on something here, if we are lucky.
First the lack of a listbox. Can you look and see if you have:
VA Options -> Floating Buttons and Icons -> Denote content from Visual Assist with tomato icons
turned On or Off. If this is turned Off, please turn it On.
Interestingly, when I type the dot and get a listbox, the listbox always has tomato icons for me, regardless of the setting I have for:
VA Options -> Enhanced Listboxes -> Source of C/C++ content: Visual Assist OR Default Intellisense
after the dot has been converted to ->, what happens if you press CTRL-SPACE? This should "force" a listbox to appear, but given the context and definition field information you are getting, I suspect this won't help. For reference, with the caret in the "->" I am getting the context and definition fields:
std.iterator<simpleFelineTestClass *>.->
simpleFelineTestClass ** operator->()
If you place the caret into "beginIterator" where we are testing dot to -> and then press Alt-Shift-G you should get a menu with 3 items. The middle item "Types of Symbol" should open a sub-menu.
For me the three items in the sub-menu are:
iterator - vector:693
> simpleFelineTestClass - test_general.cpp:40
> iterator - xutility:4347
obviously the file and line will be different for your copy of "simpleFelineTestClass", but what about the iterator? I am guessing a different file and line. |
| Mordachai |
Posted - May 24 2018 : 4:42:41 PM
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->()
|
| feline |
Posted - May 24 2018 : 3:23:56 PM
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? |
| Mordachai |
Posted - May 24 2018 : 10:44:51 AM
#include <limits> in my simple project does not alter the outcomes. |
