Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 auto keyword support (UE4)

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
Amimoller Posted - Dec 15 2020 : 3:27:52 PM
Hi,
We are using vs2019 and Unreal (4.25)

For as long as i can remember, using the auto keyword has messed up VA. Both auto completion and "convert . to ->"

Here is a common example of getting a component.



When you type . it does not get converted to ->

if you change the code to be "auto* health" convertion works as normal, but the listbox will not adhere to "List non-inherited entries first"

Both issues makes the use of auto problematic as it slows down your workflow.

Getting this fixed would be great :)
Cheers!
30   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Dec 13 2022 : 07:17:50 AM
It has been a while since I last read Scott Meyers, but I recall being really impressed by his books Thank you for explaining what is going on here. Once I knew it was compiling I could see what was happening, and in a way it is clearer than the round backet constructor call, but it was unexpected the first time I saw it.

Unfortunately our bug tracker isn't publicly visible, but this thread will be updated when this has been fixed, and you can always ask for updates. As more people run into a problem or limitation of our parser then it becomes more urgent to address it, so knowing how many people are encountering this will be useful.
Malcolm Posted - Dec 12 2022 : 4:17:01 PM
That line is indeed braced initialization of a sort. It's specifically list initialization (https://en.cppreference.com/w/cpp/language/list_initialization). The relevant part of the explanation states:
quote:
The effects of list-initialization of an object of type T are:
If T is an aggregate class and the braced-init-list has a single element of the same or derived type (possibly cv-qualified), the object is initialized from that element (by copy-initialization for copy-list-initialization, or by direct-initialization for direct-list-initialization).


As of C++11 you can initialize variables in this way, and it provides a more consistent initialization syntax, although you do have to be careful about initializer_lists. I found this article to be a good summary of the situation, https://blog.quasar.ai/2017/03/05/cpp-braced-initialization, and it mentions Item 7 in Scott Meyers' book "Effective Modern C++", which is worth reading if you have access to it. We do often use this syntax, for the reasons given in the book (summarised in the article), and I expect it has quite a widespread usage, given the notability of Scott Meyers' writing.

Thank you for referencing the case number (141519), is there somewhere I can look to see how that case is progressing?

FYI: As a test, I tried using direct initialization (auto Thing( GetThing<Thing1> );) and copy initialization (auto Thing = GetThing<Thing1>();) and Visual Assist evaluated everything correctly.
feline Posted - Dec 12 2022 : 1:21:30 PM
Apologies for these problems. I am seeing the same problem with your simple code, but I am not quite sure how to read the line:

auto Thing{ GetThing<Thing1>() };

this is brace initialization, but that is normally used for the components of a struct. But here there is only one component. It almost makes me think of a Tuple with a single item in it. This page on brace initialization seems fairly complete, but it doesn't seem to cover this case:

https://learn.microsoft.com/en-us/cpp/cpp/initializing-classes-and-structs-without-constructors-cpp?view=msvc-170

and to be honest I never thought of doing this with brace initialization.

VA doesn't understand what you are doing here, so it isn't working out the correct type for the auto variable, which I have confirmed without even using any templates. So UE and templates is actually a red herring in this particular situation. Do you often do this?

OK, testing this, with the simplified code sample:

struct StructToCreate { void DoStuff1() {} };
	
void func()
{
	StructToCreate localFoo1;
	// this code compiles in VS2013 and above, does not compile in VS2012
	auto CreateStructInstance{ localFoo1 };
	// BUG - VA shows no listbox when typing dot after "CreateStructInstance"
	// BUG - Goto Related cannot show members of this type
	CreateStructInstance;
	// this does NOT compile in VS2013, since in VS2013 auto type is std::initializer_list<StructToCreate>
	// this Does compile in VS2015 and above
	CreateStructInstance.DoStuff1();
}

it only compiles in recent enough versions of Visual Studio. That's what I get for trying to be thorough

We are working to make sure VA's support for brace initialization is solid, so I think this belongs as part of that case:

case=141519
Malcolm Posted - Dec 08 2022 : 05:38:12 AM
Hello! I also apologise for necro'ing this thread, but it seems to mirror my experiences, and I wanted to know if there was any update on the handling of auto, or if there's an issue tracker somewhere that I can have visibility on?

