请问：从事IT行业，是不是找同行的男朋友更好？？？MM的烦恼！！！
一直在犹豫，是不是一定要找个程序员？？？如果他不是程序员，我就不可能认为他是优秀的，有了这种思想，就不敢与非程序员交往啦，可要找一个好程序员，真难！！！:( 问题点数：50、回复次数：78Top
1 楼eternalee（看看）回复于 2001-10-08 19:31:34 得分 0
看看
Top
2 楼clinfo（疯狂者）回复于 2001-10-08 19:37:00 得分 0
晕了。。。
Top
3 楼Only_I（我）回复于 2001-10-08 19:42:59 得分 10
me,it's me!Top
4 楼hello770725（hello）回复于 2001-10-08 20:08:04 得分 0
to clinfo:为什么要晕啦？？？
我一同学就与我讨论过这个问题，得出结论：找同行的好，你不这么认为吗？？？Top
5 楼Only_I（我）回复于 2001-10-08 20:13:44 得分 0
I want to be ...Top
6 楼eternalee（看看）回复于 2001-10-08 20:14:16 得分 0
比我还大，看来我是不成啦
Top
7 楼Only_I（我）回复于 2001-10-08 20:18:30 得分 0
give me your ...Top
8 楼clinfo（疯狂者）回复于 2001-10-08 20:30:53 得分 0
reply hello770725(hello)
好是好，但程序员没有情趣，少一些浪漫。。。
怕你不能适应。因为大部分人是上午睡觉，下午晚上工作。
Top
9 楼renyuanhu（人平）回复于 2001-10-08 20:41:12 得分 0
说的很对，我现在就是的，上午上课一直在睡，下午没课了，反而做在电脑上一直到深夜！
哈哈~~
你还是找一个程序员吧！
比较实际的！
嘻嘻~~~！Top
10 楼hello770725（hello）回复于 2001-10-08 20:48:05 得分 0
to Only_I:are you .......Top
11 楼clinfo（疯狂者）回复于 2001-10-08 20:51:55 得分 0
程序员真的很像妓女耶。。。
TMD。妓女也是上午睡觉，下午晚上做生意。
我靠。Top
12 楼lithium（里怒西）回复于 2001-10-08 21:00:26 得分 0
找程序员干嘛，找个经理多好Top
13 楼Only_I（我）回复于 2001-10-08 21:07:05 得分 0
Boy!I am a boy!Top
14 楼Only_I（我）回复于 2001-10-08 21:09:10 得分 0
数学的逻辑有时会导致看来十分怪异的结论。一般的规则是，如果逻
辑推理没有漏洞，
那么结论就必定站得住脚，即使它与你的直觉矛盾。 1998年9月，加
利福尼亚州帕洛阿
尔托的Stephen M. Omohundro寄给我一道难题，它恰好就属于这一类
。这难题已经流传
了至少十年，但是Omohundro对它作了改动，使它的逻辑问题变得分
外复杂了。
先来看看此难题原先的形状。10名海盗抢得了窖藏的100块金子，并
打算瓜分这些战利
品。这是一些讲民主的海盗（当然是他们自己特有的民主），他们的
习惯是按下面的方
式进行分配：最厉害的一名海盗提出分配方案，然后所有的海盗（包
括提出方案者本
人）就此方案进行表决。如果50%或更多的海盗赞同此方案，此方案
就获得通过并据此
分配战利品。否则提出方案的海盗将被扔到海里，然后下提名最厉害
的海盗又重复上述
过程。
所有的海盗都乐于看到他们的一位同伙被扔进海里，不过，如果让他
们选择的话，他们
还是宁可得一笔现金。他们当然也不愿意自己被扔到海里。所有的海
盗都是有理性的，
而且知道其他的海盗也是有理性的。此外，没有两名海盗是同等厉害
的——这些海盗按
照完全由上到下的等级排好了座次，并且每个人都清楚自己和其他所
有人的等级。这些
金块不能再分，也不允许几名海盗共有金块，因为任何海盗都不相信
他的同伙会遵守关
于共享金块的安排。这是一伙每人都只为自己打算的海盗。
最凶的一名海盗应当提出什么样的分配方案才能使他获得最多的金子
呢？
为方便起见，我们按照这些海盗的怯懦程度来给他们编号。最怯懦的
海盗为1号海盗，
次怯懦的海盗为2号海盗，如此类推。这样最厉害的海盗就应当得到
最大的编号，而方
案的提出就将倒过来从上至下地进行。
分析所有这类策略游戏的奥妙就在于应当从结尾出发倒推回去。游戏
结束时，你容易知
道何种决策有利而何种决策不利。确定了这一点后，你就可以把它用
到倒数第2次决策
上，如此类推。如果从游戏的开头出发进行分析，那是走不了多远的
。其原因在于，所
有的战略决策都是要确定：“如果我这样做，那么下一个人会怎样做
？” 因此在你以
下海盗所做的决定对你来说是重要的，而在你之前的海盗所做的决定
并不重要，因为你
反正对这些决定也无能为力了。
记住了这一点，就可以知道我们的出发点应当是游戏进行到只剩两名
海盗——即1号和2
号——的时候。这时最厉害的海盗是2号，而他的最佳分配方案是一
目了然的：100块金
子全归他一人所有，1号海盗什么也得不到。由于他自己肯定为这个
方案投赞成票，这
样就占了总数的50%，因此方案获得通过。
现在加上3号海盗。1号海盗知道，如果3号的方案被否决，那么最后
将只剩2个海盗，而
1号将肯定一无所获——此外，3号也明白1号了解这一形势。因此，
只要3号的分配方案
给1号一点甜头使他不至于空手而归，那么不论3号提出什么样的分配
方案，1号都将投
赞成票。因此3号需要分出尽可能少的一点金子来贿赂1号海盗，这样
就有了下面的分配
方案： 3号海盗分得99块金子，2号海盗一无所获，1号海盗得1块金
子。
4号海盗的策略也差不多。他需要有50%的支持票，因此同3号一样也
需再找一人做同
党。他可以给同党的最低贿赂是1块金子，而他可以用这块金子来收
买2号海盗。因为如
果4号被否决而3号得以通过，则2号将一文不名。因此，4号的分配方
案应是：99块金子
归自己，3号一块也得不到，2号得1块金子，1号也是一块也得不到。
5号海盗的策略稍有不同。他需要收买另两名海盗，因此至少得用2块
金子来贿赂，才能
使自己的方案得到采纳。他的分配方案应该是：98块金子归自己，1
块金子给3号，1块
金子给1号。
这一分析过程可以照着上述思路继续进行下去。每个分配方案都是唯
一确定的，它可以
使提出该方案的海盗获得尽可能多的金子，同时又保证该方案肯定能
通过。照这一模式
进行下去，10号海盗提出的方案将是96块金子归他所有，其他编号为
偶数的海盗各得1
块金子，而编号为奇数的海盗则什么也得不到。这就解决了10名海盗
的分配难题。
Omohundro的贡献是他把这一问题扩大到有500名海盗的情形，即500
名海盗瓜分100块金
子。显然，类似的规律依然成立——至少是在一定范围内成立。事实
上，前面所述的规
律直到第200号海盗都成立。 200号海盗的方案将是：从1到199号的
所有奇数号的海盗
都将一无所获，而从2到198号的所有偶数号海盗将各得1块金子，剩
下的1块金子归200
号海盗自己所有。
乍看起来，这一论证方法到200号之后将不再适用了，因为201号拿不
出更多的金子来收
买其他海盗。但是即使分不到金子，201号至少还希望自己不会被扔
进海里，因此他可
以这样分配：给1到199号的所有奇数号海盗每人1块金子，自己一块
也不要。
202号海盗同样别无选择，只能一块金子都不要了——他必须把这100
块金子全部用来收
买100名海盗，而且这100名海盗还必须是那些按照201号方案将一无
所获的人。由于这
样的海盗有101名，因此202号的方案将不再是唯一的——贿赂方案有
101种。
203号海盗必须获得102张赞成票，但他显然没有足够的金子去收买10
1名同伙。因此，
无论提出什么样的分配方案，他都注定会被扔到海里去喂鱼。不过，
尽管203号命中注
定死路一条，但并不是说他在游戏进程中不起任何作用。相反，204
号现在知道，203号
为了能保住性命，就必须避免由他自己来提出分配方案这么一种局面
，所以无论204号
海盗提出什么样的方案，203号都一定会投赞成票。这样204号海盗总
算侥幸拣到一条命
：他可以得到他自己的1票、203号的1票、以及另外100名收买的海盗
的赞成票，刚好达
到保命所需的50%。获得金子的海盗，必属于根据202号方案肯定将一
无所获的那101名
海盗之列。
205号海盗的命运又如何呢？他可没有这样走运了。他不能指望203号
和204号支持他的
方案，因为如果他们投票反对205号方案，就可以幸灾乐祸地看到205
号被扔到海里去喂
鱼，而他们自己的性命却仍然能够保全。这样，无论205号海盗提出
什么方案都必死无
疑。206号海盗也是如此——他肯定可以得到205号的支持，但这不足
以救他一命。类似
地，207号海盗需要104张赞成票——除了他收买的100张赞成票以及
他自己的1张赞成票
之外，他还需3张赞成票才能免于一死。他可以获得205号和206号的
支持，但还差一张
票却是无论如何也弄不到了，因此207号海盗的命运也是下海喂鱼。
208号又时来运转了。他需要104张赞成票，而205、206、207号都会
支持他，加上他自
己一票及收买的100票，他得以过关保命。获得他贿赂的必属于那些
根据204号方案肯定
将一无所获的人（候选人包括2到200号中所有偶数号的海盗、以及20
1、203、204
号）。
现在可以看出一条新的、此后将一直有效的规律：那些方案能过关的
海盗（他们的分配
方案全都是把金子用来收买100名同伙而自己一点都得不到）相隔的
距离越来越远，而
在他们之间的海盗则无论提什么样的方案都会被扔进海里——因此为
了保命，他们必会
投票支持比他们厉害的海盗提出的任何分配方案。得以避免葬身鱼腹
的海盗包括201、
202、204、208、216、232、264、328、456号，即其号码等于200加2
的某一方幂的海
盗。
现在我们来看看哪些海盗是获得贿赂的幸运儿。分配贿赂的方法是不
唯一的，其中一种
方法是让201号海盗把贿赂分给1到199号的所有奇数编号的海盗，让2
02号分给2到200
号的所有偶数编号的海盗，然后是让204号贿赂奇数编号的海盗，208
号贿赂偶数编号的
海盗，如此类推，也就是轮流贿赂奇数编号和偶数编号的海盗。
结论是：当500名海盗运用最优策略来瓜分金子时，头44名海盗必死
无疑，而456号海盗
则给从1到199号中所有奇数编号的海盗每人分1块金子，问题就解决
了。由于这些海盗
所实行的那种民主制度，他们的事情就搞成了最厉害的一批海盗多半
都是下海喂鱼，不
过有时他们也会觉得自己很幸运——虽然分不到抢来的金子，但总可
以免于一死。只有
最怯懦的200名海盗有可能分得一份脏物，而他们之中又只有一半的
人能真正得到一块
金子，的确是怯懦者继承财富。 Top
15 楼Only_I（我）回复于 2001-10-08 21:11:15 得分 0
Standard C++ Programming: Virtual Functions and Inlining
Josée Lajoie and Stanley Lippman
--------------------------------------------------------------------------------
[This is the last installment of a column that was being published in C++ Report magazine. Since the magazine ceased publication before this installment could be published, Josée Lajoie and Stan Lippman were gracious enough to let us publish it on the CUJ website. — mb]
At one time, a common question that we used to hear when speaking on C++ was, "Should a virtual function really be declared inline?" These days, we hardly ever hear that question. Rather, what we hear now is "You shouldn抰 have made print inline. It抯 wrong to declare a virtual function inline."
The two primary reasons for taking this position are (1) virtual functions are resolved at run-time while the inline facility is a compile-time mechanism, so there is nothing to be gained by the declaration; and (2) declaring a virtual function inline results in multiple copies of the function being defined within our executable, so we pay a space penalty for a function that can抰 be inlined in any case. An obvious no-brainer.
Only that抯 not really true. Let抯 take item (1) first: there are many cases in which a virtual function is resolved statically — essentially any time a derived class virtual method invokes the method of its base class(es). Why would one do that? Encapsulation. A good example is the static invocation chain of base class destructors triggered by the virtual resolution of a derived class destructor. All the destructor calls except for the initial resolution are resolved statically. Without making the base class virtual destructors inline, we cannot take advantage of this. Does it make much of a difference? If the hierarchy is deep and there are many objects destructed, yes.
For another example that does not use destructors, imagine that we are designing a library lending material hierarchy. We抳e factored the material抯 location into the abstract LibraryMaterial class. While we declare its print function as a pure virtual function, we also provide a definition: it prints out the material抯 location.
class LibraryMaterial {
private:
MaterialLocation _loc; // shared data
// ...
public:
// declares pure virtual function
inline virtual void print( ostream& = cout ) = 0;
};
// we actually want to encapsulate the handling of the
// location of the material within a base class
// LibraryMaterial print() method - we just don抰 want it
// invoked through the virtual interface. That is, it is
// only to be invoked within a derived class print() method
inline void
LibraryMaterial::
print( ostream &os ) { os << _loc; }
Next we introduce a Book class; its print function outputs the title, author, and so on. Before this, it invokes the base class LibraryMaterial::print function to display the location information. For example,
inline void
Book::
print( ostream &os )
{
// ok, this is resolved statically,
// and therefore is inline expanded ...
LibraryMaterial::print();
os << "title:" << _title
<< "author" << _author << endl;
}
Our AudioBook class, derived from Book, introduces an alternative lending policy, and adds additional information such as narrator, format, and so on. These are displayed in its print function. Before this, it invokes Book::print(), which in turn, etc:
inline void
AudioBook::
print( ostream &os )
{
// ok, this is resolved statically,
// and therefore is inline expanded ...
Book::print();
os << "narrator:" << _narrator << endl;
}
In both this example and the example of the class destructor, the virtual method of the derived class incrementally expands on the functionality of its base class and involves a chain of invocations where only the initial invocation is resolved virtually. This unnamed hierarchical design pattern is significantly less effective if we never declare a virtual function to be inline.
What about the potential of code bloat cited in item (2)? Well, let抯 think about that. If we write,
LibraryMaterial *p =
new AudioBook( "Mason & Dixon",
"Thomas Pynchon", "Johnny Depp" );
// ...
p->print();
is this instance of print to be inlined? No, of course not. This has to be resolved at run-time through the virtual mechanism. Okay. Does it cause this instance of print to have its definition laid down? Also no. The call is transformed into something of the form:
// Pseudo C++ Code
// Possible transformation of p->print()
( *p->_vptr[ 2 ] )( p );
where 2 represents the location of print within the associated virtual function table. Because this call to print is done through the function pointer _vptr[2], the compiler cannot statically determine the location of the called function, and the function cannot be inlined.
Of course the definition of the inline virtual print function must appear somewhere in the executable for the code to run properly. That is, at least one definition is necessary in order for its address to be placed within the virtual table. How does the compiler decide when to generate that definition? One implementation strategy is to generate that definition at the same time the class virtual table is generated. That means that for each virtual table instance generated for a class, an instance of each inline virtual function is also generated.
Just how many virtual tables are actually generated within an executable for a class? Ah, well, that抯 a good question. The Standard makes requirements on the behavior of virtual functions; it does not make requirements on their implementation. Since the presence of a virtual table is not required by the Standard, obviously the Standard in turn makes no requirements on how the virtual table is handled or how many are generated. The optimal number, of course, is one. Stroustrup抯 original cfront implementation, for example, achieved that in most cases through cleverness. (Stan and Andy Koenig described the algorithm in the March 1990 C++ Report article, "Optimizing Virtual Tables in C++ Release 2.0.")
Moreover, the C++ Standard now requires that inline functions behave as though only one definition for an inline function exists in the program even though the function may be defined in different files. The new rule is that conforming implementations should behave as though only a single instance is generated. Once this aspect of the Standard is widely implemented, lingering concerns over potential code bloat from inline functions should disappear.
One of the tensions in the C++ community is the pedagogical need to present a simple checklist set of rules versus the practical need to apply rules judiciously based on the situational context. The former is a response to the complexity of the language; the latter, to the complexity of the solutions we need to construct. The problem of when to declare virtual functions inline is a good illustration of this tension.
--------------------------------------------------------------------------------
About the Authors
Stanley Lippman was the software Technical Director for the Firebird segment of Disney's Fantasia 2000. He was recently technical lead on the ToonShooter image capture and playback system under Linux for DreamWorks Feature Animation and consulted with the Jet Propulsion Laboratory. He is currently IT Training Program Chair for You-niversity.com, an e-learning training company. He can be reached at stanleyl@you-niversity, www.you-niversity.com, and www.objectwrite.com.
Josée Lajoie is currently doing her Master's degree in Computer Graphics at the University Waterloo. Previously, she was a member of the C/C++ compiler development team at the IBM Canada Laboratory and was the chair of the core language working group for the ANSI/ISO C++ Standard Committee. She can be reached at jlajoie@cgl.uwaterloo.ca. Top
16 楼rdtt（切·格瓦拉）回复于 2001-10-08 21:50:15 得分 0
你要想好拉？你以后找个programmer吃饭，睡觉的是干同样的事情
没点神秘，没新鲜，多了就无聊了，不过还是programmer 了解programmer
你干的事情他应该了解，从这点出发你应该要个programmer
不过我个人认为女的programmer都是花瓶Top
17 楼gs571（*人称二炮*）回复于 2001-10-08 22:33:35 得分 0
你好好想想吧！最好找个老板，然后再洗手不当proprammer了就是了！
生活总不能只停在一颗树上，有机会到别的树上去看看！Top
18 楼pine2515（poney）回复于 2001-10-08 23:20:22 得分 0
还是找个别的行业的吧，你会发现一片美好的天地，他会给你带来意想不到的惊喜，毕竟找工作伙伴和找男朋友不是一回事。。。。。。。。。。。。。。。。。。。Top
19 楼big_net（jasonking）回复于 2001-10-08 23:46:44 得分 0
感觉好就可以了！Top
20 楼wondful（莫名）回复于 2001-10-08 23:52:57 得分 0
我没找过男朋友，我没经验，对不起，我是男的。Top
21 楼MarkDong（）回复于 2001-10-09 15:07:44 得分 0
女programer想找男programer；可是男programer们,你们想找女programer吗？有谁见到能看的女programer吗？女programer几乎和恐龙是同义词。Top
22 楼smartboyme（淡泊明志，宁静致远）回复于 2001-10-09 15:32:55 得分 0
其实我想乐！
哈哈
不知道为什么Top
23 楼longlong3（long）回复于 2001-10-09 16:33:11 得分 0
不要找PROGRAMER
现在的网上什么都有，你放心吗？Top
24 楼jack_ffbb（）回复于 2001-10-09 16:37:08 得分 0
oh!my god!!!!!
和我差不多嘛!我到想找个programer girl!!!
Top
25 楼hello770725（hello）回复于 2001-10-09 17:49:54 得分 0
to Only_I:看来你的逻辑性是比我强，嘻嘻。。。。。。
to MarkDong:你的见识也太少了吧！！！
to smartboyme:不知道理由就能乐起来，属于乐观派吗？？？
to longlong3:你的理由太不充分了吧？？？
to jack_ffbb:想法一样，那朝着这个目标努力吧！！！（其实我是在鼓励自己！嘻）
Top
26 楼lzumcj（流水无情）回复于 2001-10-09 18:15:04 得分 0
程序员是最好的职业选择！Top
27 楼Only_I（我）回复于 2001-10-09 18:43:27 得分 0
你真的是女孩吗？
。。。。。。Top
28 楼CjiajiaPHP（游戲）回复于 2001-10-09 18:46:36 得分 0
同感
renyuanhu(>人浪之<)
不过，我喜欢程序员，又不过，我是boy!Top
29 楼selfhood（小雪）回复于 2001-10-09 19:13:52 得分 0
在一次晕了。Top
30 楼HighRugal（RUGAL）回复于 2001-10-09 19:46:03 得分 0
I'am a boy.
以后大概也会沦落为程序员吧.我理想中的GF应该是学国贸的.
呵呵--Top
31 楼caiyi9000（小猫）回复于 2001-10-09 19:46:24 得分 0
一帮无聊的变态！Top
32 楼rdtt（切·格瓦拉）回复于 2001-10-09 20:05:32 得分 0
丫的,我才不要我gf是个programmer丑陋就不说了关键她们
不知道自己丑(比如我的同学).你以后对着她说来说去还是老本
行.有什么意思啊,没一点浪漫.最好的是读外语的应该不错.
起码有点女人味嘛Top
33 楼hello770725（hello）回复于 2001-10-09 20:59:00 得分 0
to Only_I:当然是女的，你连这个都不信还来发言？？？
to rdtt:你也太小看人了吧？？？女程序员就丑吗？？？我怎么见到那么多漂亮的MM PROGAMMER,
Top
34 楼selfhood（小雪）回复于 2001-10-09 21:00:10 得分 0
管了好多水了Top
35 楼hello770725（hello）回复于 2001-10-09 21:00:11 得分 0
to all:丑美不能针对某个行业Top
36 楼QXLEE（Jh）回复于 2001-10-10 01:03:48 得分 10
哈哈 hello770725(hello)姐姐是一个测试员好像是吧，我见过你的帖子以前
：）
祝你早日找到如意郎君：）我要的是喜糖Top
37 楼mars884813（一帆）回复于 2001-10-10 01:15:42 得分 0
that i'm single ... Top
38 楼hello770725（hello）回复于 2001-10-10 08:50:32 得分 0
to QXLEE(我不后悔):可以改行嘛！！！嘻嘻。。。。。。
难得有人记住我！！！Top
39 楼leafzhou（）回复于 2001-10-10 09:22:39 得分 0
当然是找同行了，为什麽不找?Top
40 楼GrayWhite（灰白）回复于 2001-10-10 10:10:01 得分 0
哈哈，有趣Top
41 楼ddkc_c（ddkc_c）回复于 2001-10-10 10:40:51 得分 0
知道居里夫人和皮埃尔的故事吗？知道爱因斯坦的婚姻吗？朗之万的妻子吗？Top
42 楼ddkc_c（ddkc_c）回复于 2001-10-10 10:47:59 得分 10
我无法接受一个毫无共同语言的女友，很惨的啦Top
43 楼qqchen79（知秋一叶）回复于 2001-10-10 11:00:42 得分 0
hehe, 我的GF就是Programmer，还是同学。
我觉得没什么不好的，不会对你的工作时间有所抱怨，还可以分享你成功的喜悦。
但我觉得女孩子不适合长期从事程序员职业，工作压力太大了。
所以，建议hello770725(hello)：
找个程序员，你自己嘛，就可以有一些其它打算了。Top
44 楼wt13（饿狼．ＳＥＸ）回复于 2001-10-10 11:36:08 得分 0
还是不要找程序员了，以后两个人随便碰到什么事都要先算一下概率怎么样，吃了饭洗碗的时候还要两个人先分析用哪种算法速度最快。
到那时不头痛Ｓ才怪。Top
45 楼Only_I（我）回复于 2001-10-10 12:53:21 得分 0
我只是想啊!
唉！
可惜还没达到优秀！
还不合格啊！Top
46 楼rdtt（切·格瓦拉）回复于 2001-10-10 13:25:55 得分 10
何必呢。就是你问我们，我们的意见也是没用的用，
最后还是自己的决定，找个自己有感觉的，可靠的就可以了
不一定要象我这么帅（容许我骗骗自己）。帅哥通常没良心的
不过大家都是programmer的话，以后的家务谁有时间去打理呢？
万一不幸结婚了，孩子谁来照顾呢？？？没错吧
Top
47 楼richwang72（沧海一笑）回复于 2001-10-10 13:45:24 得分 0
一切随缘，又何必为自己画一个圈儿呢？
难道还会遇上一个自己心仪的人，就因为他不是PROGRAMMER而和他拜拜！Top
48 楼midholy（中圣医药集团）回复于 2001-10-10 13:47:15 得分 0
什么职业都行啦，只要爱你就可以了嘛。哈哈。Top
49 楼guowf（冰山上的来客）回复于 2001-10-10 14:20:53 得分 0
不要找programmer.
if(男朋友==programmer)
if (他负责的项目必须在1个月里面完成）
你在这个月里将享受不到生活的乐趣
Top
50 楼Only_I（我）回复于 2001-10-10 18:57:00 得分 0
rdtt
雇个保姆，不就结了Top
51 楼fatty（自由自在,随心所欲）回复于 2001-10-11 08:24:50 得分 0
程序员并不比别人高出一等啊!
只有菜鸟才说自己是程序员!
Top
52 楼lormee（老米）回复于 2001-10-11 14:36:05 得分 0
找程序员可以理解。不过要是你以后还是个programmer，那你们的生活就太可怕了。没人能有稳定的时间来顾家里的事了。Top
53 楼veryfree（任逍遥）回复于 2001-10-11 18:35:13 得分 0
征婚：本人愿意找一个女程序员为伴。哈哈！Top
54 楼lovec（敏捷小子）回复于 2001-10-11 20:20:43 得分 0
天,这个都要考虑,哎,败给你了,哎只怕做程序员得更累了,真实服了YOU,只要开心合得来就行Top
55 楼wangwang78（上海之春）回复于 2001-10-11 21:01:42 得分 0
随缘吧
有些事情是没法预先安排的！Top
56 楼wangwang78（上海之春）回复于 2001-10-11 21:02:46 得分 0
随缘吧
有些事情是没法预先安排的！Top
57 楼hello770725（hello）回复于 2001-10-12 17:49:59 得分 0
to lormee(老米):我倒是想改行！！！
to qqchen79(知秋一叶):还是你说得有道理！！！Top
58 楼maoliao（毛料）回复于 2001-10-12 21:57:15 得分 0
gg is finding mm who use c++...Top
59 楼caoxin（）回复于 2001-10-12 22:51:31 得分 0
天哪，女程序员？太没情趣了，宁可找个站柜台的Top
60 楼luciferwl（汪磊）回复于 2001-10-13 00:10:56 得分 0
一群人，就在这里聊这些无聊的东东么？
你答我，我答他，他又答这中间又出现的问题。
怎么看，都像是一个我编出来的程序，无序且没有目的，而且漏洞百出，只有开始，没有终结的死循环一样。
不觉得浪费你们程序员天才的头脑和大师的文笔么？Top
61 楼qqchen79（知秋一叶）回复于 2001-10-13 09:27:55 得分 0
以程序员对数学和程序的敏感，改行应该不会很难的。
Wall Street不知道有多少dealer是从大学的计算机系毕业的（女的可不少噢！）
关键还是
1)你是不是真的对计算机非常感兴趣？
2)你能承受程序员的工作压力吗？
至于男朋友嘛，我觉得文理科的隔阂还是很大的，况且找程序员也是很现实的选择。Top
62 楼genius007（踏雪无痕）回复于 2001-10-13 09:33:34 得分 0
没这种说法啦，我就不想找学计算机的女生，哈哈Top
63 楼SCUM（人渣）回复于 2001-10-13 09:47:51 得分 0
女程序员一般说来非常适合男程序员 反过来就绝对不合适了
Top
64 楼hxx（小小鸟）回复于 2001-10-13 09:56:15 得分 0
MM,找我的，我很优秀，英俊，年轻，睿智，很有男人味。我随时可以改行。
哈哈。各位别介意啦。Top
65 楼kickmaster（忘情天师）回复于 2001-10-13 10:07:19 得分 0
我说不如找个老头子，有钱的那种，给你投个几十万，随你怎么写程序，反正是别人的钱，玩累了，不想写程序了，再找个有点钱的小伙子嫁掉算了。嘻嘻……
-----------------------------------------------对立志成为程序员的MM的忠告Top
66 楼smartboyme（淡泊明志，宁静致远）回复于 2001-10-13 11:31:58 得分 0
2 hello770725(hello):
有什么话就明说吧！
是不是面对选择的时候了?想听听大家的意见！
还是捕风捉影，无病呻吟？
我觉得人生短短，不管作什么，只要高兴就行了。
哪怕就是捡垃圾的，也会遇到适合自己的伴侣~~~~
知足就行了！
Top
67 楼newyzy（样子）回复于 2001-10-13 12:36:13 得分 0
怪哉!
根据优化组合的原理，我的意见：找不结婚的就找同行；不然，无此限制，就看缘分了。Top
68 楼rdtt（切·格瓦拉）回复于 2001-10-13 13:00:38 得分 0
to :only_i
如果是雇保姆的话，你是不是少了很多
为人父母的乐趣呢，是不是少了很多
为人父母的责任呢。唉总之，2个都是programer
的话好没有情趣的，Top
69 楼snowman_pc（cpp）回复于 2001-10-13 13:04:37 得分 0
看没看新浪上的一篇文章，不找IT男孩的十大理由，去看看吧Top
70 楼wmouse（山水）回复于 2001-10-13 14:12:35 得分 10
这么多人！一切随缘吧。好程序员怎么定义?是指一个职业是程序员的好人，还是一个工作出色的程序员？好——关键在于适合自己。Top
71 楼9653013（csL阴转晴）回复于 2001-10-13 15:15:13 得分 0
哈哈哈,我是男的，我是程序员,很符合条件了,不如嫁给我吧
算了，还是给我点分实际些!:)
Top
72 楼Only_I（我）回复于 2001-10-13 15:40:04 得分 0
"关键在于适合自己"
说的好！可惜分析不出来哦！Top
73 楼eric_520_2001（william520）回复于 2001-10-13 17:04:03 得分 0
其实，我认为这个事情很简单，随着改革开放到今天，中国人的恋爱观已经有很大的变化，已经不局限于身份和地位的相符，是真正的恋爱自由，现在包二奶和离婚的现象普遍存在，但是大家只会用道德去批评他们，我认为这和他们结婚当时的历史环境有很大关系，所以这代人自由恋爱并结合的不多，所以，由于婚后比较融洽，现在还继续享受着美满的生活，但是婚后不幸福的人大有人在，随着时代的进步他们的恋爱观改变了，他们也从以前的认命的被动态度转变为争取幸福的主动态度，所以这些现象说明了时代的进步，更体现出了人权！
我说了这么多，意思是能够决定你是否选择它的决定性因素是：你是否真的爱他（主观）
不要考虑太多身份和职业的匹配（客观），如果你注重客观的因素太多，可能的结果是感情的破裂！
我想你明白我的意思了：爱才是婚姻的最坚实基础！！！Top
74 楼xbsmail（夏阳）回复于 2001-10-13 17:11:15 得分 0
我不是程序员，是不是可以嫁给我啊，哈哈Top
75 楼joknan（）回复于 2001-10-13 17:16:30 得分 0
www.hello770725.mm
Top
76 楼hello770725（hello）回复于 2001-10-13 17:56:12 得分 0
to all:我打算结束这个问题啦！！！建议越多越不知道如何选择！！！
Top
77 楼Only_I（我）回复于 2001-10-13 21:19:21 得分 0
多结交几个异性朋友！
有空就多出去玩玩！（当然是和朋友一起了！）
如果你肯组织，一定他们都肯出去玩的！（唉，谁叫我们是男人呢~~)
多相处，总会找到你想要的！
互相不了解的，怎么说也不是。。。
唉，说不大清楚
就是相知相爱，结了婚还不一定过的来呢
谈恋爱可以找喜欢的
结婚可得找踏实的
Top
78 楼wmouse（山水）回复于 2001-10-14 10:31:54 得分 0
其实建议只是代表提建议那人的观点，并不代表真理（世上有没有真理？），当你觉得无从选择的时候，就抛开所有人的建议，以自己所想的去选择。虽然这时你可能已经受到了影响，但影响你的就是对你触动最深的。Top
