Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
February 20, 2007 struct encapsulation | ||||
---|---|---|---|---|
| ||||
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; } |
February 20, 2007 Re: struct encapsulation | ||||
---|---|---|---|---|
| ||||
Posted in reply to alex | 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
|
February 20, 2007 Re: struct encapsulation | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
|
February 20, 2007 Re: struct encapsulation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Soerensen | 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 |
February 20, 2007 Re: struct encapsulation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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 :-)
|
Copyright © 1999-2021 by the D Language Foundation