As previous posters have said, VA doesn't always work when I use the auto keyword. I'm working with Unreal 4, so there are lots of UE shenanigans around, but it happens even when I'm steering clear of UObjects. Below is some sample code that I threw into the very top of a random cpp file (in our code, not the engine). The indicated line is where the issue is experienced. No autocomplete list comes up, and, the definition field shows auto Thing so it hasn't been able to work out the type of Thing (although, it has the context correct as func.Thing).
struct Thing1 { void DoStuff1() {} };
struct Thing2 { void DoStuff2() {} };

template<typename T> T GetThing();
template<> Thing1 GetThing<Thing1>() { return Thing1{}; }
template<> Thing2 GetThing<Thing2>() { return Thing2{}; }

void func()
{
	auto Thing{ GetThing<Thing1>() };
	Thing. // <- No autocomplete list here
	GetThing<Thing1>(). // <- this works, autocomplete list shows DoStuff1
}
The template parameter T is slightly interesting; if I put the cursor on it, the Context field just shows T, and the definition field shows constexpr FORCEINLINE const T (&AsConst(T (&Array)[N]))[N] which is a definition within UE's UnrealTemplate.h, and Alt+G takes me to that definition, which is this:
/**
 * Returns a non-const reference type as const.
 * This overload is only required until the pointer overloads are removed.
 */
template <typename T, SIZE_T N>
constexpr FORCEINLINE const T (&AsConst(T (&Array)[N]))[N]
{
	return Array;
}
If I rename T to something definitely unique, it doesn't fix the autocomplete issue, but the Context field and definition field show TemplateParameter.TMyUniqueName234 and typename TMyUniqueName234 respectively. No idea if that's important, but it seemed potentially relevant.

Edit: I just thought to do this, and it was again interesting. I did a VA Find Symbol (Alt+Shift+S) for T and it came up with the above 'AsConst' definition. My unique template parameter name didn't appear in the symbol definitions list.

I look forward to hearing from you, thanks very much!
feline Posted - Feb 08 2022 : 06:37:51 AM
I have the file, many thanks for this:

case=147804

It will be treated confidentially, it is just likely to be a little while before I have anything to report. I hope to be able to discard quite a bit of the file fairly quickly, but since I don't know what might be triggering this bug, I need to do so a little carefully.
bpdburden Posted - Feb 07 2022 : 12:15:44 PM
quote:
Originally posted by feline

Thank you for checking. That seems to rule out a macro for T being a problem, but I am not sure what this leaves us with.

Can you please run Find References on T, and in the Find References Results check and see if any results are hidden. This is listed on the bar where the number of results is listed. If any results are hidden you can unhide them with the context menu filters. Also please check and make sure both:

Search all projects (P)
Show Projects

are turned On.

Would you be able to copy the full results and email me the results as a text file? This will contain details of your code, so I don't know if this will be a concern or not, but I am only interested in looking at the results to see if there is anything that offers a clue about what is going wrong here. If I find anything odd or strange I can try to set up versions of it here.

Assuming you can do so, the problem with this approach is that it doesn't include results from your include directories, only your solution, but hopefully it will still help.

If you are able to send me the results, please send me the files via email:

[email protected]

including this thread ID or URL in the description, so we can match it up.



Okay, yes I can send you that. But, fair warning, it's about 10,000 lines.
feline Posted - Feb 07 2022 : 06:12:59 AM
Thank you for checking. That seems to rule out a macro for T being a problem, but I am not sure what this leaves us with.

Can you please run Find References on T, and in the Find References Results check and see if any results are hidden. This is listed on the bar where the number of results is listed. If any results are hidden you can unhide them with the context menu filters. Also please check and make sure both:

Search all projects (P)
Show Projects

are turned On.

Would you be able to copy the full results and email me the results as a text file? This will contain details of your code, so I don't know if this will be a concern or not, but I am only interested in looking at the results to see if there is anything that offers a clue about what is going wrong here. If I find anything odd or strange I can try to set up versions of it here.

Assuming you can do so, the problem with this approach is that it doesn't include results from your include directories, only your solution, but hopefully it will still help.

If you are able to send me the results, please send me the files via email:

[email protected]

including this thread ID or URL in the description, so we can match it up.
bpdburden Posted - Feb 04 2022 : 12:16:22 PM
quote:
Originally posted by feline

Thank you. The following Find in Files regular expression search is working well for me in VS2019:

^(?([^\r\n])\s)*#(?([^\r\n])\s)*define(?([^\r\n])\s)+T\b

and should catch any #define for T. I am running this with both Match Case and Use Regular Expressions turned On.

