Hi,

I have a class "A" in which I want to have a reference/ pointer to an object of class "B" for usage within the member functions of A.

Currently I do this:

// class A definition

	const Crealysm_d3drenderer::CD3dscene* mD3dscene;

	// Initial - creation of the renderqueue
	bool Create(const Crealysm_d3drenderer::CD3dscene *pD3dscene, const int pLightingEffectId);

// class A implementation

bool CRenderQueue::Create(const Crealysm_d3drenderer::CD3dscene *pD3dscene, const int pLightingEffectId)
{
	if(!pD3dscene->IsLoaded()) return false;

	if((mD3dscene = pD3dscene) == NULL) return false;	// set const pointer to d3dscene

Functionally this all works, but I believe I've only made the pointer const, so the actual pointer is const instead of the object it points to.

Although I'm not sure, because I'm not able to make changes to the objects it points to (pD3dscene).

Can someone clear this up for me?

First, you can't have an uninitialized reference as a member. If D3dscene is a global object, you can declare "extern CD3dscene D3dscene;" and declare as a member "CD3dscene& myD3dscene = D3dscene;" Not a very good solution, though.

Perhaps a better approach is to let pD3dscene protect itself, by declaring members as protected or private as appropriate, and providing access to those members via const return values.

(By the way, it's more common that what you're calling a definition is a declaration, and your implementation is the definition.)

Thanks, I've changed it into a const pointer to a const object, in the create member function.

It works. I can now not longer call non-const member functions with mD3dscene (member).

The member pointer of the renderqueue can ofcourse still be modified (point to something else), but that's logical I think.

bool CRenderQueue::Create(const Crealysm_d3drenderer::CD3dscene *const pD3dscene, const int pLightingEffectId)
{
	if(!pD3dscene->IsLoaded()) return false;

	if((mD3dscene = pD3dscene) == NULL) return false;	// set const pointer to d3dscene

?

	const Crealysm_d3drenderer::CD3dscene* mD3dscene;

@Buckeye; I've actually protected all members of CD3dscene correctly, but there are still ways through public functions to make changes in the d3dscene, which I do not want the renderqeue to be able to. Thanks for the correct naming, will remember it.

Thanks, when it's not necessary I fully agree.

I've been playing around just to make sure I understand correct;

- the pD3dscene only has to be "const CD3dscene *pScene", that way my goal is achieved that within renderqueue, after copying the pointer, the mD3dscene cannot be altered

- adding the extra const only makes sure that within the Create function pd3dscene (the actual pointer) cannot be altered, which is unlikely to happen

Regarding the pLightingEffectId it's sort of the same, but I most of the time don't take the risk that member functions of classed are allowed to change passed values which are needed within the memberfunctions (just to be sure, I could make a mistake by accidentally changing passed values).

Thanks, I understand. But still within the 'Create' function I could change pD3dscene as a pointer itself, make it NULL or point to something else by accident (although that's not very likely and in this case can only happen before copying it to m3dscene).

Thanks, I understand. But still within the 'Create' function I could change pD3dscene as a pointer itself, make it NULL or point to something else by accident (although that's not very likely and in this case can only happen before copying it to m3dscene).

Perfectly true and you seem to understand the scope of the pointer okay. In theory we should all be this specific about const in function parameters since it makes the code entirely self-documented, but in practice the my feeling is the additional complexity to the reader outweighs the benefits but its entirely up to you.

But this is like:

void setLives(const int number);

Which you don't tend to see, even if number is not supposed to be modified by the function. Its technically correct, but it doesn't offer the same benefits as a const reference (can be initialised with a temporary) or const member functions (can be selected based on the object's own constness) so people tend not to bother. Maybe we should.

The point is the areas people do religiously use const offer slightly wider benefits than just preventing you accidentally changing a variable in a local scope.