Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Copy construction with inaccessible base class copy c-tor

Reply
Thread Tools

Copy construction with inaccessible base class copy c-tor

 
 
Victor Bazarov
Guest
Posts: n/a
 
      03-01-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> What about this ?
> -------------------------
> class B
> {
> protected:
> B(const B&);
> B& operator=(const B&);
> public:
> B(int);
> };
> class C : public B
> {
> public:
> C(int);
> };
> int main()
> {
> C c = C(42); //
> B b = B(42); //
> }
> ------------------------
> copy ctor of base class is set to protected.


The construction of 'c' should compile, the construction of
'b' should not, IMO. 'C' has an implicit copy c-tor, which
calls the explicit copy c-tor for 'B', which it can do because
the protected access is granted to 'C'.

The construction of 'b' should NOT compile because it involves
making a copy of the temporary, and 'main' has no access to the
protected copy c-tor in 'B'.

I can see the correct behaviour in Comeau, but I have no way of
verifying this with GNU C++ at this time.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 
Reply With Quote
 
 
 
 
Nicola Musatti
Guest
Posts: n/a
 
      03-01-2007
On Mar 1, 4:03 pm, "Daniel Krügler" <(E-Mail Removed)>
wrote:
> On 1 Mrz., 13:59, "James Kanze" <(E-Mail Removed)> wrote:
>
> > That's undefined behavior, not an error requiring a diagnostic.
> > Most implementations will only detect it when linking, and of
> > course, he never got that far.

