Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

More Exceptional C++ question / access to private members

49 views
Skip to first unread message

AP(unixpronospam@verizon.net)

unread,
Sep 20, 2014, 10:08:00 PM9/20/14
to
In item 13 (Lazy optimization / copy-on-write) we see following ctor :

String::String( const String& other ): buf_(new char[other.len_]),
len_(other.len_), used_(other.used_)
{ copy(other.buf_, other.buf_+used_, buf_); }

Class is defined thus :
class String
{
public:
String(const String&);
...
private:
char* buf_;
size_t len_;
size_t used_;
...
}

Question : how does our ctor have access to her argument's private data ?
The situation repeats on quite a few occasions in the book,

In fact, such behavior is observed :

class CC
{
public:
CC(){}
CC(size_t A) : DATA(A) { cerr << "Straight ctor(" << A << ")" << endl; }
CC(const CC& cc) : DATA(cc.DATA) { cerr << "Copy ctor" << endl; }
void Copy(CC& cc) { DATA = cc.DATA; }
void CopyTo(CC& cc) { cc.DATA = DATA; }
size_t Extract(CC& cc) { DATA = cc.DATA; return DATA;}
private:
size_t DATA;
};

int main(int argc,char **argv, char **envp)
{
CC cc(1), dd(2), ee(cc);
cerr << ee.Extract(cc);
// Does not compute :
cerr << ee.DATA << endl;
}

The last line, of course, doesn't compile. The rest does so. Why am I able
to access explicitly private DATA member of my argument cc in methods Copy
and CopyTo, as well as the rest of the class ?

Ian Collins

unread,
Sep 20, 2014, 10:28:33 PM9/20/14
to
AP(unixpr...@verizon.net) wrote:
> In item 13 (Lazy optimization / copy-on-write) we see following ctor :
>
> String::String( const String& other ): buf_(new char[other.len_]),
> len_(other.len_), used_(other.used_)
> { copy(other.buf_, other.buf_+used_, buf_); }
>
> Class is defined thus :
> class String
> {
> public:
> String(const String&);
> ....
> private:
> char* buf_;
> size_t len_;
> size_t used_;
> ....
> }
>
> Question : how does our ctor have access to her argument's private data ?
> The situation repeats on quite a few occasions in the book,

Because both are objects of type String. That's how access protection
works in C++. If it were any other way, objects with private data
members couldn't be coped without a public accessor for each private member.

--
Ian Collins

Paavo Helde

unread,
Sep 21, 2014, 3:46:12 AM9/21/14
to
"AP(unixpr...@verizon.net)" <udt...@gmail.com> wrote in
news:463032a0-f557-463c...@googlegroups.com:

> Question : how does our ctor have access to her argument's private
> data ?

The purpose of protection in C++ is to enforce clean encapsulation and
limit the amount of code one needs to review and adjust when making changes
in the private pieces. This means that of course the copy constructors (as
well as all other member functions) have access to the private data of the
same class, regardless of which object it belongs to.

With 'protected' keyword this becomes a bit more complicated (but having
'protected' data members is dicouraged anyway).

Cheers
Paavo

Juha Nieminen

unread,
Sep 21, 2014, 7:16:15 AM9/21/14
to
"AP(unixpr...@verizon.net)" <udt...@gmail.com> wrote:
> Question : how does our ctor have access to her argument's private data ?

Why exactly shouldn't a String function have access to the members of
its own type?

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

Christopher Pisz

unread,
Sep 22, 2014, 11:35:50 AM9/22/14
to
On 9/21/2014 2:45 AM, Paavo Helde wrote:
> "AP(unixpr...@verizon.net)" <udt...@gmail.com> wrote in
> news:463032a0-f557-463c...@googlegroups.com:
SNIP
> With 'protected' keyword this becomes a bit more complicated (but having
> 'protected' data members is dicouraged anyway).
>
> Cheers
> Paavo

Who is discouraging the use of protected data members? No one has ever
discouraged me in my use of protected data members.


Paavo Helde

unread,
Sep 22, 2014, 12:38:38 PM9/22/14
to
Christopher Pisz <nos...@notanaddress.com> wrote in
news:lvpfk3$brl$1...@dont-email.me:

> On 9/21/2014 2:45 AM, Paavo Helde wrote:
>> With 'protected' keyword this becomes a bit more complicated (but
>> having 'protected' data members is dicouraged anyway).
>
> Who is discouraging the use of protected data members? No one has ever
> discouraged me in my use of protected data members.

Well, I am! A protected data member can be changed by derived classes,
so the encapsulation is broken. Sometimes this makes sense, but more
often it is just abused (I know because I have abused the feature many
times myself).

See also:

"http://sundararajana.blogspot.com/2007/05/never-specify-public-or-protec
ted.html"

http://www.parashift.com/c++-faq/protected-interface.html

The "discouraged" vs "prohibited" bit:

http://www.parashift.com/c++-faq/protected-data-not-evil.html

Cheers
Paavo

0 new messages