标签: iOS

1. 输入 / 输出流类层次 C++ 的输入 / 输出流类库是用派生方法建立起的，它有 2 个平行的基类， streambuf 和 ios 。其他的流类都是从这两个基类直接或间接派生的。 1.1 streambuf streambuf 类是带有缓冲区的流类库，它的作用是提供物理设备的接口、缓冲区或处理流的通用方式。当其用做流类库中的基类时，派生以下三个流类： （1） filebuf 类：使用文件来保存缓冲区中的字符序列； （2） strstreambuf 类：扩展 streambuf 的功能，提供在内存进行提取和插入操作的缓冲区管理； （3） onbuf 类：扩展类 streambuf 的功能，用于处理输出、提供控制光标、设置颜色、定义活动窗口、清屏、清一行等功能，为输出操作提供缓冲区管理； 该类使用的缓冲区由一个字符序列和输入缓冲区指针与输出缓冲区指针组成，指针指向字符被取出或插入的位置。通常情况下，均使用这三个派生类，很少直接使用 streambuf 类。 1.2 ios 类 ios 类及其派生类为用户提供了使用流类的接口，它们均有一个指针指向 streambuf 类。 Ios 及其派生类使用 streambuf 来完成对错误的格式化输入 \ 输出检查 , 并且支持对 streambuf 的缓冲区进行 I/O 时的格式化或非格式化转换。 ios 类及其派生类的层次关系： ios ， istream,ostream 和上述提到的带缓冲区的流类库 streambuf 类构成了 C++ 中 iostream 输入 / 输出功能的基础。流是一个抽象的概念，实际进行 IO 操作时，必须将流与一种具体的物理设备联系起来。比如，将流和键盘联系起来，当从该流中提取数据时，就是从键盘输入数据，可以用 istream,ostream 等类声明流对象： istream is; ostream os; 2. 标准输入 / 输出流 C++ 将一些常用的流类对象，如键盘输入，显示器输出，程序运行出错输出，打印机输出等，定义并内置在系统中，供用户之间使用。这些系统内置的用于设备间传递数据的对象称为标准流类对象，共 4 个。 （1） cin 对象：与标准输入设备相关联的标准输入流； （2） cout 对象：与标准输出设备相关联的标准输出流； （3） cerr 对象：与标准错误输出设备相关联的非缓冲方式的标准输出流； （4） clog 对象：与标准错误输出设备相关联的缓冲方式的标准输出流。 例子 输出 char* 类型的变量 C 语言中的 I/O 必须要提供数据类型信息。 C++ 对此做了改进，能够自动判别数据类型，但是有时还得提供使用类型信息。比如，字符串是 char* 类型，假设需要输出其指针的值，即字符串中第一个字符的地址，但是重载运算符 输出的只是以空（ null ）字符串结尾的 char* 类型的字符串，因此使用 void* 类型来完成上述需求（需要输出指针变量的地址时都可以使用 void* 类型）。 #include iostream using namespace std; int main() { char *string = "test" ; cout "sting is: " string; cout "\n Value of static castvoid *(string) is: " ; cout static_cast void *(string) endl; system( "pause" ); return 0; } 通常在 while 循环结构的首部用流读取运算符输入一系列的值。当遇到文件结束符时，读取运算符返回（ false ）。 #include iostream using namespace std; int main() { int grade, highestGrade = -1; cout "Enter grade(enter end-of-file to end):" ; while (cin grade) { if (grade highestGrade) highestGrade = grade; cout "Enter grade (enter end of file to end):" ; } cout "\n Highest grade is:" highestGrade endl; system( "pause" ); return 0; } 在上述程序中， cingrade 可以作为条件，因为基类 ios( 继承 istream) 提供了一个重载的强制类型转换运算符，将流变成 void* 类型的指针。如果读取数值发生错误或遇到文件结束符，则指针值为 0 。编译器能够隐式使用 void* 类型的强制转换运算符。

