David Abrahams wrote:
At Mon, 18 Oct 2010 10:29:14 -0800, Robert Ramey wrote:
Your scheme seems a lot more complicated than industry standard practice, which is to use one or two long integer constants as macros (c.f. __GCC_VERSION__ and friends).
Since I wrote that, I have had occasion to investigate the versioning scheme suggested for linux shared libraries. It seems to me that this proposal is remarkably similar to that used for these libraries:
see http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Really? What parts do you see as similar? It jumps out at me that your proposal is full of source code and that page doesn't seem to have any recommendations for source code (unless I overlooked them)
I was referring to the scheme itself - I don't remember where I saw it but maybe I cited the wrong page. ....so files have major and minor release. I think that the major one refers to an api change while the minor refers to an implemenation change and/or enhancement. I don't remember where I saw it, but I believe it was something like this http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-inf... where there are several levels of "versions" so that I can specify what level of dependency my code has on other packages.
among many others. My proposal is only an idea and I'm not prepared to mount a serious defense of it. But it seems that something along these lines is going to be necessary.'
Yes, something along these lines. I'm just wondering if you are reinventing tank treads when we already have a perfectly good wheel.
I hope so, but I'm not seeing it. The ....so.m.n.o scheme is fine as far as it goes - but It doesn't say anything about how it is to be enforced at compile/link/runtime. As far as I can tell, dependencies of header only libraries aren't even considered.
That's also useful for > #ifdefing, whereas mpl::int_<>s are not.
Well, if you want to enhance my proposal to add constants and have the mpl_<... or static assert use those constants, that would be fine with me.
Why do you want the mpl_<...> thing in the first place?
So that immediately when attampting to compile things would crap out and not depend on this or that instantiation. I wouldn't have to scatther #ifdef/... all over the place. As soon as I include a header that's too old it fails in exactly the right place. If the code isn't recompiled, the construction of the static runtime variable should force the system to fail immediately as well rather than just running until it fails. Again - all without having to scatter if/else ... all over the place. RObert Ramey