On Sat, 2012-10-06 at 20:59 +0200, _ wrote: > Now obviously you can't put stl everywhere. > I don't see kernel and low level C or C++ libs using boost or stl. any > time soon. > Afterall. No reasonable library uses it either due to binary > incompatibilities.
It seems that your proposed fix to that is as binary incompatible as using std::unique_ptr or std::shared_ptr. What happens when you link a library that was compiled with '*~' pointers enabled, with a library that was compiled without those pointers, and both exchange data/objects? > C or C like templateless C++ code is still domain of most os / > drivers source code out there. > Just go agead and try to ask Linus to wrap all pointers to stl > templates ;D I think you will run for your life then. Have you asked him for his opinion on your proposed solution? > Not everybody agrees that wrapping every single variable to macro like > templates and spreading simple code logic over zilion files is way to > go. But the main problem holding stl back is it's binary and header > incompatibilities. Adding a non-standard compiler extension most likely will not be and improvement for those problems. But if you really want to try it out, you can do it by writing a custom preprocessor that triggers on '*~' and replaces the preceding token with std::unique_ptr< token > or std::shared_ptr< token >. Cheers, Oleg
