Providing a no-overhead way for a contained class to access its container?

[Peter Olcott]

So far the only way that I found to do this was by making a
single global instance of the container class and providing
access to the contained class, through this single global
instance. Are there any other no-overhead ways that a
contained class can access its container?

The obvious choice of passing (a pointer or a reference to
the container) to the contained class is not a no-overhead
solution, it requires both memory and time. I am hoping that
there might be some obscure C++ syntax that provides the
capability that I am seeking, without the need to resort to
the single global instance of the container to provide
access.

 

[Daniel Pitts]

So far the only way that I found to do this was by making a
single global instance of the container class and providing
access to the contained class, through this single global
instance. Are there any other no-overhead ways that a
contained class can access its container?

The obvious choice of passing (a pointer or a reference to
the container) to the contained class is not a no-overhead
solution, it requires both memory and time. I am hoping that
there might be some obscure C++ syntax that provides the
capability that I am seeking, without the need to resort to
the single global instance of the container to provide
access.

It sounds like you may be asking the wrong thing. For one thing, you're
creating a tight-coupling between the contained and the container. This
prevents your contained objects from being in two separate containers at
the same time.

The other possible problem is the "no-overhead" requirement. Don't
optimize prematurely. Only worry about overhead when you find that
you're running out of memory, or that you're algorithm takes too long to
run. And then, use a profiler to determine exactly *where* your code
needs optimization.

I know its not the answer you're looking for, but I hope it helps you
non-the-less.

Good luck,
Daniel.

 

[Peter Olcott]

"Daniel Pitts" <[email protected]>
wrote in message

It sounds like you may be asking the wrong thing. For one
thing, you're creating a tight-coupling between the
contained and the container. This prevents your contained
objects from being in two separate containers at the same
time.

The other possible problem is the "no-overhead"
requirement. Don't optimize prematurely. Only worry
about overhead when you find that you're running out of
memory, or that you're algorithm takes too long to run.
And then, use a profiler to determine exactly *where* your
code needs optimization.

I know its not the answer you're looking for, but I hope
it helps you non-the-less.

Good luck,
Daniel.

I already have a solution that meets all of my criteria,
what I am looking for is a cleaner solution. Either such a
solution exists, or it does not exist. If it does not exist,
then no further discussion is required, and my somewhat
clumsy solution will have to suffice.

The no-overhead requirement is a binding constraint that can
not be avoided. Adding any space or time overhead makes the
project infeasible. This project provides a solution where
alternative solutions do not exist, and this aspect of the
design provides the core functionality of the system.

 

[Carlo Milanesi]

Peter Olcott ha scritto:

So far the only way that I found to do this was by making a
single global instance of the container class and providing
access to the contained class, through this single global
instance. Are there any other no-overhead ways that a
contained class can access its container?

You should think whether a solution is possible in any other programming
language, machine language included.
If it is not possible in machine language, of course it is possible
neither in C++.

The only solution I can think of is applicable only if your collections
occupy distinct memory pools. For example, if your collections are
arrays, you could check if the address of your object is between the
begin address and the end address of that array.
But that has a overhead though. To find the right array you have to loop
over all the arrays or something like that.

 

[Peter Olcott]

Peter Olcott ha scritto:

You should think whether a solution is possible in any
other programming language, machine language included.
If it is not possible in machine language, of course it is
possible neither in C++.

I can do it in C++, but, the solution is clumsy. I am
looking for a less clumsy C++ solution, if one exists.

The only solution I can think of is applicable only if
your collections occupy distinct memory pools. For
example, if your collections are arrays, you could check
if the address of your object is between the begin address
and the end address of that array.
But that has a overhead though. To find the right array
you have to loop over all the arrays or something like
that.

I have a solution that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>. Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>, specifying which ContainerClass
is being used. There would be no extra overhead in the use
of either the ContainerClass, nor its ContainedClass.

 

[Peter Olcott]

* Peter Olcott:

Hm, that sounds like much bullshit and zero information,
iow., trolling.

www.SeeScreen.com
This technology can be applied to the automated testing of
video games. Video games are currently a $37 Billion annual
market, and all testing is done manually by human testers.

 

