lefthandman

Oh wait, is it that you take your (n-bit long) hash function result, do the perfect hashing precomputation on the k (n/k-bit long) chunks of the result, then immediately hash all of the k (n/k-bit long) chunks to new locations with the guarantee that they are unique new locations? Genius! That would seem to work, assuming that perfect hashing doesn't decrease the uniformity of the chunks and works for even the most random of input sets (literally randomly and uniformly distributed bits).
Thanks ApochPiQ!

Ok, well the domain for the current use case is currently limited to strings. I've got a murmur hash for strings that vary (in game PMs etc) and an FNV hash for those that don't (player status tuples in string form).

However I've tried to keep the hash function a black box set of bits for as long as possible so that I don't have to rewrite my implementation for everything I use it for (not saying it's better than existing hash libraries, I'm just trying to get good at this aspect of cs and jumping head first seems reasonable).

What I've read on the wikipedia article makes it seem like perfect hashing is a way to generate a hash function (such as FNV or murmur) for a predetermined set that maps the set into your hash table without collisions. That's not exactly what I'm going for here, as I simply want to hash to k unique locations in my hash table (per string) so that I can implement cuckoo hashing.

Another way of phrasing what I'm looking for is to say that given a perfectly uniform hash function (one in which any result has equal likelihood with all the others) that spits out a result n bits long map that to k results each one being n/k bits long and not allowing any repeats. Even if this ends up sacrificing uniformity, the quality of no repeats seems useful from my perspective.

I would recommend C. You'll find quite a few discernible differences from C++ beyond the lack of OOP. It's perhaps the most important language I've learned.

Hmm, well I think that a good place to start would be to check where you're hitting the #ifndef X guards in your files (I assume you have those), and try to avoid extra #includes.
Also, try to use a tool like Hudson that compiles outside your personal computer.
Oh, and make sure you're not doing stupid stuff like compiling boost (the whole thing) every time (unless you need to ).

Although I have little experience developing for a mobile platform, I can *hopefully* assist you in choosing technologies that have the characteristics you've described.

Resizing images is expensive(in terms of RAM & speed). IE, so can Android, iOS handle resizing 10+ images(for eg .png) & display them on screen in a relatively fast amt of time? In Mosync doing such stuff depends on the phone RAM but on HTC Desire(512mb) it takes about 6 seconds which is unacceptable for my app.

In general, raster graphics are not meant to be re-sized. For this reason, I would recommend you seriously consider using vector graphics.
However, it should be possible to resize images fast even if they are in a raster format. The following could help, although it's written for Tcl/Tk: http://wiki.tcl.tk/11196

Does the API come with its own fonts & layout managers? Mosync doesn't have its own fonts, you have to create & import it & you cant change the colour of a font. You also cannot make the text in a widget display centred or word wrapped, can Android/iOS/other do this?

For a free font, I like DejaVu: http://dejavu-fonts.org/wiki/index.php?title=Main_Page
Especially DejaVu Sans Mono.

Is it a REAL headache designing your app layout because of all the different potential phone sizes there are, so the widgets placement & skins will be incorrect on small screens & images will be out of proportion on large screens? Does the Android/iOS/other API help you by automatically laying out your GUI no matter the phone size & does it automatically scale image widgets & fonts to suit phone sizes?

Yeah, I'd really suggest vector graphics.