Avoiding expensive copying, reading and writing in my program.

[Jason Heyes]

I have a class with an expensive copy, read and write. There are many
objects of this class used throughout my program. What kind of encapsulation
of this class do I use to make sure copy, read and write are optimised in my
program?

Thanks.

 

[James Aguilar]

I have a class with an expensive copy, read and write. There are many
objects of this class used throughout my program. What kind of
encapsulation of this class do I use to make sure copy, read and write are
optimised in my program?

?

C++ will not automagically fix expensive operations. If it's expensive, it
will be thus no matter how you encapsulate it.

More data would be helpful.

- JFA1

 

[E. Robert Tisdale]

I have a class with an expensive copy, read and write.
There are many objects of this class used throughout my program.
What kind of encapsulation of this class do I use to make sure copy,
read and write are optimised in my program?

Take a look at
The C++ Scalar, Vector, Matrix and Tensor class Library

http://www.netwood.net/~edwin/svmtl/

Numerical programmers are paranoid about unnecessary copies
so they prefer to pass around "references" to subvectors,
submatrices, and subtensors instead of making copies
of [parts] of larger objects.

 

[Jason Heyes]

?

C++ will not automagically fix expensive operations. If it's expensive,
it will be thus no matter how you encapsulate it.

More data would be helpful.

I can wrap the class in boost::shared_ptr to solve the copy inefficiency.
What about the read and write efficiency? I hope my question is clear.

 

[James Aguilar]

I can wrap the class in boost::shared_ptr to solve the copy inefficiency.
What about the read and write efficiency? I hope my question is clear.

Oh I see what you're saying. Well, the thing about boost:shared_ptr and
other smart pointer classes is that you aren't actually copying the object.
When you have an expensive operation, there are normally only two options:

1) Make it faster <-- good
2) Don't do it <-- better, if you can manage it

boost::shared_ptr uses option two, but I know of no really good ways of
doing these things for reading and writing. I suppose you could cache a
string representation of the output until the contents of your class
changes, but, just like boost::shared_ptr, this is just prevents printing
from actually being done. I know of no hack that can allow a read operation
to work this way.

HTH

- JFA1

 

[Jason Heyes]

Oh I see what you're saying. Well, the thing about boost:shared_ptr and
other smart pointer classes is that you aren't actually copying the
object. When you have an expensive operation, there are normally only two
options:

1) Make it faster <-- good
2) Don't do it <-- better, if you can manage it

boost::shared_ptr uses option two, but I know of no really good ways of
doing these things for reading and writing. I suppose you could cache a
string representation of the output until the contents of your class
changes, but, just like boost::shared_ptr, this is just prevents printing
from actually being done. I know of no hack that can allow a read
operation to work this way.

How about we do the following:

1) Use a file to store the string representation of the object.
2) Make the handle (object of the encapsulating class) hold the name of this
file.
3) Provide a mapping between name and object for the handle to search
through.

In the end the handle will have efficient copy, read and write. Will this
work?

 

[James Aguilar]

In the end the handle will have efficient copy, read and write. Will this
work?

Can you define what you mean by read and write? Because, the way I
understood it, what you meant is that, to read the object from an input
stream (i.e. a serialized version) was expensive, and writing it out was
also expensive. I can be dense sometimes, so perhaps it is obvious, but I
cannot see how saving a file association with the string representation
would prevent you from doing these expensive reads and writes every time the
object changes any of its properties.

However, if you almost never change the object, it could be useful to have
that file representation around, at least for the writing. Maybe. On
second thought, reading a file is super slow, so it's probably not going to
help you.

- JFA1

 

[Jason Heyes]

Damn! What happened to that reply?