What is the general rule when using Text, String or Name?

Development Programming & Scripting UI
, , , ,
1

I know what each type does in principle, however, the variables tutorial skips any explanation of Name and Text variables in context of each. I have seen this but it is isn’t that contextual.

Is there some general rule-of-thumb that can be applied when determining whether to use a Text, Name or String variable?

Should I always start with Text (for localisation) unless some factor forces a cast to another type?
(e.g. a cast to a String where a Text variable is being compared or manipulated).

Could you give a simple example of where each variable type would be more appropriate than the others?

3 Likes
2

this is not an answer but an opinion. in my projects i use string for all of my variables unless it is used for variables i now is only going to be used for name (i.e. hitboxName). from there i just use my strings and cast to what i need them to be. sorry i couldnt give you an answer to your question but i hope this will at least get you by for the meantime :)!

3

Ok,

so (unless this is deemed technically incorrect by UE staff)
my crude rule-of thumb could be:

Use ‘Text’ variables where localised alpha-numeric display is required

Use ‘Name’ variables for alpha-numeric network sends/receives, or where a smaller memory footprint is desired

Use ‘String’ variables for all other alpha-numeric requirements, unless forced to cast, or if you know in advance that you will be using string manipulation functions

Thanks guys.

1 Like
4

#Data Type Size

Well I can tell you the following and you can answer your own question from there

FText is 40 bytes ~ (more than 2x size of FString, more than 4x the size of an FName)

FString is 16 bytes ~ (2x size of FName, 4x the size of a float/int32)

FName is 8 bytes ~ (smallest! Twice the size of a float/int32)

So whenever you dont need the extra bytes you can use FName, and you should only use FText for visible displayed text that actually matters to be different, region to region, thus requiring Localization.

Your internal naming scheme in code can be be FString or FName

Advantage of FString is all the handy functions in UnrealString.h

FString is the easiest type to manipulate, modify, search and replace, concatenate, etc etc.

Strings you save to hard disk or send over the network should be FName to minimize data storage / data transfer

Remember, with FName you are sending half the bytes across the network but you can still reconstruct into an FString on the other side!

Reconstruct an FName to FString like this:

YourFName.ToString()

convert FString to FName like this

FString Str = "Yay";
FName NewName = FName(*Str);

Enjoy!

Rama

16 Likes
5

Thanks Lauren, that does help.
I wasn’t aware of the FName case-insensitivity.

6

FNames are usually going to be an ID for something. They’re case-insensitive, which is probably the most important thing to remember about them.

  • Asset names
  • Material Parameters
  • Tagging Actors
  • Skeleton bone names

FText is generally what you want to use for anything that your users will see, even if you aren’t planning on localizing.

  • Any text you show on a HUD
  • When your player enters their name for a high score
  • Calendar dates & times

FStrings do allow you to manipulate the variable value, like with reversing the string or taking a substring.

  • Building a URL
  • Creating a save file name

Do those examples help to clear things up? :slight_smile:

2 Likes
7

I’ve got a question:
Why should I use FText/FString/FName instead of good old std::string.
Same thing for TArray and std::vector.

8

Allocators, mostly.

9

Sorry, Rama, but you’re really wrong on this one.

While the size of an FText, FString or FName may be those this is not how they are stored or replicated. It is the equivalent of saying a TArray variable is only 12 bytes when it has a million entries because its memory footprint is 12 bytes, so it’s only 12 bytes to store or replicate. I was told this is how you came to these numbers.

Now, I have no idea how much space it takes to replicate an FText (probably similar, but with some overheard,) but an FString will replicate the string length plus the string itself. So if it’s 2 characters long, you’ll get 3 bytes. If it’s a thousand characters long, it’ll be 1002 bytes (7-bit int encoding.) Double that if it’s 2-byte per character encoding. Or somewhere in between for unicode.

For FNames, they are sent over the network or serialized in 2 ways. Firstly, the few hard coded ones (see UnrealNames.inl) will be sent via a 7-bit int encoding (1-2 bytes.) The others are sent as plain text, exactly the same as FStrings.

1 Like
10

Bit late to the party, but don’t FNames replicate easier by having the ID pre-compiled on both ends? I.e. FName(“MyName”) will always have id 0, as an example, so replication will just say “FName(0)” or similar, and the other end will know that it means FName(“MyName”) without having to send across the plain text. This was just my guess, however - you obviously have looked at it more closely. I just want to double-check :slight_smile:

11

While Rama’s answer is mostly correct you should NOT use FName to save to disk nor send it across the network for communication.

To quote staff user: https://answers.unrealengine.com/users/1232/gmpreussner.html
from: FNames under the hood - Programming & Scripting - Epic Developer Community Forums

Note that you should not store FNames
on disk or serialize them over the
network. They are guaranteed to be
unique only within the local process
(not even on the same machine). When
persisting or serializing FName
fields, convert them from and to
FString instead.

2 Likes
12

FName

  • immutable
  • case-insensitive
  • useful for ids.

FText

  • immutable
  • case-sensitive
  • useful for writing static content that will be “localized” - e.g. translating a game to another language

FString

  • mutable
  • has standardish function library.
  • useful for dynamically manipulating text at runtime.
4 Likes