А у меня другой вопрос по java: стоит ли повсеместно использовать final для аргументов метода, которые не должны изменяться? В C++, например, рекомендуют использовать const, а в стандартной библилотеке java я этого не заметил.
> А у меня другой вопрос по java: стоит ли повсеместно использовать final для аргументов метода, которые не должны изменяться? В C++, например, рекомендуют использовать const, а в стандартной библилотеке java я этого не заметил.
В C++ имеет смысл объявлять аргумет как const T *arg или const T &arg. Но нет смысла писать const T arg: здесь const ничего не меняет. В яве такого обилия вариантов нет. Фактически там аргументы передаются как T &arg, но без возможности сделать arg=boo. Поэтому имеет смысл писать final SomeClass arg, но писать final int arg смысла нет.
>> стоит ли повсеместно использовать final для аргументов метода
> Если компилятор не требует, то имхо нафиг не нужно.
Компилятор много чего не требует... Зато, преодолев лень и дописав ненужное слово, можно получить аж два профита: защиту от своих же ошибок, когда зачем-то изменяешь объект, который не задумывалось изменять, и дополнительную возможность оптимизации: при вызове метода компилятор может рассчитывать, что объект-параметр не изменится (не уверен про яву, в плюсах это работает... ну и да, компилятор виноват, что не делает глобальную IPO, это хорошее оправдание лени).
Разобрался. В плюсах, для const-аргументов, которые являются объектами, нельзя вызывать non-const методы. А в java, действительно, только прямое присваивание запрещается.
И, для сравнения:
c++ std::vector: void push_back ( const T& x )
java.util.ArrayList: public boolean add(E e)
>> при вызове метода компилятор может рассчитывать, что объект-параметр не изменится
Единственное, на что может рассчитывать компилятор в этом случае, это то, что не будет param = new SomeClass(), но ни как ни то, что объект не изменит свое состояние. В чем тут профит оптимизации пока не понятно.
>А у меня другой вопрос по java: стоит ли повсеместно использовать final для аргументов метода, которые не должны изменяться?
Теоретически final - аргументы можно выгоднее заJIT'ить, но практически вряд ли. Хотя Джошуа Блох и говорил где-то что это хорошая подсказка для HotSpot-а сами сановцы в своем JDK используют final только там где без него не компилируется, то есть для доступа к локальным переменным охватывающей функции из анонимного класса.
> А в java, действительно, только прямое присваивание запрещается.
> В чем тут профит оптимизации пока не понятно.
Согласен, этот момент я проглядел. Если в яве final запрещает изменять переменную (aka ссылку на объект), а не сам объект, то ничего тут особо не наоптимизируешь.