Improvements to openni_pcd_recorder

[j-oberlaender]

The recorder now has command-line support for device IDs just like openni_viewer.
Also, a problem with free memory and buffer size calculation was fixed.

[jspricke]

Could you exclude 6b44c54 from this pull request? I think it needs further discussion. Rest is fine, thanks!

[j-oberlaender]

Thanks for the feedback! I created a separate pull request for the all but 6b44c54.
For me, 32-Bit systems with a PAE kernel are a regular reality, and since it is easy to support those systems as well I think we should try to report correct memory and buffer sizes for them. Note that currently, the PCD recorder outputs nonsensical numbers like this:

Total available memory size: 579102311809286765MB.

(This of course is because the print statement expects a %llu, but the variable given is not a 64-bit one.) Because the variable can not hold the true memory size, the calculated default buffer size is basically random.

Of course, if my commit breaks something on ARM we need a different solution. Unfortunately I currently don't have an ARM system at my disposal to check that. I did try to keep everything compatible by using std::size_t where it matters. I only force the actual memory size calculation to use 64-bit unsigned integers in case there is more total memory than a size_t can hold.

[jspricke]

Hm.. looks like we are using uint64_t already in a couple of places, So maybe it's ok (let's wait for the others to comment). Could you clean up this pull request to only contain the type change (use git rebase -i and git push -f)?

[jspricke]

I guess this should be:
uint64_t memory = std::numeric_limits<size_t>::max ();

[j-oberlaender]

I guess what you meant to write was std::numeric_limits<size_t>::max () (which got swallowed by the Markdown parser)?

Yeah, you could use the size_t maximum, but that should not make a difference since the value is limited to std::numeric_limits<size_t>::max () in line 82 anyway.

Got back from my lunch break, I'll clean up and squash things now.

[jspricke]

Yes, that's what I meant and you are right that it doesn't make a difference, only that it makes more sense to me and wouldn't break that easy if we change something later ;).

[j-oberlaender]

I'll clean this one, and rebase it, once we're ok with #673.