On 09/08/2016 01:58 PM, Corinna Vinschen wrote: > On Sep 2 13:36, Michael Haubenwallner wrote: >> On 09/02/2016 10:52 AM, Corinna Vinschen wrote: >>> On Sep 2 10:05, Michael Haubenwallner wrote: >>>> Moving the allocator into pathfinder would work then, but still the >>>> tmp_pathbuf instance to use has to be provided as reference. >>> >>> Hmm, considering that a function calling your pathfinder *might* >>> need a tmp_pathbuf for its own dubious purposes, this makes sense. >>> That could be easily handled via the constructor I think: >>> >>> tmp_pathbuf tp; >>> pathfinder finder (tp); >>> >>> Still, since I said I'm willing to take this code as is, do you want me >>> to apply it this way for now or do you want to come up with the proposed >>> changes first? >> >> As I do prefer both pathfinder and vstrlist to not know about tmp_pathbuf >> in particular but a generic memory provider only: Yes, please apply as is. > > Done, minus patch 4.
Then my original problem with dlopen isn't fixed yet, where some application code within /opt/app/bin/app.exe does dlopen(libAPP.dll), currently finding /usr/bin/libAPP.dll although app.exe linked against /opt/app/bin/libAPP.dll. However, thank you anyway! > I still think that there should be only a single > pathfinder object and the rest encapsulated within and called via some > pathfinder member function. I'll look into it later this year. A thought to avoid the extra tmp_pathbuf_allocator class: Have cygmalloc.h (or similar) declare the allocator interface, to allow for tmp_pathbuf to implement it by itself. The complete idea is to have another allocator implementation using cmalloc+cfree, as well as one more using malloc+free. Probably there is use for another one using VirtualAlloc+VirtualFree as well. Then even path_conv might utilize the allocator interface, using the cmalloc+cfree implementation (provided by cygmalloc.h) by default... /haubi/