[Jerry Coffin]

"Alf P. Steinbach" <[email protected]> wrote in message

[ ... ]

www.SeeScreen.com
This technology can be applied to the automated testing of
video games. Video games are currently a $37 Billion annual
market, and all testing is done manually by human testers.

This looks like it retains the same level of information (i.e. none) and
adds only distraction. The question is exactly why you require zero
overhead for this particular aspect of a program. The annual revenues of
video games has nothing whatsoever to do with the question at hand.

 

[Peter Olcott]

(e-mail address removed)
says...

"Alf P. Steinbach" <[email protected]> wrote in message

[ ... ]

www.SeeScreen.com
This technology can be applied to the automated testing
of
video games. Video games are currently a $37 Billion
annual
market, and all testing is done manually by human
testers.

This looks like it retains the same level of information
(i.e. none) and
adds only distraction. The question is exactly why you
require zero
overhead for this particular aspect of a program. The
annual revenues of
video games has nothing whatsoever to do with the question
at hand.

I was directly addressing your last remark, which itself
avoided rather than addressed the issue at hand. You really
don't need to know these details to answer my question. The
question is how can a contained class access its container
without adding any overhead? It seems like you are saying
(in a very convoluted way) that you simply don't know. Good
enough, no need for further discussion.

--
Later,
Jerry.

The universe is a figment of its own imagination.

YES, I agree!

 

[Daniel Pitts]

I can do it in C++, but, the solution is clumsy. I am
looking for a less clumsy C++ solution, if one exists.


I have a solution that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>. Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>, specifying which ContainerClass
is being used. There would be no extra overhead in the use
of either the ContainerClass, nor its ContainedClass.

I'm not sure, but Boosts intrusive containers give you what you're
looking for, and then some.

 

[Daniel Pitts]

I'm not sure, but Boosts intrusive containers give you what you're
looking for, and then some.

I meant "may" give you what you're looking for.

 

[Jerry Coffin]

(e-mail address removed)
says...

"Alf P. Steinbach" <[email protected]> wrote in message

[ ... ]

Hm, that sounds like much bullshit and zero
information,
iow., trolling.

www.SeeScreen.com
This technology can be applied to the automated testing
of
video games. Video games are currently a $37 Billion
annual
market, and all testing is done manually by human
testers.

This looks like it retains the same level of information
(i.e. none) and
adds only distraction. The question is exactly why you
require zero
overhead for this particular aspect of a program. The
annual revenues of
video games has nothing whatsoever to do with the question
at hand.

I was directly addressing your last remark, which itself
avoided rather than addressed the issue at hand.

This was the first post I'd made to this thread, so none of your remarks
shows any sign of addressing anything I'd said previously.

You really
don't need to know these details to answer my question. The
question is how can a contained class access its container
without adding any overhead? It seems like you are saying
(in a very convoluted way) that you simply don't know. Good
enough, no need for further discussion.

I'm not saying I do or don't know -- I simply pointed out a serious
problem with your post. Unfortunately, I don't have a direct answer to
your question, largely because I don't think your question is entirely
clear -- in particular, while you say absolutely no overhead is allowed,
you don't say whether it's purely time overhead, space overhead, or both
that must be eliminated to qualify.

My guess is that there is no real answer -- if there is a possibility of
more than one collection to which an object might belong, _something_
must record which for the program to know -- and no matter how careful
one is to minimize that, it must still exist. Likewise if/when (for one
example) an object is moved from one collection to another, that
something must be updated to match -- and, again, no matter how
carefully that update time is optimized, it can never be reduced to
zero.

 

[acehreli]

I can do it in C++, but, the solution is clumsy. I am
looking for a less clumsy C++ solution, if one exists.




I have a solution

That is not a solution to the question you have in the subject line.
You are asking whether the contained class can have access to the
container without any overhead. No, it cannot.

Then you're providing a solution where a particular class has access
to particular instances of containers.

The fact that you *limit* the access to a certain class doesn't make
that a solution of "some class accessing its container." What you have
is a solution where everybody can access globals. That has been there
for decades.

that allows the existence of multiple
instances of the container class, the number of such
instances can be specified at run-time. These multiple
instances would be stored in a single global
std::vector<ContainerClass>.

