asm, c, c++ are my all
-- Core In Computer
posts - 139,  comments - 123,  trackbacks - 0

/********************************************\
|    欢迎转载, 但请保留作者姓名和原文链接, 祝您进步并共勉!     |
\********************************************/


1.2 A Keyword Distinction

作者: Jerry Cat
时间: 2006/04/20
链接: http://www.cppblog.com/jerysun0818/archive/2006/04/22/6064.html

-------------------------
unequivocal: 毫不含糊的
pedestrian:  步行者; 步行的, 呆板的, 通俗的
infamous:    声名狼藉的
strike aside:闪躲开
brandish:    挥舞(n. & v.)
fledgling:   n.羽毛初长的雏鸟, 羽翼未丰无经验的人, 初出茅庐的人
underpinning:基础, 支柱, 支撑
discourse:   谈话, 演说, 演讲, 论文(n. & v.)

C++的struct 与 class有恼人的暧昧关系, 表面上struct里没显式说明存储权限的全是public而class则全是private, 事实却并非如此简单当考虑到与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中内存连续分布的, 但若考虑到
   //这是在C++中, struct基本上就是类, 这类的数据成员与外来(参)变量的"tricky 捆绑式"
   //内存布局将导致派生类的数据成员"插不进去"从而导致类的数据成员内存布局不连续!
   //所以C的trick是非标准的不能滥用!

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;
   // ...
};

强烈不推荐这种种"淫巧",  不过在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)).

posted on 2006-04-22 01:23 Jerry Cat 阅读(482) 评论(0)  编辑 收藏 引用

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理



<2024年3月>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

常用链接

留言簿(7)

随笔档案

最新随笔

搜索

  •  

最新评论

阅读排行榜

评论排行榜