This essentially reverts bfd5673 whilst fixing the issue that that brought up (memleak on the assignment operator).
It brings CVariant back to 2 members or 12 bytes, rather than the previous 100-odd bytes which was only going to increase further with the addition of a wstring datatype. CVariants (and vectors or maps of them) are becoming more widely used - they'll be used for all sorting for example soon, and a vector of 1000 CVariants would be over 100k just in overheads at present.
There is very likely more room for optimisation should it be found necessary. For example, the copy constructor need not call the full operator=() (the assignment portion could be split out to a separate function for instance).
@topfs2 and @Montellese review especially appreciated. Other comments welcome as usual.
Would a m_data.array.reserve() make sense here as we know the size of strArray?
Yup - could do.
You beat me to it. I actually started the same work as well but didn't get the time to finish it yet. Looks good to me, might be worth running it through valgrind to see if there are no memleaks but with the general cleanup() being called in operator=() the previous memleak should be fixed.
Thanks for looking over it @Montellese. I'll merge it in after you've got yours in to save you having to rebase :)
switch CVariant back to using only 2 data members now that it's going…
… to be used for sorting.
fixup: MySQL error #1054 - Unknown column in 'Field List'