Brain Dumps

发信人: xixihaha2008 (回国出差), 信区: Love 标  题: 爱恋和婚姻幸福的几个关键点 发信站: BBS 未名空间站 (Sat Nov 17 13:35:46 2012, 美东) 听朋友说，爱恋和婚姻幸福的几个关键点　和大家分享－－ （１）真正的善良，正直，有正义感和同情心；       这个是其人品的关键 (无论男女） 中国人婚恋找对象还停留在还什么只看皮相的奴隶社会阶段，真的很可怜，　 我有的时候，一见男生／女生用比美比帅来找对象，就觉得很可笑。。。 皮相＼的吸引，只有三到六个月的热度，然后日子不过啦？　哈哈。。。 而且只看重皮相的人往往很虚荣，希望对方的外貌给其自身带来荣耀。。。 只有有重情意的人，才适合恋爱结婚，才能禁得起时间和风雨的考验。。。 ---信息时代，各种认识的人越来越多，诱惑也逐渐增大，　 ---各种变动增加－－现在经济这么不好，如果一方工资变低或者短暂失业；                －－或者由Local 变为成为LD；　                －－或者有任何突发的疾病或变故； 是否另一半还是一如既往的感情好, 就看修养和人品问题 （２）有主见和辨别力；        而不是人云亦云，听风就是雨，　        用自己的眼睛和心灵去观察世界，才能减少生活不必要的矛盾，让生活更和谐 。。。       （３）有很好的沟通能力，可以站在对方的角度看问题；        有任何矛盾和问题不要紧--关键看两个人是否能很好的沟通和交流，　         能很好的彼此妥协，将事情平衡解决, 才是增加幸福感的源泉。。。 （４）有责任感。。。

Item 44: Say what you mean; understand what you're saying. In the introduction to this section on inheritance and object-oriented design, I emphasized the importance of understanding what different object-oriented constructs in C++ mean. This is quite different from just knowing the rules of the language. For example, the rules of C++ say that if class D publicly inherits from class B, there is a standard conversion from a D pointer to a B pointer; that the public member functions of B are inherited as public member functions of D, etc. That's all true, but it's close to useless if you're trying to translate your design into C++. Instead, you need to understand that public inheritance means isa, that if D publicly inherits from B, every object of type D isa object of type B, too. Thus, if you mean isa in your design, you know you have to use public inheritance. Saying what you mean is only half the battle. The flip side of the coin is understanding what you're sayi

Item 41: Differentiate between inheritance and templates. Consider the following two design problems:  Being a devoted student of Computer Science, you want to create classes representing stacks of objects. You'll need several different classes, because each stack must be homogeneous, i.e., it must have only a single type of object in it. For example, you might have a class for stacks of ints, a second class for stacks of strings, a third for stacks of stacks of strings, etc. You're interested only in supporting a minimal interface to the class (see Item 18), so you'll limit your operations to stack creation, stack destruction, pushing objects onto the stack, popping objects off the stack, and determining whether the stack is empty. For this exercise, you'll ignore the classes in the standard library (including stack ? see Item 49), because you crave the experience of writing the code yourself. Reuse is a wonderful thing, but when your goal is a deep understanding of

Item 38: Never redefine an inherited default parameter value. Let's simplify this discussion right from the start. A default parameter can exist only as part of a function, and you can inherit only two kinds of functions: virtual and nonvirtual. Therefore, the only way to redefine a default parameter value is to redefine an inherited function. However, it's always a mistake to redefine an inherited nonvirtual function (see Item 37), so we can safely limit our discussion here to the situation in which you inherit a virtual function with a default parameter value. That being the case, the justification for this Item becomes quite straightforward: virtual functions are dynamically bound, but default parameter values are statically bound. What's that? You say you're not up on the latest object-oriented lingo, or perhaps the difference between static and dynamic binding has slipped your already overburdened mind? Let's review, then. An object's static type is the ty

Item 37: Never redefine an inherited nonvirtual function. There are two ways of looking at this issue: the theoretical way and the pragmatic way. Let's start with the pragmatic way. After all, theoreticians are used to being patient. Suppose I tell you that a class D is publicly derived from a class B and that there is a public member function mf defined in class B. The parameters and return type of mf are unimportant, so let's just assume they're both void. In other words, I say this: class B { public: void mf(); ... }; class D: public B { ... }; Even without knowing anything about B, D, or mf, given an object x of type D, D x; // x is an object of type D you would probably be quite surprised if this, B *pB = &x; // get pointer to x pB->mf(); // call mf through pointer behaved differently from this: D *pD = &x; // get pointer to x pD->mf(); // call mf through pointer That's because in both cases you're invoking the member function mf on the object x.

1. 指数长期永远是向上的，不易被操控的，不断被更新的，而且有政府托着的。 2. 散户为什么赔钱：因为你的对家是华尔街的数学精英+超级电脑。而且在交易费，交 易速度，信息不对称上散户占很大劣势。如果你觉得你比他们牛，可以试试看。散户唯 一的优势是能耗，用时间冲销华尔街的短期震荡。 我过去几年除了期货没动过，其他 的都试过了，long， short，option，裸卖option，赌er，赌消息。基本就是小赚，小 赚，小赚，然后来个大亏。

最近几个月特别忙，一边是手下照顾着好几百号人，另一边是一个新成立的部门，所有工作从零做起， 丝毫不敢怠慢。另外也担心在网上招惹你们会影响到我的工作，所以干脆就没更新博客，只潜水，不发 文。不过这并不代表我已离开科学网，兄弟我在这里混得这么开心，为啥要离开啊？ 今天接到科学网编辑部的电话，邀我做15日中午的访谈，题目叫“逃离”科研。为啥找我？约莫是因为 兄弟我正属于那“逃离”的人，刚巧算个反面教材吧？ 晚上又看到陈安老师给我做的广告，说我是离开科研，彻底不回头的人。我自省一下，概念有些模糊， 我确是没有选择科研岗位的人，按理说应属科研的叛徒，但依稀间仿佛也没彻底决断，背地里和书本还 有些藕断丝连。这状况之于我个人而言，恐怕也只是在摸索中前进，就像现在的祖国，要走有特色的道 路。不过话说回来，不做教授就一定等同于不做科研吗？以及，做教授的人，就一定在做科研吗？这话 不用多说，你们心里有数。 说起我为何没选择科研岗，这话太长，原因太多，大部分不能说，能说的都不是重要的。不过还是挑几 个满足一下朋友们的好奇心： 1、我只做自己喜欢的研究，但遗憾的是我喜欢的东西都巨冷门，冷到自己看了自己的题目都直打哆嗦。 当然，做科研，冷门与否并不重要，只要你能做出世界级的成果，发表在世界一流刊物上，你也照样牛 逼哄哄的。可问题是，哥做不到，哥着急连个SCI都发不出来，所以一直不怎么受人待见。 2、我读物理十年，选个专业叫理论物理。这十年里每碰到一个中国人，当他听到我的专业名称时，都必 问三个问题：（1）理论物理有用吗？（2）选这个专业好找工作吗？（3）你读理论物理，你的爹妈谁来 养？对这三个问题，我的答案都是：（1）没用。（2）不好找。（3）没法养。 于是对方马上抛来一道附加题：那你为什么还选这个专业？ 我说：因为我喜欢。 对方说：你真是有病。 十年，国人千万次的问，我做了千万次的病人。好烦啊。于是乎有一天我也失去了耐心，当别人问我学 什么专业时，我不说我学物理，我说我学的是财务料理，简称务理。对方一听有个财字，仿佛明白了什 么，便不再追问，我也落个清静。 不过在独自一人的时候，我也渐渐觉得，理论物理这东西，确实不创造什么能看得见摸得着的价值，对 于改善这个国家的人民生活而言，并无太多眼前的用处。从这角度讲，花纳税人的钱去发些不能提高人 民生活水平的文

发信人: letmebethe1 (Love Hurts), 信区: NewYork 标  题: 留美生活省钱+理财+股票 发信站: BBS 未名空间站 (Sat Sep 17 23:28:28 2011, 美东) 写这篇文章的时候 参考了很多筒子们的帖子，最后经过整理出炉本文，希望对大家有 帮助。当然我的水平有待提高，有什么不妥的地方欢迎大家指正！ 以前写过关于留美省钱的文章，11年到了在n多亲朋好友的推荐下有了新想法：钱 这个 玩意，是省下来，也是挣出来的。 一路走来，我的省钱理财计划磕磕碰碰，坎坎坷坷 ，到今天终于悟出了一条比较完美的留美省钱理财大作战，公告于后人。写给想省钱理 财的同学。 1. 用一年的时间省下你第一个1万美元。 每个月计划必要的生活费和一定的零花钱剩下的钱不要放在接近0利率银行的saving account，存到high yield saving里吧 利率1.3%左右。（假如你的奖学金税后1800刀 ，你自己吃喝住一个月600-700刀，你给自己零花钱200刀，于是你可以每个月定期把剩 下的900刀存到high yield saving里面） 常见的high yield saving 比如 discover online banking, AE bank... 这个网址 给出了全部high yield saving 信息 你可以选择适合你并且方便的http://www.depositaccounts.com/savings/ （我选择的是discover online banking, 但AE个人也觉得很不错的） 2. 买东西请讲求方法并且节制一点吧！ 不要动不动就去逛shopping center 我们女人就是一逛街就想买这买那，最后落得月光 族的悲惨下场。outlet的价格是shopping center的一半。女生买化妆品，记得一定要 多问问：有没有赠品，有没有promotion? 否则老美是不会主动把赠品给你的。 我比较喜欢的购物方式是网购，因为方便，而且省钱，尤其是借助一些cashback的网站 ，比如www.ebates.con, www.rulala.com此外还有很多类似的网站有待大家挖掘哦~ 3. 申请信用卡和bank account的时候讲求合适的时机 银行开户

Item 36: Differentiate between inheritance of interface and inheritance of implementation. The seemingly straightforward notion of (public) inheritance turns out, upon closer examination, to be composed of two separable parts: inheritance of function interfaces and inheritance of function implementations. The difference between these two kinds of inheritance corresponds exactly to the difference between function declarations and function definitions discussed in the Introduction to this book. As a class designer, you sometimes want derived classes to inherit only the interface (declaration) of a member function; sometimes you want derived classes to inherit both the interface and the implementation for a function, but you want to allow them to override the implementation you provide; and sometimes you want them to inherit both interface and implementation without allowing them to override anything. To get a better feel for the differences among these options, consider a class hierarch

Item 32: Postpone variable definitions as long as possible. So you subscribe to the C philosophy that variables should be defined at the beginning of a block. Cancel that subscription! In C++, it's unnecessary, unnatural, and expensive. Remember that when you define a variable of a type with a constructor or destructor, you incur the cost of construction when control reaches the variable's definition, and you incur the cost of destruction when the variable goes out of scope. This means there's a cost associated with unused variables, so you want to avoid them whenever you can. Suave and sophisticated in the ways of programming as I know you to be, you're probably thinking you never define unused variables, so this Item's advice is inapplicable to your tight, lean coding style. You may need to think again. Consider the following function, which returns an encrypted version of a password, provided the password is long enough. If the password is too short, the functio

Item 29: Avoid returning "handles" to internal data. A scene from an object-oriented romance: Object A: Darling, don't ever change! Object B: Don't worry, dear, I'm const. Yet just as in real life, A wonders, "Can B be trusted?" And just as in real life, the answer often hinges on B's nature: the constitution of its member functions. Suppose B is a constant String object: class String { public: String(const char *value); ~String(); // // // // operator char *() const; see Item 11 for pos- sible implementations; see Item M5 for comments on the first constructor // convert String -> char*; // see also Item M5 ... private: char *data; }; const String B("Hello World"); // B is a const object Because B is const, it had better be the case that the value of B now and evermore is "Hello World". Of course, this supposes that programmers working with B are playing the game in a civilized fashion. In particul

Item 28: Partition the global namespace. The biggest problem with the global scope is that there's only one of them. In a large software project, there is usually a bevy of people putting names in this singular scope, and invariably this leads to name conflicts. For example, library1.h might define a number of constants, including the following: const double LIB_VERSION = 1.204; Ditto for library2.h: const int LIB_VERSION = 3; It doesn't take great insight to see that there is going to be a problem if a program tries to include both library1.h and library2.h. Unfortunately, outside of cursing under your breath, sending hate mail to the library authors, and editing the header files until the name conflicts are eliminated, there is little you can do about this kind of problem. You can, however, take pity on the poor souls who'll have your libraries foisted on them. You probably already prepend some hopefully-unique prefix to each of your global symbols, but surely you must a

Item 27: Explicitly disallow use of implicitly generated member functions you don't want. Suppose you want to write a class template, Array, whose generated classes behave like built-in C++ arrays in every way, except they perform bounds checking. One of the design problems you would face is how to prohibit assignment between Array objects, because assignment isn't legal for C++ arrays: double values1[10]; double values2[10]; values1 = values2; // error! For most functions, this wouldn't be a problem. If you didn't want to allow a function, you simply wouldn't put it in the class. However, the assignment operator is one of those distinguished member functions that C++, always the helpful servant, writes for you if you neglect to write it yourself (see Item 45). What then to do? The solution is to declare the function, operator= in this case, private. By declaring a member function explicitly, you prevent compilers from generating their own version, and by making th

Item 26: Guard against potential ambiguity. Everybody has to have a philosophy. Some people believe in laissez faire economics, others believe in reincarnation. Some people even believe that COBOL is a real programming language. C++ has a philosophy, too: it believes that potential ambiguity is not an error. Here's an example of potential ambiguity: class B; class A { public: A(const B&); // forward declaration for // class B // an A can be // constructed from a B }; class B { public: operator A() const; // a B can be // converted to an A }; There's nothing wrong with these class declarations ? they can coexist in the same program without the slightest trouble. However, look what happens when you combine these classes with a function that takes an A object, but is actually passed a B object: void f(const A&); B b; f(b); // error! ? ambiguous Seeing the call to f, compilers know they must somehow come up with an object of type A, even though what they have in hand is an

Item 22: Prefer pass-by-reference to pass-by-value. In C, everything is passed by value, and C++ honors this heritage by adopting the pass-by-value convention as its default. Unless you specify otherwise, function parameters are initialized with copies of the actual arguments, and function callers get back a copy of the value returned by the function. As I pointed out in the Introduction to this book, the meaning of passing an object by value is defined by the copy constructor of that object's class. This can make pass-by-value an extremely expensive operation. For example, consider the following (rather contrived) class hierarchy: class Person { public: Person(); // parameters omitted for // simplicity ~Person(); ... private: string name, address; }; class Student: public Person { public: Student(); // parameters omitted for // simplicity ~Student(); ... private: string schoolName, schoolAddress; }; Now consider a simple function returnStudent that takes a Student argument (by va

第一季 第一集【超清】 www.6park.com 第一季 第二集【超清】 www.6park.com 第一季 第三集【HD】 www.6park.com 第一季 第四集【HD】 www.6park.com 第一季 第五集【HD】 www.6park.com 第一季 第六集【HD】 第一季完结 www.6park.com

What exactly does it mean for a member function to be const? There are two prevailing notions: bitwise constness and conceptual constness. The bitwise const camp believes that a member function is const if and only if it doesn't modify any of the object's data members (excluding those that are static), i.e., if it doesn't modify any of the bits inside the object. The nice thing about bitwise constness is that it's easy to detect violations: compilers just look for assignments to data members. In fact, bitwise constness is C++'s definition of constness, and a const member function isn't allowed to modify any of the data members of the object on which it is invoked. Unfortunately, many member functions that don't act very const pass the bitwise test. In particular, a member function that modifies what a pointer points to frequently doesn't act const. But if only the pointer is in the object, the function is bitwise const, and compilers won't complain.