Hi,

I decided to treat myself to some Free Software coding tonight, and you
lucky folks can reap the benefit. :-)

Version 0.1 of the packarray template class can be downloaded here:

http://www.netdirect.ca/~cdfrey/software/packarray.cc

This class provides an array-like interface to POD objects packed into
a std::string. I plan to integrate this into mysql++ eventually, and its
SSQLS system, but would like some feedback on what's there first.

This class will support any POD object: int, long, short, double, even structs
if they have endian conversion members.

Compile the code like this, to run the unit test:

g++ -Wall -D__TEST_MODE__ -o packarray packarray.cc

There are comments in the code which should explain things a little.

Once the ColData size bug is fixed, this class should slide right in. :-)

License: LGPL

Enjoy,
- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
Nice.

I'm glad to see that you've taken care of the endianness issue for
integers. It was clear that the person behind the post that started all
this was just storing their data in native format, and I had to bite my
tongue not to call him out on it in the thread.

You haven't covered the floating point case, though. The little-known
XDR standard can help here: http://www.faqs.org/rfcs/rfc1832.html There
should be some free XDR code out there you can kipe.

It'd also be nice if you could mass-convert the entire array at once.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Fri, Dec 02, 2005 at 05:58:18AM -0700, Warren Young wrote:
Cool, I'll have to look into that. It's just a template specialization
in my code to support it.


Can you expound on that? Not sure what you mean.

As long as you only access the buffer through packarray, the buffer will
always have the "database version" of the data. No need to run through
the buffer to double check.

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
It appears that data is stored in the array in "network order", and data
is converted appropriately when data goes into the array and when it
comes out. If so, my concern is of the efficiency hit.

I suppose I'm asking if the container could be made to operate in two
modes internally: data stored in network order, and data stored in host
order. If you know you will be doing a lot of munching on, say, a big
double_pack array, you might lock it down to host order before entering
the processing loop to speed it up. You could add a boolean flag to
indicate the state of the data, and use that to decide whether to skip
the call to the traits object to do any conversions.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Fri, Dec 02, 2005 at 11:33:04AM -0700, Warren Young wrote:
Ahh, good point. Will have to ponder that some more. It might make sense
to default to this behaviour.

Thanks,
- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Fri, Dec 02, 2005 at 05:58:18AM -0700, Warren Young wrote:
I took a look at the RFC, and it appears they use IEEE floating point format
to store floats and doubles. This is the same format used in C++, as
far as I know.

That's why I assumed using the C++ in-memory representation of double was ok,
and just passed the same value through in the c2buf() templates for double.

Am I missing something?
- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
Yes, that is better...when assigning data to the array, convert it to
host order, so accesses can happen directly. The element assignment
operator then wouldn't need to do any conversion. The only trick is
that you may have to add another method to retreive a network-order copy
of the data.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
Yes. XDR is pretty much a codification of the SPARC data formats, for
use with protocols like NFS and RPC. So, Sun just wants everyone to do
it their way.

The IEEE standard allows for different byte ordering. To illustrate:

#include <stdio.h>

int main(void)
{
int i;
double x = 42.42;
unsigned char* p = (unsigned char*)&x;

printf("sizeof x = %d, value = ", sizeof(x));
for (i = 0; i < sizeof(x); ++i) {
printf("%02X ", *p++);
}

puts("");
return 0;
}

Run on an x86 box (Linux with GCC or WinXP with VC++), I get:

sizeof x = 8, value = F6 28 5C 8F C2 35 45 40

Run on a G5 PowerMac (GCC 4), I get:

sizeof x = 8, value = 40 45 35 C2 8F 5C 28 F6

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Fri, Dec 02, 2005 at 01:26:23PM -0700, Warren Young wrote:
Thanks. Looks like it should be sufficient to convert the float/double
data to network byte order too.

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw