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?

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


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

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
 
 
 
Peter Olcott
Guest
Posts: n/a
 
      06-15-2008

"Daniel Pitts" <(E-Mail Removed)>
wrote in message
news:485537da$0$13359$(E-Mail Removed)...
> Peter Olcott wrote:
>> 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.
>


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.

> --
> Daniel Pitts' Tech Blog:
> <http://virtualinfinity.net/wordpress/>



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

--
Carlo Milanesi
http://digilander.libero.it/carlmila
 
Reply With Quote
 
Peter Olcott
Guest
Posts: n/a
 
      06-15-2008

"Carlo Milanesi" <(E-Mail Removed)> wrote in
message news:48554e13$0$17933$(E-Mail Removed)...
> 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 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.


 
Reply With Quote
 
Peter Olcott
Guest
Posts: n/a
 
      06-15-2008

"Alf P. Steinbach" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>* Peter Olcott:
>>
>> 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.

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

>
>
> Cheers,
>
> - Alf
>
> --
> A: Because it messes up the order in which people normally
> read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in
> e-mail?



 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      06-15-2008
In article <kuc5k.2413$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(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.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Peter Olcott
Guest
Posts: n/a
 
      06-15-2008

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


 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      06-15-2008
Peter Olcott wrote:
> "Carlo Milanesi" <(E-Mail Removed)> wrote in
> message news:48554e13$0$17933$(E-Mail Removed)...
>> 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 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' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      06-15-2008
Daniel Pitts wrote:
> Peter Olcott wrote:
>> "Carlo Milanesi" <(E-Mail Removed)> wrote in message
>> news:48554e13$0$17933$(E-Mail Removed)...
>>> 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 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.
>

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

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
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