数码天地 今日: 0|主题: 4759|排名: 40 

最后发表： key
回复内容：
实体之间有One-To-One, One-To-Many, Many-To-One, Many-To-Many的关系。
其中单单是One-To-One又可以分成unidirection, bi-direction两种。

就unidirection来看，很明显，这里可以分成主从两个实体，主实体里可以找到从实体的
对象，而从实体对于主实体可以说是一无所知的。在程序对象中，这个关系很容易表达，
只要在主实体类中结合一个从实体对象即可；而在数据库中，这种关系往往可以由
Foreign-Key来实现：Foreign-Key在哪一个表中，那么这个表就是主表，另一个表
则是从表。

但有的时候，情况是这样的：如果从表没有建立自己的独立主键，而直接使用主表的主键
作为自己的主键，这样，主表只需要在从表里查找那条包含了自己主键值的记录即可；
这种情况不需要别外附加一个新的外键。

对于上面两种情况，在EJB Entity技术中有两个对应的Annotation：
@JoinColumn
@PrimaryKeyJoinColumn

我们来看看它们是怎样实现和操作的。为了简化程序，我把两种情况在同一个Entity中实现了。

主实体使用@JoinColumn的从实体使用@PrimaryKeyJoinColumn的从实体操作实体的Session Bean程序（部分）这里需要注意的是程序62行，我们需要通过manager.persist(user)来materialize
user对象，然后才能获得一个id值（注意@GeneratedValue(strategy=GenerationType.AUTO)）
然后再才这个id值赋给address对象。

有几种出错的可能：
1. address.userid没有赋值，这样就不能直接存放
2. address或birth两个对象之一或全部没有persist()到数据库中，程序执行不成功，
在结束这个方法的时候会抛出rollback

现在再看看数据库中的情况：

user表birthday表address表user与birthday的外键注意到，这里从user到address之间是没有外键的，他们之间采用的是primary到primary的直接关联，
换句话说，address的主键就是外键。

如果一定要建立bi-direction关系，只需要在从实体类中做手脚即可

改变后的address类改变后的birthday类改变后的Session Bean这里有一个问题：
1. mappedBy中指出的不是对应的“表字段”名称，而是类属性名称

再看一下数据库的情况，和之前是一模一样，没有改变。
可以想到，bi-direction与unidirection是程序上的概念，而不是数据库存贮的概念，
这个需要注意了。

最后发表： xblues
回复内容：
3公司可以签约iphone 3gs了，2年的价格，每个月80刀。目前有点贵，iphone 3g的价格是50刀，这个价格比较合理了。希望iphone 3 gs快点降价。

最后发表： ubuntuhk
回复内容：
我支持他们推广ubuntu，当然如果能学会遵从GPL就更好了

最后发表： key
回复内容：
采用内嵌式的实体是真的把另一个实体嵌进入的。所以，两个类之间不能有同名的field或property内嵌后的结果如下：

最后发表： xblues
回复内容：

最后发表： chubbycat
回复内容：

最后发表： ubuntuhk
回复内容：


Jobs确实是神，还记得M$10多年前为了避免apple倒掉而成为垄断官司的对象，帮Apple买了一些股票的事情吗？

谁能想到现在Apple这么风光。

不过还是有点担心神的健康问题。

最后发表： ubuntuhk
回复内容：
还是装个杀毒软件防身吧，这年头只要上网，电脑就是不安全的

最后发表： bfox
回复内容：
貌似没有提到pdf的支持程度？

最后发表： kaile
回复内容：
之后还有一次QQ大规模掉线，不了了之，没有人敢追查责任，呵呵。

最后发表： coredump
回复内容：
FROM:http://www.devx.com/cplus/Article/42365

What were you doing during the morning hours (EST) of July 13th 2009? On that auspicious day, in a dramatic vote, the C++ standards committee decided to remove concepts from C++0x. Undoubtedly, this resolution will have a huge impact on C++. In this column I will outline the causes of concepts' failure, discuss the lessons from this unprecedented event, and try to predict how it will affect the future of C++.