The recent Apple Spring Forward event was notable for the hardware it unveiled. And indeed, here is a quote from my previous comment: As is often the case in situations like this, the "rest of the story" will only appear in the coming hours, days, and weeks, as Apple spokespersons accidently (or not) let more details slip during the post-presentation product showcase, as developers leak more details in the process of finalizing their applications and associated services, and certainly as initial review units show up at doorsteps. To wit, I've already learned some interesting additional facts about the Apple Watch and MacBook, which I'll share in a coming-soon follow-up writeup. But Spring Forward's various services announcements were, to me, the highlight of the event. Partner (at least for now) HBO's "Now" unbundled offering was particularly notable, for example; a coming-soon dedicated-topic post will delve into it in greater detail. And the other new-service release that was front-and-center on my radar screen was ResearchKit. Apple's website defines it as "an open source software framework that makes it easy for researchers and developers to create apps that could revolutionize medical studies, potentially transforming medicine forever." As I heard the pitch, I was reminded of SETI@home , a distributed-computing volunteer project that those of you old enough (like me) and geeky enough (ditto) might also remember. SETI@home is still around, actually; you can download a copy of the client utility from the website hosted by the University of California, Berkeley (SETI@home is funded by grants from the National Science Foundation, NASA, and donations from volunteers). About those volunteers, here's how the overview page describes the service: "SETI@home is a scientific experiment that uses Internet-connected computers in the Search for Extraterrestrial Intelligence (SETI). You can participate by running a free program that downloads and analyzes radio telescope data." That "free program" is, I suspect, at the core of why SETI@home is no longer as popular as it initially was. In part, this is because the service has plenty of competition nowadays , ironically including distributed computing projects focused on medicine . And in part, if my particular experience is indicative of the norm, it's because the client didn't do a particularly good job of discerning when the computer was idle and only tapping into available processing resources at those times. Instead, I frequently found my computers slowing to a crawl when I needed them to be responsive for even modest word processing, email, and other similar tasks, unless I manually paused the client beforehand (and remembered to un-pause it afterward). Implementation hiccups aside, the concept of SETI@home was sound; it relied on the altruism of its participants, something that I'd wager will be even easier to harness when the possible outcomes are improvements in the quality and longevity of fellow human beings' lives, versus the potential for finding signals broadcast by aliens in space. Think about it for a minute, and I think you'll agree that a smartphone or tablet, soon to be (in the Apple world) or already (in the Android ecosystem) paired with a smart watch, is an ideal platform for logging, pre-processing, and uploading to the "cloud" (for further processing, and archiving) a diversity of medical data. First and foremost, consider the platform's mobility (in and of itself a key enabler) and ubiquity, the latter driven both by our desire to communicate and (in some geographies) the equally important fiscal allure of service provider subsidies. Consider the formidable (and faster all the time) available host CPU processing facilities, along with the additional general-purpose compute capabilities of co-processors such as the GPU, DSP, ISP, etc. Consider the plentiful allocations of both local volatile and nonvolatile memory. And consider the (mostly) persistent and (increasingly) bandwidth-robust cloud connectivity. Next, let's look at system specifics. Focusing first on the smartphone and tablet, an abundance of integrated resources are available to tap into a diversity of medically interesting attributes: High-precision touchscreen High-resolution front and rear cameras Microphone(s) and speaker(s) (plus external headset support) GPS (for current-location and movement discernment, along with associated current-temperature assessment) Compass (additional movement details) Accelerometer and gyroscope (ditto) Barometer (for both weather and elevation discrimination) Unique identification capabilities, and Encrypted communications support Now consider that the Apple Watch not only can harness the hardware of its wirelessly tethered iOS partner, but also contains a touchscreen, microphone, speaker, unique ID, encryption support and accelerometer, the latter helpful for additional (and wrist-centric) movement measurement purposes. Plus, it integrates all-important heart rate monitoring facilities. The first five announced ResearchKit applications use this potential in interesting ways, foreshadowing even more creativity to come: With the Asthma Health app , developed by Mount Sinai, Weill Cornell Medical College, and LifeMap, "data from the GPS in your iPhone is combined with information about the air quality in your city to help you avoid areas where symptoms could be triggered." mPower , from the University of Rochester and Sage Bionetworks, focuses on Parkinson's Disease and leverages the gyroscope in an iPhone, along with its touchscreen, to measure dexterity, gait stability and other factors. GlucoSuccess , created by Massachusetts General Hospital, combines user-entered glucose levels with data generated by iPhone sensors like the accelerometer and gyroscope, to enable you to compare your activity and glucose levels. Share the Journey , provided by the Dana-Farber Cancer Institute, UCLA Fielding School of Public Health, Penn Medicine, and Sage Bionetworks, focuses on breast cancer research. It relies on you inputting data on a regular and frequent basis in order to discern how your activity levels correlate to symptoms. Finally, MyHeart Counts from Stanford Medicine and University of Oxford places its attention on cardiovascular disease. "The activity data that can be measured with your iPhone can be assessed against your diet and lifestyle information to give you a much more objective Lifetime Risk Estimate," says the description. Researchers sure seem enthused; check out, for example, this recent quote from Alan Yeung, medical director of Stanford Cardiovascular Health, after having received 11,000 signups for MyHeart Counts in the first 24 hours of the application's availability: To get 10,000 people enrolled in a medical study normally, it would take a year and 50 medical centers around the country. And in general, I'm also quite enthused about ResearchKit's potential, not only for Apple's customers but also for the computing and communications world more generally. To that point, and to the best of my knowledge, Apple hasn't yet been particularly forthcoming about what it means by "open source" in the context of ResearchKit. I'm guessing it doesn't mean that, for example, the iOS applications' source code will be freely provided to Android developers ... even if it were, the reliance on operating system-specific APIs wouldn't make the code very portable, anyway. Instead, I suspect what will be openly documented will be the types, formats, and precisions of the data required by a particular service, and the protocols necessary to get that data up to the associated server for analysis and archive. With that all said, however, I do have a few concerns: iPhones, iPads, Apple Watches, and the like appeal to a demographic that skews younger and more affluent than the norm. As such, it's not clear to me to what degree the data generated by iOS-based ResearchKit apps will be indicative of the population at large. Speaking of data, its associated demographics are highly dependent on the honesty (and more general willingness to divulge personal information) of its users. Age, gender, ethnicity, income level, height, weight, and other similar attributes are both important to researchers and feasible to be fudged by participants. Speaking of personal information, Apple and its ResearchKit partners will need to maintain absolute scrupulousness regarding how the data is handled in order to obtain and retain users' trust. Can a particular data set be traced to a particular person, for example? And will it be retained only for research purposes, or subsequently transferred to commercial enterprises? Apple has subsequently clarified at least some of these potential issues by adding entries to its developer guidelines , but it'll need to remain vigilant, including rapidly yanking apps that inevitably stray into misbehaving territory. "Sandboxing" is another area that'll require ongoing vigilance. Apps that access information on a user's device beyond the strict data set necessary for whatever medical condition is being monitored must also be quickly dismissed from the App Store. Speaking of age, and the recently augmented developer guidelines, one of them insists that apps must require minors to obtain consent from a parent or guardian before the program is allowed to run. The means by which this consent is assured is not yet clear, nor is the ease by which a minor can falsify his or her age (corrupting the integrity of the logged data set in the process). Finally, government organizations such as the FDA and FTC haven't yet (again to the best of my knowledge) been explicitly mentioned by Apple in the context of ResearchKit. Recently, the FTC fined several companies who claimed that their apps accurately diagnosed skin cancer. Such mole-growth and other assessment capabilities are in fact possible, especially when a series of images consecutively captured over a period of time are compared. Where these companies seemed to go astray, however, was in going beyond marketing their products as diagnosis guides and instead promoting them as definitive diagnosis tools. Share your thoughts on the latest from Apple in the comments below.   Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance. He is also a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company's online newsletter. And he's an off-hours freelancer as the Principal at Sierra Media, where he contributes to (among other things) the Brian's Brain blog at EDN Magazine. Brian has a BSEE from Purdue University in West Lafayette, IN. His professional career began at Magnavox Electronics Systems in Fort Wayne, IN, where he worked for an aggregate 2.5 years as a co-op engineer.  

