Re: Alternatives languages on the JVM: which one or is there no alternative?
On 30.11.2013 00:22, Volker Borchert wrote:
Robert Klemme wrote:
What does dynamic_cast in C++ do differently? As far as I am informed
it involves a type check as well. I mean, you can have the same in Java
by catching the exception (which is what you need to do in C++ IIRC).
No you don't, that is exactly the raison d'etre of dynamic_cast.
if (o instanceof C) {
final C c = (C) o;
// do something with c
}
does _two_ typechecks
final C c = dynamic_cast<C>(o);
if (c != null) {
// do something with c
}
would do _one_ typecheck and a cheap IFNONNULL
I was only aware of the exception thrown from dynamic_cast - but that is
only the case for reference types. Thanks for the update!
I have no idea how these really compare performance wise: there is JIT
and then I do not know how expensive the type check is really. The best
would be to make _realistic_ measurements of the type checking overhead.
I find it difficult to discuss this without knowing more about your
requirements and situation. But then again, maybe you don't want or
cannot disclose that.
One example, for a Cache<Key,Value> that supports mixed flavor Value
references, and a subclass which additionally has entries doubly
linked, somewhat similar to LinkedHashMap, I want
AbstractEntry<K,V> WeakReference<V>
| |
| |
/ \ |
+---------------+---+----------+-------------+ |
| | | |
| | | |
AbstractLinkedEntry<K,V> StrongEntry<K,V> | |
| | | |
| | | |
+---------------+---+----------+ +--+---+--+
| \ / \ /
| | |
| | |
| StrongLinkedEntry<K,V> WeakEntry<K,V>
| |
| |
+------------------------------+---+--------------+
\ /
|
|
WeakLinkedEntry<K,V>
(soft flavor omitted for safe of readability)
So if I understand your diagram correctly you want to mix two
implementation aspects
1. weak or strong referencing
2. linked and not linked entries (probably for LRU scheme)
Given what I know so far I'd still do it as suggested earlier: use an
Object field to either reference the item or a WeakReference. If that
overhead compared to the cached keys and values is significant then,
yes, that might be something to worry about. If on the other hand you
are caching contents of Icon files I wouldn't think about that overhead.
The linked entry class would then be a sub class of the simple reference
and contain everything necessary for managing the linked list of entries.
If a single cache has uniform entries then you can avoid the type
checking with instanceof and just cast. The algorithmic part could even
be abstracted away via an interface referenced by the cache instance.
For the strong reference type you would end up with the single cast that
appears outside the cache when the reference is assigned a variable of a
specific type; type erasure will make all V things Object inside the cache.
Now we just need to know what you want to do with this and why you need
to be asynchronously notified of GC'ed entries. :-)
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/