Immaculate ConceptsThe main impetus for adding concepts to C++ was to allow template designers to precisely specify requirements and constraints on and among types. The problem was how to design a constraints mini-language that would be simple and intuitive on the one hand, and complete and efficient on the other hand. To demonstrate the problem that concepts were supposed to solve, consider the function template min(). It imposes certain implicit requirements on the type T:
template<typename T>const T& min(const T& x, const T& y) {  return x < y? x : y;}T must be a type that has a less-than operator (<) to compare two values of type T, and the result of which must be convertible to a Boolean value. In C++03 it's difficult to express these requirements in a clear and bullet-proof manner. Bjarne Stroustrup and Gabriel Do Reis presented the first concepts paper in 2003 (other committee members contributed to this endeavor later). At first, it seemed as if concepts ticked the right boxes. Here's a modified min() function that uses concepts to express the constraints on T:
concept LessThanComparable<typename T> {  bool operator<(const T& x, const T& y);}template<typename T>requires LessThanComparable<T>const T& min(const T& x, const T& y) {  return x < y? x : y;}If C++ templates had to deal only with simple cases like min(), the design of concepts would be a cinch. However, the C++ Standard Library consists of far more complex templates—containers that impose certain requirements on their elements, smart pointers with peculiar ownership semantics, algorithms that must meet certain performance limits, various categories of iterators—you name it. That is why the authors have been refining the concepts specification for more than seven years.
After several iterations, the concepts proposal forked off in two different directions (the technical differences between the two proposals will not be discussed here). A compromise was reached at the October 2005 meeting in Mont-Tremblant, Canada; the two competing proposals would be merged into an integrated concepts proposal known as the "Mont-Tremblant compromise."
Off the record, some committee members viewed the Mont-Tremblant compromise as the watershed—the integrated concepts proposal had simply turned into an incoherent monster. Debates about whether the imminent C++ standard should include a conceptualized Standard Library heated up. While some of the problems with concepts were resolved promptly, each new day led to the discovery of additional problems and disagreements. With serious efforts, the committee managed to approve the C++0x Committee Draft (which included concepts) in September 2008. However, in recent months, the criticism and doubts concerning concepts reached a boiling point. The last straw was probably Stroustrup's latest concepts paper, which added more fears and doubts. The concepts-related threads on the committee's reflectors (list servers) pointed out that concepts were "untried, risky, incomplete and controversial." Concerns about compile-time and runtime overhead were also voiced. As the Frankfurt meeting got closer, these voices became harsher and louder.
Two Tough ChoicesThe distrust and antipathy toward concepts paved the way to voting this feature out of C++0x. There was one huge problem with this decision though: concepts were already pervasive in the Committee Draft (CD). Almost every paragraph and code listing involving templates uses concepts directly or indirectly. Worse yet, many new features that have been accepted into C++0x in recent years presuppose concepts. Removing concepts from the standard will require a massive excision operation that might kill the patient. But what other choices did the committee have?
Leaving concepts in situ wasn't a better choice. Even the authors agree that the current concepts specification isn't complete, and that perfecting it would take "several more years." However, they consider the current proposal "good enough for now." Furthermore, they insist that the outward complexity of concepts is misleading—the underlying model is "good enough;" it's only the surface complexity (what the user has to write) that needs fixing. Considering that concepts have already taken seven years of precious committee time, no one was willing to spend five more years or so on refining the surface complexity, or indeed any other concepts complexity. The cruel choice was thus between a painful excision, and asymptotic refinement of concepts. On the afternoon of July 13th the die was cast: Concepts were voted out of C++0x by a decisive margin.
An Unprecedented EventUnlike other self-contained features that usually have no huge impact on C++ as a whole (nullptr for example), the removal of concepts amounts to a landslide, and will probably lead to a witch hunt. Committee members and the C++ community will want answers. It appears that the committee's limited resources were wasted on a feature that failed, while at the same time, other critical C++0x features such as multithreading and garbage collection didn't get enough attention.
As far as I can remember, this fiasco is unprecedented. I've been following the C++ standardization process closely since the early 1990s and witnessed all sorts of things, such as features that were radically revised just a couple of days before finalization of the standard, and ghost features that made into the standard even though few people understood what they were good for—only to be deprecated years later (examples are exception specifications, and vector<bool>). We even had exported templates in C++98, a feature that (except for Comeau, some eight years later) no compiler vendor has ever bothered to implement. And yet, nothing prepared us for the removal of a feature that was already in the Committee Draft, and that was considered as the most important addition to C++ in years. Why did concepts go wrong?


Standardizing Existing PracticeGenerally, the standards committee is best at standardizing existing practice, that is, wordsmithing features that some compiler vendor has already implemented independently. For example, consider thread-local storage. The committee based this proposal on a similar non-standard extension that several vendors had been offering voluntarily for years. Hashed containers (called unordered containers in C++03) were also based on previous non-standard extensions of various vendors. By contrast, concepts were designed ex-nihilo, and were never tested in real-world projects outside the committee's sandbox.

