[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ] Cliff Jansen commented on ISPN-470: ----------------------------------- Dealing more specifically with the API issues: The patch provides a basic implementation of get() and put() as a straw man for analysis. It was pointed out to me, before the ink even started drying, that returning objects rather than pointers to objects led to bad usage patterns: RemoteCache<Ktype, Vtype> cache = cacheManager.getCache<Ktype, Vtype>(); try { Vtype result = cache.get(key); // do something with result } catch (const HotRodKeyNotFoundException& e) { // do "key not found" processing } This gets a thumbs down because a non-existent key is not a rare exceptional condition and should not invoke expensive exception machinery to deal with it. So to avoid the exception (and be closer to the Java client in this respect), we could switch to return a pointer to the object, allowing the following processing: TbdType result_ptr = cache.get(key); if (result_ptr) // do something with result else // do "key not found" processing Every library hates to be blamed for someone else's sloppy memory management. We could just return the raw pointer and assume the user will act responsibly and always free the object when done. Or we could return some sort of smart pointer, but the availability and functionality of these varies from C++03 to C++11. We could define TbdType to be essentially unique_ptr or auto_ptr depending on platform. Since auto_ptr is a bit wonky and unfixable without C++11, that is less than perfect, but the downside is understood. A variant system with extensibility points for custom classes and marshallers is also an option. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira