By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,238 Members | 1,746 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,238 IT Pros & Developers. It's quick & easy.

Large private data member access

P: n/a
Hi all,
I guess this is more of a design problem than a language problem, but
I'm confused either way! I have a class and it has a private data member
which is a struct. The size of the struct is what I would call relatively
large (about 1Mb). I have written methods for this class so that the struct
can be correctly filled with the corerct data and certain parts of the
struct can be extracted. But the problem I face is that I now have another
class that will also hold a private data member of the same struct, but this
class will work on the struct in a very different way. The thing I can't
resolve is that I want to transfer the contents of the struct from one class
to the other ... these are my ideas of how to do it but I don't know which
is best to use!

1. I could have a 'GetStruct' method which would return a const reference to
my private struct and then have my second class use memcpy to fill its
struct. For some reason I feel nervous giving out any reference to a private
member as it doesn't take much to defeat the 'constness' and mess around
with the internal struct ... I've had someone do that before with my code
before!

2. I could write a helper class that behaves rather like an STL iterator. I
could then get 'iterators' to the begining and end of my struct and transfer
it byte by byte. If possible I want to avoid using the STL itself because
this code may well end up in an embedded system and my customer isn't keen
on STL (despite my protesting!).

I'm sure this is a fairly standard problem that people come across all the
time, can anyone suggest the prefered/best method for doing this - oh and I
want to try and keep things as quick as possible.

Thanks,
Rich.
Jul 23 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Richard Webb wrote:
....

I'm sure this is a fairly standard problem that people come across all the
time, can anyone suggest the prefered/best method for doing this - oh and I
want to try and keep things as quick as possible.


Without knowing more about your issue, it's hard to give you valuable
advice. However a few shots in the dark:

a) Use friend declarations. This way one of your classes is able to
access the other's private parts.

b) If you're trying to avoid copying the data, you may use a reference
counted wrapper class that is private and make the other two classes
friends.
Jul 23 '05 #2

P: n/a

"Richard Webb" <we***@REMOVEMErichardwebb-online.co.uk> wrote in message
news:Y6********************@pipex.net...
Hi all,
I guess this is more of a design problem than a language problem, but
I'm confused either way! I have a class and it has a private data member
which is a struct. The size of the struct is what I would call relatively
large (about 1Mb). I have written methods for this class so that the
struct
can be correctly filled with the corerct data and certain parts of the
struct can be extracted. But the problem I face is that I now have another
class that will also hold a private data member of the same struct, but
this
class will work on the struct in a very different way. The thing I can't
resolve is that I want to transfer the contents of the struct from one
class
to the other ... these are my ideas of how to do it but I don't know which
is best to use!

1. I could have a 'GetStruct' method which would return a const reference
to
my private struct and then have my second class use memcpy to fill its
struct. For some reason I feel nervous giving out any reference to a
private
member as it doesn't take much to defeat the 'constness' and mess around
with the internal struct ... I've had someone do that before with my code
before!

2. I could write a helper class that behaves rather like an STL iterator.
I
could then get 'iterators' to the begining and end of my struct and
transfer
it byte by byte. If possible I want to avoid using the STL itself because
this code may well end up in an embedded system and my customer isn't keen
on STL (despite my protesting!).

I'm sure this is a fairly standard problem that people come across all the
time, can anyone suggest the prefered/best method for doing this - oh and
I
want to try and keep things as quick as possible.


I'm not sure I understand the problem entirely. Why are you thinking of
doing all that byte-by-byte copying? If you need to copy the data, why not
use an assignment operator for it? (Or the default assignment operator, if
the internal struct is a POD type.)

Do you actually need a copy of that internal data structure, or do you just
need to get information from it that you use to compute other information?
If you don't actually *need* another copy of all that data, then you could
simply refer to the first object's struct via any method you wish, such as a
const reference (as you mentioned). Or, perhaps better, getter functions
that return just the parts you need from that private structure. Or even
member functions of that first object that do whatever operations the second
object needs done to the internal struct, assuming it does both "gets" and
"sets".

Without more info, it's hard to guess what would work best for your case. (I
think what confused me most was your statement that the second object holds,
in your words, a private data member "of the same struct". I can't tell if
you meant just "the same struct type" or an "exact copy", or a "copy, but
one which will then be changed so that it's different".

-Howard

Jul 23 '05 #3

P: n/a
> I'm not sure I understand the problem entirely. Why are you thinking of
doing all that byte-by-byte copying? If you need to copy the data, why not use an assignment operator for it? (Or the default assignment operator, if the internal struct is a POD type.)

Do you actually need a copy of that internal data structure, or do you just need to get information from it that you use to compute other information?
If you don't actually *need* another copy of all that data, then you could
simply refer to the first object's struct via any method you wish, such as a const reference (as you mentioned). Or, perhaps better, getter functions
that return just the parts you need from that private structure. Or even
member functions of that first object that do whatever operations the second object needs done to the internal struct, assuming it does both "gets" and
"sets".

Without more info, it's hard to guess what would work best for your case. (I think what confused me most was your statement that the second object holds, in your words, a private data member "of the same struct". I can't tell if you meant just "the same struct type" or an "exact copy", or a "copy, but
one which will then be changed so that it's different".

-Howard


Howard,
Thanks for your reply. I already have functions that extract specific
pieces of information from the struct. But the problem is that I want
another class to have access to this entire large member object. The simple
straight answer is to provide what I'm doing already and that is to return a
const reference to the struct which is a private member. I was simply trying
to have another class access the entire struct, ideally without copying it.
The only reason I'm trying to think of a new method of doing this is that I
have had occassion before where the other people who've used my classes have
not been the best C++ coders in the world and have defeated the constness of
a const reference to a private member ... then accessed the private member
and broken the operation of the class. I'm trying to add an extra layer of
fool-proofness that doesn't impose a large overhead by having to copy the
data.

I think though that I may be wasting my time a little bit with this idea. I
will stick with the answer that I normally give which is if you use my class
incorrectly that's your fault!!

Thanks,
Rich.
Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.