oncepts Didn't Eliminate Template ComplexityConcepts didn't live up to their promise. They were supposed to make template programming and usage easier. Instead, they transferred the complexities from templates into concept maps and axioms. Pedagogically, concepts were a disaster. There's no way that Joe Coder would ever master such a huge, confusing and unintuitive set of rules and constructs.
No DeadlineConcepts took seven years to design, without reaching satisfactory results. It might have been a good idea to reconsider the whole idea after a certain time limit. How many software projects go on forever without a clear deadline? How many years should a new feature take to design?
What Next?At this stage, no one really knows how difficult (and dangerous) the removal of concepts will be. Rewriting every piece of code and sentence that refer to concepts will be a painstaking process. Yet the main problem here isn't just editorial. In the past five years C++0x has pretended that concepts are a done deal. Therefore, every phrase in "conceptese" will have to be rephrased in plain English. To illustrate the extent of this problem, consider article 30.3.1/3 of the CD:

"A Mutex type shall be DefaultConstructible and Destructible. […] A Mutex type shall not be copyable nor movable."

These two sentences alone reference four different concepts! And the CD contains 1,340 pages of text, charts and code.
The removal of concepts leads C++ developers back to square one. The same problems that have been troubling C++ users and library designers for years are back with a vengeance. Presently, there's no real alternative to concepts. We'll simply have to make do with C++03-style hacks and improvisations such as SFINAE and type traits. Although the authors are free to refine concepts or redesign it from scratch, don't hold your breath. That could take years—and I doubt that committee members will risk a second fiasco.
The removal of concepts was probably the right choice, no matter how painful it will prove to be. However, I suspect that it will haunt the C++ community for many years to come.

最后发表： coredump
回复内容：
The Removal of Concepts From C++0xLast updated Jul 17, 2009.
On Monday, July 13th 2009 Concepts were dramatically voted out ofC++0x during the C++ standards committee meeting in Frankfurt. Thisshocking news raises many questions and concerns. Unquestionably, thesewill be discussed in various forums in coming weeks and months.However, I will try to answer three burning questions here: What led tothe failure of Concepts? How will the removal of Concepts affect C++0x?Will Concepts make a comeback in the near future?
The Writing on the WallWhen I first heard the news, I couldn't believe it. Conceptswere supposed to be the most important addition to core C++ since 1998.Tremendous efforts and discussions were dedicated to Concepts in everycommittee meeting during the past five years. After dozens of officialpapers, tutorials and articles -- all of which were dedicated topresenting and evangelizing Concepts -- it seemed very unlikely thatjust before the finishing line, Concepts would be dropped in a dramaticvoting. What caused this change of heart among committee members?
Early warning signs emerged long ago. Initially, Concepts weresupposed to be integrated into the Standard Library. However, the C++0xCommittee Draft (approved in September 2008) didn't include aconceptualized Standard Library. Committee members claimed that it wastoo early to adopt such a radical change to the Standard Librarywithout real world experience. Apart from that, there were still toomany unresolved issues. As a compromise, the committee decided topursue the refinement of Concepts while leaving the Standard Libraryunconceptualized for the time being. This was an ominous sign -- if thecommittee is wary of conceptualizing the Standard Library, why shouldJoe Code trust Concepts?
Two strong undercurrents shook and undermined the entire Conceptsfoundation. First, skepticism regarding the feasibility and usefulnessof concepts intensified the antipathy towards this proposal. Somepeople expressed concerns about compile-time and runtime overhead.Second, the creators of the Concepts proposal tried desperately toimprove and patch Concepts. The last nail in the coffin was BjarneStroustrup's paper "Simplifying the Use of Concepts"from June. It's a masterpiece in terms of presenting Concepts but italso scared folks. The general sense was that concepts were broken, thecommittee was not sure what the correct direction was to fix them, andit would probably take several more years to come up with a reasonablefix that would achieve consensus.  Considering that Concepts wereoriginally designed to simplify C++, a critical mass of committee members agreed in July 2009 that it was time to bid Concepts goodbye.
Possible DirectionsIt's still unclear at the time of writing which alternatives thecommittee will choose. A total overhaul of Concepts is one possibility,however unlikely. This could take up to five years and no one iscertain that the redesigned Concepts will not have introduced otherproblems. A second approach is to leave the door open for a drasticallyreduced and diluted Concepts proposal. The third approach is to refinethe current Concepts proposal further, knowing that it will not beintegrated into C++0x. I'm willing to bet on the following -- Conceptsare dead for good. The Concepts proposal was doomed because thecommittee wasn't standardizing existing practice (which is what itusually does) but instead, invented a huge, complex and controversialfeature ex nihilo. History shows that features that were added in thisunusual way to C++ have all failed. This was the case with exception specifications and exported templates.
Implications and AnalysisIt's hard to tell at this stage how the removal of Concepts willaffect C++0x. Clearly, the impact will be huge because many other C++0xfeatures presuppose Concepts. In the coming weeks, the committee willhave to scrutinize all outstanding proposals and the Committee Draft toassess the impact of this decision.
How will C++0x programming and design look like without Concepts?Brace yourself for many more years of indecipherable templatecompilation errors. Additionally, type traitswill become a hot commodity once again. Presently, type traits are oneof the very few proven techniques for enforcing compile-timeconstraints on templates. Pedagogically, C++ will be a tad easier toteach.
The removal of Concepts paves the way to other radical changes. IfConcepts could be removed, there's no reason why other "safe" featuresshould become sacred cows. No, I'm not going to name such features butsuffice it to say: the Committee Draft has plenty of features that needto be reconsidered or dropped.
The collapse of Concepts might seem as a sad end to a well-intendedattempt to solve a fundamental problem. However, there's no reason forsobbing. This story shows that the committee isn't afraid to take toughdecisions if it has to. It's also a good reminder to all programminglanguages' designers: don't get enamored of your own proposals. Everynew proposal seems neat and promising at first but after a fewiterations and redesigns, it might easily turn into a bloated tumorthat impedes the natural growth and evolution of the language(namespaces anyone?). If we're ever going to have concepts in C++, it's"the marketplace", not the committee, that needs to do its work firstand only then should the committee bless the result -- if it sochooses. Doing things the other way around is a recipe for failure.

