Visibility in files.

[DaJones]

In Delphi everything declared in the same file (or unit in Delphi speak) can
see each other. 2 classes in one file can access each others private data /
methods.

It doesnt seem like this is the case in C++?

I was knocking up a basic windows app and found that a plain function (the
WindowProc callback) cant access private members of a class even though it's
definition is in the same file. So I assume i need to make it a static
member of the Window class? Or mark it as a freind function? I think the
former makes more sense as the WindowProc function is only used with the
Window class.

Does this seem like the right aproach?

 

[Alf P. Steinbach]

* DaJones:

In Delphi everything declared in the same file (or unit in Delphi speak) can
see each other. 2 classes in one file can access each others private data /
methods.

It doesnt seem like this is the case in C++?

In C++ anything that's used must first be declared.

There is a special case for class definitions, because a class definition like

struct X
{
void foo() { bar(); }
void bar() {}
};

is effectively a shorthand for writing

struct X
{
void foo();
void bar();
};

inline void X::foo() { bar(); }
inline void X::bar() {}

So the apparent forward reference in the first way of writing it is just an
apparent forward reference; in the second way there's no such.

I was knocking up a basic windows app and found that a plain function (the
WindowProc callback) cant access private members of a class even though it's
definition is in the same file. So I assume i need to make it a static
member of the Window class? Or mark it as a freind function? I think the
former makes more sense as the WindowProc function is only used with the
Window class.

Does this seem like the right aproach?

It's debatable. A callback of this kind needs to have "C" linkage ('extern
"C"'), and formally you can't have that for a static member routine, so
/formally/ no. On the other hand, as far as I know all relevant compilers
support that, and I think it was the intention that it should be possible to use
it that way, and it's common, so /in practice/ it's the simplest -- you'd just
have to add an otherwise meaningless level of indirection, a traditional C
routine to call that static member routine, to comply with the formal.

However, I think nowadays I'd add that level of indirection.

For the idea that typing a short routine definition is a lot of work is just a
misconception -- that's not where the work is.

Then it'd go like

extern "C" void cXCallback();

class X
{
friend void cXCallback();
private:
void onCallback() {}
static void staticCallback()
{
somehowPickUpInstance().onCallback();
}
};

extern "C" void cXCallback() { X::staticCallback(); }

But instead of doing this stuff yourself I think it would be easier to use some
existing C++ wrapper.


Cheers & hth.,

- Alf

 

[DaJones]

Then it'd go like

extern "C" void cXCallback();

class X
{
friend void cXCallback();
private:
void onCallback() {}
static void staticCallback()
{
somehowPickUpInstance().onCallback();
}
};

extern "C" void cXCallback() { X::staticCallback(); }

But instead of doing this stuff yourself I think it would be easier to use
some existing C++ wrapper.


Cheers & hth.,

It helped a lot, thanks.

chris