And that's no memory overhead?

Another single instance global
integer would be used as the current subscript into this
std::vector<ContainerClass>,

How about that one? That is both a memory overhead and a time
overhead, because you need to manage it in non-zero time.

specifying which ContainerClass
is being used. There would be no extra overhead in the use
of either the ContainerClass, nor its ContainedClass.

When an object "uses" the container, it does it so because some time
has been spent to set the global(s) properly. That is overhead.

You may have something else in mind but you are not asking that.

Ali

 

[Peter Olcott]

That is not a solution to the question you have in the
subject line.
You are asking whether the contained class can have access
to the
container without any overhead. No, it cannot.

Then you're providing a solution where a particular class
has access
to particular instances of containers.

The fact that you *limit* the access to a certain class
doesn't make
that a solution of "some class accessing its container."
What you have
is a solution where everybody can access globals. That has
been there
for decades.


And that's no memory overhead?


How about that one? That is both a memory overhead and a
time
overhead, because you need to manage it in non-zero time.


When an object "uses" the container, it does it so because
some time
has been spent to set the global(s) properly. That is
overhead.

You may have something else in mind but you are not asking
that.

Ali

With my solution there is no additional memory or time
required for the contained class to access its container
over and above the memory and time required for any class to
access any other class.

 

[Puppet_Sock]

I am hoping that
there might be some obscure C++ syntax that provides the
capability that I am seeking, without the need to resort to
the single global instance of the container to provide
access.

Did you ever stop to consider the possibility that your
goal is ill chosen? Making an object know that it is
contained in a container is not a good design plan.
An object should not be doing different things based
on how it is being held.

The phrase "obscure C++ syntax" ought to be a warning
signal in your own mind that you are approaching things
from the wrong end.

Maybe you need to refactor things so that you don't need
to do this.
Socks

 

[PeteOlcott]

Uh?  

Interesting solution.  So if I make is very difficult for any class to
access any other class, then I can solve your problem since all the
book keeping and dereferencing needed for a class to access its
container will not be "over and above" what is needed for any other
classes.  ?!?

Sorry but you are lying to yourself:
- having globals is overhead.  
- having single instance globals is overhead
- having a global container is overhead.
- having a global container of containers is overhead (vector<ContainerClass>)
- having a global integer that is used as index into a vecotr is
overhead, you need to call vector.at(global_int).  That is not free.

So that reduces your statement to: "I have a solution that has no
overhead that I don't ignore nor any that I am not unaware of."

Yannick- Hide quoted text -

- Show quoted text -

http://en.wikipedia.org/wiki/Computational_overhead
Overhead is only the EXTRA cost over-and-above providing the basic
functionality.

My solution (although clumsy) has no EXTRA cost over and above the
normal cost of one class accessing another class.

The most typical solution would require that a pointer to the
container be passed to the contained class. This typical solution does
require an EXTRA cost over-and-above the basic cost of one class
accessing another class. The pointer takes memory, and it must also be
copied.

 

[PeteOlcott]

Did you ever stop to consider the possibility that your
goal is ill chosen? Making an object know that it is
contained in a container is not a good design plan.
An object should not be doing different things based
on how it is being held.

The phrase "obscure C++ syntax" ought to be a warning
signal in your own mind that you are approaching things
from the wrong end.

Maybe you need to refactor things so that you don't need
to do this.
Socks

I am completely certain that my design is optimal in this specific
case even though it necessarily breaks some of the established rules.
The only reason that I even need to have the contained class is so
that I can overload the operator<() on it, and thus use std::sort().

I am beginning to think that my clumsy solution is the only possible
way (that can be implemented in C++) for providing access to a
contained classe's container that does not require any additional
space or time over-and-above the essential time and space required for
one class to access another.

 

[Daniel Pitts]

I am completely certain that my design is optimal in this specific
case even though it necessarily breaks some of the established rules.
The only reason that I even need to have the contained class is so
that I can overload the operator<() on it, and thus use std::sort().

The point that people are trying to make is that you don't necessary
need "optimal" at this level. It is not impossible you do, but often
times the inexperienced programmer will think they need to make low
optimizations, which is often wrong, and leads to a slower/less stable
product.

