Gary R. Wheeler wrote:
Implementing them to the standard is just so freaking complicated that compiler designers don't seem to be able to issue decent diagnostics for them. The point at which they detect problems is so far removed from the original source that they can't associate the two.
I think that's a big reason I sat on the bench about them for so long. When I played with them in the past, I didn't really need them so it was more of an academic exercise. Then I just got frustrated with them and bagged it. I'm using VC++ 20008 now and it doesn't choke as much but diagnostics aren't much better.
Gary R. Wheeler wrote:
My main source of never-ending grief is ">>" versus ">{space}>".
I got bit on that one early and now, if I'm on my game, remember to look for it. Part of the whole finicky somewhat arcane notation which has to be just so or you're scratching your head again about compiler errors. :^)
Gary R. Wheeler wrote:
Most of the Boost libraries do not like to be mixed with other libraries such as MFC or ATL.
Gary R. Wheeler wrote:
I would imagine Boost requires that your wxWidget objects have certain Boost-specified characteristics, and they don't. You might need to encapsulate them in your own objects for serialization purposes.
Yes, ran into that one but fortunately so far I'm only serializing two, wxColor and wxString. I first tried deriving serializable classes from them but ran into problems. Now I just have a data container to shadow wxColor and create an instance to do the serialization at the point it's needed. For wxString, I convert it to an std::string and go from there. I'm sure as time goes on, I'll be building up the repetoire but that's a bridge that can be double crossed later. On top of that, I'm using OpenCV, too, with its own set of simple primitives but since it's a C API, it will be a bit easier as the data is public for most of it.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.