最后发表： 8戒
回复内容：
国内的电视棒接天线的时候天线要尽量短一些，我以前也用过一款国内的电视棒一样的问题，最后短到2CM长就OK了。

最后发表： mingliangfeng
回复内容：
还有一个想法是既零售，也做些批发生意。

最后发表： 向往自然
回复内容：
Windows / Mac / Linux版本的Chrome Dev同时更新到了3.0.195.1，主要更新内容如下：
表单建议收缩正常,扩展可以自动更新了,中文字体大小默认设定为12号，日语，韩语，阿拉伯语和泰语为10号.Mac版支持了将URL，纯文本，HTML拖拽进/出 内容显示区，支持文本域以及新标签页的预览图。URL也支持在Chrome和Finder / Desktop / Dock和外部程序之间拖来拖去。
Mac版修正清除下载列表时崩溃的问题。
Mac版加入了infobars。
Mac版在View->Developer菜单下面加入JavaScript Console功能。
Linux版可以将某个链接拖动到书签栏创建新的书签项目。
Linux版增加快捷键，(Ctrl-Enter, Shift-F5, Shift+Scroll Wheel)
Linux新增可以Dock的开发者工具。

点击这里查看完整的Release Note.

下载:Google Chrome 3.0.195.1

最后发表： 向往自然
回复内容：
出处：http://www.eddsoft.com/?p=34

最后发表： 向往自然
回复内容：
chrome os是基于linux下的chrome浏览器的，用web应用代替传统的桌面窗口应用，保证数据都是portable的，这个概念不错啊

最后发表： Tux
回复内容：
原来是Portable Chrome;-)

貌似Portableapps没有做Chrome啊。

最后发表： key
回复内容：
如果你的电脑上有多个位置用来存放代码，可以通过设定eclipse的启动快捷方式来实现路径的区分。
下面的命令就是用于区分源程序路径：

eclipse -data <路径>

比如：具体操作：
1. 找到eclipse.exe
2. 用鼠标右键点击，在popup menu中选择“创建快捷方式”
3. 在创建出来的快捷方式上用鼠标右键点击，选择“属性”
4. 在目标(T)处append： -data c:\sources\webapp
其中c:\sources\webapp改成你自己的路径。
5. 点“确定”

然后可以把快捷方式copy/cut到任何你想要的位置。

最后发表： diegolin
回复内容：
关键是，俺不需要vista，同样也不需要7，俺只需要P4能跑的飞快的OS，比如过时的XP

