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
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,
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
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
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
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