The "Look in" pull down dialog offers both "entire solution" and "all visual C++ directories"

If you have the time to leave this running, can you see if it finds anything?



That did not return any results with those settings on either "entire solution" or "all visual c++ directories." I tried all other options as well, and none of those returned anything either. I also tried disabling "match case" which also found nothing.
feline Posted - Feb 04 2022 : 11:28:56 AM
Thank you. The following Find in Files regular expression search is working well for me in VS2019:

^(?([^\r\n])\s)*#(?([^\r\n])\s)*define(?([^\r\n])\s)+T\b

and should catch any #define for T. I am running this with both Match Case and Use Regular Expressions turned On.

The "Look in" pull down dialog offers both "entire solution" and "all visual C++ directories"

If you have the time to leave this running, can you see if it finds anything?
bpdburden Posted - Feb 04 2022 : 10:12:38 AM
quote:
Originally posted by feline

In my main test solution here, where the sample code works just fine, doing the Find Symbol search for .T. returns 2,033 results. This is with the same search settings. Most of these results are from the Boost library rather than my solution, but still, it shows that having lots of results for T isn't by its self enough to trigger this bug.

Which version of the IDE are you using? I have put together a regular expression find to look for a macro for T, which works in VS2022, but isn't working in VS2019. So I will just work out a version of the regex that works for your IDE. Maybe an IDE find in files will turn up some clues.



We're using VS2019 16.11.5
feline Posted - Feb 04 2022 : 08:10:28 AM
In my main test solution here, where the sample code works just fine, doing the Find Symbol search for .T. returns 2,033 results. This is with the same search settings. Most of these results are from the Boost library rather than my solution, but still, it shows that having lots of results for T isn't by its self enough to trigger this bug.

Which version of the IDE are you using? I have put together a regular expression find to look for a macro for T, which works in VS2022, but isn't working in VS2019. So I will just work out a version of the regex that works for your IDE. Maybe an IDE find in files will turn up some clues.
bpdburden Posted - Feb 03 2022 : 11:26:47 AM
quote:
Originally posted by feline

I really didn't expect VA to have a problem due to T in the template class. I am not sure what to make of that to be honest.

First, the "easy" test, what do you get in the Find Symbol dialog for the search string:

.T.

to try and make this a bit more focussed, can you please right click in the list of symbols and make sure that you have:

Find Symbol dialog -> Right click menu -> Match case of search strings that contain uppercase letters = ON

just in case there are a load of lower case "t" symbols floating around as well.

To be honest I am not sure what we are looking for here, but macros called T would be my first concern.

You may need to turn Off both:

Find Symbol dialog -> Show only symbols defined in current solution
Find Symbol dialog -> Only classes, structs & namespaces

since we don't want to make any assumptions about where this problem is coming from, or the nature of the symbol behind it. Assuming it is going to show up in the Find Symbol dialog.

Another approach is to select T in the template class and try Alt-Shift-G and see what you get. If the "Goto Member..." dialog actually lists members then that may take us directly to what is confusing VA.

If this doesn't produce any useful clues, how many projects does your solution contain? If there is more than one, I am wondering if you would have the time to load individual projects, to see if we can pin down which project is triggering the problem. This assumes that the problem is triggered by a single project, and not by a global header included in several projects.



Our solution has 31 projects, but that does not include any external libraries. Doing that search returns hundreds of results, and goto member also returns a bunch of results. All template argument variables named T; all from various areas of the code, various projects, including external libraries.

It's definitely seeming like template argument variables are globally scoped from VA's point of view.
feline Posted - Feb 03 2022 : 05:50:05 AM
I really didn't expect VA to have a problem due to T in the template class. I am not sure what to make of that to be honest.

First, the "easy" test, what do you get in the Find Symbol dialog for the search string:

.T.

to try and make this a bit more focussed, can you please right click in the list of symbols and make sure that you have:

Find Symbol dialog -> Right click menu -> Match case of search strings that contain uppercase letters = ON

just in case there are a load of lower case "t" symbols floating around as well.

To be honest I am not sure what we are looking for here, but macros called T would be my first concern.

You may need to turn Off both:

Find Symbol dialog -> Show only symbols defined in current solution
Find Symbol dialog -> Only classes, structs & namespaces

since we don't want to make any assumptions about where this problem is coming from, or the nature of the symbol behind it. Assuming it is going to show up in the Find Symbol dialog.

