Здравствуйте, Igor Trofimov, Вы писали:

iT>Вот именно об этом я и говорил.. Что по идее это заслуга рантаймового механизма интернирования...

Этот механизм интернирования работает только для литералов. В твоем посте это не было обговорено.

L>Этот механизм интернирования работает только для литералов.

Вот мне почему-то казалось, что не только для литералов... Иначе чего в нем вообще особенного??? Какой компилятор не умеет копии литералов вместе слеплять???

Здравствуйте, Igor Trofimov, Вы писали:

iT>Вот мне почему-то казалось, что не только для литералов... Иначе чего в нем вообще особенного??? Какой компилятор не умеет копии литералов вместе слеплять???

Вот я и привел пример, который показывает что это не так.

N>>А как насчет
N>>if( str!= null && str.Length !=0 )
N>>{
N>>// do smth
N>>}

T>В условии задачи спрашивали про String.Empty Этот метод конечно быстрее всего.

Может и быстрее, конечно, в текущей версии. Слышал, как foreach для строк и простых массивов в простой for оптимизировали? Сравнение с пустыми кавычками, пожалуй, тоже могут на завтрашнем этапе подогнать.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Igor Trofimov, Вы писали:

iT>>Вот именно об этом я и говорил.. Что по идее это заслуга рантаймового механизма интернирования...

L>Этот механизм интернирования работает только для литералов. В твоем посте это не было обговорено.
И для строк полученных через String.Internal. Если бы в закрытом конструкторе для String.Empty это было бы сделано, то все пучком. Недоработачка.

Здравствуйте, mihailik, Вы писали:

N>>>А как насчет
N>>>if( str!= null && str.Length !=0 )
N>>>{
N>>>// do smth
N>>>}

T>>В условии задачи спрашивали про String.Empty Этот метод конечно быстрее всего.

M>Может и быстрее, конечно, в текущей версии. Слышал, как foreach для строк и простых массивов в простой for оптимизировали? Сравнение с пустыми кавычками, пожалуй, тоже могут на завтрашнем этапе подогнать.

Не слышал. Где читать?

S> И для строк полученных через String.Internal. Если бы в закрытом конструкторе для String.Empty это было бы сделано, то все пучком. Недоработачка.

Ага, а оно не сделано? Ну, тогда такое сравнение будет быстрее:

string s="";
if( s=="" )

а такое медленнее:

string s="";
if( s==String.Empty )

Здравствуйте, mihailik, Вы писали:

S>> И для строк полученных через String.Internal. Если бы в закрытом конструкторе для String.Empty это было бы сделано, то все пучком. Недоработачка.

M>Ага, а оно не сделано? Ну, тогда такое сравнение будет быстрее:

M>

M>string s="";
M>if( s=="" )
M>

M>а такое медленнее:

M>

M>string s="";
M>if( s==String.Empty )
M>

С какого перепугу?

Здравствуйте, mihailik, Вы писали:

S>> И для строк полученных через String.Internal. Если бы в закрытом конструкторе для String.Empty это было бы сделано, то все пучком. Недоработачка.

M>Ага, а оно не сделано? Ну, тогда такое сравнение будет быстрее:

M>

M>string s="";
M>if( s=="" )
M>

M>а такое медленнее:

M>

M>string s="";
M>if( s==String.Empty )
M>

Кстати конструктор

private static String()
{ string.Empty = "";
string.WhitespaceChars = new char {
 "ERROR" 
};
 
}

Но почему тогда не равны адреса или еще ХэшТаблицы нет????
Ну за константной строкой будет лезть в хэштаблицу и доставать оттуда ссылку.
При String.Empty адрес строки уже есть и сначала идет сравнение ссылок а затем содержания

M>>Ага, а оно не сделано? Ну, тогда такое сравнение будет быстрее:
M>>а такое медленнее:

T>С какого перепугу?

Ну, по идее, сравнение интернированых строк должно быть быстрее, так как это один будет и тот же объект (ссылка).

M>>Может и быстрее, конечно, в текущей версии. Слышал, как foreach для строк и простых массивов в простой for оптимизировали? Сравнение с пустыми кавычками, пожалуй, тоже могут на завтрашнем этапе подогнать.

T>Не слышал. Где читать?

По-моему, в описании Whats New для .NET Framework 1.1

А ещё есть в CodeProject две статьи, Strings Undocumented и ARRAYS Undocumented. Там это обговаривается, но, кажется, писались они до .NET 1.1

Здравствуйте, 4mbi3nt, Вы писали:

4>Я помню что когдато в книжке читал, что string переменные рекомендуется
4>проверять на String.Empty а не на "" или null как некоторые делают. А если string
4>имеет значение null, то по идеи String.Empty его тоже должен отлавливать.

4>Это глюк C#? ...или посоветуйте мне как надо по другому проверять значения

Вы так еще договоритесь, что new byte[0] == null