I am beginning to think that my clumsy solution is the only possible
way (that can be implemented in C++) for providing access to a
contained classe's container that does not require any additional
space or time over-and-above the essential time and space required for
one class to access another.

It may be the only way to implement the particular design you're
insisting on. It is definitely not the only way to implement a solution
to your particular problem.

 

[Peter Olcott]

(e-mail address removed)
says...

(e-mail address removed)
says...


[ ... ]

Hm, that sounds like much bullshit and zero
information,
iow., trolling.

www.SeeScreen.com
This technology can be applied to the automated
testing
of
video games. Video games are currently a $37 Billion
annual
market, and all testing is done manually by human
testers.

This looks like it retains the same level of
information
(i.e. none) and
adds only distraction. The question is exactly why you
require zero
overhead for this particular aspect of a program. The
annual revenues of
video games has nothing whatsoever to do with the
question
at hand.

I was directly addressing your last remark, which itself
avoided rather than addressed the issue at hand.

This was the first post I'd made to this thread, so none
of your remarks
shows any sign of addressing anything I'd said previously.

You really
don't need to know these details to answer my question.
The
question is how can a contained class access its
container
without adding any overhead? It seems like you are saying
(in a very convoluted way) that you simply don't know.
Good
enough, no need for further discussion.

I'm not saying I do or don't know -- I simply pointed out
a serious
problem with your post. Unfortunately, I don't have a
direct answer to
your question, largely because I don't think your question
is entirely
clear -- in particular, while you say absolutely no
overhead is allowed,
you don't say whether it's purely time overhead, space
overhead, or both
that must be eliminated to qualify.

The somewhat clumsy solution that I derived takes zero extra
space and zero extra time over-and-above the space and time
required for a typical class to access another.

My guess is that there is no real answer -- if there is a
possibility of
more than one collection to which an object might belong,
_something_
must record which for the program to know -- and no matter
how careful
one is to minimize that, it must still exist. Likewise
if/when (for one
example) an object is moved from one collection to
another, that
something must be updated to match -- and, again, no
matter how
carefully that update time is optimized, it can never be
reduced to
zero.

The extra time and space required for a contained class to
access its container over-and-above the time and space
required for a typical class to access another can be and
has been reduced to zero. There is a very slight extra time
and extra space cost for switching between multiple
containers if and only if there is more than one such
container.

 

[Jerry Coffin]

[ ... ]

The only reason that I even need to have the contained class is so
that I can overload the operator<() on it, and thus use std::sort().

You can use std::sort without having an overloaded operator< for the
type. You can create the comparison as either a function or a functor,
and then pass it as the third parameter to std::sort. For example:

#include <vector>
#include <algorithm>
#include <iostream>

class X {
int y;
public:
X(int a=0) : y(a) {}
operator int() const { return y; }
};

struct less {
bool operator()(X const &a, X const &b) {
return (int)a < (int)b;
}
};

int main() {
std::vector<X> x;

for (int i=0; i<20; i++)
x.push_back(rand());

std::sort(x.begin(), x.end(), less());
std::copy(x.begin(), x.end(),
std:stream_iterator<int>(std::cout, "\n"));
return 0;
}

 

[PeteOlcott]

[ ... ]

The only reason that I even need to have the contained class is so
that I can overload the operator<() on it, and thus use std::sort().

You can use std::sort without having an overloaded operator< for the
type. You can create the comparison as either a function or a functor,
and then pass it as the third parameter to std::sort. For example:

#include <vector>
#include <algorithm>
#include <iostream>

class X {
        int y;
public:
        X(int a=0) : y(a) {}
        operator int() const { return y; }

};

struct less {
        bool operator()(X const &a, X const &b) {
                return (int)a < (int)b;
        }

};

int main() {
        std::vector<X> x;

        for (int i=0; i<20; i++)
                x.push_back(rand());

        std::sort(x.begin(), x.end(), less());
        std::copy(x.begin(), x.end(),
                std:stream_iterator<int>(std::cout, "\n"));  
        return 0;

}

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

What about the case where the contained class must store its data in
its container?