Unless you provide custom deleter, which I don't believe arrow does, it is just default delete()->free(), which exactly matches to the problem I am having. It would have to be a shared_ptr with additional template parameter.
So no, unless special care was taken by arrow developers, shared_ptr would not solve the issue :-( Also I think potentially something like returning std::vector by value would cause the same issue. From: dev@arrow.apache.org At: 05/12/23 11:53:34 UTC-4:00To: dev@arrow.apache.org Subject: Re: Freeing memory when working with static crt in windows. I'm not very familiar with Windows. However, I read through [1] and that matches your description. I suppose I thought that a shared_ptr / unique_ptr would not have this problem. I believe these smart pointers store / template a deleter as part of their implementation. This seems to be reinforced by [2]. [1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing -crt-objects-across-dll-boundaries?view=msvc-170 [2] https://stackoverflow.com/questions/1958643/is-it-ok-to-use-boostshared-ptr-in-d ll-interface On Fri, May 12, 2023 at 8:21 AM Arkadiy Vertleyb (BLOOMBERG/ 120 PARK) < avertl...@bloomberg.net> wrote: > Hi all. > > In some cases arrow API allocates an object and returns a shared pointer > to it. Which means the object will be deallocated on the client side. > > This represents a problem when working with a static CRT in windows (which > I am experiencing right now). > > IIUC, the way to deal with this would be to export a "free" wrapper from > arrow DLL and use custom deleter on the shared pointer to call this > wrapper, so that both allocation and deallocation happens inside the arrow > DLL itself. > > Does arrow provide this kind of facility? > > Thanks, > Arkadiy > >