最后发表： nimo630
回复内容：
谷歌与篮球巨星姚明投资的巨鲸音乐网联合推出了拥有百万首高品质正版音乐的搜索下载服务。UMI360在音乐分享的基础上，结合谷歌音乐服务，推出了UMI360谷歌音乐特别版（www.umi360.com/google），为所有喜爱谷歌音乐的网友打造了一个集音乐搜索、下载、播放、音乐存储管理、朋友分享、留言讨论为一体的正版音乐交流分享平台。

谷歌音乐搜索基于广告支持的免费优质的正版音乐搜索模式，是一个尊重音乐产业、与产业供应的模式。长时间以来，音乐产业的发展被盗版所严重困扰，UMI360一直是坚定的正版音乐支持者，并致力于深入挖掘在音乐传播、分享所产生的巨大价值。

我们相信，谷歌音乐服务结合强大的UMI360分享平台，将使中国的数字音乐产业进入一个崭新的时代，必将推动整个音乐产业的健康发展。

最后发表： troublemaker
回复内容：
博客贴，顶一下～～～·

最后发表： 大杨树
回复内容：
rational system architecture

最后发表： 大杨树
回复内容：
cap因为没有cap,又live bill, 超了很跪，所以很痛苦。

最后发表： ubuntuhk
回复内容：
呵呵，俺不是ubuntu方面的专家啦，只是一个用家而已

最后发表： yuba
回复内容：
我开通了

可是没有人愿意打我那个号码

不过上周竟然有一个未接来电

最后发表： AAA2009
回复内容：
如何保养和维护好一台电脑，最大限度的延长其使用寿命，是大家都非常关心的话题。就像我们每天都要洗脸刷牙一样，电脑也需要你每天对她关心，一般的电脑维护有以下几点：     1．保持安置电脑的房间干燥和清洁，尤其是电脑工作台要每天（或两三天，视房间的清洁度而定）除尘。要知道，显示器是一个极强的“吸尘器”。曾经就遇到过因为环境不良，显示器内部灰尘厚积，天气转潮时，导致线路板短路打火损坏显示器的事故。

　　2．正确开机（先外设，后主机）和关机。其实这本不应该算是维护的内容，但是很多用户对此总不以为然，甚至错误地认为现在的电脑连“软关机”都有了，还要“老生常谈”。但是这绝对是有必要的：“先外设，后主机”的顺序如果搞反了，就有可能使系统无法识别相关硬件，或者无法装载设备驱动程序。

　　3．使用光盘或软盘前，一定要先杀毒；安装或使用后也要再查一遍毒，因为一些杀毒软件对压缩文件里的病毒无能为力。

　　4．系统非正常退出或意外断电，应尽快进行硬盘扫描，及时修复错误。因为在这种情况下，硬盘的某些簇链接会丢失，给系统造成潜在的危险，如不及时修复，会导致某些程序紊乱，甚至危及系统的稳定运行。

　　为了能让电脑长期的正常工作，用户有必要学习打开机箱进行电脑维护，当然，如果你没有把握，还是包给专业人员每年进行清洁一次，对于部分品牌机，说明书中申明不得随意拆封机箱，就不要打开机箱，否则是不给予保修的。

　　要进行硬件维护，一般用户不可能拥有专业工具，我们用以下工具就可将其轻松搞定：十字螺丝刀，镜头拭纸，吹气球（皮老虎），回形针，一架小型台扇。

　　1．切断电源，将主机与外设之间的连线拔掉，用十字螺丝刀打开机箱，将电源盒拆下。你会看到在板卡上有灰尘，用吹气球或者皮老虎细心地吹拭，特别是面板进风口的附件和电源盒（排风口）的附近，以及板卡的插接部位，同时应用台扇吹风，以便将被吹气球吹起来的灰尘盒机箱内壁上的灰尘带走。

　　2．将电源拆下，电脑的排风主要靠电源风扇，因此电源盒里的灰尘最多，用吹气球仔细清扫干净后装上。另外还需注意电风扇的叶子有没有变形，特别是经过夏季的高温，塑料的老化常常会使噪音变大，很可能就是这方面的原因。

　　3．将回形针展开，插入光驱前面板上的应急弹出孔，稍稍用力，光驱托盘就打开了。用镜头试纸将所及之处轻轻擦拭干净，注意不要探到光驱里面去，也不要使用影碟机上的“清洁盘”进行清洁。

