Thanks Monty for the clarification. I think I started going down that rathole when I was removing macros and tried to replace the actual my_* files, thinking that was the ultimate way to go. I didn't get very far on that front, but it wasn't a total loss - in following all of the references using those files I learned a lot about other parts of the codebase!
Chris On Mon, Jul 13, 2009 at 8:35 PM, Monty Taylor <[email protected]> wrote: > Chris Musialek wrote: > > I've been working through one of the low-hanging fruit tasks, trying to > > remove and replace some of the macros, and after some time in the mysys/ > > directory cleaning up macros that I found I came to realize that most of > the > > macros and even files in the mysys/ dir are all stuff that should > probably > > just be replaced by C++ STL. I was wondering, what pieces are still tied > > into using the mysys/ directory that prevent it from being removed > entirely? > > I have some ideas, but I thought I'd leave it to the experts. Would it > make > > sense to build a task around that goal? > > Yes, you are correct. There is a task in fact - > > https://blueprints.edge.launchpad.net/drizzle/+spec/code-cleanup-mysys-replacement > | http://drizzle.org/wiki/Mysys_replacement > > Shrews has been working on this some already, and it's sort of an > ongoing thing, just because of the spidering of stuff. In any case, > finding something and making a plan on removing it and using either STL > constructs or standard POSIX calls is a great idea - just be careful, > you can easily go down a rathole. > > As far as I'm concerned, the entire dir should eventually go away - as > should mystrings.... it's just about taking it one step at a time. > > Monty > >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp

