类成员变量:实例Vs指针 [英] Class Member Variables:instance Vs pointer

查看:76
本文介绍了类成员变量:实例Vs指针的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在重新组织我的代码并且遇到了问题,我在这个帖子的主题行中描述了问题。


我有很多类,其他类的实例作为成员

变量。那么包括前向声明没有帮助,是吗?

面对这些,我有以下选项:

- 在包含<的头文件中包含相应的标题br />
类定义,其成员变量是类实例

而不是指向类的指针

- 更改成员变量一个班级的班级实例

指针。


我有以下问题:

1)哪种方法更好*为什么?

2)如果你需要包括标题和

的前向声明,那么这个课程没有帮助(这是合理的)你做了什么?

现在,我正在使用这个


#ifndef __FILE_H

#include" File.h"

#endif


提前致谢。

I am in the process of reorganizing my code and came across and I came
across a problem, as described in the subject line of this posting.

I have many classes that have instances of other classes as member
variables. So including a forward declaration doesnt help, does it?
Faced with these, I had the following options:
-Include the appropriate header in the header file that contains the
class definition that has a member variable that is a class instance
as opposed to a pointer to the class
-Change the member variable from being a class instance to a class
pointer.

I have the following questions:
1) Which approach is *better* and why?
2) If you need to include the header and the forward declaration of
the class doesnt help(which is reasonable) what do you do?
For now, Im using this

#ifndef __FILE_H
#include "File.h"
#endif

Thanks in advance.

推荐答案

Mon写道:
#ifndef __FILE_H
#include" File.h"
#endif

提前致谢。
#ifndef __FILE_H
#include "File.h"
#endif

Thanks in advance.




包括警卫通常在h文件本身中


- my_file .h -

#ifndef MY_FILE_H_

#define MY_FILE_H_

//文件内容

#endif

-


另外,你需要一个不同的ifndef。任何标识符(预处理器或其他)

与两个相邻的下划线(前导或不前导)保留给

实现。类似地,任何带有单个前导下划线的标识符(后跟大写字母)都保留给实现。这就是为什么我使用一个单独的尾随下划线为我的样本包括后卫。



include guards usually are in the h file itself

-- my_file.h --
#ifndef MY_FILE_H_
#define MY_FILE_H_
// file contents
#endif
--

Also, you need a different ifndef. Any identifier (preprocessor or otherwise)
with two adjacent underscores (leading or not) is reserved to the
implementation. Similarly, any identifier with a single leading underscore,
followed by a capital letter, is reserved to the implementation. That''s why I
used a lone trailing underscore for my sample include guard.


" Mon" <他********** @ hotmail.com>在消息中写道

news:8b ************************** @ posting.google.c om ...
"Mon" <he**********@hotmail.com> wrote in message
news:8b**************************@posting.google.c om...
我正在重新组织我的代码并遇到了问题,我发现了一个问题,如本帖子的主题部分所述。

我有许多类,其他类的实例作为成员
变量。那么包括一个前向声明没有帮助,是吗?
面对这些,我有以下选择:
- 在包含
类定义的头文件中包含适当的头文件作为类实例的成员变量
而不是指向类的指针
- 将成员变量从类实例转换为类
指针。

我有以下问题:
1)哪种方法更好*为什么?
2)如果你需要包括标题和前面的声明
这个类没有帮助(这是合理的)你做了什么?
目前,我正在使用这个

#ifndef __FILE_H
#include" File.h"
#endif

提前致谢。
I am in the process of reorganizing my code and came across and I came
across a problem, as described in the subject line of this posting.

I have many classes that have instances of other classes as member
variables. So including a forward declaration doesnt help, does it?
Faced with these, I had the following options:
-Include the appropriate header in the header file that contains the
class definition that has a member variable that is a class instance
as opposed to a pointer to the class
-Change the member variable from being a class instance to a class
pointer.

I have the following questions:
1) Which approach is *better* and why?
2) If you need to include the header and the forward declaration of
the class doesnt help(which is reasonable) what do you do?
For now, Im using this

#ifndef __FILE_H
#include "File.h"
#endif

Thanks in advance.




*更好*是一个非常主观的东西...


在这样的如果我正在共享一个cl的实例,我只使用一个指针(或一个引用,这也将是
与前向声明一起工作)

在多个对象中,或者由于某种原因,实例在其他地方创建了

并传递给构造函数。


如果一个实例仅属于一个父对象,那么一个实例就是我使用的b
。使用指针需要一个额外的新的和删除与我的懒惰方面的

冲突。清晰度也是一个因素 - 实例的存在告诉我*它是*属于*父母。指针或参考可以是从其他地方借来的


Tom



*Better* being a very subjective thing...

In such a situation, I only use a pointer (or a reference, which will also
work with a forward declaration) if I am sharing an instance of a class
among a number of objects or if, for some reason, the instance is created
elsewhere and passed to the constructor.

