Hi,
2012/9/10 Luc Maisonobe <luc.maison...@free.fr>:
> Le 10/09/2012 21:08, Sébastien Brisard a écrit :
>> Hi,
>
> Hi Sébastien,
>
>> I thought it was not good practice to rely on exception in
>> unexceptional circumstances. In ArrayFieldVector, there are numerous
>> occurences of the following pattern
>>
>> public FieldVector<T> add(FieldVector<T> v)
>> throws DimensionMismatchException {
>> try {
>> return add((ArrayFieldVector<T>) v);
>> } catch (ClassCastException cce) {
>> checkVectorDimensions(v);
>> T[] out = buildArray(data.length);
>> for (int i = 0; i < data.length; i++) {
>> out[i] = data[i].add(v.getEntry(i));
>> }
>> return new ArrayFieldVector<T>(field, out, false);
>> }
>> }
>>
>> The "catch (ClassCastException cce)" seems uggly to me. Should I file
>> a JIRA issue and start replacing with instanceof?
>
> This was done on purpose a long time ago.
> At that time, it appeared that it was faster to do it this way, i.e.
> attempt by default the fast method which did not rely on getEntry, and
> fall back to a loop using getEntry only in the very rare cases the first
> fails.
>
> I am not sure this is useful anymore, as JVM optimizers are better and
> better (so they may well replace the getEntry on the fly and use direct
> array access when they can).
>
> Perhaps you could do some benchmark with a modern JVM and look if this
> hack is still useful or not.
>
If it still is, a comment should be added to make future maintainers
aware of this fact.
Benedikt
> best regards,
> Luc
>
>> Best regards,
>> Sébastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
