Re: New Repo for Native Client

I agree with Sarge. I support using the standard tools for each language. I'm inclined to think unification on a single tool can hurt more (e.g. remember ant). And if we don't draw the line in the build process then where will we draw it? I would hate to see more Java code reformatted into C++

Re: [jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

It has been moved into a contrib directory outside the core sources where other standalone tools can live too. https://github.com/apache/geode-native/tree/develop/contrib/pdxautoserializer Thanks, David On Wed, Mar 1, 2017 at 9:28 AM, Michael Stolz wrote: > We should make

[DISCUSS] geode-native c++ exceptions

C++ client uses a custom standalone base exception class [1 ] and several derived exceptions [2

Re: [VOTE] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

Actually, it looks like Jake is right. According to documentation it's undefined behavior since it's not a template specialization. http://en.cppreference.com/w/cpp/language/extending_std Thanks, David On Fri, Sep 15, 2017 at 10:37 AM, Ernest Burghardt wrote: > cool

Re: [Discuss] Investigation of C++ object return types

I am wrong. > > I am still in the shared pointer camp for cache and a raw pointer to cache > in cacheImpl. > > Sorry, and thanks, > Mark > > > > > On Sep 18, 2017, at 10:14 AM, David Kimura <dkim...@pivotal.io> wrote: > > > > +1 value approach (via som

Re: [Discuss] Investigation of C++ object return types

structor easier, but... > > If the consensus is that this is a significant ease of use benefit for the > user, I am on board… > > +1 > > Thanks, > Mark > > On Sep 18, 2017, at 11:15 AM, David Kimura <dkim...@pivotal.io> wrote: > > > > The benefit I see isn't for p

Re: [Discuss] Investigation of C++ object return types

;>>> > >> > >>>> As value: > >> > >>>> Serializable* MyClass::fromData(DataInput& dataInput) { > >> > >>>> auto cache = dataOutput.getCache(); > >> > >>>> ... > >> > >&g

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

ittle to understand the > purpose of the PdxWrapper. > > On Thu, Sep 21, 2017 at 11:37 AM David Kimura <dkim...@pivotal.io> wrote: > > > Is using PdxWrapper any different than if user added their type into the > > serialization registry? If not, then do we really want to provid

Re: [Discuss] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

Seems like a good idea. Here's a quick thought - I think c++11 is not really an obj.toString() kind of language (like Java or C#). Would it make sense to add std::to_string() and std::to_wstring() equivalents for CacheableString? This might mean implementing following functions:

Re: Return types form methods on Cache

I favor values, but we should probably be diligent. Do any of the objects returned from Cache depend on Cache to out-live the returned object? A quick scan suggested no, but we still have a std::enable_shared_from_this. Maybe dead code. In code example, if this happens (for any cache.get*),

Re: Return types form methods on Cache

Err... I missed a return in example above. Region r = [](){ return CacheFactory::create().getRegion("myregion"); } (); On Tue, Sep 19, 2017 at 10:19 AM, David Kimura <dkim...@pivotal.io> wrote: > I favor values, but we should probably be diligent. > > Do any of the ob

Re: Return types form methods on Cache

be valid. It’s “references” to > interns cache/region would be invalid. The behavior is undefined. > > > On Sep 19, 2017, at 10:24 AM, David Kimura <dkim...@pivotal.io> wrote: > > > > Err... I missed a return in example above. > > > > Region r = []()

Re: Return types form methods on Cache

Cool. +1 value model. Thanks, David On Tue, Sep 19, 2017 at 11:15 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > It isn’t. A Region should not outlive cache. > > > On Sep 19, 2017, at 10:54 AM, David Kimura <dkim...@pivotal.io> wrote: > > > > Oh, man. I

Re: [DISCUSS] C++ Returning null values

I'm not sure if this is the same as the sentinel value you mentioned, but what about introducing a no-op region type and returning that? I'm thinking a null object pattern which would no-op and then nobody should need to check if nullptr. Thanks, David On Tue, Oct 10, 2017 at 10:27 AM, Jacob

Re: [Discuss] What type should C++ object creation functions return?

; wrote: > Great, can you provide some examples of what some of the APIs would look > like if we made these changes? > > On Wed, Sep 6, 2017 at 2:29 PM David Kimura <dkim...@pivotal.io> wrote: > > > Good point. In those cases, the copy constructor should have been >

Re: [Discuss] What type should C++ object creation functions return?

> > > std::unique_ptr looks like a good option. > > > > then again if the typical usage is like so: > > > > cachePtr = CacheFactory::createCacheFactory(pp)->create(); > > > > it seems simple enough to just return the bare object > > >

[Discuss] Investigation of C++ object return types

Follow up of attached discussion after more investigation. I created an example of returning Cache as shared pointer versus raw value: https://github.com/dgkimura/geode-native-sandbox I still like returning by value as it lets the user do what they want with their object. // Here user

Re: [DISCUSS] Using out parameters and its effects on function overload resolution

on why, > > https://www.fluentcpp.com/2016/11/22/make-your-functions-functional/. > > > > As a bonus, once we go C++17 (in 2020ish I am sure) we can use auto > > structured return values. > > auto [a, b] = foo.getAAndB(); > > > > -Jake > > > &

[DISCUSS] Using out parameters and its effects on function overload resolution

Is there a use case in our C++ client code to ever use out parameters? Currently code uses out parameters to return multiple values from a function. [1] virtual int64_t* PdxReader::readLongArray(const char* fieldName, int32_t& length) = 0; In this case, we could return a tuple instead. I

Re: [Discussion] Geode-Native Removing Stats from Public API

I agree, a statistics interface seems beyond the scope of Geode Native client responsibility. Hiding or removing seems appropriate to me. Thanks, David On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt wrote: > +1 for removal > > On Thu, Nov 16, 2017 at 1:46 PM, Jacob

Re: Discussion: Native PDX Reader/Writer std::string

Given that C++17 is feature-complete, it seems prudent to adopt those patterns as much as possible. My fear with #4 is that we're introducing a special case API that users become accustomed to and then unwilling to later switch to std::optional. And then we'd end up supporting multiple ways to do

[Discussion] Native - Should C++ client support wchar_t type?

While working on removing out parameters, we noticed code that makes assumption that wchar_t is always 16 bits. virtual void PdxInstance::getField(const char* fieldName, wchar_t& value) const = 0; void PdxInstanceImpl::getField(const char* fieldname, wchar_t& value) const { auto dataInput =

Re: Permissions to update JIRA tickets

Thanks Dan! On Thu, Feb 1, 2018 at 11:32 AM, Dan Smith <dsm...@pivotal.io> wrote: > Hi David, > > Done - you should have access. > > Thanks! > -Dan > > On Thu, Feb 1, 2018 at 11:14 AM, David Kimura <dkim...@pivotal.io> wrote: > > > Hi, > &g

Permissions to update JIRA tickets

Hi, I would like to be able to update the status of Geode JIRA tickets I worked on. Would someone be able to give me the permissions to do so? My username in JIRA is dkimura. Thanks, David

Re: [DISCUSS] Streamline return value from RemoteQuery

On Wed, Aug 15, 2018 at 5:24 AM, Jacob Barrett wrote: > Oh wouldn’t it be nice if it was asynchronous... :( "Hold my beer" :P

Re: [DISCUSS] Streamline return value from RemoteQuery

hat too! > > > > -Dan > > > > On Tue, Aug 14, 2018 at 10:47 AM, Anilkumar Gingade > > > wrote: > > > >> In Java, they are separated so that the results can be managed > effectively. > >> For example StructSet has its own implementation to manage the

Re: [DISCUSS] Streamline return value from RemoteQuery

I have a couple questions: Do you have an idea or theories of what was the original intent behind separating ResultSet and StructSet? Is execute a blocking or non-blocking call and does the interface have any guarantee of that? Thanks, David On Mon, Aug 13, 2018 at 4:06 PM, Ernest Burghardt

[jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

[ https://issues.apache.org/jira/browse/GEODE-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876425#comment-15876425 ] David Kimura commented on GEODE-2441: - Current idea is to move PDXAutoSerializer either to geode

[jira] [Created] (GEODE-2484) Remove ACE from native client dependencies

David Kimura created GEODE-2484: --- Summary: Remove ACE from native client dependencies Key: GEODE-2484 URL: https://issues.apache.org/jira/browse/GEODE-2484 Project: Geode Issue Type: Task