At Mon, 18 Oct 2010 13:45:08 -0800, Robert Ramey wrote:
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.
Yes, that's "industry standard" practice.
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.
Sure, I thought everybody was aware of that sort of scheme, and what you were mostly proposing had to do with how it was expressed in code.
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.
So now we're back to expressing it in code.
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.
#defines do that nicely too.
I wouldn't have to scatther #ifdef/... all over the place.
I don't know what you're talking about. Wouldn't you just do something like STATIC_ASSERT(LIBFOO_VERSION >= 4001003); // libfoo must be 4.1.3 or later ? I don't see any #ifdefs here.
As soon as I include a header that's too old it fails in exactly the right place.
Doesn't the above accomplish it?
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.
I think maybe you're being a bit dramatic about this :-) The advantage I was citing for a preprocessor #define is that you *can* use #ifdefs, if and where you need them. It doesn't mean you have to. They do everything your mpl typedefs do, and more. -- Dave Abrahams BoostPro Computing http://www.boostpro.com