If an instance belongs solely to a parent object then an instance is what I
use. Using a pointer requires an extra new and delete which conflicts with
my lazy side. Clarity is also a factor - the presence of an instance tells
me that it *belongs to* the parent. A pointer or reference could be
borrowed from elsewhere.

Tom


Mon写道:
Mon wrote:
我有很多类,其他类的实例作为成员
变量。那么包括一个前向声明没有帮助,是吗?
面对这些,我有以下选择:
- 在包含
类定义的头文件中包含适当的头文件作为类实例的成员变量
而不是指向类的指针
- 将成员变量从类实例转换为类
指针。

我有以下问题:
1)哪种方法更好*为什么?
2)如果你需要包括标题和前面的声明
这个类没有帮助(这是合理的)你做什么的?


我尝试了两种方法(组合和关联),我会给你几个快速的理由,为什么我通常更喜欢第一种方法。


有一段时间,我试图避免让任何头文件包含任何其他

文件;这相当于您的选项2。这种方法的优点

是模块间依赖性的最小化,快速编译,以及标题不需要那些令人烦恼的宏来防止多个
的事实/>
包含,因为只有从一个实现文件中明确地完成了多个包含才能实现




非包含标题的缺点是更丰富。最大的缺点是(在大多数现有的开发环境中)模板

不能在标题中使用。额外的间接级别经常使代码复杂化而不是简化;例如,如果一个类是
实际上只是一个成员的包装器(Bridge设计模式),那么该类的每个

方法必须明确写入才能转发

函数调用。客户对这些转发功能的调用通常也不能内联,因为转发功能不能在标题中定义为



替代方案,选项1,有很多好处。代码更容易写入
,程序的性能得到改善等等。在一个包含不同类的

Bridge类的情况下,私有继承可以<使用了
,并且由于与其他模块兼容的原因,在它们变为

之前不需要编写转发函数。


最大的问题选项1是模块之间的强耦合。

为了缓解这种痛苦,我编写了一个Perl脚本来编写Makefiles列出

所有依赖项。编译仍然可能非常慢,因为改变单个标题可能需要重新编译几个大的实现文件,即使它们不直接包含标题。


选项2的大多数优点都可以通过编写一个接口

类,然后使用Factory来提供实现
$ b $的对象来获得。 b界面。这样,真实的类定义在实现

文件中,并且可以有非指针成员。

现在,我正在使用它

#ifndef __FILE_H
#include" File.h"
#endif
I have many classes that have instances of other classes as member
variables. So including a forward declaration doesnt help, does it?
Faced with these, I had the following options:
-Include the appropriate header in the header file that contains the
class definition that has a member variable that is a class instance
as opposed to a pointer to the class
-Change the member variable from being a class instance to a class
pointer.

I have the following questions:
1) Which approach is *better* and why?
2) If you need to include the header and the forward declaration of
the class doesnt help(which is reasonable) what do you do?
I have tried both approaches (composition and association), and I''ll
give you a couple of quick reasons why I usually prefer the first.

For a while, I tried to avoid letting any header file include any other
file; this amounts to your "option 2." The advantages of this approach
are minimization of inter-module dependencies, fast compilation, and the
fact that headers don''t need those annoying macros to prevent multiple
inclusion, since multpile inclusion is only possible if done explicitly
from an implementaton file.

The downsides to non-including headers are more plentiful. The biggest
drawback is that (in most existing development environments) templates
cannot be used in headers. The extra level of indirection often
complicates the code more than it simplifies; for example, if a class is
really only a wrapper around a member (the Bridge design pattern), each
method of the class must be written explicitly just to forward the
function call. Clients'' calls to these forwarding functions often
cannot be inlined, either, since the forwarding functions cannot be
defined in the header.

The alternative, option 1, has a lot of upside. Code is easier to
write, the program''s performance is improved, etc. In the case of a
Bridge class wrapping a different class, private inheritance can be
used, and no forwarding functions need be written until they become
necessary for reasons of compatibility with some other module.

The biggest problem option 1 has is the strong coupling between modules.
To ease this pain, I wrote a Perl script to write Makefiles listing
all the dependencies. Compilation still can be very slow, since
changing a single header may require several large implementation files
to be recompiled, even if they do not include the header directly.

Most of the advantages of option 2 can be gained by writing an interface
class, then using a Factory to provide objects implementing the
interface. That way, the "real" class definitions are in implementation
files, and can have non-pointer members.
For now, Im using this

#ifndef __FILE_H
#include "File.h"
#endif




Fyi,那些守卫通常会进入头文件。当然,

无论对你有用,对我来说都没关系。 :)


-Jeff



Fyi, those guards usually go inside the header file. Of course,
whatever works for you is okay by me. :)

-Jeff


这篇关于类成员变量:实例Vs指针的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