Is Nameof() Evaluated at Compile-Time

Is nameof() evaluated at compile-time?

Yes. nameof() is evaluated at compile-time. Looking at the latest version of the specs:

The nameof expression is a constant. In all cases, nameof(...) is evaluated at compile-time to produce a string. Its argument is not evaluated at runtime, and is considered unreachable code (however it does not emit an "unreachable code" warning).

From nameof operator - v5

You can see that with this TryRoslyn example where this:

public class Foo
{
public void Bar()
{
Console.WriteLine(nameof(Foo));
}
}

Is compiled and decompiled into this:

public class Foo
{
public void Bar()
{
Console.WriteLine("Foo");
}
}

Its run-time equivalent is:

public class Foo
{
public void Bar()
{
Console.WriteLine(typeof(Foo).Name);
}
}

As was mentioned in the comments, that means that when you use nameof on type parameters in a generic type, don't expect to get the name of the actual dynamic type used as a type parameter instead of just the type parameter's name. So this:

public class Foo
{
public void Bar<T>()
{
Console.WriteLine(nameof(T));
}
}

Will become this:

public class Foo
{
public void Bar<T>()
{
Console.WriteLine("T");
}
}

Does the C# 6 nameof get optimized out during build?

Yes. nameof is a language feature, not a CLR feature. It compiles down to a string constant.

Expression vs nameof

Why use expressions to do something you can do on compile time? nameof(Url) is determined on compile time. It costs 0 ms. to evaluate that afterwards. Building an expression is costly and pointless when you can use nameof.

So the bottom line is: don't use expressions unless you really have to (you are already working inside an expression and you have to go from there). Otherwise use nameof.

nameof() operator for static string

nameof is an operator that is evaluated at compile time, so once your application is compiled there is actually no difference between those two solutions.

However, using nameof in this case has a few benefits:

  • It makes the string value less “magic”. So instead of being some disconnected magic string, the semantic reasoning behind that value is very clear: It’s the name of the variable itself.
  • The name is an actual reference to the name, so they are both connected. This allows you to refactor either of them and automatically affect the other one. It also makes that “string” appear as a reference when looking up references to that variable. So you know exactly where it has been used.

Why is this function evaluated at compile time in g++ but not in clang++

The point is that get_name() is a constexpr function and you have written

 std::string_view s = get_name<std::string>(); 

and not

 constexpr std::string_view s = get_name<std::string>(); 

In the second case (initialization of a constexpr variable) the compiler must (almost: ignoring the as-if rule) initialize the s variable compile-time.

In your case, the execution doesn't depend from run-time known values so the compilers are authorized to choose the compile-time or the run-time execution.

One of they choose to execute compile-time, the other one choose to execute run-time.

Both behaviors are legal.

Is sizeof in C++ evaluated at compilation time or run time?

sizeof is a compile time operator.

Why is this self-referential code using nameof() valid?

The nameof expression is resolved during the compilation of your program. The compiler knows the name of the property TestProperty and will substitute nameof(TestProperty) with "TestProperty".

nameof(TestProperty) has a dependency on TestProperty, but TestProperty does not have a dependency on nameof(TestProperty). Because of this, there is no circular dependency and the compiler can determine the value with no issues

nameof won´t reflect using

It's because the nameof keyword is meant to "get the name of an identifier", without evaluating its value or anything else, like said in docs:

A nameof expression is evaluated at compile time and has no effect at run time.

More info here



Related Topics



Leave a reply



Submit