Предотвращение dynamic_cast/RTTI
Попробуйте использовать атрибут complete или success (только один)
$(document).ready(function() {
$.ajax({
url: "assetData.php",
dataType: "json"
success/complete: (function (jsonData) {
document.getElementById("test").innerHTML = jsonData;
}
});
6 ответов
1. Загрязняет пространство имен класса и vtable для объектов, которым не нужно оно. Хорошо, когда у Вас есть горстка методов, которые будут обычно реализовываться, но плоскость, ужасная когда только необходимый для единственного производного класса.
2. Справедливо dynamic_cast<> в платье в горошек и помаде. Не заставляет клиент кодировать немного более простой, и запутывает всю иерархию, требуя, чтобы основа и каждый производный класс полузнали о любом производном классе.
Просто используйте dynamic_cast<>. Это - то, для чего это там.
Если Вы хотите стать умными, Вы могли бы также создать двойной шаблон отправки, который является двумя третями шаблона "посетитель".
- Заложите основу
TokenVisitorкласс, содержащий пустой виртуальныйvisit(SpecificToken*)методы. - Добавьте виртуальный сингл
accept(TokenVisitor*)метод к Маркеру, который называет правильно введенный метод на переданном TokenVisitor. - Произойдите из TokenVisitor для различных вещей, которые необходимо будет сделать переменными способами по всем маркерам.
Для полного шаблона "посетитель", полезного для древовидных структур, имеют значение по умолчанию accept методы выполняют итерации по детям, звонящим token->accept(this); на каждом.
Если Вы знаете, что преобразование не может быть недопустимым, затем просто используют static_cast.
Истинный очевидный способ для предотвращения dynamic_cast должен иметь указатели правильного типа в правильном месте. Абстракция должна заботиться об остальных.
По моему скромному мнению, причина, что dynamic_cast имеет эту репутацию, состоит в том, потому что ее производительность ухудшается немного каждого раза, когда Вы добавляете другой подтип вниз в Вашей иерархии классов. Если у Вас есть 4-5 классов в иерархии, это - ничто для волнения о.
Почему Вы хотите избегать использования dynamic_cast? Это вызывает недопустимое горлышко бутылки на Вашем приложении? Если не не могло бы стоить делать что-нибудь к коду прямо сейчас.
Если Вы соглашаетесь с торговлей некоторой суммой безопасности некоторое время скорости в Вашей конкретной ситуации, необходимо быть прекрасным выполнением a static_cast; однако, это цементирует Ваше предположение, что Вы знаете тип объекта и нет никакого шанса броска, являющегося плохим. Если Ваше предположение становится неправильно позже, Вы могли бы закончить с некоторыми таинственными ошибками катастрофического отказа в своем коде. При возвращении к моему исходному вопросу Вы действительно уверены, что компромисс стоит того здесь?
Что касается опций Вы перечислили: первое действительно не походит на решение так же как последний взлом, который я ожидал бы видеть добавленный, когда кто-то был написанием кода в 3:00. Функциональность, сочащаяся ее путь к основе иерархии классов, является одним из наиболее распространенных антишаблонов, пораженных людьми, плохо знакомыми с ООП. Не делайте этого.
Для второй опции Вы перечислили любую опцию как этот, действительно просто повторно реализуют dynamic_cast - если Вы находитесь на платформе только с загаженными доступными компиляторами (я услышал, истории о компиляторе Gamecube, поднимающем четверть доступной RAM системы с информацией о RTTI) этот, мог бы стоящий, но более, чем вероятный Вы просто тратите впустую свое время. Вы действительно уверены, что это - что-то стоящее, касающееся сами о?
Забавный материал. dynamic_cast в токенизаторе подразумевает, что Вы хотите на самом деле разделить Маркер на что-то, что создает Маркер на основе текущей позиции в текстовом потоке и логики в Маркере. Каждый маркер или будет автономным или иметь для создания Маркера точно так же, как выше к тексту процесса правильно.
Тем путем Вы вытаскиваете универсальный материал и все еще можете проанализировать на основе иерархии маркеров. Можно даже сделать этот целый синтаксический анализатор управляемым данными без использования dynamic_cast.