Компилятор c # умнее компилятора VB.NET? - PullRequest
Новая
       31

Компилятор c # умнее компилятора VB.NET?

11 голосов
/ 09 февраля 2012

Если я посмотрю на IL, созданный в Linqpad для двух следующих фрагментов кода, мне будет интересно, что здесь происходит.

В c # 

int i = 42;

получается следующий код IL

IL_0000:  ret

, тогда как в VB 

Dim i As Integer = 42

это 

IL_0000:  ldc.i4.s    2A 
IL_0002:  stloc.0

По-видимому, компилятор c # понимает, что значение никогда не используется, и, следовательно, просто ничего не возвращает.В VB.NET реальный код переводится.

Это из-за различий в оптимизации компилятора или есть что-то еще в работе?

Обновление: Просто чтобы прояснить это- Я просто ввожу эту строку в LinqPad и смотрю на IL, который он создает (наиболее точно, запустив соответствующий компилятор).Там нет программы.

Ответы [ 2 ]

10 голосов
/ 09 февраля 2012

Убрав вопрос linqpad, я запустил vbc и csc с /optimize+ /debug- в этих программах: 

Module f

Public Sub Main()
    Dim i As Integer = 42
End Sub

End Module

и 

public static class f
{

public static void Main()
{
    int i = 42;
}

}

и получил эти результаты CIL от ILDASM:

Для VB: 

.method public static void  Main() cil managed
{
  .entrypoint
  .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) 
  // Code size       4 (0x4)
  .maxstack  1
  .locals init (int32 V_0)
  IL_0000:  ldc.i4.s   42
  IL_0002:  stloc.0
  IL_0003:  ret
} // end of method f::Main

Для C #: 

.method public hidebysig static void  Main() cil managed
{
  .entrypoint
  // Code size       1 (0x1)
  .maxstack  8
  IL_0000:  ret
} // end of method f::Main

Итак, да , по крайней мере, в этом отношении csc «умнее», чем vbc. Но я уверен, что JITter устранит любую разницу во время выполнения.

редактировать

Я проверил, и фактически исполняемый собственный код отличается, по крайней мере, в моей системе. Я вставил Console.ReadLine() вызовов в оба, чтобы дать мне возможность подключить отладчик, и я получил эти разборки:

Из VB: 

00000000  sub         rsp,38h 
00000004  mov         dword ptr [rsp+20h],0 
0000000c  mov         rax,7FF000434D8h 
00000016  mov         eax,dword ptr [rax] 
00000018  test        eax,eax 
0000001a  je          0000000000000021 
0000001c  call        FFFFFFFFE45BA230 
00000021  mov         dword ptr [rsp+20h],2Ah 
00000029  call        FFFFFFFFE26ABF20 
0000002e  mov         qword ptr [rsp+28h],rax 
00000033  nop 
00000034  jmp         0000000000000036 
00000036  add         rsp,38h 
0000003a  ret

Из C #: 

00000000  sub         rsp,38h 
00000004  mov         rax,7FF000534D8h 
0000000e  mov         eax,dword ptr [rax] 
00000010  test        eax,eax 
00000012  je          0000000000000019 
00000014  call        FFFFFFFFE45AA230 
00000019  call        FFFFFFFFE391BF20 
0000001e  mov         qword ptr [rsp+20h],rax 
00000023  nop 
00000024  jmp         0000000000000026 
00000026  add         rsp,38h 
0000002a  ret

Теперь, моя ассемблер почти не существует, но даже я вижу, что 

mov         dword ptr [rsp+20h],2Ah

в from-VB относится к постоянному значению hex 2A, что составляет 42 десятичного знака. Итак, вы идете, он выполняет выполнение дополнительных инструкций в конце.

1 голос
/ 09 февраля 2012

Я думаю, что в случае C # компилятор выполняет часть выделения памяти и сохраняет значение int за один шаг, а в случае VB оператор DIM является первым шагом, который просто выделяет память, а затем значение сохраняется на втором шаге.DIM является универсальным и используется со всеми типами данных, поэтому во всех случаях это может быть что-то вроде дополнительного шага.Мысли

...