>
> That's an interesting position, I never realized that. Does that mean,
> that essentially every C++ program more or less relies on this kind
> of UB? Even the standard provides class definitions, where
> some of the usual suspects (copy c'tor, assignment op)
> are declared but not defined, e.g. (I take N2134 as reference):
>
> 20.5.14.2:
> // 20.5.14.2.6, undefined operators:
> template<class Function2> bool operator==(const function<Function2>&);
> template<class Function2> bool operator!=(const function<Function2>&);


I'm not sure whether I misunderstood James or you did. Just to be
sure, in my opinion the following invokes undefined behaviour:

class A {
public:
A();
};

class B : public A {
};

int main() {
B b;
}

A compiler might be able to generate a definition for B::B(), however
this would contain a call to A::A() which cannot be resolved by the
linker. This not very different from the following program:

void f();

int main() {
f();
}

The following, instead, is downright malformed:

class C {
private:
C();
};

class D : public C {
};

int main() {
D d;
}

The compiler is not allowed to generate a definition for D:()
because C::C() is not accessible. In a way malformation kicks in
before undefined behaviour does.

Cheers,
Nicola Musatti



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 
Reply With Quote
 
 
 
 
=?iso-8859-1?q?Daniel_Kr=FCgler?=
Guest
Posts: n/a
 
      03-02-2007
On 1 Mrz., 18:56, "Nicola Musatti" <(E-Mail Removed)> wrote:
> I'm not sure whether I misunderstood James or you did. Just to be
> sure, in my opinion the following invokes undefined behaviour:


I'm quite sure that you didn't misunderstood James. Don't ask me why,
but I got totally lost in an arcane idea.
Fact is, as you correctly said, that an inaccessible and not defined
class member is (normally) harmless, because access rules apply before
the compiler has finished. What I indeed never consciously realised,
(but this was not what I meant in my previous posting) was that an
used but undefined entity (e.g. usual function or function member)
causes UB, most probably because I always relied on the linker to
recognize such situations. What I want to say is, that according to
the outcome of this discussion even

class T {
T(); // not defined;
public:
static void foo() {
T item;
}
};

int main() {
T::foo();
}

or even simpler

void foo(); // not defined

int main() {
foo();
}

causes UB. I assume that this surprising result
(at least for me) is related to the fact that the
C++ standard does not describe a linker model.
The existence of the linker and the occurence of
a linker error here and there seems so natural
for most of us that I never considered its cause
to be a programmers fault which actually belongs
to the UB family.

Greetings from Bremen,

Daniel Krügler



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      03-03-2007
On Mar 1, 4:03 pm, "Daniel Krügler" <(E-Mail Removed)>
wrote:
> On 1 Mrz., 13:59, "James Kanze" <(E-Mail Removed)> wrote:


> > That's undefined behavior, not an error requiring a diagnostic.
> > Most implementations will only detect it when linking, and of
> > course, he never got that far.


> That's an interesting position, I never realized that. Does that mean,
> that essentially every C++ program more or less relies on this kind
> of UB? Even the standard provides class definitions, where
> some of the usual suspects (copy c'tor, assignment op)
> are declared but not defined, e.g. (I take N2134 as reference):


I'm afraid I wasn't very clear. Old Wolf said "The compiler
should generate an error because you haven't provided a body for
the constructor of C." That's really the only statement I'm
responding to; not providing bodies (or providing multiple
bodies) to a function that is actually used is a violation of
the one definition rule, and as such is undefined behavior.
(Not providing bodies to a function which is not actually used
is perfectly legal. Applying the standard's definition of
"used", i.e. virtual functions are always used, as is a user
declared operator delete, and maybe some other special cases.)

The original code requires a diagnostic (and will require one
even if bodies are provided for all of the user defined
functions) because the compiler is required to generated the
definition of the implicite copy constructor, and can't.

--
James Kanze (Gabi Software) email: (E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      03-03-2007
On Mar 2, 12:28 pm, "Daniel Krügler" <(E-Mail Removed)>
wrote:
> On 1 Mrz., 18:56, "Nicola Musatti" <(E-Mail Removed)> wrote:


> > I'm not sure whether I misunderstood James or you did. Just to be
> > sure, in my opinion the following invokes undefined behaviour:


> I'm quite sure that you didn't misunderstood James. Don't ask me why,
> but I got totally lost in an arcane idea.


When I reread my statement, I got confused by it myself, so the
problem is on my side.

> Fact is, as you correctly said, that an inaccessible and not defined
> class member is (normally) harmless, because access rules apply before
> the compiler has finished. What I indeed never consciously realised,
> (but this was not what I meant in my previous posting) was that an
> used but undefined entity (e.g. usual function or function member)
> causes UB, most probably because I always relied on the linker to
> recognize such situations. What I want to say is, that according to
> the outcome of this discussion even


> class T {
> T(); // not defined;
> public:
> static void foo() {
> T item;
> }
> };


> int main() {
> T::foo();
>
> }


> or even simpler


> void foo(); // not defined


> int main() {
> foo();
>
> }


> causes UB.


That's correct. In practice, in this particular case, you will
certainly get an error from the linker (although I once used a
linker, many, many years ago, that would occasionally use the
address 0, rather than reporting an undefined external).

> I assume that this surprising result
> (at least for me) is related to the fact that the
> C++ standard does not describe a linker model.
> The existence of the linker and the occurence of
> a linker error here and there seems so natural
> for most of us that I never considered its cause
> to be a programmers fault which actually belongs
> to the UB family.


I think that the real reason is that this is part of a larger
rule, the one definition rule, and there are some violations of
this rule which are not easily detected. If, for example,
instead of providing no definition, you provide two, and you
link through libraries. It wouldn't be too difficult for the
standard to require a diagnostic in the case of a missing
definition; it may not describe the exact linker model, but it
does talk about resolving external symbols, and such, in the
phases of compilation. It's probably not worth addressing now,
however; hopefully, the next version of the standard will
contain some support for dynamic linking, and then, you do sort
of get undefined behavior.

--
James Kanze (Gabi Software) email: (E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 
Reply With Quote
 
Greg Comeau
Guest
Posts: n/a
 
      03-04-2007
In article <ervn2p$as5$(E-Mail Removed)>,
Victor Bazarov <(E-Mail Removed)> wrote:
>class B
>{
> B(const B&);
> B& operator=(const B&);
>public:
> B(int);
>};
>
>class C : public B
>{
>public:
> C(int);
>};
>
>int main()
>{
> C c = C(42); // Comeau: no error
> B b = B(42); // Comeau: error
>}
>
>Both 'c' and 'b' are copy-constructed, as I understand it.
>B's copy c-tor is inaccessible, so construction of 'b' is
>ill-formed. And Comeau (online test drive) flags it such.
>But it lets the construction of 'c' through. Should it?
>
>As I understand it, a temporary can be omitted, but its
>creation should be possible (12.2/1) as if it weren't omitted.
>And since C's copy c-tor cannot be created (12.8/7), the code
>that requires (or would require) it is also ill-formed.
>Where do I err? Or do I?


Sorry for the delay in responding. I started mulling it and
got caught up in other things. I don't think you err:
The standard seems pretty clear that it needs to be accessible
in your context, even if it can be sidestepped regarding its "need".

Kanze seems to have the answer I would have provided (thanks James
It's a more deeper issue internally and as with all reports
it will be given consideration at some point.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
inaccessible base despite public inheritance Stefan Weber C++ 9 05-29-2007 07:58 AM
virtual base class and construction/destruction order BeautifulMind C++ 7 02-08-2007 12:35 PM
'B' is an inaccessible base of 'D' yuvalif@gmail.com C++ 2 12-26-2005 07:55 AM
Default construction versus construction with initial values Ook C++ 10 10-08-2005 09:00 PM
Base class inaccessible due to ambiguity daniel.w.gelder@gmail.com C++ 4 05-04-2005 04:54 PM



Advertisments