Construction From vector<char> ?
Robert Evans
bobsphysics at yahoo.com
Wed Aug 13 21:10:19 CEST 2008
Sorry, I am not explaining myself well. What we have is not a vector containing the characters (i.e. ascii) representing a number, but the actual hex bytes. For example, we might have a 4 byte array containing [0x31 0x32 0x33 0x34]. For us this is NOT the number "1234" but the number 0x31323334 or in decimal 825373492. I supposed we should have used the name vector<unsigned short> but someone used vector<char> which is a bit misleading.
Thanks, Bob
----- Original Message ----
From: Marc Glisse <marc.glisse at normalesup.org>
To: Robert Evans <bobsphysics at yahoo.com>
Cc: gmp-discuss at swox.com
Sent: Wednesday, August 13, 2008 12:38:49 PM
Subject: Re: Construction From vector<char> ?
On Wed, 13 Aug 2008, Robert Evans wrote:
> Also very useful for me would be the output of an mpz_class object into
> an array (vector<char>). Perhaps there is a way to do this via the
> ostream operators? My basic problem is: we are already using byte
> arrays which represent trans-64 bit numbers. I could do a HUGE amount of
> refactoring of really bad code which manipulates such arrays if I could
> construct a mpz_class from such an array, do the arithmetic within GMP,
> output back into an array. The C++ interface seems to character-based
> I/O only.
I am having a hard time understanding what you say. You are complaining
that the interface is character-based and you would like something that
interacts better with a vector of characters...
If as I believe your vector<char> is just a string with a silly name, the
conversions are pretty trivial, and I gave you two ways (there are many
others) to go from vector<char> to string. The reverse direction is just
as easy.
The only other thing your vector could be is like a gmp representation
with 8-bit limbs, which sounds very strange so I am not considering it.
If you think the conversions include too many copies, you can use the
mpn_set_str function for instance, that takes a char* and a length instead
of expecting a null char to mark the end. But beware that you need to deal
with the allocations yourself then.
--
Marc Glisse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gmplib.org/list-archives/gmp-discuss/attachments/20080813/3cc2ede4/attachment.html
More information about the gmp-discuss
mailing list