　　4．用吹气球清除软驱中的灰尘。

　　5．如果要拆卸板卡，再次安装时要注意位置是否准确，插槽是否插牢，连线是否正确等等。

　　6．用镜头试纸将显示器擦拭干净。

　　7．将鼠标的后盖拆开，取出小球，用清水洗干净，晾干。

　　8．用吹气球将键盘键位之间的灰尘清理干净。

最后发表： akai
回复内容：
防火墙全部关了试试
如果关了能放 我们继续讨论下一步.

最后发表： pipiman
回复内容：
那个是信号问题不是质量问题


似乎电器行只有dick simith是可以14天无条件退货的

JBhifi和harvynorman都是必须有质量问题才行

我之前在JB买的电视也是因为信号问题不能用，因为不是质量问题不给退，我想就当显示器吧，结果那个垃圾玩意儿居然坏了，所以，哈哈，退了

最后发表： key
回复内容：


一看就知道是 C/C++ 程序员，哈哈哈
因为C/C++是以{}为scope的，而Java似乎不吃这一套。

最后发表： valpa
回复内容：
应该容易吧

共同学习python中，同学同学

最后发表： key
回复内容：
通过<c:url>标签与HttpServletResponse.encodeURL()两种方法都能重写URL，
但这两种方法是有区别的：

对于http://开头的路由，大家都不支持，这个没有什么好说了。

但余下的部分，两者处理有所不同：
HttpServletResponse.encodeURL()只能使用相对路径，比如你可以看到u, u2都有重写，但u3没有。另外，还应该注意到，u3没有加入context path。这也是和<c:url>非常不同的地方。

再看<c:url>的表现u和u2的结果和前面的一致，但u3则不同，u3自动加入了context path及进行了url write

最后发表： suntest001
回复内容：
小贵，但是有保修哦。

最后发表： maaboo
回复内容：
我PS3卖了……MS还没有玩儿到这里。
以后有钱了再买一台，游戏还留着呢

最后发表： beibeihe1
回复内容：

本人今年4月底签了一个VODAFONE手机，两年合同，只用了3个月，现在要转让合同和手机，是每月115元，无限量打!手机型号为SONY ERICSSON黑色，属于全新,因为以前有生意所以有2部手机这部只是接听,所以没怎么用,现在生意结束所以CAP根本用不完,所以转让.
（还没来得及刷中文）可以给你付刷机的钱。

已询问VODAFONE公司，转让方式非常简单，转让后资料都会更新，也就是说和本人毫无关系了，敬请放心！
可以与本人商谈适当的折扣。

如有兴趣速与本人联系Beibeihe1@hotmail.com   电话：0415240583 Rebecca

最后发表： ubuntuhk
回复内容：
分析得不错

最后发表： conty
回复内容：
看来同好很少啊

最后发表： justinli79
回复内容：
big-O notation
(definition)

Definition: A theoretical measure of the execution of an algorithm, usually the time or memory needed, given the problem size n, which is usually the number of items. Informally, saying some equation f(n) = O(g(n)) means it is less than some constant multiple of g(n). The notation is read, "f of n is big oh of g of n".

Formal Definition: f(n) = O(g(n)) means there are positive constants c and k, such that 0 ≤ f(n) ≤ cg(n) for all n ≥ k. The values of c and k must be fixed for the function f and must not depend on n.

little-o notation
(definition)

Definition: A theoretical measure of the execution of an algorithm, usually the time or memory needed, given the problem size n, which is usually the number of items. Informally, saying some equation f(n) = o(g(n)) means f(n) becomes insignificant relative to g(n) as n approaches infinity. The notation is read, "f of n is little oh of g of n".

Formal Definition: f(n) = o(g(n)) means for all c > 0 there exists some k > 0 such that 0 ≤ f(n) < cg(n) for all n ≥ k. The value of k must not depend on n, but may depend on c.

最后发表： someonehappy
回复内容：
现在3gs可以网上买，免运费的。unlocked的在商店里面不一定有现货，今天看有人排队，可能又有了。

至于计划，可以去这个网站看看，不过基本上都是每月７０左右开始。你可以根据你自己的使用情况筛选一下。
http://mobile-phones.smh.com.au/MobilePhones

最后发表： lily07
回复内容：
黑龙舞兮云飞扬
呵呵，其实已经打过了，实在想不起了。
严重期待那部YY中的新作啊！

[ 本帖最后由 lily07 于 15-7-2009 01:15 编辑 ]