Что состоит в том, чтобы объяснить простой способ, как Сборка "мусора" работает?
Вы получаете открытый текст после первого ?>, потому что это конечный тег php, а плагин Code Snippets не позволяет использовать несколько операторов php и просто вылетает и сбрасывает простой текст, а не выполняет код .
Вам нужно переписать всю функцию как одну инструкцию php и echo все кнопки html, вместе с переменными php, разделенными в html и .. Простой пример:
<?php
$var = "Hello World";
echo "<p>The value of the variable is : " . $var . "</p>";
?>
И, возможно, вам также понадобится использовать более стандартную конструкцию ACF get field:
$value = get_field( "text_field" );
Найдите в SE дополнительные примеры повторяя html в php.
5 ответов
Путем обхода указателей/ссылок сказал бы я. В принципе Вы просто смотрите, имеет ли объект все еще ссылки, указывающие на него (от других объектов, локальных переменных в настоящее время выполняемого кода...). Если это не имеет затем никакой ссылки на этот объект, может быть получен снова (на языках как Java, по крайней мере, где Вы не можете сделать обмана указателя), таким образом, обычно безопасно выбросить тот конкретный объект.
Другие используемые схемы (или все еще используемый) являются, например, подсчетом ссылок, где каждый объект имеет счетчик ссылок на него, которые должны быть увеличены каждый раз, когда кто-то получает ссылку на тот объект и постепенно уменьшился каждый раз, когда кто-то теряет ссылку на тот объект. COM в Windows прокладывает себе путь, если я помню правильно.
Java и использование.NET (среди других) сборка "мусора" поколений, где каждый объект, как первоначально предполагается, умирает очень быстро (гипотеза поколений). Это затем emplos некоторая оптимизация, чтобы сохранить циклы сборки "мусора" быстро и таким образом не разрушить программы, работающие слишком много. В Вас olde времена это не было редко, чтобы GC запер программу, в то время как это работало, иногда в течение нескольких секунд.
Кроме этого, обычно только работает GC, когда память является низкой, т.е. слишком много мертвых объектов накопились и должны быть исправлены. Вот почему большинство управляемых приложений, кажется, тратит впустую намного больше памяти по сравнению с неуправляемыми, даже при том, что во многих случаях большая часть той памяти может быть исправлена путем выполнения GC однажды.
Сборщик "мусора" будет всегда знать о каждом выделенном объекте, так как иначе он не может возможно обнаружить недостижимые объекты для удаления. Это все заботится о во время выделения памяти. Это имеет смысл, с тех пор если бы сборщик "мусора" не знает о каждом объекте, то было бы возможно сформировать осиротевшие наборы объектов, которые не могут быть достигнуты, даже сборщиком "мусора". В основном это было бы утечкой памяти. Таким образом, по крайней мере сборщик "мусора" должен знать о каждом выделенном объекте.
Это приводит к вопросу того, как сборщик "мусора" определяет, какие объекты имеют право на удаление. Существуют различные методы для этого, но два, что Вы услышите о много, "метка и развертка" и "подсчет ссылок" (они часто подходят в учебниках), и их стоит знать собирающийся понять основные идеи о сборке "мусора".
Mark и развертка включают сборщик "мусора", идущий через ссылки на объект (запускающийся в известном наборе неколлекционируемых объектов) и отмечающий каждый объект, которого это может достигнуть (установка флага на объекте, например). Когда это исчерпало все ссылки, затем набор объектов, которые НЕ отмечены, может быть удален во время фазы сигнала развертки.
Подсчет ссылок включает сборщик "мусора", сохраняющий счет для каждого объекта в память о том, сколько другие объекты отсылают к нему. Этот счетчик будет увеличен каждый раз, когда ссылка на объект устанавливается от другого объекта и постепенно уменьшается, когда ссылка удалена. Когда счетчик совершает нападки 0, на объект больше не ссылается ничто, и сборщик "мусора" знает, что может быть безопасно удален (это по существу стало недостижимым в этой точке - никакой объект "больше не знает об" этом объекте).
Коллектор должен знать о местоположении ссылок на объект в области глобальных переменных, а также в кадре активации каждой функции/метода/вызова процедуры, для каждого потока. Регистры процессора могут также содержать ссылки на объект. Некоторая информация должна быть предоставлена или компилятором, или виртуальной машиной.
Запустите с корневых объектов (т.е. те, которые на стеке в Вашем основном () - эквивалентны), затем просто следуют за каждым указателем/ссылкой и отмечают каждый объект как 'достижимый'. Продолжите, пока Вы не отметили каждый объект. Остающиеся объекты (которые не были отмечены) являются мусором.
Другой путь состоит в том, чтобы иметь подсчет ссылок, который является сборкой "мусора" также, за исключением того, что маркировка сделана в каждой записи указателя, и очистка является istantaneous (как только объект недостижим, это касательно количества, нуль, таким образом, это уничтожается). Обратите внимание что потребности касательно подсчета метка-и-фаза-сигнала-развертки (как вышеупомянутый) для решения циклов. (Т.е. объекты, которые цепляются друг за друга, но никто еще не заботится о),
Можно думать о под управлением программе (возможно, я должен быть характерен для Java), как являющийся многими Threads. Виртуальная машина может использовать корневой кадр каждого потока как a root. Это может затем спуститься с дерева достижимости всего, на что ссылаются от того корня (плюс все стековые фреймы под корнем).
Что-либо еще не достижимо