On Monday, June 9, 2003, at 5:48 PM, Alex Henderson wrote:
I'd like to calculate a value for a cyclic redundancy check (crc) for a number of files.
This isn't going to be transmitted anywhere, I simply want to compare the values to see whether the files are exactly the same. I know I can simply check byte for byte, but I've got a few thousand files and it's easier to calculate the crc for each and see whether any are the same first.
I've looked at the crc library, but can't get my head round the example. It seems to test the library rather than show how its used.
Yes, the sample program is meant as a test of the library. You can still get an idea of usage from it. There are also short examples in the HTML documentation.
I'm after something like
std::vector<char> MyStream1; // the whole file (about 500kb)
boost::SomeCRCTypeThatIsOptimisedForSafetyAndLargeishBlocks<???> x;
long = x.checkme(MyStream1);
Could someone please point me to some code where a simple example is detailed?
What's in the documentation is it. Do you have a specific CRC algorithm in mind? If so, you just pick the appropriate template parameters. If not, you can choose one of the samples I provided, like boost::crc_32_type. The optimized CRC function objects can work with a single byte at a time or an array-segment of bytes. By putting your file's data in a std::vector as you have in your example, you limit yourself to just the single-byte computing call, as the elements of a vector may not be contiguous. Just allocate a simple char array and use one of the CRC object's array computing calls or use one of the CRC functions. Based on what you said, I don't think you need the object-wrapping that std::vector gives. Daryle
--- At Tue, 10 Jun 2003 15:10:46 -0400, Daryle Walker wrote:
On Monday, June 9, 2003, at 5:48 PM, Alex Henderson wrote:
I'd like to calculate a value for a cyclic redundancy check (crc) for a number of files.
This isn't going to be transmitted anywhere, I simply want to compare the values to see whether the files are exactly the same. I know I can simply check byte for byte, but I've got a few thousand files and it's easier to calculate the crc for each and see whether any are the same first.
I've looked at the crc library, but can't get my head round the example. It seems to test the library rather than show how its used.
Yes, the sample program is meant as a test of the library. You can still get an idea of usage from it. There are also short examples in the HTML documentation.
I'm after something like
std::vector<char> MyStream1; // the whole file (about 500kb)
boost::SomeCRCTypeThatIsOptimisedForSafetyAndLargeishBlocks<???> x;
long = x.checkme(MyStream1);
Could someone please point me to some code where a simple example is detailed?
What's in the documentation is it.
Do you have a specific CRC algorithm in mind? If so, you just pick the appropriate template parameters. If not, you can choose one of the samples I provided, like boost::crc_32_type.
The optimized CRC function objects can work with a single byte at a time or an array-segment of bytes. By putting your file's data in a std::vector as you have in your example, you limit yourself to just the single-byte computing call, as the elements of a vector may not be contiguous. Just allocate a simple char array and use one of the CRC object's array computing calls or use one of the CRC functions. Based on what you said, I don't think you need the object-wrapping that std::vector gives.
[ I expect a correction flood on this one. :-) ] In fact, vector<> is guaranteed to be contiguous. It is the only standard container that satisfies this requirement. ...Duane
On Tuesday, June 10, 2003, at 3:20 PM, Duane Murphy wrote: [SNIP]
[ I expect a correction flood on this one. :-) ]
In fact, vector<> is guaranteed to be contiguous. It is the only standard container that satisfies this requirement.
I think the contiguous requirement is only given in a correction report, not in the standard itself. But my point was that if the OP only needed a simple byte bucket, he could just allocate one without complicating matters with a full-blown object. It's more efficient because the multi-byte processing function only works with simple byte buckets. Daryle
--- At Tue, 10 Jun 2003 16:19:54 -0400, Daryle Walker wrote:
On Tuesday, June 10, 2003, at 3:20 PM, Duane Murphy wrote:
[SNIP]
[ I expect a correction flood on this one. :-) ]
In fact, vector<> is guaranteed to be contiguous. It is the only standard container that satisfies this requirement.
I think the contiguous requirement is only given in a correction report, not in the standard itself.
That is correct. However, the correction was mostly accademic as it was understood that no one had actually implemented a vector that wasnt continguous.
But my point was that if the OP only needed a simple byte bucket, he could just allocate one without complicating matters with a full-blown object. It's more efficient because the multi-byte processing function only works with simple byte buckets.
This used to be my consensus as well. However, after reading Meyer's More Effective STL as well as several CUJ articles I became convinced that there was virtually no overhead and lots of convenience to actually using a vector instead of "raw" storage. The automatic size management coupled with automatic destruction is a huge win over raw allocated storage management. In addition, most standard libraries have optimized vectors for pod's that remove the overhead of constructing and destructing intrinsic types and pointers. My conclusion was that vector<> is your friend. :-) ...Duane
On Tuesday, June 10, 2003, at 10:15 PM, Duane Murphy wrote:
--- At Tue, 10 Jun 2003 16:19:54 -0400, Daryle Walker wrote: [SNIP]
But my point was that if the OP only needed a simple byte bucket, he could just allocate one without complicating matters with a full-blown object. It's more efficient because the multi-byte processing function only works with simple byte buckets.
This used to be my consensus as well. However, after reading Meyer's More Effective STL as well as several CUJ articles I became convinced that there was virtually no overhead and lots of convenience to actually using a vector instead of "raw" storage. The automatic size management coupled with automatic destruction is a huge win over raw allocated storage management. In addition, most standard libraries have optimized vectors for pod's that remove the overhead of constructing and destructing intrinsic types and pointers.
My conclusion was that vector<> is your friend. :-)
If we just need the automation, we could make an array-variant of std::auto_ptr<>. I did that once on my previous computer. Maybe I should make a submission for boost::auto_array<>. Daryle
participants (2)
-
Daryle Walker -
Duane Murphy