You're right that the default is delete/free. However, the important bit is that it needs to be the correct delete/free. The error you described originates from the fact that the final application has two copies of the CRT and thus two copies of delete/free. Since shared_ptr/unique_ptr picks the call to delete/free at compile time this means that it should be picking the correct delete/free.
On Fri, May 12, 2023 at 9:27 AM Arkadiy Vertleyb (BLOOMBERG/ 120 PARK) < avertl...@bloomberg.net> wrote: > Maybe I am wrong about shared_ptr though. Yes, according to Scott Meyers > it is safe, at least in tr1. Have to see what is there now... > > From: dev@arrow.apache.org At: 05/12/23 12:23:48 UTC-4:00To: > dev@arrow.apache.org > Subject: Re: Freeing memory when working with static crt in windows. > > 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 > <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 > <https://stackoverflow.com/questions/1958643/is-it-ok-to-use-boostshared-ptr-in-dll-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 > > > > > > >