Another approach is to select T in the template class and try Alt-Shift-G and see what you get. If the "Goto Member..." dialog actually lists members then that may take us directly to what is confusing VA.

If this doesn't produce any useful clues, how many projects does your solution contain? If there is more than one, I am wondering if you would have the time to load individual projects, to see if we can pin down which project is triggering the problem. This assumes that the problem is triggered by a single project, and not by a global header included in several projects.
bpdburden Posted - Feb 02 2022 : 1:53:57 PM
quote:
Originally posted by feline

The timing problem makes sense, since VA's parser takes time to look up all of the symbols in the code, to put it properly into "context" of your solution. This very strongly suggests that something in this block of code that I haven't renamed is the problem.

But this only really leaves us with "T", "test" and keywords.

OK, lets do the fast "fun" test. Can you please open VA's Find Symbol dialog and search for the following strings:

.auto.
.template.
.class.
.void.


dot means start or end of word, so these are whole word only matches. I am guessing one or more of these is going to match something in your main solution, ".auto." seems the most likely, since it is auto variables we are seeing the problem with.

The other test is to rename T to something quite random, in case that makes a difference. Can you please try this?



The only one of those that returns any results is .void. and it shows things where the void keyword is included in either a template definition or a templated instance.

Also, if I rename T to something wild like SDFJKHDSFKJH then it works 100% of the time again. I definitely know that T is a very common template type variable name in our codebase, and there are numerous other template type variable names that we reuse in various places. Is VA possibly having trouble with the scoping of these template type variables?
feline Posted - Feb 02 2022 : 1:40:51 PM
The timing problem makes sense, since VA's parser takes time to look up all of the symbols in the code, to put it properly into "context" of your solution. This very strongly suggests that something in this block of code that I haven't renamed is the problem.

But this only really leaves us with "T", "test" and keywords.

OK, lets do the fast "fun" test. Can you please open VA's Find Symbol dialog and search for the following strings:

.auto.
.template.
.class.
.void.


dot means start or end of word, so these are whole word only matches. I am guessing one or more of these is going to match something in your main solution, ".auto." seems the most likely, since it is auto variables we are seeing the problem with.

The other test is to rename T to something quite random, in case that makes a difference. Can you please try this?
bpdburden Posted - Feb 02 2022 : 12:23:09 PM
quote:
Originally posted by feline

Thank you, that actually makes more sense of this. It doesn't help much with the random element, but it does tell us that something in your main solution is a factor. My first theory, since you can see this in an empty file, is another symbol with the same name, quite possibly a macro, since I have seen odd effects when macros have overlapping names.

So, I have renamed the sample code, hopefully no chance of name clashes with this version:

class FelineVisualAssistAutoContentClass
{
  public:
	void FuncInsideFelineVisualAssist() { }
};

template <class T> T* FelineVisualAssistTemplateAutoItem()
{
	return new T();
}

void test()
{
	auto* felineTestVAVar = FelineVisualAssistTemplateAutoItem<FelineVisualAssistAutoContentClass>();
	felineTestVAVar;
}

do you still see the problem with this renamed version? If this "fixes" the problem it doesn't prove its duplicate symbol names, but it does suggest that's something to check.



We have the same problem with the renamed version in an empty file in our solution.
Another thing I just noticed is that if I paste the variable name, the box at the top correctly detects the type, but then quickly goes blank. Almost like there's a timing element to the randomness.

Edit: To add to that last bit, for the brief time while the box at the top is correctly detecting the type, VA works properly. So, if you paste the variable name and then quickly type "." it pretty much always works, but if you wait a few seconds after pasting, it almost never works. It seems like something timing related is coming in and stomping the proper parsing results.
feline Posted - Feb 02 2022 : 12:05:33 PM
Thank you, that actually makes more sense of this. It doesn't help much with the random element, but it does tell us that something in your main solution is a factor. My first theory, since you can see this in an empty file, is another symbol with the same name, quite possibly a macro, since I have seen odd effects when macros have overlapping names.

So, I have renamed the sample code, hopefully no chance of name clashes with this version:

class FelineVisualAssistAutoContentClass
{
  public:
	void FuncInsideFelineVisualAssist() { }
};

template <class T> T* FelineVisualAssistTemplateAutoItem()
{
	return new T();
}

void test()
{
	auto* felineTestVAVar = FelineVisualAssistTemplateAutoItem<FelineVisualAssistAutoContentClass>();
	felineTestVAVar;
}

