标签: c++

qt是基于c++的一个图形界面的实现框架，并且在其中加入了多线程，xml读写，IO操作，图片的操作，网络等等的支持。   所有说，如果你需要为你的c++程序选择一个界面的实现，并且在很多的配置和网络方面有特定的需求而又不想去自己完成复杂的细节代码，那么选择qt是一个明智的决定。关于qt，如果你需要了解相关的历史或是由来，那么推荐你去阅读c.gui.Qt.4编程（第二版）这本书在开头的以Qt简史为题的篇章，这本书作者是布兰切特和萨默菲尔德，很多时候，事情就是这样子发生的，当人们觉得现存的工具不足以简单或是优雅的完成他们需要的某个功能的时候，他们的第一个想法就是：自己做一个。   在某种程度上，人类的进步史就是一部工具的制造和使用的历史，在这里还是要感激那些用于创造工具并且将他们贡献出来的人们，在这方面最杰出的代表就是unix的众多战将们，前两天一口气读完了《unix编程艺术》，可以说，这本书真的是一口气读完的，很久没有这种舒爽的感觉了，很多里面的内容，比如unix的一个倡导：让程序简单，模块化，并且尝试组合他们完成任务，真的是很有感触。   在书中，我也更多的了解到了unix的发展和背后的心酸和艰苦的历程，在书的最后，作者这样信心满满的说道：我们可以赢得最终的胜利，只要我们想。多么充满豪气的话语！这也是几代人去凝结出来的一种经验，或是感悟。   回到Qt，使用Qt，推荐你使用linux系统，并且使用平台下的两种最流行的编辑器：vi或是Emacs进行编程，你会真正的体会到你许久之前曾经盼望过的编程的快感和贴近你所进行使用的语言的感觉，你需要相信自己，因为有了这样的系统，和这样的语言（c++），你真的可以做很多，不仅仅是工具这么简单，更多的是自己的能力的提升，和自信心的获得。

记得上大学时教C++的美女老师讲：endl和'\n'是一样的，都有换行的作用。教材上好像也是这样讲的，所以一直对此深信不疑，在一些简单程序中互换使用，效果也确实一样。最近写了一个小示例，终于发现这两个命令不完全相同。   示例实现一个简单的功能：键盘输入三个数，然后自动输出其中最大的一个数。代码如下：   #include iostream.h #include windows.h   void main(void) {        int a, b, c;        char close;        cout"Input three INT please:"endl;        cinabc;                    //输入三个数          cout"a = "a'\t'"b = "b'\t'"c = "c'\n';   //输出三个数          cout"The max is:"'\t';                     if(a = b a = c)        {               coutaendl;        }        else        {               if(b = a b = c)               {                      coutbendl;               }               else               {                      coutcendl;               }        }                                        //以上代码计算并输出最大数        cout'\a';                            //A输出振铃        cout"a"endl;                 //B        cout"b";                          //C        cout"c"'\n';                   //D        system("pause");                  //E }   在C++编译环境中运行此段代码，输入三个数回车以后，立即输出最大数，以及A行振铃“嘀”的一声，输出B行字符“a”，然后输出“请按任意键继续…”，按任意键后输出“bc”，然后输出“Press any key to continue…”，然后按任意键结束。如果单独执行程序生成的“.exe”文件，前面输入输出都一样，输出“请按任意键继续…”后，按任意键，没有看见“bc”输出，程序直接结束退出了。 其中“请按任意键继续…”是由E行输出的。按道理，程序顺序执行，输出“a”换行再输出“bc”，然后才执行E行会输出“请按任意键继续…”。而实际上屏幕上显示的是E行先于C，D两行输出，这显然不合常理。因为B行用了endl，而D行用的是'\n'，可见这两个命令还是有区别的。在网上找到如下解释：   endl 是一个特殊值，称为操纵符，将它写入输出流时，不仅具有输出换行的效果，而且它刷新与设备关联的缓冲区，通过刷新缓冲区，用户可立即看到写入到流中的输出。 \n 仅仅是一个换行符，将它写入到输出流时，只能起到一个换行的作用，不能刷新输出。 因此建议，在能用 coutendl; 的形式时不要用 cout'\n'; 形式。 程序员经常在调试过程中插入输出语句，这些语句都应该刷新输出流。忘记刷新输出流可能会造成输出信息停留在缓冲区，如果程序崩溃，将会导致对程序崩溃位置的错误判断。 endl = \n + flush   看过这段解释后，终于明白了。示例程序执行时，是按顺序ABCDE依次执行下来的，B行输出“a”后换行，并刷新了缓冲区，所以屏幕上显示了“a”。而CD行输出“bc”后虽然也换行，但是并没有刷新显示出来。于是又执行了E行，程序暂停并输出提示信息，等待用户结束程序。在编译环境中，由于程序调试时自行加了暂停等待的命令“Press any key to continue…”，所以在程序退出之前还能看见“bc”被显示出来。而单独的exe文件中并没有这个命令，在“请按任意键继续…”之后按任意键，程序直接退出了，“bc”同样也输出了，但是还没显示出来程序已经退出了。 20111206223203  

