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

Problem about self-string operator[] 's unnecessary copy

P: n/a
I write a non-template simple string with the technique
that giving the same string a same storage with a count.

so i must give the necessary copy operation when the string will be
modified, I differ the two kinds of operator[] s.

// const object to use as const
const char& operator[] const
{
//directly get the ref
}
char& operator[]
{
// first copy. then give the new copy 's ref
}
but you see, when I just want to get the value ,not to modify it, a
unnecessary copy ocurrs.
Is there some methods to avoid this ?
Thanks.
Jul 23 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"belief" <su*********@163.com> schrieb im Newsbeitrag news:d5**********@news.yaako.com...
I write a non-template simple string with the technique
that giving the same string a same storage with a count.

so i must give the necessary copy operation when the string will be
modified, I differ the two kinds of operator[] s.

// const object to use as const
const char& operator[] const
{
//directly get the ref
}


char& operator[]
{
// first copy. then give the new copy 's ref
}
but you see, when I just want to get the value ,not to modify it, a
unnecessary copy ocurrs.
Is there some methods to avoid this ?
Thanks.


Don't return a reference. Create your own class, which behaves like a reference, knows which string it refers to, and knows when a copy is required. Something like

class char_ref
{
public:
char_ref(string& base, int offset);
char_ref& operator=(char); // assigns to location refered to,
// copies if neccessary.
operator char() const; // get content of location
...
};

Good luck
Heinz
Jul 23 '05 #2

P: n/a
Hi,Heinz.

It's a good solution ! by giving a intermediate layer .
Maybe char_ref will give me more work to implement it's behavior
like inner type char, i.e. operator= operator+= opeartor*= operator/= etc.

As the solution , the necessary copy operation will be separated to two
pieces.
some ones in the String(e,g, insert, replace) ,and others in the char_ref
like operators just talking above, isn't it?

I think i get it .
Thanks a ton.

wisdo (belief).

//--------------------------------------------------------------------------
----------------------------------------------------------------------------
-

"Heinz Ozwirk" <ho**********@arcor.de> ????
news:42***********************@newsread4.arcor-online.net...
"belief" <su*********@163.com> schrieb im Newsbeitrag
news:d5**********@news.yaako.com...

Don't return a reference. Create your own class, which behaves like a
reference, knows which string it refers to, and knows when a copy is
required. Something like

class char_ref
{
public:
char_ref(string& base, int offset);
char_ref& operator=(char); // assigns to location refered to,
// copies if neccessary.
operator char() const; // get content of location
...
};

Good luck
Heinz
Jul 23 '05 #3

P: n/a

belief schreef:
I write a non-template simple string with the technique
that giving the same string a same storage with a count.

so i must give the necessary copy operation when the string will be
modified, I differ the two kinds of operator[] s.

// const object to use as const
const char& operator[] const
{
//directly get the ref
}
It's probably more efficient to return a plain char. What's the point
in having a reference? That also prevents the following bug:

SimpleString a = "foo";
SimpleString const& b = a;
char const& f = b[0];
a[0]='x';
assert(f=='f');
char& operator[]
{
// first copy. then give the new copy 's ref
}
but you see, when I just want to get the value, not to modify it,
a unnecessary copy ocurrs.


References are dumb (like pointers), use a smart ref class.

Regards,
Michiel Salters

Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.