Re: [boost] [GSoC11] Checks & Hashes

Subject: Re: [boost] [GSoC11] Checks & Hashes
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2011-03-23 11:01:25

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Mateusz Nowak
> Sent: Wednesday, March 23, 2011 2:11 AM
> To: boost_at_[hidden]
> Subject: [boost] [GSoC11] Checks & Hashes

> I'm 3rd year Informatics student at ETI, Gdańsk University of Technology and I'm
> highly interested in participating in GSoC 2011. I choose boost and "Checks &
> Hashes" project idea, because it meets with my coding abilities and "always try
> to make something useful" general rule. I have 7 years experience in
> programming and algorithms. I would rate my knowledge: c++ 4/5, svn 3-3.5/5.
> 
> Some questions about the project. As CRC class seems to be only separate
> hashcodes library in boost, should the rest of algorithms libraries at least try to
> inherit crc methods naming and parameters convention or, if decision to use
> completely different convention, the crc library should be adapted or left as it is
> now?
> Actual naming idea is that function name should start with algorithm type - if it
> produces checksum or hash, than algorithm name (sha, crc,
> ...) and then variant (like in sha: sha1, sha256,...), so sha1 function name will
> look like h_sha_1, or for "Simple modulo 256 etc check values and digits." it will
> be c_simple_256.
> 
> How many algorithms you expect to be found/implemented, documented,
> tested and got to work more or less? This would help me making work plan. Also
> i will have exams between 8-21 June, so my commitment to the project at that
> time will be low. I hope that this won't be a problem.

Hi Mateusz

Glad you too are interesting in this project (I have 3 others interested already).

I hope this project will produce something "immediately useful" and I believe that it is most important that it should be *finished*.

Fortunately, in this case, 'finished' can be 'as long as a piece of string' in that it can be limited by the number of checks/hashes attempted.

As long as the structure, tests and docs are complete on a few checks, it could be considered 'finished'.

But I'd hope that the implementer would get at least part way through my list of ideas (or others - these are only suggestions - you may consider Polish Driving Licence numbers of paramount importance ;-)

The internal structure, inheritance, naming are *your* project decisions (perhaps guided by Boosters - who always have strong views on things, but who also carry the final seal of approval if it survives a Boost review. 

Meanwhile, if you would like to see how you get on with the idiosyncratic Boost Way of Doing Things...

https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/

You might like to see if you can re-build the existing skeleton code (Boost uses a rather bizarre build language called bjam - for portability).

You will need to download Boost 1.46 library, and use Tortoise SVN to get boost-sandbox/

(you only need to top level folder structure - be very careful to clear the box that says "include subfolder" or you will get the whole of sandbox (big)!)

Then download (update) the /soc/2011/checks folder, *including all the sub-folders this time*. 

and if you can, you could try coding one of the simple suggested checksums using some literature algorithm.
(checksum of byte or int arrays modulo 256 perhaps?).

You will find that the ISBN and ISSN examples are already done.

You should also be able to add some skeleton documentation to the existing using Doxygen.

You probably won't have write access to the sandbox, but you could work on a local copy and email me privately a zip of your folder.

Paul

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]