storing pointer vs storing object

[toton]

Hi,
all of the containers in STL stores object itself (thus copy
contsructabilit y & 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
contsructabilit y & 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
contsructabilit y & 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
contsructabilit y & 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<SmartP ointer<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