VB.NET оптимизирует конкатенацию строковых литералов?
Расслабься, просто игнорируй. Все проекты, над которыми я работал, никогда не вызывали конфликтов без их импорта. Кроме того, потому что каждый «.import» уникален с ПК на ПК.
3 ответа
Да. Это Делает. Я только протестировал VS 2008, но я сильно подозреваю, что предыдущие версии сделали также.
VB.NET
Public Class Class1
Dim s As String = "test " + "this " + "function"
Public Function test() As String
Return s
End Function
End Class
I.L. - Замечают, что строка "тестирует эту функцию"
{
.maxstack 8
L_0000: ldarg.0
L_0001: call instance void [mscorlib]System.Object::.ctor()
L_0006: nop
L_0007: ldarg.0
L_0008: ldstr "test this function"
L_000d: stfld string ClassLibrary1.Class1::s
L_0012: nop
L_0013: ret
}
Компилятор оптимизирует конкатенацию строк в надлежащих случаях. Однако необходимо рассмотреть использование класса StringBuilder, если Вы не знаете, сколькими там могут быть конкатенации.
http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx
От вышеупомянутой статьи:
Выполнение операции конкатенации для объекта Строки или StringBuilder зависит от того, как часто выделение памяти происходит. Операция Конкатенации строк всегда выделяет память, тогда как операция конкатенации StringBuilder только выделяет память, если буфер объекта StringBuilder является слишком маленьким для размещения новых данных. Следовательно, Строковый класс предпочтителен для операции конкатенации, если постоянное число Строковых объектов связывается. В этом случае отдельные операции конкатенации могли бы даже быть объединены в единственную операцию компилятором. Объект StringBuilder предпочтителен для операции конкатенации, если произвольное число строк связывается; например, если цикл связывает случайное число строк ввода данных пользователем.
В то время как я ищу его, вот страница загрузки для спецификации.
Раздел 11.2 похож на него, был бы правильный бит - это - в основном эквивалент 7,18 в спецификации C# 3.0 - но это не содержит ту же гарантию. Я подозреваю, что компилятор все еще делает это, но я не вижу гарантии. У меня будет другой взгляд все же.
Раздел 11.2 действительно указывает, что "Константное выражение является выражением, значение которого может быть полностью оценено во время компиляции" (мой акцент), но я не вижу, что это на самом деле гарантирует, что полностью оценит его во время компиляции. Откровенно это было бы нечетно, чтобы сделать категорию выражения на основе этого условия, но не на самом деле использовать его.
Быстрый тест показывает, что текущий компилятор VB действительно делает конкатенацию во время компиляции, но действительно должна быть гарантия в спецификации, если это - намерение.
Раздел 7.3 становится немного ближе:
Когда операнды выражения являются всеми константами типа примитива, для компилятора возможно оценить выражение во время компиляции. Такое выражение известно как константное выражение.
Теперь Строка не является типом примитива с точки зрения CLR (Тип. IsPrimitive возвратил бы false), но это с точки зрения спецификации VB.
Это все еще не говорит, что оценит его хотя...