storing pointer vs storing object

Discussion in 'C++' started by toton, Oct 11, 2006.

  1. toton

    toton Guest

    Hi,
    all of the containers in STL stores object itself (thus copy
    contsructability & assignability is needed), while NTL or boost
    ptr_container stores pointer to the object in the container (either
    exclusively owns, or just stores).
    Now, my question is for a general guideline when to use which one?
    What I understand,
    1) polymorphic objects need ptr_container.
    2) non copy constructable, non assignable objects need ptr_container.

    Other than that, any guideline is there? I am specially interested for
    small devices (handheld, pda etc) with limited memory, where gaining
    performance is important.
    To be specific, can it be a guideline like, lots of small objects =>
    STL container (faster due to cache effect)., a few large objects (like
    GUI widgets) , use ptr_container. So, why there should be two different
    types of container, and when one or the other would be used?

    thanks
    abir
    toton, Oct 11, 2006
    #1
    1. Advertising

  2. toton

    KiLVaiDeN Guest

    > toton wrote:
    >
    > Hi,
    > all of the containers in STL stores object itself (thus copy
    > contsructability & assignability is needed), while NTL or boost
    > ptr_container stores pointer to the object in the container (either
    > exclusively owns, or just stores).
    > Now, my question is for a general guideline when to use which one?
    > What I understand,
    > 1) polymorphic objects need ptr_container.
    > 2) non copy constructable, non assignable objects need ptr_container.
    >
    > Other than that, any guideline is there? I am specially interested for
    > small devices (handheld, pda etc) with limited memory, where gaining
    > performance is important.
    > To be specific, can it be a guideline like, lots of small objects =>
    > STL container (faster due to cache effect)., a few large objects (like
    > GUI widgets) , use ptr_container. So, why there should be two different
    > types of container, and when one or the other would be used?
    >
    > thanks
    > abir


    Hi,

    Storing a copy of the original data is in my opinion only usefull when
    you need to have very fast access to little values, as you mentionned.
    For exemple in a very demanding loop, storuing object copies might be a
    good idea, if those are often used. Because accessing to pointed data
    is always slower than accessing directly to the copy.

    A rule of thumb I'd say :

    If your concern is memory optimization with reasonable speed ->
    pointers/reference

    If your concern is speed AND you have sufficient memory AND you store
    little objects -> copy ( because the copy of big objects can be a
    little slow )

    Cheers,
    K
    KiLVaiDeN, Oct 11, 2006
    #2
    1. Advertising

  3. toton

    Gavin Deane Guest

    KiLVaiDeN wrote:
    > > toton wrote:
    > >
    > > Hi,
    > > all of the containers in STL stores object itself (thus copy
    > > contsructability & assignability is needed), while NTL or boost
    > > ptr_container stores pointer to the object in the container (either
    > > exclusively owns, or just stores).
    > > Now, my question is for a general guideline when to use which one?
    > > What I understand,
    > > 1) polymorphic objects need ptr_container.
    > > 2) non copy constructable, non assignable objects need ptr_container.
    > >
    > > Other than that, any guideline is there? I am specially interested for
    > > small devices (handheld, pda etc) with limited memory, where gaining
    > > performance is important.
    > > To be specific, can it be a guideline like, lots of small objects =>
    > > STL container (faster due to cache effect)., a few large objects (like
    > > GUI widgets) , use ptr_container. So, why there should be two different
    > > types of container, and when one or the other would be used?
    > >
    > > thanks
    > > abir

    >
    > Hi,
    >
    > Storing a copy of the original data is in my opinion only usefull when
    > you need to have very fast access to little values, as you mentionned.
    > For exemple in a very demanding loop, storuing object copies might be a
    > good idea, if those are often used. Because accessing to pointed data
    > is always slower than accessing directly to the copy.
    >
    > A rule of thumb I'd say :
    >
    > If your concern is memory optimization with reasonable speed ->
    > pointers/reference
    >
    > If your concern is speed AND you have sufficient memory AND you store
    > little objects -> copy ( because the copy of big objects can be a
    > little slow )


    Unless and until proven otherwise, both those concerns are secondary
    to:

    "Which option produces the most clearly human-readable code" and
    "Which option enables you to get to the point where that code is
    written, teted and error-free more quickly"

    So, to the OP: consider the options in that context and choose
    whichever answers those questions best. If you find, for example, that
    it takes longer (including testing and debugging time) to write correct
    code using containers of pointers, and that code is less clear to a
    human reader, then use containers of objects.

    Premature optimisation is the root of all evil and all that.

    Gavin Deane
    Gavin Deane, Oct 11, 2006
    #3
  4. toton

    KiLVaiDeN Guest

    > Gavin Deane wrote:
    >
    > Unless and until proven otherwise, both those concerns are secondary
    > to:
    >
    > "Which option produces the most clearly human-readable code" and
    > "Which option enables you to get to the point where that code is
    > written, teted and error-free more quickly"
    >
    > So, to the OP: consider the options in that context and choose
    > whichever answers those questions best. If you find, for example, that
    > it takes longer (including testing and debugging time) to write correct
    > code using containers of pointers, and that code is less clear to a
    > human reader, then use containers of objects.
    >
    > Premature optimisation is the root of all evil and all that.
    >
    > Gavin Deane


    I totally agree with your point, in a normal environnement, but he's
    working for small devices, therefore it's not only a matter of
    Optimization, but more a matter of good practices for those targeted
    platforms.

    The considerations you make are very valuable though; The best is to
    test both of the scenarios, see how it's managed in your targeted
    device, and then sticking to one or another; Tell me if you agree :)

    Cheers,
    K
    KiLVaiDeN, Oct 11, 2006
    #4
  5. toton

    Gavin Deane Guest

    KiLVaiDeN wrote:
    > > Gavin Deane wrote:
    > >
    > > Unless and until proven otherwise, both those concerns are secondary
    > > to:
    > >
    > > "Which option produces the most clearly human-readable code" and
    > > "Which option enables you to get to the point where that code is
    > > written, teted and error-free more quickly"
    > >
    > > So, to the OP: consider the options in that context and choose
    > > whichever answers those questions best. If you find, for example, that
    > > it takes longer (including testing and debugging time) to write correct
    > > code using containers of pointers, and that code is less clear to a
    > > human reader, then use containers of objects.
    > >
    > > Premature optimisation is the root of all evil and all that.
    > >
    > > Gavin Deane

    >
    > I totally agree with your point, in a normal environnement, but he's
    > working for small devices, therefore it's not only a matter of
    > Optimization, but more a matter of good practices for those targeted
    > platforms.


    He did say he was working with small devices. I am not sure that good
    practice differs very much though. My comments boil down to "Unless and
    until proven necessary, don't optimise at the expense of clear, concise
    code". It may happen to be that in the OP's case, such optimisation is
    proven necessary more often than not. That would not contradict my
    comments.

    > The considerations you make are very valuable though; The best is to
    > test both of the scenarios, see how it's managed in your targeted
    > device, and then sticking to one or another; Tell me if you agree :)


    Absolutely. And with increasing experience of your development tools
    and target environment, you will become better able to correctly
    predict what will and will not be a problem without necessarily testing
    every last detail.

    What does not work however, is to guess, or to work to arbitrary
    guidelines not based on evidence, which is the trap it looked like the
    OP might be wandering towards.

    Gavin Deane
    Gavin Deane, Oct 11, 2006
    #5
  6. toton

    Kaz Kylheku Guest

    toton wrote:
    > Hi,
    > all of the containers in STL stores object itself (thus copy
    > contsructability & assignability is needed),


    False. The STL containers can be used over pointers, e.g.:

    std::set<Type *>

    instead of

    std::set<Type>

    And of course they can be used over smart pointers also

    std::set<SmartPointer<Type> >.

    The Type might not be copy-constructable or assignable, but the smart
    pointer is.
    Kaz Kylheku, Oct 11, 2006
    #6
  7. toton

    Kaz Kylheku Guest

    Gavin Deane wrote:
    > Unless and until proven otherwise, both those concerns are secondary
    > to:
    >
    > "Which option produces the most clearly human-readable code" and
    > "Which option enables you to get to the point where that code is
    > written, teted and error-free more quickly"


    That would be, whichever option involves the least possible amount of
    C++.

    Since you're using C++, you've relegated these concerns to a very low
    priority.
    Kaz Kylheku, Oct 11, 2006
    #7
  8. toton

    Gavin Deane Guest

    Kaz Kylheku wrote:
    > Gavin Deane wrote:
    > > Unless and until proven otherwise, both those concerns are secondary
    > > to:
    > >
    > > "Which option produces the most clearly human-readable code" and
    > > "Which option enables you to get to the point where that code is
    > > written, teted and error-free more quickly"

    >
    > That would be, whichever option involves the least possible amount of
    > C++.
    >
    > Since you're using C++, you've relegated these concerns to a very low
    > priority.


    I'm not sure I follow you. At what point in the software development
    process does either the need to produce clearly human-readable and
    therefore easily maintainable code or the need to get from the point of
    having no code to the point of having written, tested and debugged code
    faster rather than slower become a very low priority?

    Gavin Deane
    Gavin Deane, Oct 12, 2006
    #8
  9. toton

    Kaz Kylheku Guest

    Gavin Deane wrote:
    > Kaz Kylheku wrote:
    > > Gavin Deane wrote:
    > > > Unless and until proven otherwise, both those concerns are secondary
    > > > to:
    > > >
    > > > "Which option produces the most clearly human-readable code" and
    > > > "Which option enables you to get to the point where that code is
    > > > written, teted and error-free more quickly"

    > >
    > > That would be, whichever option involves the least possible amount of
    > > C++.
    > >
    > > Since you're using C++, you've relegated these concerns to a very low
    > > priority.

    >
    > I'm not sure I follow you. At what point in the software development
    > process does either the need to produce clearly human-readable and
    > therefore easily maintainable code or the need to get from the point of
    > having no code to the point of having written, tested and debugged code
    > faster rather than slower become a very low priority?


    At that point in the process when it was decided to do it in C++.
    Kaz Kylheku, Oct 12, 2006
    #9
  10. toton

    Gavin Deane Guest

    Kaz Kylheku wrote:
    > Gavin Deane wrote:
    > > Kaz Kylheku wrote:
    > > > Gavin Deane wrote:
    > > > > Unless and until proven otherwise, both those concerns are secondary
    > > > > to:
    > > > >
    > > > > "Which option produces the most clearly human-readable code" and
    > > > > "Which option enables you to get to the point where that code is
    > > > > written, teted and error-free more quickly"
    > > >
    > > > That would be, whichever option involves the least possible amount of
    > > > C++.
    > > >
    > > > Since you're using C++, you've relegated these concerns to a very low
    > > > priority.

    > >
    > > I'm not sure I follow you. At what point in the software development
    > > process does either the need to produce clearly human-readable and
    > > therefore easily maintainable code or the need to get from the point of
    > > having no code to the point of having written, tested and debugged code
    > > faster rather than slower become a very low priority?

    >
    > At that point in the process when it was decided to do it in C++.


    You appear to be considering what criteria one might use to select
    between programming languages. I am assuming that C++ has already been
    selected as the language. There could be many reasons for that and for
    the purposes of my point, the reason is irrelevant. So, given that C++
    is the language chosen, and understanding that for a given programming
    problem there will be multiple C++ solutions with varying degrees of
    human-readability and varying rates of progress to correct, tested and
    debugged completion, let me rephrase:

    At what point in the C++ software development process does either the
    need to produce clearly human-readable and therefore easily
    maintainable code or the need to get from the point of having no code
    to the point of having written, tested and debugged code faster rather
    than slower become a very low priority?

    Gavin Deane
    Gavin Deane, Oct 12, 2006
    #10
  11. toton

    Axter Guest

    toton wrote:
    > Hi,
    > all of the containers in STL stores object itself (thus copy
    > contsructability & assignability is needed), while NTL or boost
    > ptr_container stores pointer to the object in the container (either
    > exclusively owns, or just stores).
    > Now, my question is for a general guideline when to use which one?
    > What I understand,
    > 1) polymorphic objects need ptr_container.
    > 2) non copy constructable, non assignable objects need ptr_container.
    >
    > Other than that, any guideline is there? I am specially interested for
    > small devices (handheld, pda etc) with limited memory, where gaining
    > performance is important.
    > To be specific, can it be a guideline like, lots of small objects =>
    > STL container (faster due to cache effect)., a few large objects (like
    > GUI widgets) , use ptr_container. So, why there should be two different
    > types of container, and when one or the other would be used?
    >


    I recommend an alternative to the boost ptr_container, which is the
    following smart_ptr:
    http://axter.com/smartptr/
    You can use the above smart pointer with the STL containers, and it can
    be more efficient then the boost::ptr_container. It's also more
    compatible to the STL containers.
    Axter, Oct 13, 2006
    #11
  12. toton

    toton Guest

    KiLVaiDeN wrote:
    > > Gavin Deane wrote:
    > >
    > > Unless and until proven otherwise, both those concerns are secondary
    > > to:
    > >
    > > "Which option produces the most clearly human-readable code" and
    > > "Which option enables you to get to the point where that code is
    > > written, teted and error-free more quickly"
    > >
    > > So, to the OP: consider the options in that context and choose
    > > whichever answers those questions best. If you find, for example, that
    > > it takes longer (including testing and debugging time) to write correct
    > > code using containers of pointers, and that code is less clear to a
    > > human reader, then use containers of objects.
    > >
    > > Premature optimisation is the root of all evil and all that.

    I am well aware of that. Both STL & pointer container generates human
    readable code. If one wants to throw pointer_container from readibility
    point of view , I can say it is matter of taste. I want from efficiency
    point of view. I am not using unreadable C++ or C code. I am using some
    very well known and well proven library like STL, Boost and Blitz.
    > > Gavin Deane

    >
    > I totally agree with your point, in a normal environnement, but he's
    > working for small devices, therefore it's not only a matter of
    > Optimization, but more a matter of good practices for those targeted
    > platforms.

    I don't do optimization, not perform any treak to optimize a code,
    other than writing some template specialization. Only I want to assist
    compiler to optimize my code. And to the requirement of the program,
    and target platform this assistance change (It is much profile guided
    optimization). I am using GCC, and target is a StrongARM processor
    (Intel XScale). memory is as little as 50-200K.
    May be C is a better choice, but from design point I needed to use
    standard C++ (as it is going to be a scale down version of C++ program
    written for PC ) , and in my experience, C++ is doing better job of
    parallization of code or copying memory at a chunk.
    The main difference is, for this small processors, one have to be
    extremely carefull about memory allocation (or in that matter any
    memory related operations). It is better to keep them at the bottom
    level. while simple instructions are reasonably faster.And caching
    effect is very dominant in those processors. Thus the thumb rule most
    of the time becomes, pre-allocate some memory and use them, rather than
    create memory and delete memory. We use a specially designed container
    (circular_buffer ) for most purpose which is a deque but have reserve
    facility like vector, little more flexible than boost::circular_buffer.
    So mainly placement new comes a better choce (allocator class).
    However GCC really helps me for all of these optimizations.
    I am looking at https://sourceforge.net/projects/smart-pointer , and
    how they make a faster than boost ptr_container. It looks good.
    > The considerations you make are very valuable though; The best is to
    > test both of the scenarios, see how it's managed in your targeted
    > device, and then sticking to one or another; Tell me if you agree :)


    Thanks to all for these valuable discussions.
    > Cheers,
    > K
    toton, Oct 13, 2006
    #12
    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. Replies:
    10
    Views:
    671
    Chris Torek
    Feb 4, 2005
  2. jimjim
    Replies:
    16
    Views:
    822
    Jordan Abel
    Mar 28, 2006
  3. Replies:
    4
    Views:
    1,230
    Fred Zwarts
    Jul 2, 2009
  4. A
    Replies:
    7
    Views:
    625
  5. , India

    pointer to an array vs pointer to pointer

    , India, Sep 20, 2011, in forum: C Programming
    Replies:
    5
    Views:
    441
    James Kuyper
    Sep 23, 2011
Loading...

Share This Page