Каково различие между этими двумя способами бросить в Java?
IIRC, много компиляторов C++ предупредят при попытке бросить результат битовой операции как bool. Необходимо было бы использовать бросок типа для создания компилятора счастливым.
Используя битовую операцию в, если выражение обслуживало бы ту же критику, хотя, возможно, не компилятором. Любое ненулевое значение считают верным, таким образом, что-то как "если (7 & 3)" будет верно. Это поведение может быть приемлемым в Perl, но C/C++ является очень явными языками. Я думаю, что бровь Spock является должной осмотрительностью.:) Я добавил бы "== 0" или"! = 0 дюймов для создания его совершенно ясным, какова цель была.
, Но так или иначе, это походит на персональное предпочтение. Я выполнил бы код через линт или подобный инструмент и видел бы, думает ли это также, что это - неблагоразумная стратегия. Лично, это читает как ошибка кодирования.
5 ответов
Вы можете использовать только первую форму для статически связанных классов.
Во многих случаях этого недостаточно - например, вы могли получить экземпляр класса с помощью отражения или он был передан вашему методу как параметр; отсюда и вторая форма.
Потому что вы не можете просто написать (T) objectToCast , когда T является параметром универсального типа (из-за стирания типа). Компилятор Java позволит вам это сделать, но T будет там обрабатываться как Object , поэтому преобразование всегда будет успешным, даже если преобразованный объект на самом деле не является экземпляром. из Т .
Это первое обычное приведение. Это требует, чтобы тип, к которому выполняется приведение, был известен во время компиляции. Он проверяет во время компиляции, что приведение может быть правильным, и проверяет (если тип для преобразования не является универсальным), что приведение является правильным во время выполнения.
Второе использует API отражения. Это требует, чтобы класс, к которому выполняется приведение, был известен во время выполнения. Он ничего не проверяет во время компиляции, но всегда проверяет правильность преобразования во время выполнения.
Параметры типа известны только в типе компиляции, поэтому вы не можете использовать второй подход для параметра типа (выражение ] T.class не компилируется).
Динамически загружаемые классы (например, с Class.forName (String)) известны только во время выполнения, поэтому первый подход нельзя использовать.
Изменить: Однако, как указывает Павел, нет смысла использовать в динамически загружаемый класс. Я согласен с тем, что единственная реальная полезность Class.cast (Object) - это приведение к параметру типа, для которого у вас есть доступный объект класса.
Если тип для приведения к нему не содержит параметр типа, первый подход лучше, поскольку дополнительная проверка во время компиляции может выявить ошибки, вы не потеряете безопасность типов во время выполнения и получите более короткий синтаксис для загрузки.
В первом у вас есть для жесткого кодирования класса приведения.
( ClassToCast ) objectToCast;
Во втором классе приведения может быть параметр:
Class toCast = getClassToCast();
toCast.cast( objectToCast );
Здесь вы можете найти пример использования, в котором используется Class # cast () . Это может дать новые идеи.