outer class `this` in local classes without inheritance?
Lorenzo Caminiti
I am new to this groups. I would like to post a C++ programming
question.
Is there a way to access the outer class `this` from a local class but
without using inheritance?
Let me explain with an example:
class x { // outer class
public:
void g() {}
void f() {
this->g(); // (1)
struct y: x { // local class but using inheritance...
y(x* super): x(*super) {} // (2)
void h() {
this->g(); // (3)
}
};
y(this).h();
}
};
*** Is there a way to do this but without inheriting `y` from `x`? ***
At line (3), the local class `y` can access the outer class `x::g()`
simply using `this` because `y` inherits from `x`. However, this
inheritance requires to construct another object `x` when `y` is
constructed as in line (2) adding runtime overhead and requiring `x`
to have an accessible copy constructor.
In my application, I need line (3) to essentially look the same as
like line (1) so you can program code inside `y` members as if it were
inside `x` members. A part from that, the local class `y` could look
as it is needed to solve this problem -- with more member variables,
member functions, etc.
(For example, I tried to redefine `y::operator->()`/`y::operator*()`
to return a pointer/reference to `x` but this does not work because
`this->`/`*this` always retain pointer semantics and do not use the
operators I redefined...)
Thank you very much.
--
Lorenzo
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Goran Pusic
>
> I am new to this groups. I would like to post a C++ programming
> question.
>
> Is there a way to access the outer class `this` from a local class but
> without using inheritance?
Bar "code organisation purposes", inner and outer classes have no
connection between them, so, no. Your inner class has to have a
reference to an instance of the outer class (or derive from it).
>
> Let me explain with an example:
>
> class x { // outer class
> public:
> void g() {}
>
> void f() {
> this->g(); // (1)
>
> struct y: x { // local class but using inheritance...
> y(x* super): x(*super) {} // (2)
Using a reference seems a better option here. You never check super
for NULL, and if you ever do y(NULL), you'll crash. In C++, you can
make this design decision spelled out by the syntax.
It is also unusual to construct a derived object by using a conversion
constructor (fancy word for a constructor with one argument) that is
receiving an instance of a base class, but seems justified given the
context (albeit, context is IMO wrong).
> void h() {
> this->g(); // (3)
g is already a public method of x. You could simply do this:
struct y
{
y(x& xx) : _x(x) {}
void h()
{
_x.g();
}
x _x;
}
If g isn't public, and since you are already controlling both classes,
you can make y a friend of x to be able to touch it's private parts.
> At line (3), the local class `y` can access the outer class `x::g()`
> simply using `this` because `y` inherits from `x`. However, this
> inheritance requires to construct another object `x` when `y` is
> constructed as in line (2) adding runtime overhead and requiring `x`
> to have an accessible copy constructor.
Well, you decided to create another object, what did you expect? ;-)
> In my application, I need line (3) to essentially look the same as
> like line (1) so you can program code inside `y` members as if it were
> inside `x` members. A part from that, the local class `y` could look
> as it is needed to solve this problem -- with more member variables,
> member functions, etc.
The thing is, like with many newbie questions, you think that you need
line (3). But in fact, there's probably much more ways to achieve
desired end result, overall (calling g() on an instance of x is just
part of that result). In other words, you should consider changing
your question so that it tells more about what you want to do. The
question you asked is "can I do __this__ so that I can do __that__?".
But __this__ is tangential (and trivial).
> (For example, I tried to redefine `y::operator->()`/`y::operator*()`
> to return a pointer/reference to `x` but this does not work because
> `this->`/`*this` always retain pointer semantics and do not use the
> operators I redefined...)
Yeah, that's a dead end.
HTH,
Goran.
--
Daniel Krügler
> I am new to this groups. I would like to post a C++ programming
> question.
You are welcome to do so!
> Is there a way to access the outer class `this` from a local class
> but without using inheritance?
>
> Let me explain with an example:
>
> class x { // outer class
> public:
> void g() {}
>
> void f() {
> this->g(); // (1)
>
> struct y: x { // local class but using inheritance...
> y(x* super): x(*super) {} // (2)
> void h() {
> this->g(); // (3)
> }
> };
> y(this).h();
> }
> };
>
> *** Is there a way to do this but without inheriting `y` from `x`? ***
Yes, but that requires that y has a constructor accepting
a (reference or pointer to) x and has a member of pointer or
reference type, e.g. like this:
class x { // outer class
public:
void g() {}
void f() {
this->g(); // (1)
struct y { // local class, no inheritance
x* that; // References an object of the outer class
y(x* super): that(super) {} // (2)
void h() {
that->g(); // (3)
}
};
y(this).h();
}
};
Question: Do you have Java background, where it is possible to
define a "non-static" inner class with implied constructor argument
for an object of the outer class?
> At line (3), the local class `y` can access the outer class `x::g()`
> simply using `this` because `y` inherits from `x`. However, this
> inheritance requires to construct another object `x` when `y` is
> constructed as in line (2) adding runtime overhead and requiring `x`
> to have an accessible copy constructor.
Yes, and this idiom is not required.
> In my application, I need line (3) to essentially look the same as
> like line (1) so you can program code inside `y` members as if it were
> inside `x` members. A part from that, the local class `y` could look
> as it is needed to solve this problem -- with more member variables,
> member functions, etc.
But note that there are some restrictions to local classes, among
them it is not feasible to have static data members.
> (For example, I tried to redefine `y::operator->()`/`y::operator*()`
> to return a pointer/reference to `x` but this does not work because
> `this->`/`*this` always retain pointer semantics and do not use the
> operators I redefined...)
This should also work, you can simply define:
x* operator->() const { return that; }
as inline function in y. It is not possible to define any member
functions outside of the local class, though.
HTH & Greetings from Bremen,
Daniel Krügler
--
Anthony Williams
> Is there a way to access the outer class `this` from a local class but
> without using inheritance?
Pass it in to the local class either as a constructor parameter or a
function parameter:
#include <iostream>
class X
{
private:
void g()
{
std::cout<<"g(), this="<<this<<std::endl;
}
public:
void f()
{
std::cout<<"f(), this="<<this<<std::endl;
struct local
{
X* self;
local(X* self_):
self(self_)
{}
void foo()
{
self->g();
}
};
local y(this);
y.foo();
}
};
int main()
{
X x;
x.f();
}
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++0x thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Lorenzo Caminiti
>
> > In my application, I need line (3) to essentially look the same as
> > like line (1) so you can program code inside `y` members as if it were
> > inside `x` members. A part from that, the local class `y` could look
> > as it is needed to solve this problem -- with more member variables,
> > member functions, etc.
>
> The thing is, like with many newbie questions, you think that you need
> line (3). But in fact, there's probably much more ways to achieve
> desired end result, overall (calling g() on an instance of x is just
> part of that result). In other words, you should consider changing
> your question so that it tells more about what you want to do. The
> question you asked is "can I do __this__ so that I can do __that__?".
> But __this__ is tangential (and trivial).
I want to program code inside `y` members as if it were inside `x`
members. This is my only requirement.
Here's more background information about what I want to do and why.
BACKGROUND
I am programming a macro which evaluates a code expression in constant-
correct context by executing the code from within a local function by
passing the object `this` and other variables as `const`. For example,
the `BLOCK_INVARIANT()` macro can be programmed so that the following:
class c {
public:
c(int x): x_(x) {}
bool eq(int x) const { return x_ == x; };
void f(int x) {
BLOCK_INVARIANT( (const (c*)(this) (int)(x) (this_->eq(x)
== false)) )
}
private:
int x_;
};
Expands to:
class c {
public:
c(int x): x_(x) {}
bool eq(int x) const { return x_ == x; };
void f(int x) {
struct block_invariant {
static void check(c const* const this_, int const& x)
{
if(!( this_->eq(x) == false )) { // Evaluated in
constant-correct context because `this_` and `x` are `const`.
throw int(-1);
}
}
};
block_invariant::check(this, x);
}
private:
int x_;
};
Now the compiler will generate an error if the code expression passed
to `BLOCK_INVARIANT()` -- `this_->eq(x)` in this example -- is not
constant-correct.
However, ideally the code expression passed to `BLOCK_INVARIANT()`
will looks the exactly the same as the code programmed within `f()`.
Therefore, `this_->eq(x)` will ideally be `this->eq(x)`. Is there a
way I can do this without inheriting `block_inv` from `c`? And that is
what I need.
REPLIES
For example, thank you for the following suggestions but they do not
work because:
On Jul 27, 10:43 am, Daniel Krügler <daniel.krueg...@googlemail.com>
wrote:
> class x { // outer class
> public:
> void g() {}
>
> void f() {
> this->g(); // (1)
>
> struct y { // local class, no inheritance
> x* that; // References an object of the outer class
> y(x* super): that(super) {} // (2)
> void h() {
> that->g(); // (3)
> }
> };
> y(this).h();
> }
> };
Line (3) does not look the same as line (1). In other words, this
solution does not work because I would use `that` inside `y` members
and `this` inside `x` members so line (1) and (3) look different from
each other.
On Jul 27, 10:44 am, Anthony Williams <anthony....@gmail.com> wrote:
> #include <iostream>
> class X
> {
> private:
> void g()
> {
> std::cout<<"g(), this="<<this<<std::endl;
> }
> public:
> void f()
> {
> std::cout<<"f(), this="<<this<<std::endl;
> struct local
> {
> X* self;
> local(X* self_):
> self(self_)
> {}
>
> void foo()
> {
> self->g();
> }
> };
>
> local y(this);
> y.foo();
> }
>
> };
Similarly, this does not work because `self->g()` from within the
local function looks different from `this->g()` from within the non-
local function.
Goran Pusic
(You could have shown definition of BLOCK_INVARIANT)
That said, if const-correctness is your goal, then you still don't
need additional class. A const_cast (no blind C casts please, we're in
C++ ;-) ) could do, couldn't it?
What if you simply do:
#define BLOCK_INVARIANT(object_type, check, param_type, param) \
{ if (!const_cast<const object_type*>(this)->check((const param_type&)
(param))) throw -1;}
and then, in f():
BLOCK_INVARIANT(c, eq, int, x).
You can eliminate c by using another macro inside class definition
file, e.g. in c.cpp
#define BLOCK_INVARIANT_C(check, param_type, param) BLOCK_INVARIANT(c,
check, param_type, param)
By the way, that throw -1 stands out like a sore thumb. How's that
supposed to be used? When your invariant is broken, you pop up to the
top of the stack (e.g. to main) and do
catch(int i)
{
return int;
}
?
That's, frankly, worse than crashing or aborting, because you will
lose the place where crash happened. How about at least an exception
containing __FILE__, and __LINE__?
Goran.
Daniel Krügler
> Here's more background information about what I want to do and why.
>
> BACKGROUND
>
> I am programming a macro which evaluates a code expression in constant-
> correct context
Do you mean *const-correct* here?
> by executing the code from within a local function by passing the object
> `this` and other variables as `const`. For example, the
`BLOCK_INVARIANT()`
> macro can be programmed so that the following:
>
> class c {
> public:
> c(int x): x_(x) {}
>
> bool eq(int x) const { return x_ == x; };
>
> void f(int x) {
> BLOCK_INVARIANT( (const (c*)(this) (int)(x) (this_->eq(x)
> == false)) )
> }
>
> private:
> int x_;
> };
>
> Expands to:
>
> class c {
> public:
> c(int x): x_(x) {}
>
> bool eq(int x) const { return x_ == x; };
>
> void f(int x) {
> struct block_invariant {
> static void check(c const* const this_, int const& x)
> {
> if(!( this_->eq(x) == false )) { // Evaluated in
> constant-correct context because `this_` and `x` are `const`.
OK, you *mean* const-correct ;-)
> throw int(-1);
> }
> }
> };
> block_invariant::check(this, x);
> }
>
> private:
> int x_;
> };
>
> Now the compiler will generate an error if the code expression passed
> to `BLOCK_INVARIANT()` -- `this_->eq(x)` in this example -- is not
> constant-correct.
>
> However, ideally the code expression passed to `BLOCK_INVARIANT()`
> will looks the exactly the same as the code programmed within `f()`.
> Therefore, `this_->eq(x)` will ideally be `this->eq(x)`. Is there a
> way I can do this without inheriting `block_inv` from `c`? And that is
> what I need.
I can think only of one way to realize that, but it requires
a new feature of C++0x, which are lambda expressions:
A lambda expression produces a class type within the
smallest scope that contains the expression. Without any
macro, the test could be written as follows:
class c {
public:
c(int x): x_(x) {}
bool eq(int x) const { return x_ == x; };
void f(int x) {
// Macro expansion starts here
[&] {
if (!(this->eq(x) == false)) {
throw int(-1);
}
}();
// Macro expansion end here
}
private:
int x_;
};
I'm not sure whether this approach satisfies your const-
correctness stringency. Above code is always well-formed,
if the test-expression were well-formed within the same
context (which is the context of c::f in above example). Since
f() is a non-constant member function, it would also allow
for tests that call non-const functions, because those are
valid in that context.
HTH & Greetings from Bremen,
Daniel Krügler
Anthony Williams
> Here's more background information about what I want to do and why.
Thank you, that's helpful.
> However, ideally the code expression passed to `BLOCK_INVARIANT()`
> will looks the exactly the same as the code programmed within `f()`.
> Therefore, `this_->eq(x)` will ideally be `this->eq(x)`. Is there a
> way I can do this without inheriting `block_inv` from `c`? And that is
> what I need.
No, you cannot do that. "this" refers to an instance of the current
class. Inside member functions of a local class, "this" refers to an
instance of that local class.
You can do it with a nasty (i.e. strictly undefined behaviour, but works
in practice) hack though: if your local class has no data members and no
virtual functions then you can derive the local class from the outer
class and cast your "this" pointer to be an instance of the local class:
#include <iostream>
class X
{
private:
void g() const
{
std::cout<<"g(), this="<<this<<std::endl;
}
public:
void f()
{
std::cout<<"f(), this="<<this<<std::endl;
struct local:X
{
void foo() const
{
this->g();
}
};
local const* p=static_cast<local const*>(const_cast<X
const*>(this));
p->foo();
}
};
int main()
{
X x;
x.f();
}
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++0x thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
terminator
if 'y' is going to be somewhat an interface to x(say a java inner
class) then I can imagine no other/better solution that D.krugler
suggests.Ofcourse you can explicitly cast the 'x' object, but you
might need to wrap the cast in a function and neglecting the risk of
casting error the overhead wo`nt be any diffrent:
class Cy:x{
//no member objects
...
};
static Cy& y(x* const px){
return reinterpret_cast<Cy&>(*px);//cuation:very tricky!!!
};
regards,
FM.
Lorenzo Caminiti
wrote:
Yes, C++0x lambdas might help in this case but I cannot use C++0x
features :( I must only use the current C++ standard.
--
Lorenzo
Lorenzo Caminiti
> (You could have shown definition of BLOCK_INVARIANT)
I have not yet implemented `BLOCK_INVARIANT()` so I do not have its
#definition. Plus that would be too much code for this email thread...
If you are curious, I will implement the macro using preprocessor/
template metaprogramming (Boost.Preprocessor/Boost.MPL) in ways
similar to what I am doing for other macros in this library:
http://dbcpp.svn.sourceforge.net/viewvc/dbcpp/trunk/src/contract/aux_/prepro
cessor/
. For example, look at `CONTRACT_AUX_PP_SIGN_PARSE_FUNCTION()` and
`CONTRACT_AUX_PP_KEYWORD_IS_THIS()`.
> That said, if const-correctness is your goal, then you still don't
> need additional class. A const_cast (no blind C casts please, we're in
> C++ ;-) ) could do, couldn't it?
>
> What if you simply do:
>
> #define BLOCK_INVARIANT(object_type, check, param_type, param) \
> { if (!const_cast<const object_type*>(this)->check((const param_type&)
> (param))) throw -1;}
>
> and then, in f():
>
> BLOCK_INVARIANT(c, eq, int, x).
This works in the specific example I have listed but the
`BLOCK_INVARIANT()` macro needs to be more generic than that. The
macro needs to handle *any* code expression that can be evaluated to a
boolean within the context where the macro is used (i.e., the function
`f()` in this example).
For example the same `BLOCK_INVARIANT()` macro handles all these
different invariant assertions and checks them in constant-correct
context:
class c {
public:
c(int x): x_(x) {}
bool eq(int x) const { return x_ == x; };
int delta() const { return 10; }
void f(int x) {
BLOCK_INVARIANT( (const (c*)(this) (int)(x) (this_->eq(x)
== false)) )
int y = x;
BLOCK_INVARIANT( (const (int)(y) (int)(x) (y == x)) )
int z = x + y + this->delta();
BLOCK_INVARIANT( (const (int)(z) (int)(x) (int)(y) (c*)
(this) (z == x + y + this_->delta()) )
}
private:
int x_;
};
> By the way, that throw -1 stands out like a sore thumb. How's that
That's just for the example, don't worry about it -- it'll never make
it into real code :)
--
Lorenzo
Lorenzo Caminiti
Yes, this actually does what I need -- thanks a lot!! However, I
cannot use it if its behavior is undefined as per the C++ standard...
I can only use legal standardized C++...
*** Can you please explain more about why the behavior of this code is
undefined? ***
I reworked my previous example using your solution and it compiles
just fine on MSVC:
class c {
public:
c(int x): x_(x) {}
bool eq(int x) const { return x_ == x; };
void f(int x) {
// This macro:
// BLOCK_INVARIANT( (const (c*)(this) (int)(x) (eq(x)
== false)) )
// will expand to:
struct block_inv: remove_pointer<c*>::type {
void check(int const& x) const {
if(!( eq(x) == false )) { // Doesn't even have to
use `this`, like if it were in `f()`!!
std::cerr << "Block invariant broken" <<
std::endl;
throw int(-1);
}
std::clog << "Block invaraint passed" <<
std::endl;
}
};
static_cast<block_inv const&>(
const_cast<remove_pointer<c*>::type
const&>(*this)).check(x);
}
private:
int x_;
};
The code within the macro and therefore within the local class member
function `check()` doesn't even have to use `this`. It simply reads
`eq(x)` as it would if it were written directly within `f()` -- that
is exactly what I needed!
--
Lorenzo
--
Anthony Williams
> On Jul 29, 11:05 am, Anthony Williams <anthony....@gmail.com> wrote:
>> You can do it with a nasty (i.e. strictly undefined behaviour, but works
>> in practice) hack though: if your local class has no data members and no
>> virtual functions then you can derive the local class from the outer
>> class and cast your "this" pointer to be an instance of the local class:
>> local const* p=static_cast<local const*>(const_cast<X
>> const*>(this));
>> p->foo();
> Yes, this actually does what I need -- thanks a lot!! However, I
> cannot use it if its behavior is undefined as per the C++ standard...
> I can only use legal standardized C++...
>
> *** Can you please explain more about why the behavior of this code is
> undefined? ***
It is undefined behaviour to access an object through a pointer or
reference to a type other then the dynamic type of the object or a base
class of the dynamic type of the object. Since local is a *derived* type
of the object (which is type X) this is undefined behaviour. It works in
practice on all compilers I'm aware of though, provided local has no
data members or virtual functions and only the one base class.
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++0x thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
terminator
UB=Undefined behavior.That means there is no standard about that
behavior and every compiler is free to handle it in its own way.The
above example of UB is mostly due to probable memory overhead of
derivation which migth be used for RTTI and is platform dependent.UB
might show up as a program crash(sudden death) or a runtime/OS
error,...
regards,
FM.
Lorenzo Caminiti
> Lorenzo Caminiti <lorcamin...@gmail.com> writes:
>
> > *** Can you please explain more about why the behavior of this code is
> > undefined? ***
>
> It is undefined behaviour to access an object through a pointer or
> reference to a type other then the dynamic type of the object or a base
> class of the dynamic type of the object. Since local is a *derived* type
> of the object (which is type X) this is undefined behaviour. It works in
> practice on all compilers I'm aware of though, provided local has no
> data members or virtual functions and only the one base class.
Thank you all for the suggestions and clarifications. I think this
fully answers my original question unless there is a way to program
this without relying on undefined behavior...
FYI, using the technique you suggested, I was able to implement the
macros used by the following example. However, I still have to assess
if I can use the local member function macro with `this` (2nd usage
below) due to the undefined behavior issue -- if not, I will just use
the `this_` version of the macro (3rd usage below).
class c {
public:
c(): x_(0) {}
int get() const { return x_; }
void f() {
// Non-member local function.
CONTRACT_AUX_LOCAL_FUNCTION_DECL(
// Limitations: It cannot be template, etc.
(int) (inc)( (int&)(x) (const int&)(delta) )
) { // Func. definition outside macro so retain error line
numbers.
return x += delta; // No object.
} }; // Extra `};` closes struct wrapping local function.
int x = 0;
int y = CONTRACT_AUX_LOCAL_FUNCTION_CALL(inc)(x, 10);
// Member local function -- but implemention uses undefined
behaviour.
CONTRACT_AUX_LOCAL_FUNCTION_DECL(
(int) (minc)( (c*)(this) (const int&)(delta) ) // Can be cv-
qualified.
) {
return x_ = get() + delta; // Implicit `this` as in member
func.
} };
y = CONTRACT_AUX_LOCAL_FUNCTION_CALL(minc)(this, 100);
// Non-member local function with object parameter
(implemetation does
// not use undefined behaviour but user must explicitly use
`this_`).
CONTRACT_AUX_LOCAL_FUNCTION_DECL(
// `this_` type `c*` can be cv-qualified.
(int) (minc_)( (c*)(this_) (const int&)(delta) )
) {
return this_->x_ = this_->get() + delta; // Object via
`this_`.
} };
y = CONTRACT_AUX_LOCAL_FUNCTION_CALL(minc_)(this, 1000);
}
private:
int x_;
};
The #definitions of the `CONTRACT_AUX_LOCAL_FUNCTION_...` macros rely
on a rather large number of helper macros so I could not show it here
but you can find it at:
http://dbcpp.svn.sourceforge.net/viewvc/dbcpp/branches/msvc/src/contract/aux_/local_function.hpp?revision=698&view=markup
--
Lorenzo