/********************************************\
|????歡迎轉(zhuǎn)載, 但請保留作者姓名和原文鏈接, 祝您進(jìn)步并共勉!???? |
\********************************************/

1.2 A Keyword Distinction

作者: Jerry Cat
時間: 2006/04/20
鏈接: http://m.shnenglu.com/jerysun0818/archive/2006/04/22/6064.html
-------------------------
unequivocal: 毫不含糊的
pedestrian:? 步行者; 步行的, 呆板的, 通俗的
infamous:??? 聲名狼藉的
strike aside:閃躲開
brandish:??? 揮舞(n. & v.)
fledgling:?? n.羽毛初長的雛鳥, 羽翼未豐無經(jīng)驗的人, 初出茅廬的人
underpinning:基礎(chǔ), 支柱, 支撐
discourse:?? 談話, 演說, 演講, 論文(n. & v.)

C++的struct 與 class有惱人的曖昧關(guān)系, 表面上struct里沒顯式說明存儲權(quán)限的全是public而class則全是private, 事實(shí)卻并非如此簡單當(dāng)考慮到與C的兼容時, 尤其是對待C中的tricks時, 更是traps多多, 地雷密布!

A C program's trick is sometimes a C++ program's trap. One example of this is the use of a one-element array at the end of a struct to allow individual struct objects to address variable-sized arrays:

struct mumble {
?? /* stuff */
?? char pc[ 1 ];
};

// grab a string from file or standard input
// allocate memory both for struct & string

struct mumble *pmumb1 = ( struct mumble* )
?? malloc(sizeof(struct mumble)+strlen(string)+1);//在C中內(nèi)存連續(xù)分布的, 但若考慮到
?? //這是在C++中, struct基本上就是類, 這類的數(shù)據(jù)成員與外來(參)變量的"tricky 捆綁式"
?? //內(nèi)存布局將導(dǎo)致派生類的數(shù)據(jù)成員"插不進(jìn)去"從而導(dǎo)致類的數(shù)據(jù)成員內(nèi)存布局不連續(xù)!
?? //所以C的trick是非標(biāo)準(zhǔn)的不能濫用!

strcpy( &mumble.pc, string );
This may or may not translate well when placed within a class declaration that

1). specifies multiple access sections containing data,
2). derives from another class or is itself the object of derivation, or
3). defines one or more virtual functions.

The data members within a single access section are guaranteed within C++ to be laid out in the order of their declaration. The layout of data contained in multiple access sections, however, is left undefined. In the following declaration, for example, the C trick may or may not work, depending on whether the protected data members are placed before or after those declared private:

class stumble {
public:
?? // operations ...
protected:
?? // protected stuff
private:
?? /* private stuff */
?? char pc[ 1 ];
};
?
Similarly, the layout of data members of the base and derived classes is left undefined, thereby also negating any guarantee that the trick might work. The presence of a virtual function also places the trick's viability in question. The best advice is not to do it. (Chapter 3 discusses these layout issues in greater detail.)

//接上
If a programmer absolutely needs a data portion of an arbitrarily complex C++ class to have the look and feel of an equivalent C declaration, that portion is best factored out into an independent struct declaration. The original idiom for combining this C portion with its C++ part (see [KOENIG93]) was to derive the C++ part from the C struct:

struct C_point { ... };
class Point : public C_point { ... };
thus supporting both the C and C++ usage:

extern void draw_line( Point, Point );
extern "C" void draw_rect ( C_point, C_Point );

draw_line( Point( 0, 0 ), Point( 100, 100 ));
draw_rect( Point( 0, 0 ), Point( 100, 100 ));
This idiom is no longer recommended, however, because of changes to the class inheritance layout in some compilers (for example, the Microsoft C++ compiler) in support of the virtual function mechanism (see Section 3.4 for a discussion). Composition, rather than inheritance, is the only portable method of combining C and C++ portions of a class (the conversion operator provides a handy extraction method):

struct C_point { ... };

class Point {
public:
?? operator C_point() { return _c_point; }
?? // ...
private:
?? C_point _c_point;
?? // ...
};

強(qiáng)烈不推薦這種種"淫巧",? 不過在C/C++混合編程時你還不得不用它:)
One reasonable use of the C struct in C++, then, is when you want to pass all or part of a complex class object to a C function. This struct declaration serves to encapsulate that data and guarantees a compatible C storage layout. This guarantee, however, is maintained only under composition. Under inheritance, the compiler decides whether additional data members are inserted within the base struct subobject (again, see Section 3.4 for a discussion, as well as Figures 3.2(a) and 3.2(b)).