inaccessible constructor

[cpp_novice]

I have the following C++ declaration:

struct S {

private:

S();

};

struct T {

S s;

};

Why isnt it illegal C++?
It gives the false impression that a member function of S can
instantiate
an object of the type T.

If an object of type T cannot be constructed under any
circumstance, then
why allow the type declaration to pass in the first place?

 

[Mehturt]

(e-mail address removed) napísal(a):

I have the following C++ declaration:

struct S {

private:

S();

};

struct T {

S s;

};

Why isnt it illegal C++?

It is illegal, i.e. the gcc output:

x.cc: In constructor 'T::T()':
x.cc:8: error: 'S::S()' is private
x.cc:12: error: within this context

 

[sun1991]

Because the "s" in struct T hasn't been initial. When compile meet
something like: "T t", then it look for the comstructor for S, and
report an error.

 

[Thomas Tutone]

I have the following C++ declaration:

struct S {
private:
S();
};

struct T {
S s;
};

Why isnt it illegal C++?

You're mistaken. It will cause a compile error if you try to
instantiate T.

It gives the false impression that a member function of S can
instantiate
an object of the type T.

No it doesn't. If you try to instantiate T, you'll get a compile
error.

If an object of type T cannot be constructed under any
circumstance, then
why allow the type declaration to pass in the first place?

You're mistaken.

Try compiling the following, then please report back on what your
compiler says:

struct S {
private:
S();
};

struct T {
S s;
};

int main()
{
T t;
}


Here's what Comeau online says:

"ComeauTest.c", line 7: error: "S::S()" is inaccessible
S s;
^
detected during implicit generation of "T::T()" at line 12

1 error detected in the compilation of "ComeauTest.c".

Hope that helps.

Best regards,

Tom

 

[cpp_novice]

All that is done mate. Please explain why only the following should
compile?

struct S {
private:
S();
};

struct T {
S s;
};

If it compiles, then obviously the language designers have thought that
T is useful in some future context.

Care to explain what that might be apart from
creating pointers, assigning null to them and
comparing them (which could be accomplished
just as well with void pointers)?

 

[Thomas Tutone]

All that is done mate.

OK. Then didn't you post the results like I asked? I'm taking the
trouble to answer your question. Won't you do me the courtesy of
responding to my reasonable request?

Please explain why only the following should
compile?

struct S {
private:
S();
};

struct T {
S s;
};

Because you didn't instantiate T. Until you do so, your compiler
doesn't see the error. Other compilers may issue a diagnostic there.
Yours doesn't. Either live with it or switch compilers.

If it compiles, then obviously the language designers have thought that
T is useful in some future context.

Are you ABSOLUTELY sure? Is it POSSIBLE that the compiler writer for
the compiler you were using decided it was easier not to check such
things until you tried to instantiate the class in question, since it
would only be a problem if you instantiated the class?

Care to explain what that might be apart from
creating pointers, assigning null to them and
comparing them (which could be accomplished
just as well with void pointers)?

Different compilers exhibit different behaviors. If you want a
compiler that gives you a diagnostic for the code you posted without
instantiating T, then switch to a compiler that does so, or ask the
writer of your compiler to make that change. In fact, I'm sure that if
you offer them enough money for their services, the compiler writers
will be happy to make that change for you. But that seems like a poor
use of your money, if you ask me. If you try to instantiate T, you get
a compile error, and if you don't try to instantiate T, then your
program never tries to access the inaccessible constructor.

Best regards,

Tom

 

[Default User]

Because the "s" in struct T hasn't

See below.



Brian

 

[Default User]

All that is done mate.

See below.



Brian