Construction From vector<char> ?

[David Gillies]

For those of us using gcc, for example, we're pretty much stuck at 98.
And '&' and '[]' are overloadable operators. I'm not trying to be
obnoxious, just pointing out the pitfalls of assuming that C and C++
are so freely mixable at this level. You CAN, as it happens, do a
memcpy using a vector<char> with &v[0] as the source pointer on my
system (gcc/g++ 3.3.1 on x86 Linux under a 2.6 kernel). But in
practise, this is not guaranteed to work portably. However, GMP uses
its own assembler-based copy routines which under my implementation
are optimised for the case of blocks in the source data with
sizeof(mp_limb_t), with no nails, LSB first, same endianness as the
host machine, and aligned on an mp_limb_t boundary. Violate any of
those conditions, especially the nails one, and things get
(potentially a lot) more complicated.

On Thu, Aug 14, 2008 at 6:33 AM, Marc Glisse <marc.glisse at normalesup.org> wrote:
> 23.2.4.1 of C++03 says:
>
> The elements of a vector are stored contiguously, meaning that if v is a
> vector<T, Allocator> where T is some type other than bool, then it obeys the
> identity &v[n] == &v[0] + n for all 0 <= n < v.size().
>
> This sentence was absent in C++98.
>
>> Further, even if you have access to the raw data as a pointer to an
>> array, you can't just simply reinterpret_cast the pointer to be
>> mp_limb_t* (at least not portably - there's no ironclad law that says
>> a long is four bytes in a row, for example, and you'll probably bus
>> fault on unaligned data on a lot of machines).
>
> IMO endianness is a larger issue here.
>
>> So mpz_import() will be stuck doing a bytewise import.
>
> On a system where it is appropriate (in particular with the right
> endianness), there is no reason mpz_import can't do a single large memcpy (I
> haven't looked at the implementation so I don't know if it does).
>
> --
> Marc Glisse
>



-- 
David Gillies
San Jose
Costa Rica