In my previous column, I talked about the way I write software. I began by saying, "I've always known that the way I write software is different from virtually everyone else on the planet." Boy, was I wrong. Many readers sent me e-mails saying, in effect, "Me too." In retrospect, I was arrogant to suppose that I'm "unique on the planet," except in the sense that each of us is. It's nice to know I have some kindred spirits. (Not everyone shared my views though.) Yet, if I have so many kindred spirits, how come I never noticed? Here's what I think. Faced with a certain development environment, complete with management directives and guidelines, and impossible schedules, different people respond differently. Some folks salute smartly, say "Yes, sir," and make do. I, on the other hand—the model of soft-spoken tact—give my opinions, which range from "That's unacceptable," to the ever popular, "That's the dumbest idea I ever heard!" Such comments have justly earned me, over the years, the title Jack "not-a-team-player" Crenshaw. Having blurted out my opinion on a given environment, I try to change it to one where I can be productive. Sometimes I succeed, sometimes not. One in-house project with the potential for making the company millions of dollars, involved real-time software for a microprocessor. When the "software development environment" arrived, it turned out to be a single-board evaluation kit, complete with line-by-line assembler (no labels, just addresses), and an old 110-baud, thermal-paper terminal. When I said, "Hey, wait a minute! Where's my hard drive? Where's my bulk storage device?" the project manager calmly pointed to the terminal's 110-baud cassette drives. Fortunately, my campaign to change that environment succeeded: we got a far more acceptable one and delivered a great product. More often, I'm unable to change the development environment. On such occasions, I try to carve out a mini-environment where I can still be effective. In my last column, I mentioned an embedded system project where we were promised new builds every two weeks, whether we needed them or not. In my inimitable fashion, I blurted "That's unacceptable! I'm used to turnarounds of two seconds" and set out to find a better solution. We found one: an interactive development environment (IDE) on the company's time-share mainframe. The IDE came complete with assembler, debugger, and instruction-level CPU emulator. It wasn't perfect. The terminal was yet another 110-baud, thermal printing beauty that we used over the company's voice lines to the time-share system 1,500 miles away. But we got edit-compile-test cycles down to the 10-minute level, a whole lot better than two weeks. Were there kindred spirits on that project, doing things the same way I do? Sadly, not. But in looking back, I suspect I had many kindred spirits on other projects and just didn't know it. It wasn't that they were all corporate sheep shuffling to the slaughter. It's just that they were a lot more successful than I, in seeming to be. Like me, they (you) would carve out mini-environments and practices where they could be more effective. They just did it under the radar. They didn't blab about it and left out the "That's unacceptable" and "dumbest idea" parts. Dang! I wish I'd thought of that. Waterfall vs. agile There's a tension between the classical, waterfall-diagram approach to design (separate phases for requirements, design, code, and test) and the iterative, spiral-development approaches. I'm 100% convinced that the waterfall model doesn't work. Never did. It was a fiction that we presented to the customer, all the while doing something else behind the scenes. What's more, I can tell you why it doesn't work: we're not smart enough. The waterfall approach is based on the idea that we can know, at the outset, what the software (or the system) is supposed to do, and how. We write that stuff down in a series of specs, hold requirements reviews to refine those specs, and don't start coding until those early phases are complete and all the specs are signed off. No doubt some academics can point to cases where the waterfall approach actually did work. But I can point to as many cases where it couldn't possibly have, for the simple reason that, at the outset of the project, no one was all that sure what the problem even was, much less the solution. One of my favorite examples was a program I wrote way back in the Apollo days. It began as a simulation program, generating trajectories to the Moon. Put in an initial position/velocity state, propagate it forward in time, and see where it goes. As soon as we got that part done, we realized it wasn't enough. We knew where we wanted the trajectory to go—to the Moon. But the simulated trajectory didn't go there, and we had no idea how to change the initial conditions (ICs) so it would. We needed an intelligent scheme to generate the proper ICs. As it happens, the geometry of a lunar trajectory involves a lot of spherical trig, and I discovered that I could codify that trig in a preprocessor that would help us generate reasonable ICs or, at the very least, tell us which ICs would not work. I wrote a preprocessor to do that, which I imaginatively named the initial conditions program . Using this program, we were generating much better trajectories. Better, but not perfect. The problem is that, after all, a real spacecraft isn't so accommodating as to follow nice, simple spheres, planes, and circles. Once we'd hit in the general vicinity of the desired target, we still had to tweak the IC program to get closer. A problem like this is called a two-point boundary value (TPBV) problem. It can only be solved by an iterative approach called differential correction. We needed a differential correction program. So we wrote one and wrapped it around the simulation program, which wrapped itself around the initial conditions program. Just as we thought we were done, along came the propulsion folks, who didn't just want a trajectory that hit the target. They wanted one that minimized fuel requirements. So we wrapped an iterative optimizer around the whole shebang. Then the mission planning guys needed to control the lighting conditions at the arrival point and the location of the splashdown point back at Earth. The radiation guys needed a trajectory that didn't go through the worst of the Van Allen belts. The thermal guys had constraints on solar heating of the spacecraft, and so forth. So we embedded more software into the iterators and solvers—software that would handle constraints. In the end, I had a computer program that needed almost no inputs from me. I only needed to tell it what month we wanted to launch. The nested collection of optimizers and solvers did the rest. It was a very cool solution, especially for 1962. Here's the point. In those days, computer science was in its infancy. In no way could we have anticipated, from the outset, what we ended up with. We couldn't possibly have specified that final program, from the get-go. Our understanding of the problem was evolving right alongside the solutions. And that's why we need iterative, spiral, or agile approaches. Environment drives approach As I mentioned last time, I tend to test my software very often. It's rare for me to write more than five or six lines of code without testing, and I often test after coding a single line. You can't do this, though, if your system takes four hours to compile or two weeks to build. For my method to work, I need to keep the edit-compile-test cycle time very short, measured in seconds rather than hours, days, or weeks. If my development environment can't support this, I go looking for one that can. It hasn't always been that way, especially for embedded systems. In the beginning, we made do with paper tape inputs read by an ASR-33 terminal. Our only way to "download" software was by burning an EPROM. Fortunately, those days are gone forever. The development environments available these days are amazingly good and shockingly fast. You can develop in an environment (I prefer an IDE) that's almost indistinguishable from your favorite PC compiler system. You can download it into a target at Ethernet, if not USB, data rates, and debug it in situ, using a JTAG-based source debugger. Wonderful. Avoid the embedded part When I'm developing software for an embedded system, I follow one other rule. I can sum it up this way: Avoid the embedded system like the plague. Understand, here I'm talking about the real, production or prototype hardware, not a single-board evaluation kit. At first glance, this may seem crazy. What's the point of developing software for an embedded system if you're not using the embedded system? Let me explain. A lot of the software I develop, whether for an embedded system or not, is math intensive. And the math isn't going to change (we hope) whether it's in the embedded system or my desktop. A Kalman filter or a least-squares fit is the same, regardless of the processor it runs on. Yes, I know, that isn't strictly true; finite word lengths and processor speeds can affect the performance of an algorithm, as do the timing and handshaking between multiple tasks. Even so, the right place to test a new algorithm is not in the embedded system at all; it's in the most effective system we can find, which these days usually means the multicore, multigigahertz box on your desktop. There are at least two other reasons for shying away from the embedded system. First, it may not even be there. In many projects, the hardware is being developed in parallel with the software. If you don't even start the software development until the hardware is complete, you're behind schedule on day 1. Second, even when the hardware has arrived, it may not be stable. Many of us can tell stories about getting strange results and not knowing whether the problem is in hardware or software. We can also tell stories about how the hardware guys invariably say, "Must be a software problem. My hardware is working fine." Before we can get the hardware fixed, we first have to convince the hardware guys that it's broken. Sometimes that's not easy. Because the hardware isn't always stable, the hardware guys need access to the embedded system, just as you do. There's nothing more disheartening than to be all geared up for an intensive debugging session, only to find that the hardware isn't even there; it's gone back to the shop for rework. You end up negotiating with the hardware guys to get access to the machine. For all these reasons, I do my level best to hold off hardware-software integration to the last possible moment. Here's my typical sequence: 1. Develop the math algorithms in a desktop machine. I often use languages other than C or C++ (more on this later). 2. Code the algorithms in C++ using the desktop machine. 3. Download and test the software in a CPU simulator or emulator. If an emulator, I'll take either a software emulation, or hardware in-circuit emulator (ICE). Alternatively, I might use an instruction-level simulator, running on the desktop machine. 4. Download the software into an evaluation kit. Simulate the sensors and actuators of the real embedded system. If you're using an ICE, you can use its internal CPU for this phase. 5. After—and only after—you've tested the software in the simulated/emulated environments, go to the real hardware.  

  A 3×3 matrix class? It's this character flaw that keeps me from being able to show you a completed 3×3 matrix class. Until recently, I've been stuck in one of those while-loops, and this time the ex-wife isn't here to assert the interrupt. I wasn't able to exit the loop until I began writing this column. I'd like to tell you what I have, and see what you think.   Clearly, a 3×3 matrix is not just any old matrix, even any old matrix with one dimension of three. It's a square matrix, and square matrices have special properties. For one thing, they have well-defined diagonals. A square matrix might, in fact, be diagonal. That is, its off-diagonal elements may all be zero. That's important, because a diagonal matrix has a trivial inverse: A square matrix might also be symmetric. If so, it can easily be transformed to a diagonal matrix. When I'm doing arithmetic with 3×3 matrices, they're almost always associated with coordinate rotations. For example, to convert a vector from a rotating coordinate system to a fixed one, I might write:   The matrix T is even more specialized than most. It's a rotation matrix , also called an orthonormal matrix . It has two very important attributes: Its determinant is 1, and its inverse is the same as its transpose:   This is very important, because a transpose of a 3×3 matrix is trivial to generate, whereas an inverse takes a lot longer. Also, because the determinant is known, we don't have to worry about the matrix being singular.   Finally, there exist more than one way to represent a rotation. The matrix is one choice, but not the only one, or even the best one. Other choices include Euler angles and quaternions. Euler angles are useful because people tend to be able to visualize the rotations better. But they're terrible choices for computations. Quaternions are the best and most compact, but good luck trying to visualize them.   Side Comment: You know you've arrived as a guru when you realize you can visualize a quaternion. Since it's a four-dimensional vector, that takes a little practice.   Decisions, decisions Now that I've given you the background, I can tell you why I was stuck in the while-loop. I know that I want to use 3×3 matrices mostly to effect coordinate rotations. But is that always going to be the case? Maybe not. And if it is, may I include constructors to convert a set of 3-vectors to a matrix? Or a set of Euler angles, or quaternions? If I demand that the matrix must be orthonormal, I'd better not try to create one from vectors.   For that matter, if I'm dealing exclusively with rotation matrices, maybe I need a function to make sure they stay orthonormal.   Here's why. When we're writing dynamic simulations involving rotations, we have to numerically integrate the elements that make up the state vector. If one of those elements is a rotation matrix (or equivalent structure), numerical roundoff errors can cause the matrix to drift away from its nominally orthonormal state. Those of us who write such simulations often include functions to re-normalize the matrix. It's not an easy thing to do, and doing it in an optimal way is even harder.   So a re-normalizing function is going to be almost a necessity for rotation matrices, but it's going to look really, really strange in a general-purpose matrix package—even one specialized to 3×3 matrices.   Of course, you know the conceptual solution to problems such as this: inheritance. Write a C++ base class for 3×3 matrices. Then define a derived class that specializes the class even further, to rotation matrices. Most of the operations will be the same, but a few functions, such as re-normalization, can be added, and the inverse function can be changed to invoke the simpler transpose function.   There's only one problem with this approach. A rotation in 3-space is a very unique thing, and the function that it performs is vastly different from the more generic matrix product. Heck, the member data for a "rotation matrix" need not even include a matrix. Rotations can also be described by a quaternion or a set of Euler angles.   And because there are three possible ways to describe the rotation, we're also going to need conversion functions to transform one set of descriptors to another.   FYI, a couple of years ago I wrote a library of Matlab functions capable of converting between angle, matrix, and quaternion representations. In doing so, I even surprised myself, coming up with killer algorithms that resulted in code that was tight, accurate, and bulletproof. I'll be sharing the algorithms with you soon.   Most people who work every day with rotation-related problems choose the quaternion, because it's more efficient to do so (no angles involved, and fewer elements to store). One has to ask: what's the point having a rotation matrix be a derived class of the 3×3 matrix, if it doesn't even hold a matrix anywhere in its structure?   Off and on, I've wrestled with questions like this many times. I can't say that I've ever come up with the definitive solution. More often, I find myself in need of that priority interrupt.   But this time, I've finally got the structure I need. The trick is, there should be no class called RotationMatrix . Instead, there's a class called Rotation . When applied to a vector or another matrix (or Rotation ), the operation may look like a matrix product, but the appearance is only superficial. Internally, a Rotation should be a separate type of object, worthy of its own class. Heck, it may not—and probably won't—even have a matrix as part of its member data. And in the best tradition of object-oriented programming, the way the rotation class is implemented should be transparent to the user. If I decide to change the internal representation from matrix to quaternion, that decision shouldn't matter one iota to users of the class.   When you think about it, the fact that I can define a rotation operation that looks like a matrix product is no different than defining products of integers or real numbers. I can declare:   int i, j, k; double x, y, z; Vector X, Y; Matrix A; Rotation R;   and write:   k = i*j; z = x*y; Y = A*X; Y = R*X;   Yes, the statements look the same and mean much the same. That's the elegance of operator overloading, and it makes life incredibly easy for the programmer. But we have no particular reason for a rotation object to inherit the '*' operator from a matrix, any more than we might have it do so from class int . Separating the class Rotation into a full-blown separate class is beginning to make a lot of sense.   Wrapping up I'm glad we had this little talk. So often in life, I've found that as I try to explain a knotty problem to someone else, I realize that I suddenly know the solution. That seems to be what has happened here. Thanks for listening.

