On Sat, Jun 29, 2013 at 1:16 PM, Sam Varshavchik 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
On Tue, Aug 21, 2012 at 3:33 PM, Marc Glisse wrote:
> Note that by default, C++11 assumes that destructors don't throw. If we want
> to allow users to throw from their deallocation functions (why?), we might
> want to specify it (which disables the optimization discussed here).
This is a library
On Mon, Aug 20, 2012 at 2:43 PM, Marc Glisse wrote:
> On Mon, 20 Aug 2012, Gabriel Dos Reis wrote:
>
>> On Mon, Aug 20, 2012 at 2:24 PM, Marc Glisse wrote:
>>>
>>> This is perfectly fine, it is optimization n°2 for the case where the
>>> move
>>> c
On Mon, Aug 20, 2012 at 2:24 PM, Marc Glisse wrote:
> On Mon, 20 Aug 2012, Niels Möller wrote:
>
>> Marc Glisse writes:
>>
>>> That's where move constructors appear. One can now define something
>>> that is similar to a copy constructor, except that it leaves the
>>> original object in some arbit
On Mon, Aug 20, 2012 at 2:10 PM, Niels Möller wrote:
> Marc Glisse writes:
>
>> That's where move constructors appear. One can now define something
>> that is similar to a copy constructor, except that it leaves the
>> original object in some arbitrary state, so in particular it can steal
>> its
On Wed, Aug 15, 2012 at 2:21 PM, Marc Glisse wrote:
> On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
>
>> On Wed, Aug 15, 2012 at 9:45 AM, Marc Glisse wrote:
>>
>>> Note also that I am not going as far as some propositions for the future
>>> C++
>
On Wed, Aug 15, 2012 at 9:45 AM, Marc Glisse wrote:
> Note also that I am not going as far as some propositions for the future C++
> std::integer type, which may require construction from int to be a
> compile-time operation (no dynamic allocation).
I think that is very reasonable approach for m
On Thu, Aug 2, 2012 at 8:04 AM, Joerg Arndt wrote:
> * Niels Möller [Aug 02. 2012 14:41]:
>> Marc Glisse writes:
>>
>> > Ok, now I've criticized intmax_t enough,
>>
>> I guess this is an age old problem of backwards compatibility. As I have
>> understood it, originally in C, long was intended to