do you still see the problem with this renamed version? If this "fixes" the problem it doesn't prove its duplicate symbol names, but it does suggest that's something to check.
bpdburden Posted - Feb 02 2022 : 11:46:54 AM
quote:
Originally posted by feline

This sort of makes sense, in that it suggests VA's parser is getting quite confused about the auto variable. But the random element is quite puzzling, and really unhelpful.

Do you have time to make a simple default C++ console solution, and see if you get the same problem there with a couple of simple template classes? So far I have not seen the problem here, so I am trying to work out if the problem seems to be solution specific or not. I am guessing at the moment that it is solution specific, but that's just a guess.



Using the sample code above in a brand new solution seems to have VA work properly 100% of the time, or at least, I couldn't get it to break like in our solution.
feline Posted - Feb 02 2022 : 06:48:32 AM
This sort of makes sense, in that it suggests VA's parser is getting quite confused about the auto variable. But the random element is quite puzzling, and really unhelpful.

Do you have time to make a simple default C++ console solution, and see if you get the same problem there with a couple of simple template classes? So far I have not seen the problem here, so I am trying to work out if the problem seems to be solution specific or not. I am guessing at the moment that it is solution specific, but that's just a guess.
bpdburden Posted - Feb 01 2022 : 11:45:47 AM
quote:
Originally posted by feline

Does this sometimes work and sometimes fail in the same file and location, or does it work in some files / places and fail in other files / places? Hopefully it is location dependent, and not just "random".

If it fails some places, can you try placing the test at the very top of the file and see if this makes any difference? I am wondering if something, quite possibly from a header file, is confusing our parser. If so, then placing the test at the top of the file, before the confusing code, should "fix" it. If so then this is a useful clue.



It's the same random behavior even in an empty file with no includes.
One other thing I noticed is that when it's not working, it also doesn't auto-complete the variable name itself (it does auto-complete when it is working). Almost like it doesn't even see that the variable exists at all, not just that it can't deduce the type.
feline Posted - Feb 01 2022 : 11:38:18 AM
Does this sometimes work and sometimes fail in the same file and location, or does it work in some files / places and fail in other files / places? Hopefully it is location dependent, and not just "random".

If it fails some places, can you try placing the test at the very top of the file and see if this makes any difference? I am wondering if something, quite possibly from a header file, is confusing our parser. If so, then placing the test at the top of the file, before the confusing code, should "fix" it. If so then this is a useful clue.
bpdburden Posted - Jan 31 2022 : 2:04:52 PM
quote:
Originally posted by feline

OK, that's not something that I would expect VA to have problems with, and so far no obvious signs of problems here.

First, can you see what you have the two settings:

VA Options -> Editor -> Convert dot to -> in C/C++
Convert dot to -> if operator -> is overloaded

set to? Does turning this On make any difference? The setting is designed to help with smart pointer templates, so may help here.

Beyond that, when you see the problem, can you please place the caret into the variable and see what VA shows in its context and definition fields, these are normally at the top of the editor window and are where the Alt-M list is shown from. This will tell you what VA thinks is the variable type. If they are blank then VA is having problems working out what is going on, which would certainly explain the problem you are seeing. Or VA might have worked out the wrong type, which would also explain the problem.

Either way it hopefully gives us somewhere to start.



Both of those options are on.

For that sample code that I posted, when VA is working properly, the field above shows:
TestClass * testVar = TestTemplate<TestClass>()

and when it's not working, the field is either blank,
or
auto * testVar = TestTemplate<TestClass>()
or
template<class T> T * TestTemplate()
feline Posted - Jan 31 2022 : 1:09:58 PM
OK, that's not something that I would expect VA to have problems with, and so far no obvious signs of problems here.

First, can you see what you have the two settings:

VA Options -> Editor -> Convert dot to -> in C/C++
Convert dot to -> if operator -> is overloaded

set to? Does turning this On make any difference? The setting is designed to help with smart pointer templates, so may help here.

Beyond that, when you see the problem, can you please place the caret into the variable and see what VA shows in its context and definition fields, these are normally at the top of the editor window and are where the Alt-M list is shown from. This will tell you what VA thinks is the variable type. If they are blank then VA is having problems working out what is going on, which would certainly explain the problem you are seeing. Or VA might have worked out the wrong type, which would also explain the problem.