This is going to be a different kind of article for me. As I was planning it, I considered several possible topics. I couldn't decide which one to cover, so I decided to cover them all. You may find some of them incomplete—I'm giving you my thoughts as I'm having them. I welcome your thoughts and comments.   Vector/Matrix class redux Whenever I set out to (re)create a vector/matrix math package, I always wrestle with the decision: should I include separate functions for the special case where the vectors are dimensioned 3, and the matrices, 3×3? Clearly, classes that can handle general, n-dimensional vectors and m × n matrices can also handle the case m = n = 3. On the other hand, it's certain that if we know in advance the dimensions of the objects, the code will be a little faster and more compact.   While it's important to be able to deal with general forms of the mathematical entities called vectors and matrices, there's a good argument for the specialized functions as well.   We live, after all, in a three-dimensional universe (unless your field is String Theory). Most of the computations I do—space mechanics, rocket and aircraft dynamics, robotics, dynamic simulations—involve the motions of real, physical bodies in this three-dimensional space. It's the discipline called dynamics, whose math is defined by Newton's laws of motion.   The mathematical entities called vectors and matrices weren't exactly invented specifically to deal with physics problems, but they might as well have been. The simplifications that result from their use in physical problems is so profound, it's hard to over-emphasize the point.   That being the case, I'm always tempted to define special computer functions to process 3-d vectors and matrices. Usually I succumb to the temptation. When I was developing the C++ classes called Vector and Matrix , I wrestled with the same decision. For the sake of brevity, I chose to omit the special 3-d case. For the column, I was focused more on showing you the principles rather than defining a production-quality library of functions.   However, the argument for the special case is even stronger than usual, when defining C++ classes. That's because my general-case solutions required dynamic memory allocation .   If you declare all named objects statically, you can move most of the memory allocations to the initialization phase of the programs. We might do this, for example, when writing flight software for a satellite or missile.   But if you make use of those lovely overloaded operators, you can't avoid the creation of temporary objects, and the overhead to construct and destruct them.   Finally, there's the issue of the vector cross product, which only works for 3-vectors. In our n-vector class, I had to include tests to make sure that both vectors were, in fact, dimensioned 3. That's not a problem in the special case. (Optional for extra credit: some of us gurus in the know, know that the cross product isn't really limited to 3-vectors. There's a 4-d cross product as well. If you're "one of us," drop me a line. Say the magic word, "quaternion," and I'll send you the Secret Decoder Ring Tone.)   If we know in advance that all the vectors will be dimensioned 3, and matrices, 3×3, the double dose of dynamic allocation goes away.   The situation with respect to matrices is even nicer. If you followed the creation of the Matrix class, you'll recall that we struggled with the issue of allocating matrices with arbitrary dimensions. Because C/C++ doesn't support conformant arrays, we can't just declare the array data in the form:   double x ;   Instead, we had to resort to defining a single-dimensioned array and generating our own code to index into it. This isn't a problem for the 3×3 case. We simply declare the array:   double x ;   and let the compiler use its own indexing, presumably optimized out the gazoo.   Recently, I had occasion to do a lot of computations in the 3-d universe. So I succumbed to the temptation and wrote a new C++ class called ThreeVec . As the name implies, the class is specialized to the case of 3-d vectors. I'm going to show it to you, but in a rather unconventional way. Instead of walking you through all the design decisions yet again one more time, I'm simply going to post the files on Embedded.com. I think you'll find that the differences between the n-vector and 3-vector cases are straightforward enough so that you won't need me leading you by the hand. Please let me know if you need more help.   Do something ... For the same project, I also need a class for 3×3 matrices. I'll tell you about it soon, but first I have a confession to make. I have a character flaw (No! Really?).   I'm basically an optimizing sort of fellow. Before I do anything, I tend to look at the options, weigh them carefully, and choose the one that's, in some sense, optimal. I'm the guy who tries to guess which lane I should be in at a traffic light. There's no malice involved, no jamming my way in front of someone else. But given a choice, I'll choose the option that's most likely to get me where I'm going sooner with fewer hassles.   This tendency to optimize can be both a blessing and a curse. A blessing in that the code I generate is usually pretty good. A curse because it takes me longer to produce it. Because I'm looking for the best solution, I can never keep up with the software wizard who simply codes the first thought that comes to him.   In another lifetime, I built and raced midget cars. My kids also raced, and I was their chief mechanic. Naturally, optimizing the route to the front is a good habit for a driver, and I was pretty good at it. But optimization is also good when deciding how best to tune or modify the car. When it came time to make a modification, I'd find myself spending considerable time trying to optimize the design. The design optimization process goes something like this:   while(1){ if(option(a) option(b)) return a; if(option(b) option(a)) return b; }   The problem, of course, is that there's no predicate for equality. If I can't find a clear reason to choose one option over the other, I'm paralyzed into inaction, stuck in an infinite loop.   This sometimes happened when I was planning a new modification. I'd sit in the garage, holding the parts I could use, and literally weighing my options. I'd look at the parts in one hand, and see advantages in using them, but also disadvantages. I'd look at the other and see a different sets of pros and cons. I could find no clear winner.   Fortunately, my decision-making system had a priority interrupt. Not hearing any work being done, my wife would open the door behind me. She'd shout, "Do something, even if it's wrong!!!" and slam the door again. This interrupt was usually enough to jog me out of the loop.