www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Structs on private section.

reply Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
Hi!

It seems like structs in private section (module or class) remains public:

class A {
private:
	struct B {int b;}
}

void foo() {A.B b; b.b=10;}

this code compiles ok.

WTF?
Nov 27 2011
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/27/2011 03:57 PM, Alexey Veselovsky wrote:
 Hi!

 It seems like structs in private section (module or class) remains public:

 class A {
 private:
 	struct B {int b;}
 }

 void foo() {A.B b; b.b=10;}

 this code compiles ok.

 WTF?

D's private is different than some other languages (e.g. C++). 'private' provides access to the entire module. public: no access limitation private: access by the module package: access by the modules of the package protected: access by the inheriting classes Ali
Nov 27 2011
parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/11/2011 03:29, Alexey Veselovsky a écrit :

public: no access limitation private: access by the module package: access by the modules of the package protected: access by the inheriting classes

But it works even if class Foo declarated in dufferent module. Also this code works: module a; private { struct S {int a;}} -------- module b: import a: void f() {S s; s.a=42;}

So you now have discovered a bug.
Nov 27 2011
parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 28/11/11 1:56 AM, deadalnix wrote:
 Le 28/11/2011 03:29, Alexey Veselovsky a écrit :

'private' provides access to the entire module. public: no access limitation private: access by the module package: access by the modules of the package protected: access by the inheriting classes

But it works even if class Foo declarated in dufferent module. Also this code works: module a; private { struct S {int a;}} -------- module b: import a: void f() {S s; s.a=42;}

So you now have discovered a bug.

A bug that has been known about for quite some time. I also created a pull request for a fix quite some time ago (June), but hasn't been pushed yet. https://github.com/D-Programming-Language/dmd/pull/163 + https://github.com/D-Programming-Language/druntime/pull/32 Unfortunately, the druntime changes are required due to issue 314. For example, with the private type fix, the following code would not compile: --------------- module A; struct Foo {}; // public --------------- module B; import A : Foo; // private selective import --------------- module C; import B; import A; Foo f; // error: B.Foo is private --------------- Due to bug 314, the private import in module B causes Foo to become a private symbol of module B (rather than just importing it). When module C tries to use Foo, it first looks in module B, finding the private Foo and complains of access violation. It doesn't even look at the Foo in module A because access checks are done before overload resolution. It's quite ugly that access checks are not considered in overload resolution because it means I can break user code by adding private symbols to my library. It won't be a silent break, but it will break nonetheless.
Nov 28 2011
prev sibling parent Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
=20
=20
=20
=20
=20


=20
 public: no access limitation
=20
 private: access by the module
=20
 package: access by the modules of the package
=20
 protected: access by the inheriting classes

But it works even if class Foo declarated in dufferent module. Also this code works: module a; private { struct S {int a;}} -------- module b: import a: void f() {S s; s.a=3D42;}=
Nov 27 2011