Artyom wrote:
Sure, boost ABI changes from release to release but unless you want to provide a "one-for-all" binary release of your library, what is the issue? Even libstdc++ ABI changes every now and then.
Not correct. GCC keeps ABI since gcc-3.4... And this is now about 6 years... Not bad?
My point was that all libraries change sometimes. Frequencies vary, of course. I wonder what you'll say when libstdc++ changes the next time (and it will happen)?
You can still provide binaries for certain distributions. For instance, Ubuntu-8.04 comes with boost-1.34 and libstdc++.so.6. That won't change.
Yes, but debian comes with boost-1.35 and Ubuntu-8.10 would be with another version and maybe user wants to use in its application 1.42 and he can't because libfoo uses 1.35...
Sure, that's what source distributions are for, IMHO :-)
I would try to avoid a library that uses such pseudo-boost in its API instead of the real thing,
As I had written I do not encourage you using this. But I can't use anything else because I can't use boost!
Believe me, writing this library is far from being my first choice.
OK, but as a matter of fact, I was looking for a replacement of cakephp (not sure yet), and cppcms is on the list of candidates. If using cppcms would require using booster instead of boost, I would probably strike it from the list.
In addition, to be honest, personally because I want to use boost, not some look-alike. I don't want to use the umpteenth version of a smart pointer...
Very good point. The shared_ptr I used is boost shared_ptr but instead of inline sp_counted_base I use compiled and linked sp_counted_base so I can change implementation without breaking binary compatibility. But it is still the same shared_ptr
Small difference.
OK, can I so something like the following? boost::shared_ptr<int> a(new int(0)); booster::shared_ptr<int> b = a; (replace shared_ptr with all the other boost-look-alike classes) Regards, Roland