- 在线时间
- 0 小时
- 最后登录
- 2007-9-23
- 注册时间
- 2004-9-10
- 听众数
- 3
- 收听数
- 0
- 能力
- 0 分
- 体力
- 9975 点
- 威望
- 7 点
- 阅读权限
- 150
- 积分
- 4048
- 相册
- 0
- 日志
- 0
- 记录
- 0
- 帖子
- 1893
- 主题
- 823
- 精华
- 2
- 分享
- 0
- 好友
- 0

我的地盘我做主
该用户从未签到
 |
<TABLE width="100%" border=0>
$ m$ j# F9 A( }' J
* Z, {( g. A) o/ n<TR>* K% G; W6 h* K9 x' k: d
<TD width="7%"> </TD>
, g) L0 N. V. D% y<TD width="85%">
; p9 i# f1 }! z5 a# T<DIV class=Section1 style="LAYOUT-GRID: 15.6pt none">9 v8 h! s+ h# K. }
< align=center></P>( G9 I b9 g' E `( P
< ><B>5 </B><B>大规模程序设计</B>(Large-scale Programming)<B></B></P>
" x0 J' y8 i; w& G+ e7 X< ><B> </B></P>
/ u; h9 }4 ?. d" e! i< >本文的主要内容涵盖的是C++所支持的主要程序设计风格。然而namespace和异常处理机制虽然是重要的语言特性,但却并不属于这种讨论范畴,因为它们在所有的程序设计风格中都能支持大规模程序设计。在将分散的部件组合成完整程序的过程中,namespace和异常处理机制被用来缓减整个过程的难度和复杂度;随着程序规模的增大,它们也随之起到越来越重要的作用。</P>+ N! k/ b6 f1 m J( H3 k: w$ v
< > </P>
+ \2 i( }# S- r% O' B< ><B>5</B><B>.</B><B>1 </B><B>异常和错误处理</B>(Exceptions and Error Handling)</P>
4 M! V! ?: W: Y. o" c, Q< >当在某个位置检测到一个错误的时候,我们使用<I>异常</I>来把程序的控制权转交到能够处理这种错误的调用者(caller)那里。显然,这种机制只用来处理那些在当前区域内无法处理的错误。</P>: }7 J$ P' e& q+ \* q
< >有人可能会问:“如果一个位置所发生的事情最终能够被正确的处理并使得程序如期正常运行,那么这件事情又怎么能被认为是一个错误呢?”事实上,我们把这类异常事件(或简称异常)以及用来处理这类事件的语言机制一起成为异常处理(exception handling)。</P>
a; Y6 C2 B1 U! } [< >我们可以像这样报告Stack中发生的上溢(overflow)和下溢(underflow)错误:</P>
7 t8 r8 F. M2 y. r1 h. t5 L7 ~' C( Q3 I< >template<class T> class Stack {</P>1 w2 k% x9 O$ P* {2 f5 r
< >T* v;</P>
2 s4 B' |9 I, ]! l6 H R< >Int max_size;</P>
& J: Z0 u8 O: x( E2 N3 B< >Int top;</P>, T, d; C3 ~& ?7 E/ Y A
< > ublic:</P>5 b( m; T( C* y0 U) A* R1 s
< >class Underflow { }; // 用来报告下溢情况的型别</P>7 l5 J G9 B" k8 P# W
< >class Overflow { }; // 用来报告上溢情况的型别</P>5 i8 H6 c+ B9 s( h$ L
< >Stack(int s); // 构造函数</P>6 ?, Q ^& n$ S9 K
< >~Stack(); // 析构函数</P>* K* h& s0 j: U4 ] z6 U0 o
< >void push(T c)</P>* E2 R3 q9 V# N( @4 [5 {* A$ `: `
< >{</P>' N: Z$ @. J- N) \
< > if (top == max_size) throw Overflow(); // 检查是否发生错误</P>
) e0 O6 [+ n! a# g: h9 i< > v[top++] = c; // 增加top并将c存放在top位置</P>4 Z9 ^; }* w2 v. Z" _0 K; a. J, e
< >}</P>
" g) i1 l2 Z! |7 e< >T pop()</P>% j2 s+ N$ g/ A/ j9 n0 O
< >{</P>: Z( K6 ]" I2 p6 m2 Z) W$ C
< > if (top == 0) throw Underflow(); // 检查是否发生错误</P>6 u/ d# T- s4 x* s/ g7 ]8 w
< > return v[--top]; //减少top</P>
* r. u5 Q% \1 j! K+ M: i) }) ]< >}</P>
1 g& G% v9 c, K% X5 {9 J! j< >};</P>/ c. J5 A2 z8 O2 n
<P>一个被抛出的对象能够被抛出该对象的那个函数中的相关调用者(caller)捕获。例如:</P>
6 A, u9 @4 f: g7 f, m( R1 X- Q<P>void f()</P>
8 g7 h* j) w6 b$ c- K U<P>{</P>
% U5 v; C! o6 B* c8 U<P >Stack<string> ss (10);</P>
9 @. l# L! t, D& t' g. k0 ^! l<P >Try {</P>
3 X9 [! a9 _: u<P > ss.push(“Quiz”);</P>
. T' `; H6 y9 x$ Y% r' o) m: Q6 }<P > string s = ss.pop(); // 用pop操作弹出”Quiz”</P>& Y9 N, O( W% G- W# t8 T
<P > ss.pop(); // 这一句企图对一个空的string施以pop操作,将会抛出Underflow</P>
4 N3 q6 r6 y$ g0 J5 {7 C% m9 b<P >}</P>
* i+ y7 \" Q! c$ {$ |) |<P >catch (Stack<string>::Underflow) { // 异常处理器</P>
, C4 j" |3 |1 A j3 e<P > cerr << “error: stack underflow”;</P>
# }+ c2 h! L" k2 _5 m8 ?<P > return;</P>8 Z, n) k; C( r9 N+ A
<P >}</P>; X; H5 K+ j; G
<P >catch (Stack<string>::Overflow) { // 异常处理器</P>
( ?, Q- m& Z6 B9 S5 M<P > cerr << “error: stack overflow”;</P>1 C+ C. P; I7 G% Y
<P > return;</P>
. f; S; ^. V( K<P >}</P>) F( i |0 a, ^! }- ~, S9 O
<P >// …</P>
4 u: a) y% @/ o3 {& g) U* U8 g<P>}</P>+ a Z. _2 l8 s% F) b) M
<P>在一个try{…}代码段中抛出的异常,或者在try{…}代码段所调用的一段代码中抛出的异常会被其对应型别的catch语句捕获。</P>( \' s- h2 r2 @
<P >我们可以使用异常来把错误处理变得更具独特性且更自然。特别是异常类的层次结构,它可以用来将异常进行分组,从而使一段处理代码能够只在适当的细节层级上处理错误。例如,我们假设open_file_error类派生自io_error:</P>* ]; H3 A( Z2 t
<P>void use_file(const char* fn)</P>
! v, }3 k# g- U<P>{</P>
5 A7 d0 P( J# C, U<P >File_ptr f(fn, “r”); // 打开fn以便读取;</P>, w$ {$ a* J5 s# O# |7 [4 N: g6 c
<P >// 如果在这个过程中出现错误,则抛出open_file_error</P>. {( {2 }' ]. I5 }) I
<P >// 这里的代码使用fn</P>; u4 x9 b0 O! e+ q: J
<P>}</P>
* t" _& m9 V/ O' H; `! h% B<P>void some_fct()</P>7 {4 @0 Q- s6 ^! U
<P>{</P>
+ C$ i& ?: X6 \2 P1 M4 S<P >try {</P>
6 P l+ Y# R+ W! ]; z! {2 S& ?3 a0 y<P > // …</P>$ T0 s: r: v, ^( H8 f2 x9 R" G
<P > use_file(“homedir/magic”);</P>
9 J3 h' G' D! F# }2 Z<P > // …</P>9 r! V+ P8 l! Q1 i* N- m& m: v9 s% t
<P >}</P>
5 T7 }/ M l/ \' k& j& {<P >catch (io_error) {</P> @* @; W {! {+ E$ \
<P > // …</P>
& e. Z! |: K! z. t<P >}</P>
4 Y' l, Q! n8 U! `0 H* x! J9 N<P>}</P>
- t# A, P+ W" @" S<P>代码中的some_fct并不需要了解具体是什么出错了;这即是说,它并不需要认识open_file_error。some_fct只处理io_error这个抽象层级上的错误。</P>: m% I* r, o8 Y7 C5 h
<P >可以注意到,use_file本身根本不处理异常。其任务只是打开一个文件并予以使用。一旦没有可以打开的文件,程序控制权立即被转交给了some_fct。同样,一旦在使用文件的过程中发生了读取方面的错误,该文件将会在控制权转到some_fct之前经由File_ptr的析构函数而被正常关闭。</P>
+ S% P7 ]8 {1 e( p% H. P% b<P> </P>
" d% T: `2 Z1 l' D; z<P><B>5</B><B>.</B><B>2 namespaces</B><B>(名字空间)</B><B></B></P>6 l, }4 C3 c3 o0 S/ ^+ y
<P >一个namespace是指一个具名的范围(named scope)。namespace被用来将相关的声明划归在一起,将不相关的代码部分隔开。例如,两个各自独立开发的程序库使用相同的名称来代表不同的东西,但用户还是能够同时使用它们:</P>0 v% o$ b7 J4 `" m( G9 U
<P>namespace Mylib {</P>
I3 Q% A( D2 ]<P >template<class T> class Stack { /* … */ };</P>
7 T7 b$ v0 {5 `. K9 m ~* h<P >// …</P>
' W$ z; X# P% G. J! Q<P>}</P>
& W& o+ Y: J' v% _6 [( [<P>namespace Yourlib {</P>
+ g1 Y* y8 I# c4 s; n3 v<P >class Stack { /* … */ };</P>
3 U* C2 F2 V9 n* y6 S+ m2 d<P >// …</P>
3 n% ?8 W4 y6 ~& o! ~5 l, i<P>}</P>% ~- a& }4 l$ u$ r
<P>void f(int max)</P>
. \; J' j5 F2 [9 s9 A3 p7 n<P>{</P>
. k K( E2 t3 i2 k<P >Mylib::Stack<int> s1(max); // 使用我的那个Stack</P>5 H& c2 n! Q) r8 p4 h. g
<P >Yourlib::Stack s2(max); // 使用你的那个Stack</P>
! x4 u5 T) m+ a' ?0 s# v$ |<P >// …</P>2 M) j! |- G9 D/ |; p4 N
<P>}</P>
0 `% z( p* u, b% @" W9 A<P>然而,让一个namespace名称在同一处不断的重复出现,反而会影响和迷惑阅读者和编写者自己。因此,C++规定:在一个特定的namespace内部,即使不做显式的限定,也默认为该namespace中所包含的对象名称是有效的。例如:</P>
X7 P- p- {1 X+ P# G<P>void f(int max)</P>& L5 n1 E" t" @* Q; e5 l
<P>{</P>
, l- C7 h3 K7 g9 b<P >using namespace Mylib; // 使Mylib()中的各种名称成为有效可用的</P>
+ k! S; t; a8 K& P<P >Stack<int> s1(max); // 使用我的Stack</P>
6 \; S, l& o7 z2 Z' \<P >Yourlib::Stack s2(max); // 使用你的Stack</P>
3 d5 T. J) B8 k& _<P >// …</P>
7 b) K7 y% P' i& D8 X) v' c<P>}</P>
' s! \4 E4 y! N- z$ `; T9 h<P>namespace为管理不同的程序库和不同版本的代码提供了一个强有力的工具;特别是,它能让程序员自己控制一个non-local名称之引用的能见度。</P>; c C# g8 H% |2 m
<P></P></DIV></TD>
# ?! p. |$ X+ e% z<TD width="8%"> </TD></TR></TABLE> |
zan
|