在分析ACE的原码时发现有一种平时比较少见的调用方式,记得以前有人用C++描述Command时也用了这种方式,不过他们的代码都包装为模板,不方便理解.这里,我不用模板简单的展示其特点:
#include <iostream>
using namespace std;
class CA
{
public:
CA()
{
cc = 1;
};
int func1(int a, int x)
{
cout<<"func1"<<endl;
cc = a + x;
cout<<"cc is :"<< cc <<endl;
return cc;
}
int func2(int a, int y)
{
cout<<"func2"<<endl;
cc = cc + a * y;
cout<<"cc is:"<<cc<<endl;
return cc;
}
typedef int (CA::*FUNC)(int a, int y);
int Test1()
{
FUNC f;
f = &CA::func2;
return (this->*f) (10, 20);
}
int test2(FUNC func,int a, int b)
{
//ACE中是先做一些共同的复杂的事,然后调用不同的func部分:
return (this->*func)(a,b);
}
private:
int cc;
};
int main( void )
{
CA a;
a.Test1();
a.test2(&CA::func2,11,3);
return 0;
}
很酷!调用者可以把类的函数作为参数传递.
好再开下面,利用继承的关系,我们还可以做到同样效果:
#include <iostream>
using namespace std;
class CB
{
public:
virtual int func1(int a, int x)=0;
virtual int func2(int a, int x)=0;
typedef int (CB::*FUNC)(int a, int y);
int Test1()
{
FUNC f;
f = &CB::func2;
return (this->*f) (10, 20);
}
int test2(FUNC func,int a, int b)
{
return (this->*func)(a,b);
}
};
class CA:public CB
{
public:
CA()
{
cc = 1;
};
int func1(int a, int x)
{
cout<<"func1"<<endl;
cc = a + x;
cout<<"cc is :"<< cc <<endl;
return cc;
}
int func2(int a, int y)
{
cout<<"func2"<<endl;
cc = cc + a * y;
cout<<"cc is:"<<cc<<endl;
return cc;
}
private:
int cc;
};
int main( void )
{
CB *pB = new CA();
pB->Test1();
pB->test2(&CB::func2,11,3);
delete pB;
return 0;
}
上面的例子如果应用到Command模式中,func1 和func2就可以分别是Execute 跟 UnDo的接口了.至于如何实现,就是派生类的问题了.
(上述代码均在MinGW中测试通过)
posted @
2009-02-25 17:32 名羽 阅读(1673) |
评论 (3) |
编辑 收藏
前两个月,公司对我们部门动大手术了。把软件研发部分成了3大块,分别是:系统工程与架构部,开发部,测试部。由于以前在团队里基本所有架构方面的事都有我参与,所以,这次上头有意问我有没做架构方面工作的想法。我理想当然答应这份差事。于是,被提到系统架构师的岗位上。这段时间,经过公司培训,才发现做系统架构师其实真不简单,负的责任比我原来想的大多了。另外,自己技术方面的素养也必须尽快提高,觉得自己应在以下方面多下功夫:
1.领域内的知识面的扩展。
2.软件构建的基础知识的巩固。
3.行业内新的设计思想及技术的认知。
4.公司产品的发展方向及价值观也需关心。
总的说来,为适应新的工作,我需要:多学,多问,多研究,多动手,多关心,多参与。
posted @
2008-12-02 13:45 名羽 阅读(240) |
评论 (1) |
编辑 收藏
在概要设计时,发现参与讨论的人对什么是模块,模块的划分根据是什么的认识有很大的差异。
我也不敢乱下定论,还是看看书本是怎么说的:
---------------------------------------------------
1 .参考一下《软件架构艺术》一书,
Stephen T. Albin 在里面描述:
Modules are discrete units of software (binary and source).
Binary modules are instantiated at run time and these instantiations are
commonly called components and connectors. A given module may contain the specifications for
several component types and connector types. The component (instances) may be of
a fixed number in some situations. For example, a Web server executable, when
launched, results in a single Web server component instance. The Web server module is the binary code that exists as a set of
program files. The Web server component is a running
instance of the Web server.
I have seen some confusion over the use of the terms module, component, and connector. A module is a discrete unit
of design that is composed of a hidden set of elements and a set of shared
elements. Modules have high internal cohesion and low external coupling. Modules
may represent the physical packaging of the application's binary code, which can
be described further by component types and connector types. Components and
connectors describe the physical instantiation of a system. The term component is often used to mean a component type or module. A
module refers to a unit of software that can be designed,
implemented, and compiled into a deliverable executable system or subsystem; it
is a unit of execution. A component is a runtime entity,
the definition of which exists in a module. A classic modular architecture is a
client-server system. The client and the server are two modules. The server
exports some elements such as a set of publicly visible relational database
tables and views. The client knows about this publicly visible schema. The
client and server are unaware of the internal composition of the other.
那么按红色部分来说,如果说一个dll或一个Exe里由多少个模块组成这将是的笑话了。
2 .参考Mary shaw的《软件体系结》:
模块式软件被划分成独立命名的,并可被独立访问的成分。模块划分,粒度可大可小。划分依据是对应用逻辑结构的理解。这个定义,似乎有没有《软件架构艺术》那么严格。没有定义具体什么为“被独立访问”的成分。
3. 《Documenting_Software_Architectures》
A module tends to refer first and foremost to a
design-time entity. Parnas's foundational work in module design (1972) used
information hiding as the criterion for allocating responsibility to a module.
Information that was likely to change over the lifetime of a system, such as the
choice of data structures or algorithms, was assigned to a module, which had an
interface through which its facilities were accessed.
其说,模块是设计时的实体,特点是信息隐藏和能通过模块的接口访问。在介绍模块视图时他说:
A module is a code unit that implements a set of responsibilities.
A module can
be a class, a collection of classes, a layer, or any decomposition of the code
unit. Every module has a collection of properties assigned to it. These
properties are intended to express the important information associated with the
module, as well as constraints on the module. Sample properties are
responsibilities, visibility information, and author. Modules have relations to
one another. Example relations are
is part of or
inherits from.
---------------------------------------------------
不同的作者有不同的看法,但综合一下,我认为模块因该是一个独立设计的单元,并为其他模块提供访问接口。也就是说,他是一个架构中的设计元素,但不限制他的存在模式,也就是他是提供了可访问接口而且实现某一功能的一个实体,可以是一个类或一组类或可执行程序等。
posted @
2008-12-02 11:21 名羽 阅读(308) |
评论 (0) |
编辑 收藏
今天是年二十八,一年又要过去了。明天就可以放假休息了。下班前抽空做下年度总结。今年我主要集中精力在h323上,更确切的说是在OPenh323上。虽说我不算聪明,但这一年的研究还是有点收获的,主要在以下方面:
1 对现有opneh323不支持的h.264的加入。
虽然不是很按标准,用的是常规视频能力来加入的,但也算是在视频的清晰度上有所提高。
2 根据需要自己建立多条对应的h323逻辑通道来传送自己的数据。逻辑通道可以是rtp也可以是TCP。
3 用h323协商逻辑通道的方式来建立自定义的RTP通道。现在这种方式用在GIPS的RTP上效果还真不错!
posted @
2008-02-04 15:29 名羽 阅读(383) |
评论 (0) |
编辑 收藏
H323和SIP果然难于共存。Openh323原有的开发者也将分为两大块:
OPAL VOIP: 保留Opal现有H323功能,但重点明显是要向兼容SIP方向发展;其网站介绍为:
OPAL implements the commonly
used protocols used to send voice, video and fax data over IP networks.
Originally part of the OpenH323 project, OpalVoip has grown to include SIP and
IAX2.
h323plus:在原有OpenH323基础上继续完善ITU的H323系列的协议,其介绍为:
The H.323 Plus project intends to do much more than simply provide a new
home for open source H.323 developers. Developers have told us they intend to
work to provide significant new enhancements to the very successful H.323
systems deployed worldwide. For example, NAT/FW
traversal, instant messaging, presence, and many other enhancements are
already in progress or being planned. Further, the open source community has
expressed interest to us to enable more collaborative features to H.323,
including such things as application sharing, whiteboarding, and other
capabilities.(可惜,这些功能OPAL将不能用到了)
至于底层的pwlib(即ptlib)估计暂时还会保持一致。
分家后期邮件列表也将分开:
https://lists.sourceforge.net/lists/listinfo/opalvoip-devel
http://lists.packetizer.com/mailman/listinfo/h323plus
网站地址分别:
http://www.h323plus.org/
http://www.opalvoip.org/
对于我们可能会更关心OpenH323的主要开发者 Simon 的以下言论:
The following projects are currently
planned to be supported within H323plus.
OpenMCU (including remote conference
controls) OpenAM (upgraded to support
VoiceMail support to GnuGk) MyPhone OhPhone
The Library is almost drop-in
replacable with the existing OpenH323 and contains numerous enhancements
including video plugins (compatible with
Opal) and large amount of new work
not currently supported in Opal.
Some of the new work now available in
h323plus H.230 Conference Controls (incl
tunneling GCC (T.124))
H.239
Application Sharing
H.249
Extended user inputs
H.341
SNMP support
H.350
LDAP WhitePages
H.460
Numerous custom Extensibility features
Text Messaging (working doc ITU),
Follow Me,
PDI (Personal Data Interchange)
H.460.9 RealTime QoS Measurements
Video Plugins (fully compatible with
Opal)
H.235 Plugins (for external Biometric
and smartcard authenticators) QoS Capability negotiation Conference Controls
capability advertisement.
New work planned/proposed
H.460.presence
H.460.18/19 Nat Traversal
Video on Demand project (using
H.239/H.249)
We can also provide full consulting
service support for existing openH323 based projects as well as provide
assistance in migration of these projects to h323plus.
posted @
2007-10-22 09:58 名羽 阅读(2853) |
评论 (4) |
编辑 收藏
研究h323 端点间通过多通道发送数据,例如MCU可以向EP用多通道来发送音视频。这段时间我从音频上作了测试,可以把多路音频通过多个通道发送给EP让EP直接在声卡上混音,效果不错。但(MCU-〉EP)音频使用多通道这只是一种在网络带宽非常好的情况下的方案,因为如果用的是G.711(单路64kbit/s)就不可能在带宽有限的公网上使用了。
posted @
2007-09-29 08:57 名羽 阅读(642) |
评论 (0) |
编辑 收藏
http://www.cnweblog.com/realwnc/
posted @
2007-07-25 11:32 名羽 阅读(343) |
评论 (0) |
编辑 收藏
由于与OphenH323中h263使用的ffmpeg库冲突所以把h263也提出来另外实现.
posted @
2007-07-23 17:31 名羽 阅读(2008) |
评论 (4) |
编辑 收藏
上头头脑发热.急于让我们在原来的视频会议基础上完成数据会议T120的大部分功能.我们被避着以很多非标准的自定协议代替T120标准中规定的东西.而且新的架构的改动都没有详细分析就开始着手写代码了.也就是说我们开始生产垃圾!
鄙视领导者的短浅眼光!
posted @
2007-05-11 10:35 名羽 阅读(514) |
评论 (2) |
编辑 收藏
目前对Openh323的源代码已有较多的了解,开始对部分协议进行扩展例如H245会议管理部分,4CIF的加入.另外现有的协议栈代码中没有实现T120通道的数字会议,目前正对该部分进行补充.
posted @
2007-03-30 15:02 名羽 阅读(688) |
评论 (3) |
编辑 收藏