It's hard to see what MS can gain from the Kinect long term. All it looks to have done is give their xbox sales a bit of a boost. The hardware itself is not theirs - it's built by another company, Primesense (http://www.primesense.com/)...which is not in MS' pockets. PrimeSense is building other similar units already. One in particular with Asus. See http://www.engadget.com/2011/01/03/primesense-and-asus-team-bring-kinect-like-wavi-xtion-to-your-h/. Other companies are also already close to bringing their similar products to market - our company is engaged with one at the moment.

What is Microsoft's is some of the software bundle that is used in kinect games. But with the excitement around the product, and some software from primesense itself, that void is and will rapidly be filled. When it does it won't leave Microsoft anything for the long term. Already we're using it in all sorts of ways on our robots, running linux, using the openni and ros software. Its rather easy to forget that its an actual Microsoft product.

I'm running a fanless pc with an intel atom and a case that doubles as a heat sink. Actually most intel atom based mini boxes would suffice - I chose this one simply because I wanted it to be a router as well and its got the dual ethernet ports on the back. You don't need a netbook - they're basically the same thing with a monitor and the monitor is completely redundant for this sort of thing - just means you'll be installing far more than is necessary.

On mine I've got gentoo running with only a minimal set of packages:

ssh, apache, mysql, php, svn server, dokuwiki, samba, nfs, iptables and redmine.

- Fanless box with low wattage -> low power
- Intel atom -> compatibility problems a little easier than with some other cpus.
- Minimal -> easy to maintain.
- Gentoo -> can continually update, dont have to worry about re-installing when the next big release comes along.

It's brilliant, stacks in my bookshelf like just another book.

As always, when programming, you should understand your libraries and use it accordingly. Iostreams are when of the best misunderstood concepts because everyone tries to use it as a one size fits all solution.

Iostreams are template code. So yes, they will increase the size of your binary because everything is inline. If you're fretting about binary size, then you shouldn't even be considering using them.

You shouldn't base effectiveness of C++ on MinGW - there are alot of other factors contributing to problems with MinGW and quite likely you're missing the target point. I believe the posters above discussed this in more detail.

Iostreams are there for pure convenience. They're great if you just want to quickly code with a minimum of hassle. To do anything more complicated than that (like streaming for devices) is a bit of a nightmare. The iostream classes are fairly heavy, slow and do alot of format checking and other things that reduce it to a crawl. If you're just writing a quick program for a desktop pc, they're fine. But if you want a fast, lightweight embedded program, or want streaming for devices...you should shelve them.

It is possible to create streaming classes that run more than 100% faster than iostreams and even printf. We built some internally for our company.

What I'd really like now that its possible to start scaling up computation on embedded boards, is c++ libraries whose primary focus first is speed and *then* convenience. Boost is great for some things, but quite often it swaps those priorities around (see ublas).