Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Alternatives languages on the JVM: which one or is there no alternative? Date: Sat, 30 Nov 2013 14:41:35 +0100 Lines: 95 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net MMQUperHF+31RzB2q3E/8wvkPMxVE70fjLOVTAvm7u4qrp734= Cancel-Lock: sha1:xrC+aO0uHkP0hXcyXMjTPOnrTBw= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: X-Antivirus: avast! (VPS 131129-1, 29.11.2013), Outbound message X-Antivirus-Status: Clean Xref: csiph.com comp.lang.java.programmer:26686 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(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 that supports mixed flavor Value > references, and a subclass which additionally has entries doubly > linked, somewhat similar to LinkedHashMap, I want > > AbstractEntry WeakReference > | | > | | > / \ | > +---------------+---+----------+-------------+ | > | | | | > | | | | > AbstractLinkedEntry StrongEntry | | > | | | | > | | | | > +---------------+---+----------+ +--+---+--+ > | \ / \ / > | | | > | | | > | StrongLinkedEntry WeakEntry > | | > | | > +------------------------------+---+--------------+ > \ / > | > | > WeakLinkedEntry > > > (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/