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

Discussion in 'C++' started by Peter Olcott, Jun 15, 2008.

  1. Peter Olcott

    Peter Olcott Guest

    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.
     
    Peter Olcott, Jun 15, 2008
    #1
    1. Advertising

  2. Peter Olcott

    Daniel Pitts Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    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/>
     
    Daniel Pitts, Jun 15, 2008
    #2
    1. Advertising

  3. Peter Olcott

    Peter Olcott Guest

    "Daniel Pitts" <>
    wrote in message
    news:485537da$0$13359$...
    > 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/>
     
    Peter Olcott, Jun 15, 2008
    #3
  4. Re: Providing a no-overhead way for a contained class to access itscontainer?

    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
     
    Carlo Milanesi, Jun 15, 2008
    #4
  5. Peter Olcott

    Peter Olcott Guest

    "Carlo Milanesi" <> wrote in
    message news:48554e13$0$17933$...
    > 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.
     
    Peter Olcott, Jun 15, 2008
    #5
  6. Peter Olcott

    Peter Olcott Guest

    "Alf P. Steinbach" <> wrote in message
    news:...
    >* 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?
     
    Peter Olcott, Jun 15, 2008
    #6
  7. Peter Olcott

    Jerry Coffin Guest

    In article <kuc5k.2413$>,
    says...
    >
    > "Alf P. Steinbach" <> 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.
     
    Jerry Coffin, Jun 15, 2008
    #7
  8. Peter Olcott

    Peter Olcott Guest

    "Jerry Coffin" <> wrote in message
    news:...
    > In article <kuc5k.2413$>,
    >
    > says...
    >>
    >> "Alf P. Steinbach" <> 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!
     
    Peter Olcott, Jun 15, 2008
    #8
  9. Peter Olcott

    Daniel Pitts Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    Peter Olcott wrote:
    > "Carlo Milanesi" <> wrote in
    > message news:48554e13$0$17933$...
    >> 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/>
     
    Daniel Pitts, Jun 15, 2008
    #9
  10. Peter Olcott

    Daniel Pitts Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    Daniel Pitts wrote:
    > Peter Olcott wrote:
    >> "Carlo Milanesi" <> wrote in message
    >> news:48554e13$0$17933$...
    >>> 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/>
     
    Daniel Pitts, Jun 15, 2008
    #10
  11. Peter Olcott

    Jerry Coffin Guest

    In article <2Xc5k.2415$>,
    says...
    >
    > "Jerry Coffin" <> wrote in message
    > news:...
    > > In article <kuc5k.2413$>,
    > >
    > > says...
    > >>
    > >> "Alf P. Steinbach" <> 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.
     
    Jerry Coffin, Jun 15, 2008
    #11
  12. Peter Olcott

    Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    On Jun 15, 10:35 am, "Peter Olcott" <> wrote:
    > "Carlo Milanesi" <> wrote in
    > messagenews:48554e13$0$17933$...
    >
    > > 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
     
    , Jun 15, 2008
    #12
  13. Peter Olcott

    Peter Olcott Guest

    <> wrote in message
    news:...
    > On Jun 15, 10:35 am, "Peter Olcott" <>
    > wrote:
    >> "Carlo Milanesi" <> wrote
    >> in
    >> messagenews:48554e13$0$17933$...
    >>
    >> > 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.
     
    Peter Olcott, Jun 15, 2008
    #13
  14. Peter Olcott

    Puppet_Sock Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    On Jun 15, 11:18 am, "Peter Olcott" <> 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
     
    Puppet_Sock, Jun 16, 2008
    #14
  15. Peter Olcott

    PeteOlcott Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    On Jun 16, 8:27 am, (Yannick Tremblay) wrote:
    > In article <QWg5k.5453$>,
    >
    >
    >
    >
    >
    > Peter Olcott <> wrote:
    >
    > ><> wrote in message
    > >news:...

    >
    > >>> 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.
     
    PeteOlcott, Jun 17, 2008
    #15
  16. Peter Olcott

    PeteOlcott Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    On Jun 16, 9:51 am, Puppet_Sock <> wrote:
    > On Jun 15, 11:18 am, "Peter Olcott" <> 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.
     
    PeteOlcott, Jun 17, 2008
    #16
  17. Peter Olcott

    Daniel Pitts Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    PeteOlcott wrote:
    > On Jun 16, 9:51 am, Puppet_Sock <> wrote:
    >> On Jun 15, 11:18 am, "Peter Olcott" <> 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/>
     
    Daniel Pitts, Jun 17, 2008
    #17
  18. Peter Olcott

    Peter Olcott Guest

    "Jerry Coffin" <> wrote in message
    news:...
    > In article <2Xc5k.2415$>,
    >
    > says...
    >>
    >> "Jerry Coffin" <> wrote in message
    >> news:...
    >> > In article <kuc5k.2413$>,
    >> >
    >> > says...
    >> >>
    >> >> "Alf P. Steinbach" <> 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.
     
    Peter Olcott, Jun 17, 2008
    #18
  19. Peter Olcott

    Jerry Coffin Guest

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

    In article <5dd80816-49c4-442d-a25c-076b6c260305
    @y21g2000hsf.googlegroups.com>, 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::eek:stream_iterator<int>(std::cout, "\n"));
    return 0;
    }

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Jun 17, 2008
    #19
  20. Peter Olcott

    PeteOlcott Guest

    Re: Providing a no-overhead way for a contained class to access itscontainer?

    On Jun 17, 1:00 am, Jerry Coffin <> wrote:
    > In article <5dd80816-49c4-442d-a25c-076b6c260305
    > @y21g2000hsf.googlegroups.com>, 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::eek: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?
     
    PeteOlcott, Jun 17, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xamalek
    Replies:
    7
    Views:
    690
  2. Francis Hwang
    Replies:
    2
    Views:
    92
    Francis Hwang
    Jun 4, 2004
  3. thunk
    Replies:
    1
    Views:
    315
    thunk
    Mar 30, 2010
  4. thunk
    Replies:
    0
    Views:
    488
    thunk
    Apr 1, 2010
  5. thunk
    Replies:
    14
    Views:
    626
    thunk
    Apr 3, 2010
Loading...

Share This Page