Either way it hopefully gives us somewhere to start.
bpdburden Posted - Jan 31 2022 : 12:35:27 PM
quote:
Originally posted by feline

Would you be able to post, or send me, a code sample that shows this problem? For the Unreal Engine case, if I set up a simple test template function that seems to do the same thing, with a different name, then it works correctly. This doesn't much help with the Unreal Engine problem, but it does indicate that there is something odd going on in this case.

If I can reproduce the problem you are seeing, I might be able to do something to help.

Please send me the files via email:

[email protected]

including this thread ID or URL in the description, so we can match it up.



Just the most basic template code will cause it (in a brand new empty file, no includes):


class TestClass
{
public:
	void TestFunction() {}
};

template<class T>
T * TestTemplate()
{
	return new TestClass();
}

void test()
{
	auto * testVar = TestTemplate<TestClass>();
	testVar. // <-- point of failure
}


When writing this sample, I did notice that it seems to be extremely inconsistent. Sometimes it fails to autocomplete to "->" and/or bring up the function list, sometimes it works as expected. It can be as simple as literally just retyping "testVar." or even just typing it on a different line, or sometimes retyping the testVar variable definition. If you'd like, I can send you a video of the behavior and the various things I can poke to fix/break it.

In our actual codebase, it always fails (or at least I've never seen it work), but I suspect this is because our code is significantly more involved than this contrived example, so there's many more points of failure.
feline Posted - Jan 31 2022 : 11:10:26 AM
Would you be able to post, or send me, a code sample that shows this problem? For the Unreal Engine case, if I set up a simple test template function that seems to do the same thing, with a different name, then it works correctly. This doesn't much help with the Unreal Engine problem, but it does indicate that there is something odd going on in this case.

If I can reproduce the problem you are seeing, I might be able to do something to help.

Please send me the files via email:

[email protected]

including this thread ID or URL in the description, so we can match it up.
bpdburden Posted - Jan 28 2022 : 11:25:22 AM
quote:
Originally posted by feline

Unfortunately no progress yet. I will have another look at this, to see if some sort of work around helps.

From the bug report its not at all clear what is causing the problem, since the problem only shows up some of the time, so its not even all uses of Cast<> with auto. Very confusing.



I know this post was originally about Unreal, but it's worth mentioning that we don't use Unreal. We see it in just ordinary templated C++ functions. It's also 100% of the time for us.
feline Posted - Jan 28 2022 : 06:39:34 AM
Unfortunately no progress yet. I will have another look at this, to see if some sort of work around helps.

From the bug report its not at all clear what is causing the problem, since the problem only shows up some of the time, so its not even all uses of Cast<> with auto. Very confusing.
bpdburden Posted - Jan 27 2022 : 12:20:23 PM
quote:
Originally posted by feline

In general VA's auto handing should work well, but VA can struggle with template code, since templates are instanciated at compile time, and VA does not get to compile the code. Currently auto does not correctly work out the return type from template functions, which is an open bug report. It's possible the same bug is showing up here.

casting should work correctly, but "Cast" is an unreal engine specific function, and is thus different to "normal" casts.

One place auto does work well in my experience is STL style iterators, which tend to have very long types to write out manually. But I don't know how much of this you will be doing in Unreal Engine.

If you place the caret into "Cast" what are you seeing in VA's context and definition fields? For the simple test code:

ACharacter *simpleCharacter;
APawn* pBaseClass = simpleCharacter;
auto characterCast = Cast<ACharacter>(pBaseClass);

I am seeing:

context field = ACharacter
definition field = class ENGINE_API ACharacter : public APawn{...}

which is not right.



Sorry to necro this thread, but has there been any updates on the issue of using auto with templated return types? Is there a case number for that bug that we can reference in the future? One of my few usages for auto is when using a templated return type. It's a real bummer that I tend to need to avoid doing this, because VA doesn't work properly with that variable.
feline Posted - Dec 18 2020 : 2:47:03 PM
There is something inside Unreal Engine that is confusing our parser with Cast, but so far I cannot find any clues as to what it is. I have put a bug report in for this:

case=144225

if you set up a simple test for the Cast function outside of Unreal Engine then VA handles it correctly, and dot is converted to -> when using it with auto.
Amimoller Posted - Dec 18 2020 : 03:49:06 AM
You are right, it does seem to work pretty well on non-template code. I guess the problem is that most of the places we want to use it in Unreal is templated functions. Mostly Cast and FindComponent and its variations.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000