70,023
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
zhangyafei13 2010-06-16
- 打赏
- 举报
人好多啊。
tzyutou 2003-04-15
- 打赏
- 举报
看不懂~凑个数^_^
kangji 2003-04-15
- 打赏
- 举报
是谁把它翻上来的？？
xinglangyu 2003-04-15
- 打赏
- 举报
看到这些争论！
非常郁闷！
你们在这夸夸奇谈，不想想人家的感受！
我非常希望:
在我需要gc的时候，他来了！
自己来控制的时候，他走了！
小弟刚到，冒昧冒昧。
非常郁闷！
你们在这夸夸奇谈，不想想人家的感受！
我非常希望:
在我需要gc的时候，他来了！
自己来控制的时候，他走了！
小弟刚到，冒昧冒昧。
LoveCreatesBeauty 2003-04-11
- 打赏
- 举报
学习
wugng 2003-02-27
- 打赏
- 举报
工作时间， 先留名！
勉励前行 2003-02-27
- 打赏
- 举报
收藏一下先。
Kill一個對象，一定要馬上清理對象的屍體(內存)嗎？，用戶可以選擇：1、把屍體送到火葬場(GC?)，讓火葬場擇日銷毀。2、馬上安葬(delete )。這樣不好嗎。
我想：讓對象的生死與內存的使用分離，可更有效。
對象的生存過程：分配對象空間，生成對象 ，(對象活動期)，殺死對象,把對象清出場 。這幾個過程應該對用戶來講是透明的。不透明我覺得不好，
1、JAVA，你只管生成對象，殺死對象，對象清出場一律由JAVA代辦，這樣世上就不會有多余的對象(memory leak)，對象活動空間是我定的，超出部分(越界)我來檢查。
2、C++，只要你殺死對象，對象就要被清場(重載delete可部分自己控制內存)，你不殺死它，C++可不管那麼多。越界檢查，有些工具可幫你，自己看看要不要用吧。要移動對象，讓好幾個對象住在一塊，要自己動手。
3、GC，有多種實現方式，但用戶想控制對象的整個從生到死的過程，沒門。移動對象(內存碎片問題)，交給我處理吧，我做不做都不關你的事，我說：我做得很好。
C++對象有構造，析構這兩個過程。分配對象空間，把對象清出場這兩個過程由系統控制，如果重載對象的new 與 delete ,應當可以實現自己控制內存行為。
1、登記對象，分配對象空間，可預設生命期，(生命一到，自動死掉)
2、生成對象
3、(對象活動期)，。。。
4、殺死對象，可選擇立刻把對象清出場，還是把對象放入垃圾堆。
5、把對象清出場。
越界問題，對象重組問題，該由誰負責？
越界問題，好說，程序員的責任，最多系統幫你檢查。對象重組，這可不是程序員能做到的了，登記對象時，如果說明該對象是否可以重組(有些對象是不能移動其空間的)，交由OS做才最有效，可惜OS不提供這種功能，GC想要做，只能是在單個應用程序本身實現，JAVA，.NET
是個平台，可讓活動在該平台內的對象重組，所以可以做。C++是編譯型語言不能做，要做也效果不大。
希望有一種語言能清楚地定義這幾個過程。用起來就放心了。
Kill一個對象，一定要馬上清理對象的屍體(內存)嗎？，用戶可以選擇：1、把屍體送到火葬場(GC?)，讓火葬場擇日銷毀。2、馬上安葬(delete )。這樣不好嗎。
我想：讓對象的生死與內存的使用分離，可更有效。
對象的生存過程：分配對象空間，生成對象 ，(對象活動期)，殺死對象,把對象清出場 。這幾個過程應該對用戶來講是透明的。不透明我覺得不好，
1、JAVA，你只管生成對象，殺死對象，對象清出場一律由JAVA代辦，這樣世上就不會有多余的對象(memory leak)，對象活動空間是我定的，超出部分(越界)我來檢查。
2、C++，只要你殺死對象，對象就要被清場(重載delete可部分自己控制內存)，你不殺死它，C++可不管那麼多。越界檢查，有些工具可幫你，自己看看要不要用吧。要移動對象，讓好幾個對象住在一塊，要自己動手。
3、GC，有多種實現方式，但用戶想控制對象的整個從生到死的過程，沒門。移動對象(內存碎片問題)，交給我處理吧，我做不做都不關你的事，我說：我做得很好。
C++對象有構造，析構這兩個過程。分配對象空間，把對象清出場這兩個過程由系統控制，如果重載對象的new 與 delete ,應當可以實現自己控制內存行為。
1、登記對象，分配對象空間，可預設生命期，(生命一到，自動死掉)
2、生成對象
3、(對象活動期)，。。。
4、殺死對象，可選擇立刻把對象清出場，還是把對象放入垃圾堆。
5、把對象清出場。
越界問題，對象重組問題，該由誰負責？
越界問題，好說，程序員的責任，最多系統幫你檢查。對象重組，這可不是程序員能做到的了，登記對象時，如果說明該對象是否可以重組(有些對象是不能移動其空間的)，交由OS做才最有效，可惜OS不提供這種功能，GC想要做，只能是在單個應用程序本身實現，JAVA，.NET
是個平台，可讓活動在該平台內的對象重組，所以可以做。C++是編譯型語言不能做，要做也效果不大。
希望有一種語言能清楚地定義這幾個過程。用起來就放心了。
evence 2003-02-26
- 打赏
- 举报
ty
ahphone 2002-10-11
- 打赏
- 举报
我收起来看看吧，VC板的垃圾帖子见多了，到这而觉得这帖子挺好。
scalene 2002-10-11
- 打赏
- 举报
"JAVA的垃圾回收机制，用户完全不能控制对象的释放，而系统自动回收又是不定时的，感觉很不好"。同意。所以这种技术不能推而广之。我还是一句话，不认为什么系统都能用GC。太大不行，太小不行,性能要求太高不行，空间要求太多也不行。大家说Java成功都说J2EE，可是J2EE并非纯Java的技术，工业化的J2EE服务器还是用C写的。我认为，J2EE的主体技术是协议，而非什么GC技术。
bugfree 2002-10-08
- 打赏
- 举报
unix 中的 unlink 很有意思， 不必考虑生成垃圾文件的case,
在自己内存管理需要有这种手法.....
在自己内存管理需要有这种手法.....
windofsun 2002-10-08
- 打赏
- 举报
JAVA的垃圾回收机制，用户完全不能控制对象的释放，而系统自动回收又是不定时的，感觉很不好
Last_Dodo 2002-10-02
- 打赏
- 举报
To scalene(南瓜汤):
"我看到的滥用OO技术的问题不比完全不懂OO的人带来的危害更少"深表赞同！！！
用电锯的人可能锯断手脚，用手锯的人顶多锯破皮。但不表示大家要拒绝用电锯和电锯不好。一句话，不能因噎废食。
对ODBMS我知道的也是皮毛。据我所知它在telecom，e-commerce等许多地方都有用。尤其是需要良好object persistence以及object relationship复杂的地方。Cisco, Nortel, Sprint等的一些网元管理系统用它。你可以到ODBMS商的网站上找它们的white paper看。它常会列出它们的一些客户。ObjectDesign (ObjectStore)拥有多数的电信客户；Versant的客户多在e-commerce/web-service方面；Object Connectivity据说是现在ODBMS数据库中是最大的，他们和我们开会时说他们正在支持的某个internet datastore有几百个terrabyte的数据。对我最有用的是它带来的Object persistence，复杂的数据关系变成简单的object reference，advanced caching(dynamic cache forwarding)，以及和OO程序的0距离。我不放心的是data integrity，数据查找，和维护(找个ODBMS的DBA可不象RDBMS的DBA那么容易)。
"我看到的滥用OO技术的问题不比完全不懂OO的人带来的危害更少"深表赞同！！！
用电锯的人可能锯断手脚，用手锯的人顶多锯破皮。但不表示大家要拒绝用电锯和电锯不好。一句话，不能因噎废食。
对ODBMS我知道的也是皮毛。据我所知它在telecom，e-commerce等许多地方都有用。尤其是需要良好object persistence以及object relationship复杂的地方。Cisco, Nortel, Sprint等的一些网元管理系统用它。你可以到ODBMS商的网站上找它们的white paper看。它常会列出它们的一些客户。ObjectDesign (ObjectStore)拥有多数的电信客户；Versant的客户多在e-commerce/web-service方面；Object Connectivity据说是现在ODBMS数据库中是最大的，他们和我们开会时说他们正在支持的某个internet datastore有几百个terrabyte的数据。对我最有用的是它带来的Object persistence，复杂的数据关系变成简单的object reference，advanced caching(dynamic cache forwarding)，以及和OO程序的0距离。我不放心的是data integrity，数据查找，和维护(找个ODBMS的DBA可不象RDBMS的DBA那么容易)。
abcabcabc___ 2002-10-02
- 打赏
- 举报
the freely avalible postgresql is ODBMS, maybe not as feature rich as commercial one, but all the necessary stuff is there.
scalene 2002-10-02
- 打赏
- 举报
请教do_do：
ODBMS我不了解，能介绍一下吗？我是没见过什么产品/项目用ODBMS的。有哪些产品？什么时候用？
技术方案选择：我觉得，公司背景很有关系呀。SnowFalcon、myan、do_do、cloudwu之所以观点各不相同，不正是如此吗？如果你的公司里都是一些C程序员，你在设计的时候，难道不会考虑这个问题吗？刚刚学会C++的时候，对OO特别狂热。现在觉得，它也只是软件技术中的一种罢了。我看到的滥用OO技术的问题不比完全不懂OO的人带来的危害更少。
ODBMS我不了解，能介绍一下吗？我是没见过什么产品/项目用ODBMS的。有哪些产品？什么时候用？
技术方案选择：我觉得，公司背景很有关系呀。SnowFalcon、myan、do_do、cloudwu之所以观点各不相同，不正是如此吗？如果你的公司里都是一些C程序员，你在设计的时候，难道不会考虑这个问题吗？刚刚学会C++的时候，对OO特别狂热。现在觉得，它也只是软件技术中的一种罢了。我看到的滥用OO技术的问题不比完全不懂OO的人带来的危害更少。
Last_Dodo 2002-10-02
- 打赏
- 举报
Cber，说来也巧，关于读书的事深有同感，我正在办PhD入学的事(是part-time，完全放弃工作去读书，太太和小孩们会开除我的^_^)。
David5 2002-10-01
- 打赏
- 举报
"谁new谁own，谁own谁delete，带const就不带ownership，不带const就带ownership"
这是什么意思啊？请大侠举个例子好吗？
这是什么意思啊？请大侠举个例子好吗？
cber 2002-10-01
- 打赏
- 举报
呵呵，今天凌晨2点左右看到do_do在csdn上面，没想到是写了这么一大段文字；）
我现在在上海，但明年会去北京（myan也在北京），可能是读书吧（工作几年后，发现自己已经空了，需要充电^_^）
确实，现在的帖子离题实在厉害，导致我这个对gc没有什么概念的人也能在这乱说几句了，呵呵……
我现在在上海，但明年会去北京（myan也在北京），可能是读书吧（工作几年后，发现自己已经空了，需要充电^_^）
确实，现在的帖子离题实在厉害，导致我这个对gc没有什么概念的人也能在这乱说几句了，呵呵……
Last_Dodo 2002-10-01
- 打赏
- 举报
To: Myan
1. 能否介绍一下国外商业的C++类库提供商？我只知道有Dinkumware和Rouge Wave。Rouge Wave是一家非常capable的公司，有很多非常令人惊讶的产品。不过总的来讲，在我印象里似乎这个市场并不是非常活跃。实际情况怎么样？
C++类库提供商可以说是已经到了每个角落。所以不同的软件行业会用到许多不同的库。
RogueWave的容器确实很好用，基本上没有learning curve，拿来就能用(STL的learning curve就要大许多。事实上STL根本就不能算是OO库，而只不过是PG思想在数据结构/算法上用C++的实现)。我们公司一直都在用它。它的collectable类的Object persistence也挺好用。相比之下，它的DBTool就真是很不够。由于近来它完全改变记价方法，我们已决定放弃它而改用STL。
Dinkumware我不了解。
我们是做网管软件的，除了数据结构/算法库外，我们还用到数据库，通讯，网管协议/标准，加密/解密，等商用库。在这些方面，我的了解是(可能很片面)：
数据库方面，象RogueWave的DBTools这样一类的只管数据库连接的库基本上被ODBC/JDBC以及native API挤垮(其实也没多少市场)。更进一步的是包括OR mapping(Relational database to Object mapping，就是把关系型数据库映射到类/对象)的产品。在Object database和Relational database的仗打完之后，大家也都意识到ODBM没法取代RDBM。当然ODBM也找到自己的位置而。所有的ODBM生产商基本上都做过(甚至还在卖)OR映射的库。现在OR映射商做到了distributed caching和这些cache的动态更新上。象Persistence System的PowerTier，ObjectStore(现称ObjectDesign)，Object connectivity等都有这方面的产品。它给数据库悠关的分布式系统的开放带来很大的方便。
通讯方面，最基本的是Douglas的ACE中的socket wrapper。然后是MOM(message oriented middleware)类的库生产商。有Tibco, Vitria, Kabira(可能拼的不对，这名字特象一啤酒名)等。其实，它们又有许多的不同，Tibco是纯message handling(direct messaging/publish-subscribe messaging)的库生产商。Vrtria和Kabira是以对象为目标的messaging system。它们常被称为system software bus (EAI的关键)。再往上层走就是CORBA/EJB/COM等这些东西。
通讯协议库一般是从硬件制造商那里买(象X.25/OSI 7 layer等)。
网管协议库也有些厂商在做，由于市场不是很大，价格较高，所以有些我们自己也做。这两年由于美国经济不振，这类厂商有些已经倒掉了。
这些库生成商往往是几个人在某一行业有较深的了解以后自己出来干的。
2. 我目前在一个项目里专门从事后台支持类的设计开发，把前面的东西交给别人去做。这项技术活做了一段时间之后，发现一个问题，就是自己总是对前一阶段的设计不满意，从而不断地在修改先前的设计。由于这种不断地修改占用了大量的时间，而产出有限，使自己的工作性质越来越象一个全职的“工具制造者”。目前国内的软件项目里应该是没有给这种人留下什么容身之地。美国的情形如何？我记得Brooks曾经建议每个项目组里专门有人负责工具制作和改进，不过McConnell说实际上没有一个项目组真的这么做，是这样吗？
这里也有类似的分工，但不明显(即不大可能是长期全职的以及不大可能是每个小组都有)。只要是生产自己的软件产品的公司，它就一定需要写一些常用的库(买不到或由于市场小，买的成本和自己开发的相差不多了，自己开发就有利些)。这些库往往是由一帮较成熟的工程师来负责。
你的那种状况是很常见的。由于许多原因(比如知识的积累，对方法的认识的加深，看问题更全面，以及需求的变化等)，总觉得对以前的设计不满意，然后就不停地改。一开始是越改越好，然后越改越没把握是变好了还是坏了，有时是自己觉得好了可使用者觉得坏了等。我觉得这是OO的一大缺点，即模拟现实世界。然而，现实中的物体是非常稳定，或者说是真正的well-defined，它不会老是变。由于软件的特点就是变，要给某些类一个准确的定义常常是很难的事。还有，许多东西是只在软件中存在的，它本来就没有确切的定义。这样其结果就是看谁定义的，什么时候定义的。当我回过头来看我自己以前的设计/代码时，我能清楚地看到我的认识的进化过程。
我现在觉得走中庸才是较好的选择，也就是根据需求和自己经验带来的眼光(vision)来定义类和设计。一旦定下来不是万不得已不改，即使改也是以需求以及对整体的影响为主OO为辅。几个release下来以后有机会了才改邪归正^_^。所以做这些类的人最好是有经验的。这些人弄不好就自己开公司写库卖去了。
国内没这些人容身的地方应该是短期的。长远来说一定会变。看到SnowFalcon说90万的项目最后选了10万元的标。我觉得这是因为社会整体对软件行业的了解还有段路要走。这90万本身可能就是个大概，定这个数的人可能不大了解软件制作过程以及其行情。出10万标的人是瞎闹(如果90万是个比较可信的数字)。而选10万标的人就更是不负责任。我觉得成熟的市场应该是选低于但非常靠近90万的标(办好事重于省了钱。我认为不办事的清官还不如办好事的贪官就是这个道理)。
SnowFalcon不要灰心，迟早还是会回到一分钱一分货的规律上来。记得96年出差回国，听到某部领导关于为什么花钱买软件不值的评论。当时就坚信迟早人们会明白买软件的道理的。事实上也就几年，大家就改变了看法。软件市场也会一样，最多5年就够了。
另外，这里的能人不少，不妨自己开公司写库卖。当然最好是不太通用的库，因为太通用的库，你会面对国外的竟争(因为市场大，价格就容易下来--软件的特点)。通用但又不太通用的库，国外大公司不怎么看重(因为市场不大)，小公司不大可能把开发放到国内从而成本很高(我粗略的估计，象样的程序员/工程师在这里的总体成本是$150K-$200K它包所有的福利，工资只是50%左右。而在国内可能只需要$20K-30K，也就是美国的20%-30%)无法和你竞争。如果买库的成本能降下来了加上社会对软件行业的认识增加，软件库一定有市场。就象现在的美国，软件公司写的是自己的商业逻辑代码加上系统间的集成(其实象CA，J.D. Adward它们的很大一部分就是专做软件集成的)。这有点象地产商只做房子而不是木料，钢筋，水泥什么都做。一旦站稳了脚，可以反过来进攻国外市场。当然这里的关键是如何开头(所谓万事开头难)，这里包含的就不只是书上的东西了。
Cber，你也在深圳哪，十几年没去那了，下次回国一定到那去一趟(不少好友在那)。
我这贴子越扯越离题了。还是那句话，请原谅！
1. 能否介绍一下国外商业的C++类库提供商？我只知道有Dinkumware和Rouge Wave。Rouge Wave是一家非常capable的公司，有很多非常令人惊讶的产品。不过总的来讲，在我印象里似乎这个市场并不是非常活跃。实际情况怎么样？
C++类库提供商可以说是已经到了每个角落。所以不同的软件行业会用到许多不同的库。
RogueWave的容器确实很好用，基本上没有learning curve，拿来就能用(STL的learning curve就要大许多。事实上STL根本就不能算是OO库，而只不过是PG思想在数据结构/算法上用C++的实现)。我们公司一直都在用它。它的collectable类的Object persistence也挺好用。相比之下，它的DBTool就真是很不够。由于近来它完全改变记价方法，我们已决定放弃它而改用STL。
Dinkumware我不了解。
我们是做网管软件的，除了数据结构/算法库外，我们还用到数据库，通讯，网管协议/标准，加密/解密，等商用库。在这些方面，我的了解是(可能很片面)：
数据库方面，象RogueWave的DBTools这样一类的只管数据库连接的库基本上被ODBC/JDBC以及native API挤垮(其实也没多少市场)。更进一步的是包括OR mapping(Relational database to Object mapping，就是把关系型数据库映射到类/对象)的产品。在Object database和Relational database的仗打完之后，大家也都意识到ODBM没法取代RDBM。当然ODBM也找到自己的位置而。所有的ODBM生产商基本上都做过(甚至还在卖)OR映射的库。现在OR映射商做到了distributed caching和这些cache的动态更新上。象Persistence System的PowerTier，ObjectStore(现称ObjectDesign)，Object connectivity等都有这方面的产品。它给数据库悠关的分布式系统的开放带来很大的方便。
通讯方面，最基本的是Douglas的ACE中的socket wrapper。然后是MOM(message oriented middleware)类的库生产商。有Tibco, Vitria, Kabira(可能拼的不对，这名字特象一啤酒名)等。其实，它们又有许多的不同，Tibco是纯message handling(direct messaging/publish-subscribe messaging)的库生产商。Vrtria和Kabira是以对象为目标的messaging system。它们常被称为system software bus (EAI的关键)。再往上层走就是CORBA/EJB/COM等这些东西。
通讯协议库一般是从硬件制造商那里买(象X.25/OSI 7 layer等)。
网管协议库也有些厂商在做，由于市场不是很大，价格较高，所以有些我们自己也做。这两年由于美国经济不振，这类厂商有些已经倒掉了。
这些库生成商往往是几个人在某一行业有较深的了解以后自己出来干的。
2. 我目前在一个项目里专门从事后台支持类的设计开发，把前面的东西交给别人去做。这项技术活做了一段时间之后，发现一个问题，就是自己总是对前一阶段的设计不满意，从而不断地在修改先前的设计。由于这种不断地修改占用了大量的时间，而产出有限，使自己的工作性质越来越象一个全职的“工具制造者”。目前国内的软件项目里应该是没有给这种人留下什么容身之地。美国的情形如何？我记得Brooks曾经建议每个项目组里专门有人负责工具制作和改进，不过McConnell说实际上没有一个项目组真的这么做，是这样吗？
这里也有类似的分工，但不明显(即不大可能是长期全职的以及不大可能是每个小组都有)。只要是生产自己的软件产品的公司，它就一定需要写一些常用的库(买不到或由于市场小，买的成本和自己开发的相差不多了，自己开发就有利些)。这些库往往是由一帮较成熟的工程师来负责。
你的那种状况是很常见的。由于许多原因(比如知识的积累，对方法的认识的加深，看问题更全面，以及需求的变化等)，总觉得对以前的设计不满意，然后就不停地改。一开始是越改越好，然后越改越没把握是变好了还是坏了，有时是自己觉得好了可使用者觉得坏了等。我觉得这是OO的一大缺点，即模拟现实世界。然而，现实中的物体是非常稳定，或者说是真正的well-defined，它不会老是变。由于软件的特点就是变，要给某些类一个准确的定义常常是很难的事。还有，许多东西是只在软件中存在的，它本来就没有确切的定义。这样其结果就是看谁定义的，什么时候定义的。当我回过头来看我自己以前的设计/代码时，我能清楚地看到我的认识的进化过程。
我现在觉得走中庸才是较好的选择，也就是根据需求和自己经验带来的眼光(vision)来定义类和设计。一旦定下来不是万不得已不改，即使改也是以需求以及对整体的影响为主OO为辅。几个release下来以后有机会了才改邪归正^_^。所以做这些类的人最好是有经验的。这些人弄不好就自己开公司写库卖去了。
国内没这些人容身的地方应该是短期的。长远来说一定会变。看到SnowFalcon说90万的项目最后选了10万元的标。我觉得这是因为社会整体对软件行业的了解还有段路要走。这90万本身可能就是个大概，定这个数的人可能不大了解软件制作过程以及其行情。出10万标的人是瞎闹(如果90万是个比较可信的数字)。而选10万标的人就更是不负责任。我觉得成熟的市场应该是选低于但非常靠近90万的标(办好事重于省了钱。我认为不办事的清官还不如办好事的贪官就是这个道理)。
SnowFalcon不要灰心，迟早还是会回到一分钱一分货的规律上来。记得96年出差回国，听到某部领导关于为什么花钱买软件不值的评论。当时就坚信迟早人们会明白买软件的道理的。事实上也就几年，大家就改变了看法。软件市场也会一样，最多5年就够了。
另外，这里的能人不少，不妨自己开公司写库卖。当然最好是不太通用的库，因为太通用的库，你会面对国外的竟争(因为市场大，价格就容易下来--软件的特点)。通用但又不太通用的库，国外大公司不怎么看重(因为市场不大)，小公司不大可能把开发放到国内从而成本很高(我粗略的估计，象样的程序员/工程师在这里的总体成本是$150K-$200K它包所有的福利，工资只是50%左右。而在国内可能只需要$20K-30K，也就是美国的20%-30%)无法和你竞争。如果买库的成本能降下来了加上社会对软件行业的认识增加，软件库一定有市场。就象现在的美国，软件公司写的是自己的商业逻辑代码加上系统间的集成(其实象CA，J.D. Adward它们的很大一部分就是专做软件集成的)。这有点象地产商只做房子而不是木料，钢筋，水泥什么都做。一旦站稳了脚，可以反过来进攻国外市场。当然这里的关键是如何开头(所谓万事开头难)，这里包含的就不只是书上的东西了。
Cber，你也在深圳哪，十几年没去那了，下次回国一定到那去一趟(不少好友在那)。
我这贴子越扯越离题了。还是那句话，请原谅！
cloudwu 2002-09-30
- 打赏
- 举报
to Analyst: 刚刚看到你的回帖, 我其实经常在 csdn 吵架的啊 :)
上次跟 ajoo 为了多继承的问题,几个晚上没睡好觉呢.
这几个月我对 GC 的了解应该比以前要多一些了. 不会一味反对的 ^^
上次跟 ajoo 为了多继承的问题,几个晚上没睡好觉呢.
这几个月我对 GC 的了解应该比以前要多一些了. 不会一味反对的 ^^
加载更多回复（326）