创建基于Arduino自动化系统的过程，一般解决处理问题需要大量时间。 Arduino Manager 是一个app，可在iPhone和iPad上使用，用它来控制你的Arduino板，并可通过以太网、WiFi及BLE 来获取信息。Arduino Manager整合了iOS设备和Arduino，让操作变得不能再简单了！这里就告诉你如何通过手机或平板电脑控制你的Arduino。   更多信息

深圳市微码兴科技有限公司 是一家APPLE授权的资深开发商，至2004年来，为众多知名的厂商提供技术方案，并取得了巨大的成功，是业界公认的技术标杆。SE819 iSO蓝牙模块为我司2012年主打产品，是专明用于IOS / ANDROID系统的通讯模块，支持iOS外部设备与iOS device(iPhone,iPad, iPod) 之间的双向双模式通讯。可实现用苹果iOS 设备控制外部设备以及设备采集的数据在iOS device上显示两大功能，该产品支持蓝牙Bluetooth 2.1+EDR 规范标准，采用嵌入式蓝牙 Bluetooth stack (SPP, PAN)蓝牙协议栈，并集成了Apple CP Chip 及MCU，APPLE通讯协议由我司资深工程师倾力编写，确保所有APPLE产品的兼容性万无一失，支持iAP (iPod Accessory Protocol)、Apple XCode、Extend session API 的扩展编程及Android OS操作系统。 SE819具有网络节点密度高，稳定无线性能等优势，内置APPLE 通讯协议及标准化的APPS通讯接口，并且接口简便，便于您二次开发。无需外挂MCU及APPLE CP Chip；可大大减小产品体积及BOM成本，专为高端品牌客户开发苹果创意产品。 适用范围： 高端玩具和游戏产品（蓝牙遥控玩具，并用手机来显示相关数据，如速度，方位，，，） 智能家居 （如蓝牙控制灯光、窗帘，，，） 健康护理保健产品（配合APPS使用，如脉博仪，血压器，心跳议） 电子称 （蓝牙电子称，通过蓝牙发送数据给手机收接，通过手机来管理体重数据） 家庭医疗设备 （适用于各种需要显示数据的设备，我们可以用手机来显示并管理这些数据） 健身器材 车载产品 www.beesong.com.cn 咨询电话：13825273452 /xuleicheng@beesong.com.cn 许先生； 关键词：（MFI蓝牙模块，APPLE蓝牙模块，MFi蓝牙，iOS蓝牙模块，iPhone Bluetooth module，苹果蓝牙模块，苹果认证蓝牙，ios蓝牙模块，MFI通讯模块）  

