Где Java и строковые литералы.NET находятся?
Ошибка синтаксиса: ошибка синтаксиса, неожиданный T_XXX
Случается, когда в неожиданном месте есть T_XXX токен , несбалансированные (лишние) круглые скобки, использование короткого тега без его активации в php.ini и т. д.
Вопросы, относящиеся:
- Ссылка: Ошибки анализа / синтаксиса PHP;
- Ошибка синтаксиса: неожиданно '{'
- Ошибка синтаксиса: ошибка синтаксиса, неожиданный конец файла в моем PHP-коде
- Ошибка анализа: синтаксическая ошибка, неожиданный '& lt;' in-Fix?
- Ошибка анализа: синтаксическая ошибка, неожиданный '?'
Для получения дополнительной помощи см .:
- http://phpcodechecker.com/ - что дает более полезные объяснения ваших синтаксических проблем.
7 ответов
Строки в.NET являются ссылочными типами, таким образом, они всегда находятся на "куче" (даже когда они интернируются). Можно проверить это использование отладчика, такого как WinDbg.
, Если у Вас есть класс ниже
class SomeType {
public void Foo() {
string s = "hello world";
Console.WriteLine(s);
Console.WriteLine("press enter");
Console.ReadLine();
}
}
И Вы звоните Foo() на экземпляре, можно использовать WinDbg для осмотра "кучи".
ссылка будет, скорее всего, сохранена в регистре для небольшой программы, таким образом, самое легкое должно будет найти, что ссылка на определенную строку путем выполнения !dso. Это дает нам адрес нашей рассматриваемой строки:
0:000> !dso
OS Thread Id: 0x1660 (0)
ESP/REG Object Name
002bf0a4 025d4bf8 Microsoft.Win32.SafeHandles.SafeFileHandle
002bf0b4 025d4bf8 Microsoft.Win32.SafeHandles.SafeFileHandle
002bf0e8 025d4e5c System.Byte[]
002bf0ec 025d4c0c System.IO.__ConsoleStream
002bf110 025d4c3c System.IO.StreamReader
002bf114 025d4c3c System.IO.StreamReader
002bf12c 025d5180 System.IO.TextReader+SyncTextReader
002bf130 025d4c3c System.IO.StreamReader
002bf140 025d5180 System.IO.TextReader+SyncTextReader
002bf14c 025d5180 System.IO.TextReader+SyncTextReader
002bf15c 025d2d04 System.String hello world // THIS IS THE ONE
002bf224 025d2ccc System.Object[] (System.String[])
002bf3d0 025d2ccc System.Object[] (System.String[])
002bf3f8 025d2ccc System.Object[] (System.String[])
Теперь использование !gcgen для обнаружения, в котором находится поколение экземпляр:
0:000> !gcgen 025d2d04
Gen 0
Это находится в нуле поколения - т.е. это имеет просто быть выделенным. Кто базируется он?
0:000> !gcroot 025d2d04
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread 1660
ESP:2bf15c:Root:025d2d04(System.String)
Scan Thread 2 OSTHread 16b4
DOMAIN(000E4840):HANDLE(Pinned):6513f4:Root:035d2020(System.Object[])->
025d2d04(System.String)
ESP является стеком для нашего Foo() метод, но заметьте, что мы имеем object[] также. Это - таблица интерна. Давайте смотреть.
0:000> !dumparray 035d2020
Name: System.Object[]
MethodTable: 006984c4
EEClass: 00698444
Size: 528(0x210) bytes
Array: Rank 1, Number of elements 128, Type CLASS
Element Methodtable: 00696d3c
[0] 025d1360
[1] 025d137c
[2] 025d139c
[3] 025d13b0
[4] 025d13d0
[5] 025d1400
[6] 025d1424
...
[36] 025d2d04 // THIS IS OUR STRING
...
[126] null
[127] null
я сократил объемы производства несколько, но Вы получаете идею.
В заключении : строки находятся на "куче" - даже когда они интернируются. Интернированная таблица содержит ссылку на экземпляр на "куче". Т.е. интернированные строки не собраны во время GC, потому что интернированная таблица базируется их.
В Java (от Глоссарий Java):
В JVM Sun’s, интернированные Строки (который включает Строковые литералы) хранятся в специальном пуле RAM, названной генералом перманента, где JVM также загружает классы и хранилища исходно скомпилированный код. Однако преданные земле Строки ведут себя не по-другому, чем имел их сохраненный в обычной объектной "куче".
Поправьте меня, если я ошибаюсь, но не все объекты находятся в куче, как в Java, так и в .NET?
В .Net строковые литералы, когда они «интернированы», хранятся в специальной структуре данных, называемой «интерна». Это отдельно от кучи и стека. Однако не все строки интернированы ... Я уверен, что те, которые не сохранены, хранятся в куче.
Не знаю о Java
Я нашел это на сайте MSDN о ldstr инструкция IL :
ldstrинструкция продвигает ссылку на объект (тип O) к новому строковому объекту представление определенного строкового литерала, сохраненного в метаданных.ldstrинструкция выделяет необходимый объем памяти и выполняет любое преобразование формата, требуемое преобразовать строковый литерал из формы, привыкшей в файле к формату строки, требуемому во времени выполнения.Общеязыковая инфраструктура (CLI) гарантирует, что результат двух ldstr инструкций, относящихся к двум маркерам метаданных, которые имеют ту же последовательность символов, возвращает точно тот же строковый объект (процесс, известный как "строковое интернирование").
Это подразумевает, что строковые литералы на самом деле хранятся на "куче" в.NET (в отличие от Java, как указал mmyers).
В Java строки как все объекты находятся в "куче". Только локальные примитивные переменные (ints, символы и ссылки на объекты) находятся в стеке.
Interned String в Java расположены в отдельном пуле, называемом String Pool. Этот пул поддерживается классом String и находится в обычной куче (а не в пермском пуле, как упоминалось выше, который используется для хранения данных класса).
Как я понимаю, не все строки интернированы, но вызов myString.intern () возвращает строку, гарантированную из пула строк.
См. Также: http://www.javaranch.com/journal/200409/ScjpTipLine-StringsLiterally.html и javadoc http://java.sun.com/j2se/1.5. 0,0 / документы / API / Java / языки / String.html # стажер ()