This code compiles - I don't think it should.
If b is a private member of A then why can I change it outside the class ?

struct A
{
private:
	int b;
};


int main()
{
	A a;
	a.b = 10;

	return 0;
}

alex Wrote:

> This code compiles - I don't think it should.
> If b is a private member of A then why can I change it outside the class ?
> 
> struct A
> {
> private:
> 	int b;
> };
> 
> 
> int main()
> {
> 	A a;
> 	a.b = 10;
> 
> 	return 0;
> }

The code compiles when the accessing code is in the same module, otherwise it fails as expected.

Sorry I misunderstood the meaning of private.
Alex

On Mon, 19 Feb 2007 21:18:05 -0500, alex wrote:

> This code compiles - I don't think it should.
> If b is a private member of A then why can I change it outside the class ?
> 
> struct A
> {
> private:
> 	int b;
> };
> 
> 
> int main()
> {
> 	A a;
> 	a.b = 10;
> 
> 	return 0;
> }

I see that you have solved your problem, but I have some thought on struct encapsulation.

Imagine a struct like:

struct angle
{
float degrees;
}
Now imagine we write a lot of code using angle:

 angle a1;
 a1.degrees= 60.0;
 ...
 writefln(a1.degrees);


and then we need to refactor angle to use radians

We change angle to
class angle
{
float radians;
public:
float degrees(); // get degrees
void degrees(float); //set degrees
}

But now we have to go trough all the code and change it to.

angle a1;
 a1.degrees(60.0);
 ...
 writefln(a1.degrees());


What I think could be very useful is for D to automatic
accept bar() and bar(type) as getter and setter for elements in structs and classes like.

struct foo
{
type bar;
}

I know that we might like to keep the old way for backwards compatibility with c/c++ and D 1.0, but at last it will allow further generations to write maintainable code.

Knud Soerensen wrote:
> On Mon, 19 Feb 2007 21:18:05 -0500, alex wrote:
> 
>> This code compiles - I don't think it should.
>> If b is a private member of A then why can I change it outside the class ?
>>
>> struct A
>> {
>> private:
>> 	int b;
>> };
>>
>>
>> int main()
>> {
>> 	A a;
>> 	a.b = 10;
>>
>> 	return 0;
>> }
> 
> I see that you have solved your problem, but I have some thought on struct
> encapsulation.
> 
> Imagine a struct like:
> 
> struct angle
> {
> float degrees;
> }
> Now imagine we write a lot of code using angle:
> 
>  angle a1;
>  a1.degrees= 60.0;
>  ...  writefln(a1.degrees);
> 
> 
> and then we need to refactor angle to use radians
> 
> We change angle to class angle
> {
> float radians;
> public:
> float degrees(); // get degrees
> void degrees(float); //set degrees
> }
> 
> But now we have to go trough all the code and change it to.
> 
> angle a1;
>  a1.degrees(60.0);
>  ...  writefln(a1.degrees());
> 
> 
> What I think could be very useful is for D to automatic
> accept bar() and bar(type) as getter and setter for elements in structs and classes like.
> 
> struct foo
> {
> type bar; }
> 
> I know that we might like to keep the old way for backwards compatibility
> with c/c++ and D 1.0, but at last it will allow further generations to
> write maintainable code.


Either A) I'm totally misunderstanding you, B) you're being funny or C) you're not aware of property syntax:
   http://www.digitalmars.com/d/property.html#classproperties

--bb

On Tue, 20 Feb 2007 17:23:30 +0900, Bill Baxter wrote:

> Knud Soerensen wrote:
>> On Mon, 19 Feb 2007 21:18:05 -0500, alex wrote:
>> 
>>> This code compiles - I don't think it should.
>>> If b is a private member of A then why can I change it outside the class ?
>>>
>>> struct A
>>> {
>>> private:
>>> 	int b;
>>> };
>>>
>>>
>>> int main()
>>> {
>>> 	A a;
>>> 	a.b = 10;
>>>
>>> 	return 0;
>>> }
>> 
>> I see that you have solved your problem, but I have some thought on struct encapsulation.
>> 
>> Imagine a struct like:
>> 
>> struct angle
>> {
>> float degrees;
>> }
>> Now imagine we write a lot of code using angle:
>> 
>>  angle a1;
>>  a1.degrees= 60.0;
>>  ...
>>  writefln(a1.degrees);
>> 
>> 
>> and then we need to refactor angle to use radians
>> 
>> We change angle to
>> class angle
>> {
>> float radians;
>> public:
>> float degrees(); // get degrees
>> void degrees(float); //set degrees
>> }
>> 
>> But now we have to go trough all the code and change it to.
>> 
>> angle a1;
>>  a1.degrees(60.0);
>>  ...
>>  writefln(a1.degrees());
>> 
>> 
>> What I think could be very useful is for D to automatic
>> accept bar() and bar(type) as getter and setter for elements in structs and classes like.
>> 
>> struct foo
>> {
>> type bar;
>> }
>> 
>> I know that we might like to keep the old way for backwards compatibility with c/c++ and D 1.0, but at last it will allow further generations to write maintainable code.
> 
> 
> Either A) I'm totally misunderstanding you, B) you're being funny or C)
> you're not aware of property syntax:
>     http://www.digitalmars.com/d/property.html#classproperties
> 
> --bb

I seems to remember something about this property feature
but I got it reversed in my test, so it didn't work.
This is how it goes when one tries to post on newsgroups
early in the morning after a night without sleep :-)