Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Providing a no-overhead way for a contained class to access its container?

Reply
Thread Tools

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

 
 
Jerry Coffin
Guest
Posts: n/a
 
      06-15-2008
In article <2Xc5k.2415$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed)
says...
>
> "Jerry Coffin" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > In article <kuc5k.2413$(E-Mail Removed)>,
> > (E-Mail Removed)
> > says...
> >>
> >> "Alf P. Steinbach" <(E-Mail Removed)> 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.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
 
 
 
acehreli@gmail.com
Guest
Posts: n/a
 
      06-15-2008
On Jun 15, 10:35 am, "Peter Olcott" <(E-Mail Removed)> wrote:
> "Carlo Milanesi" <(E-Mail Removed)> wrote in
> messagenews:48554e13$0$17933$(E-Mail Removed). it...
>
> > 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++.

>
> 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.

>
> > --
> > Carlo Milanesi
> > http://digilander.libero.it/carlmila

>
> 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
 
Reply With Quote
 
 
 
 
Peter Olcott
Guest
Posts: n/a
 
      06-15-2008

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Jun 15, 10:35 am, "Peter Olcott" <(E-Mail Removed)>
> wrote:
>> "Carlo Milanesi" <(E-Mail Removed)> wrote
>> in
>> messagenews:48554e13$0$17933$(E-Mail Removed). it...
>>
>> > 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++.

>>
>> 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.

>>
>> > --
>> > Carlo Milanesi
>> > http://digilander.libero.it/carlmila

>>
>> 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


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.


 
Reply With Quote
 
Puppet_Sock
Guest
Posts: n/a
 
      06-16-2008
On Jun 15, 11:18*am, "Peter Olcott" <(E-Mail Removed)> wrote:
[snip]
> 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
 
Reply With Quote
 
PeteOlcott
Guest
Posts: n/a
 
      06-16-2008
On Jun 16, 8:27*am, (E-Mail Removed) (Yannick Tremblay) wrote:
> In article <QWg5k.5453$(E-Mail Removed)>,
>
>
>
>
>
> Peter Olcott <(E-Mail Removed)> wrote:
>
> ><(E-Mail Removed)> wrote in message
> >news:(E-Mail Removed)...

>
> >>> 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.

>
> >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.

>
> 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.
 
Reply With Quote
 
PeteOlcott
Guest
Posts: n/a
 
      06-16-2008
On Jun 16, 9:51*am, Puppet_Sock <(E-Mail Removed)> wrote:
> On Jun 15, 11:18*am, "Peter Olcott" <(E-Mail Removed)> wrote:
> [snip]
>
> > 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


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.
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      06-17-2008
PeteOlcott wrote:
> On Jun 16, 9:51 am, Puppet_Sock <(E-Mail Removed)> wrote:
>> On Jun 15, 11:18 am, "Peter Olcott" <(E-Mail Removed)> wrote:
>> [snip]
>>
>>> 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

>
> 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.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Peter Olcott
Guest
Posts: n/a
 
      06-17-2008

"Jerry Coffin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <2Xc5k.2415$(E-Mail Removed)>,
> (E-Mail Removed)
> says...
>>
>> "Jerry Coffin" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > In article <kuc5k.2413$(E-Mail Removed)>,
>> > (E-Mail Removed)
>> > says...
>> >>
>> >> "Alf P. Steinbach" <(E-Mail Removed)> 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.
>

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.

>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.



 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      06-17-2008
In article <5dd80816-49c4-442d-a25c-076b6c260305
@y21g2000hsf.googlegroups.com>, (E-Mail Removed) says...

[ ... ]

> 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.
 
Reply With Quote
 
PeteOlcott
Guest
Posts: n/a
 
      06-17-2008
On Jun 17, 1:00*am, Jerry Coffin <(E-Mail Removed)> wrote:
> In article <5dd80816-49c4-442d-a25c-076b6c260305
> @y21g2000hsf.googlegroups.com>, (E-Mail Removed) says...
>
> [ ... ]
>
> > 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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"An attempt was made to access a socket in a way forbidden by its access permissions" exiter Computer Support 3 02-27-2012 08:36 PM
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 14 04-03-2010 10:08 AM
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 0 04-01-2010 10:25 PM
Its a bird, its a plane, no ummm, its a Ruide thunk Ruby 1 03-30-2010 11:10 AM
Providing services for 802.11b and 802.11g on the cisco 1200 access points Chris Davies Cisco 6 06-15-2004 01:42 PM



Advertisments