当今，Android已逐步发展成为手机不可或缺的一部分，一直摇领中国市场先锋老大诺基亚会不会也应用Android呢？我们一起讨论下吧。   在诺基亚发现需要将 Symbian 平台升级为智能手机的操作系统是，通过选择另一款操作系统能否使诺基亚避免现在一系列的麻烦么？ 诺基亚没有选择 Google 研发的并且风靡全球的 Android 系统，而是选择了微软的 Windows Phone 操作系统作为旗下智能手机的操作平台。诺基亚应当选择 Android 吗？毕竟，三星、 LG 、华为和摩托罗拉所生产的智能手机均使用了 Android 系统。根据市场调查公司 Gartner 的调查，在 2011 年底 Android 就占据了超过全世界一半的智能手机操作系统的市场份额。苹果公司使用 iOS 系统的 iPhone 手机，是排在第二位的，占有 23.8% 。 Windows Phone 排在第 6 位。 为什么是 Windows Phone ？   要知道为什么诺基亚做出这个选择，我们需要回到 2011 年的二月份诺基亚 - 微软联合新闻发布会。那时，诺基亚 CEO Stephen Elop 向全世界宣布了两家公司的联合。   为什么是 Windows Phone ？“它将会给我们领先的机会” Elop 说，“它给我们指引了一条通向美国市场的捷径”。   Elop 之后表示诺基亚目前有三个选择：与其自身的 Symbian 系统协同工作的 MeeGo （一个基于 Linux 的开源操作系统，现在并不支持）， Android ，和微软。     “我们确实与 Google 的同事们谈了谈”他说。即使 Elop 承认 Android 正在快速进步并且增长市场份额，他担心诺基亚会成为另一个只是运行 Android 的手机。“我们本身的想法是我们会很难和其他品牌区分，”他说。“商品化风险很高。”早些时候， Elop 在一次采访中承认 Android 要比 Windows Phone 领先：“ Android 正在迅速的成长，它会有很可观的市场份额。”他还表示“诺基亚会给 Android 带来很大的用户数量并且将会预示手机操作系统市场的重大转变。”   底线   所以，诺基亚智能手机操作系统的选择并不是因为任何的技术优势，亦或是市场份额优势，而是因为诺基亚作为手机市场昔日的领跑者只是害怕它的产品将会成为另一个毫无特点的运行 Android 的设备。   原文请参考：http://www.dailyfinance.com/2012/04/17/should-nokia-have-gone-with-android/