In general, it's a good idea to used signed ints whenever possible.
Here are the only 2 reasons I see for unsigned ints: - matching hardware or wire spec - You need the extra range afforded, and don't need negative numbers.
And the reasons for using signed integers otherwise: - It prevents other overflow and comparison problems. Ie, fixes other dumb coding issues like "if (my_gold - your_gold > 0)" becomes a bug when the gold types are unsigned.
Reliability - Reliability is more than just "we're more stable than Windows." We need to be reliable in the face of hardware failure and service failure.
Ah yes, reminds me of college when a fellow student brought down the department Sun box by using the "manual" (ie, paper-clip) eject button on the CD drive when it wouldn't eject his audio CD. Perhaps Sun has gotten better in the last couple years, but this is hardly reliable.
I'll start by saying these are great speeds. But one thing no one seems to have noticed is how much physical bandwidth it takes up:
The frequency bandwidths for the test are 100MHz in width...
Current technology (3G) uses 1-5MHz bandwidths. So they're starting with 25-100 TIMES the amount of raw materials as current technologies. No wonder they can get better transmit rates. If I had 25-100 56k modems in my PC I could get transfer rates that blow most "broadband" connections away.
Seeing as we're currently running 7Mbps over a 5MHz link in trials, this isn't a huge step up.
In general, it's a good idea to used signed ints whenever possible.
Here are the only 2 reasons I see for unsigned ints:
- matching hardware or wire spec
- You need the extra range afforded, and don't need negative numbers.
And the reasons for using signed integers otherwise:
- It prevents other overflow and comparison problems. Ie, fixes other dumb coding issues like "if (my_gold - your_gold > 0)" becomes a bug when the gold types are unsigned.
The Bluetooth 3.0 + HS spec does exactly what you mentioned -- it takes the Bluetooth profiles, and runs them on top of WiFi.