Hubert Figuiere wrote: > In the last commit I fixed a double free of the popt context in the > Cocoa code. While reviewing, I found out that it was caused by tamlin's > leak fixes in the Win32 code.
Ouch. Sorry Hub, obviously that wasn't my intention. But wouldn't it make more sense to let the arg class handle both the resource aquisituion and release instead of repeating the same code in every platform implementation, opening up for mistakes and misunderstandings like this? Not only would it enhance encapsulation and making sure stuff like this don't happen, it would also force the arg class to provide a functional interface, opening the door for using whatever argument parsing lib one desires, without changing any code in the user/client code using the arg class, with only one single place to change - ap_Args.cpp. If it doesn't make sense: why? What's the benefit of global static data that anyone can probe/set/reset/screw up compared to a class encapsulating the resource aquisition/release and its interface providing the necessary operations? (hmmm, this reminds me of an old AW+libpng "incident"... :-> ) /Mike
