What are "native" and "literal" keywords

Question

I see many times using native and literals "keywords" in C# articles. What do they mean?

examples:

string.Empty article:

The Empty constant holds the empty string value. We need to call the String constructor so that the compiler doesn't mark this as a literal. Marking this as a literal would mean that it doesn't show up as a field which we can access from native.

C# vs Java Wikipedia article:

Simple/primitive types
Both languages support a number of built-in types which are copied and passed by value rather than by reference. Java calls these types primitive types, while they are called simple types in C#. The simple/primitive types typically have native support from the underlying processor architecture.

Answer 1

From the C# spec section 2.4.4:

A literal is a source code representation of a value.

So for example there are literals for strings and numbers:

string x = "hello";
int y = 10;

... but C# has no literal syntax for dates and times; you'd have to use:

DateTime dt = new DateTime(2011, 12, 11);

As for native support - there are different levels of "native" here, but as far as C# is concerned, I'd usually consider it type-specific support in whatever output format is used. So for example, there are IL instructions to deal with the binary floating point types (float, double) but when the C# compiler emits code dealing with decimal values, it has to call the operators declared in System.Decimal. I'd therefore consider that float and double have native support in IL, but decimal doesn't.

(It would be possible to write a C# compiler targeting a different platform which did have native support for decimal - or which didn't have native support for float and double, for example. Unlikely, but possible.)

Then when the IL is being run in an execution engine, that will be running on top of "real" native code - x86 for example - which can have specific support for certain types. That's another level of "native". For example, if someone came up with a new version of IL which included native support for decimal, that wouldn't mean that the CPUs themselves suddenly gained native support.

Answer 2

The quote from the string.Empty article looks like a classic case of code comments getting out of sync with their associated code. The comment says "we're calling the constructor rather than using a literal" but the code doesn't call the constructor: it uses the literal. The moral of the story: don't let your confusion make you think you've misunderstood, because the comment is confusing.

There is a lot of misinformation out there regarding string.Empty, since it is a bit of an odd case. The expression new string() == "" is generally expected to be false, since the new operator is generally expected to create a new instance. But it doesn't create a new instance, it returns the instance in the intern pool, which its the same as "", so the expression is true.

I suspect that the "native" in "access from native" refers to native code (the second meaning of "native" that Jon Skeet mentioned). But if I were you, I wouldn't spend too much time on that article. It's far too concerned with abstract theory that anyway seems incorrect.

If you want to know whether string.Empty is more or less efficient than "", compile two versions of the same function, and check the IL. If the IL differs, run some performance tests.