storing pointer vs storing object

[toton]

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

[KiLVaiDeN]

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

[Gavin Deane]

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

[KiLVaiDeN]

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

[Gavin Deane]

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

[Kaz Kylheku]

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]

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.

[Gavin Deane]

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

[Kaz Kylheku]

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

[Gavin Deane]

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

[Axter]

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.

[toton]

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