Re: Moving C++ bindings in gmpxx.h into a namespace
On Sat, Jun 29, 2013 at 1:16 PM, Sam Varshavchik mr...@courier-mta.com wrote: Is there any interest in moving all the C++ bindings into their own namespace, say gnu::mp? We need a cost/benefit analysis. What do we gain compared to the massive amount of existing code that is sure to break? (I don't see the point of having to liter my code with either 'using namespace gmp' or 'gmp::' just to get the existing working code work again.) -- Gaby ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Moving C++ bindings in gmpxx.h into a namespace
Marc Glisse writes: On Sat, 29 Jun 2013, Sam Varshavchik wrote: Is there any interest in moving all the C++ bindings into their own namespace, say gnu::mp? Vaguely. Preferably at the same time as some other ABI-breaking changes. This is popular with many C++ dev libraries, like boost, for example. There are several advantages with doing that; mainly reducing the risk of clashing with application's own symbols, or even with symbols from other libraries that an app also links to. The risk of clashing is very low. We currently use the old C namespacing technique of giving all names an application-specific prefix (plus we illegally put most names in the implementation namespace). Did you hit a particular issue or are you just suggesting it because it sounds good? I was pondering including gmp internally as part of another C++ library, that has its own vanity namespace; where I follow the principle of not adding its symbols to the global namespace; I think that should be entirely for client apps, so I like not to meddle therer. Or, for 100% source backwards compatibility, rename gmpxx.h to something else, and have it declare everything in gnu::mp, and replace gmpxx.h with a stub that includes the real file, and provides the three typedefs. I'd probably import the names to the global namespace by default anyway, so no point complicating things too much. That'll work too; as long as it's possible to avoid that, and possible to import only the library-specific namespace. pgpXaplfNod19.pgp Description: PGP signature ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Moving C++ bindings in gmpxx.h into a namespace
Niels Möller writes: Sam Varshavchik mr...@courier-mta.com writes: Compatibility with existing code is trivial. What about binary compatibility? I imagine namespaces are involved in the symbol name mangling in some way? (I'm no C++ guy, so I don't have any strong opinion on whether or not it's a good idea to use namespaces in GMP). Correct, and binary compatibility is lesser of an issue for C++ than it is for C. It's generally expected that C++ source is going to get recompiled after updating a library. See, for example: http://boost.2283326.n4.nabble.com/ABI-and-API-compatibility-td2643120.html Another data point: although recently gcc is trying to maintain its own libstdc++'s ABI compatibility across major branch releases, for a while the ABI was compatible only within a gcc branch release. Until some time ago, even if some particular C++ library's ABI remained the same, app code (and that library itself!) would need to be recompiled after updating gcc. Additionally, gmpxx.so does not use versioning. This would also be a consideration to discuss, here. pgpSRDAgmiNeZ.pgp Description: PGP signature ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Moving C++ bindings in gmpxx.h into a namespace
On 06/29/13 20:16, Sam Varshavchik wrote: Is there any interest in moving all the C++ bindings into their own namespace, say gnu::mp? This is definitely a good idea. -- Prof. Roberto Bagnara Applied Formal Methods Laboratory - University of Parma, Italy mailto:bagn...@cs.unipr.it BUGSENG srl - http://bugseng.com mailto:roberto.bagn...@bugseng.com ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: Moving C++ bindings in gmpxx.h into a namespace
On Sat, 29 Jun 2013, Sam Varshavchik wrote: Is there any interest in moving all the C++ bindings into their own namespace, say gnu::mp? Vaguely. Preferably at the same time as some other ABI-breaking changes. This is popular with many C++ dev libraries, like boost, for example. There are several advantages with doing that; mainly reducing the risk of clashing with application's own symbols, or even with symbols from other libraries that an app also links to. The risk of clashing is very low. We currently use the old C namespacing technique of giving all names an application-specific prefix (plus we illegally put most names in the implementation namespace). Did you hit a particular issue or are you just suggesting it because it sounds good? I can prepare a patch to do that, if there's interest. Compatibility with existing code is trivial. Binary compatibility is trivially broken. And some odd programs would also fail to compile (though that might be acceptable). Either provide a separate file that existing code can include, that contains a grand total of three typedefs: typedef gnu::mp::mpz_class mpz_class; typedef gnu::mp::mpf_class mpf_class; typedef gnu::mp::mpq_class mpq_class; You forgot gmp_randclass at least (and using is shorter than typedef). Or, for 100% source backwards compatibility, rename gmpxx.h to something else, and have it declare everything in gnu::mp, and replace gmpxx.h with a stub that includes the real file, and provides the three typedefs. I'd probably import the names to the global namespace by default anyway, so no point complicating things too much. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Moving C++ bindings in gmpxx.h into a namespace
Is there any interest in moving all the C++ bindings into their own namespace, say gnu::mp? This is popular with many C++ dev libraries, like boost, for example. There are several advantages with doing that; mainly reducing the risk of clashing with application's own symbols, or even with symbols from other libraries that an app also links to. I can prepare a patch to do that, if there's interest. Compatibility with existing code is trivial. Either provide a separate file that existing code can include, that contains a grand total of three typedefs: typedef gnu::mp::mpz_class mpz_class; typedef gnu::mp::mpf_class mpf_class; typedef gnu::mp::mpq_class mpq_class; Or, for 100% source backwards compatibility, rename gmpxx.h to something else, and have it declare everything in gnu::mp, and replace gmpxx.h with a stub that includes the real file, and provides the three typedefs. pgpjLFou4kEol.pgp Description: PGP signature ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
