Language problem with properties ?!?
in [Learn C or C++]
|
From: Skybuck Flying on 19 Oct 2009 10:34 Hello, I have the following code SomeArray[SomeIndex].SomeField := 5; I would like to do special processing when SomeField gets assigned. However I would also need the index parameter to know what needs to be assigned. Currently with properties this is problematic. I could only use an "access" specifier which returns a Trecord for SomeIndex... then assigning to that record would pretty much be effectless because the record would be on the stack and later be discarded. Implementing a write property would be effectless since it will never be called... [SomeIndex].SomeField will trigger a "read property" not a "write property". I also though about overloading the "dot" / "." operator but this is not possible in Delphi 2007 not sure about Delphi 2010 ? I could use pointers and return a pointer... then somefield would be writing into a pointer... this has two disadventages at least... first of all the pointer itself would slow down memory access... second of all... pointer might be stored by programmer... later pointer might be invalid introducing problems. Lastly I wonder how c/c++ evolves since c/c++ does not seem to have any experimental language to try out new stuff ? ;) I have seen some extensions to c/c++ in for example c++ builder... but that's pretty stupid isn't it for a standard to have non-standard elements ?!? Therefore I wonder if it's a could idea to make an "experimental c/c++ language" for people to try out ! ;) I shall suggest a name for it from the top of my head :): "Cexp" :) for C experimental ;) :) or simply short: "Cx" :) Bye, Skybuck.
From: Piranha on 24 Oct 2009 23:34 On 19 Okt., 15:34, "Skybuck Flying" <BloodySh...(a)hotmail.com> wrote: > Hello, > > I have the following code > > SomeArray[SomeIndex].SomeField := 5; > > I would like to do special processing when SomeField gets assigned. However > I would also need the index parameter to know what needs to be assigned. > > Currently with properties this is problematic. > > I could only use an "access" specifier which returns a Trecord for > SomeIndex... then assigning to that record would pretty much be effectless > because the record would be on the stack and later be discarded. > > Implementing a write property would be effectless since it will never be > called... > > [SomeIndex].SomeField will trigger a "read property" not a "write property". > > I also though about overloading the "dot" / "." operator but this is not > possible in Delphi 2007 not sure about Delphi 2010 ? > > I could use pointers and return a pointer... then somefield would be writing > into a pointer... this has two disadventages at least... first of all the > pointer itself would slow down memory access... second of all... pointer > might be stored by programmer... later pointer might be invalid introducing > problems. > > Lastly I wonder how c/c++ evolves since c/c++ does not seem to have any > experimental language to try out new stuff ? ;) I have seen some extensions > to c/c++ in for example c++ builder... but that's pretty stupid isn't it for > a standard to have non-standard elements ?!? Therefore I wonder if it's a > could idea to make an "experimental c/c++ language" for people to try out ! > ;) > > I shall suggest a name for it from the top of my head :): > "Cexp" :) for C experimental ;) :) > > or simply short: > > "Cx" :) > > Bye, > Skybuck. Not sure if I understand what you want to do, but I would make assigning SomeField a function, that can in addition perform any required extra processing. SomeArray[SomeIndex].SomeField := SetSomeField(5); int SetSomeField(int value) { // Whatever processing is needed here return value; }
From: Skybuck Flying on 25 Oct 2009 13:45 Which completely defeats the property of properties ;) Anyway properties is on of those language features which I miss the most in c/c++/cg/etc ;) Bye, Skybuck.
From: White Wolf on 20 Nov 2009 20:48 Skybuck Flying wrote: > Hello, > > I have the following code > > SomeArray[SomeIndex].SomeField := 5; > > I would like to do special processing when SomeField gets assigned. However > I would also need the index parameter to know what needs to be assigned. I don't get your problem. Overload the assignment operator for the type of SomeField. You can do your magic in there. You do not need to know the index in the assignment operator, the index has already selected the right "record" (to use your words) in which the right SomeField is. Why would you need it in the assignment? Are you saying that the SomeField = 5 won't actually assign 5 to SomeField, but 5 and SomeIndex "mixed together"? > Currently with properties this is problematic. > > I could only use an "access" specifier which returns a Trecord for > SomeIndex... then assigning to that record would pretty much be effectless > because the record would be on the stack and later be discarded. Access specifier in C++ is private: protected: and public:, three keywords that have no runtime meaning. How could those return a value? > Implementing a write property would be effectless since it will never be > called... I think that you have not much knowledge of C++. It seems I have to guess my way through your post, because the terminology you use has nothing to do with C++ and I don't know it from elsewhere either, so your text need a little intuition to translate into something that makes sense to me. I have guessed above that you want to make an assignment to SomeField (of the record selected by the index) using both the right hand side of the assignment operator and the value of the index. Then you go on ruminating/brainstorming on how you could do that, but you seem to do that without knowing the power of C++. It can be done. What you miss here is that C++ has both references and pointers that can be stored in your temporary on the stack and give you access to the selected row/record. > [SomeIndex].SomeField will trigger a "read property" not a "write property". > > I also though about overloading the "dot" / "." operator but this is not > possible in Delphi 2007 not sure about Delphi 2010 ? There are a few things I still don't get. Properties (as I understand them) are much more dynamic thing than index-number and a member name of a class. (Let's not open the debate about how using non-const public data in a class defeats the whole purpose of having one.) I would expect to see: SomeArray[SomeIndex][SomeField] := 5; instead of the dot notation. SomeField may be a string or an enum we converted from a string the user gave etc. In this case you won't hit the problem of not being able to overload the dot operator. The "value" of SomeArray[SomeIndex] is an "expression object" with a reference/pointer to SomeArray and SomeIndex inside. It's type has the [] operator with an index of the type of SomeField. The return type of that operator is again an expression object that now also has the "SomeField" inside. It has the assignment operator overloaded. The overloaded assignment operator has access to all the elements used to index into the properties table and can refer to the table itself. This is obviously not a perfect solution, we have lost type safety during compilation time. > I could use pointers and return a pointer... then somefield would be writing > into a pointer... this has two disadventages at least... first of all the > pointer itself would slow down memory access... second of all... pointer > might be stored by programmer... later pointer might be invalid introducing > problems. Accessing members of a class type over a pointer that is created and used within the same expression won't produce a slowdown that you could easily measure; and certainly not one that would make you complete program slow down. Chances are (or I could say: you could bet) the this line is most probably in the 80% of the code that does not affect performance. The constructor of the expression class may be private, with friendship provided *only* to the [] operator that creates it. So no, programmers could not create it. The expression objects are created and destroyed within the single expression that is the assignment. If SomeArray is gone during the lifetime of that expression (you say that event as: pointer may be invalid), any code will have serious problems. If you destroy the thing you assign to while you are assigning to it... > Lastly I wonder how c/c++ evolves since c/c++ does not seem to have any > experimental language to try out new stuff ? ;) I have seen some extensions > to c/c++ in for example c++ builder... but that's pretty stupid isn't it for > a standard to have non-standard elements ?!? Therefore I wonder if it's a > could idea to make an "experimental c/c++ language" for people to try out ! > ;) The standard has no non-standard elements. Your compiler has (conforming or non-conforming) extensions. > I shall suggest a name for it from the top of my head :): > "Cexp" :) for C experimental ;) :) > > or simply short: > > "Cx" :) Or just admit that you have no clue what's really going on, and stop assuming and guessing. ;-) Also off the top of my head: There are at least 6 places where I know that experimental compilers exist and in 3 out of the 6 they are being used and tested until nose bleeding as we speak. (Maybe at the other 3 as well, I just dunno.) Texas Uni (where Bjarne and Gaby is), Indiana Uni (conceptgcc), EDG, Microsoft, Google and Apple. There are more. These are only the ones I know about. In addition to that problems such as property trees and other common things are addressed (in a very professional and "high tech"/modern/useful way) at http://www.boost.org; and a lot of what they did experiment with in the last 10 years will be part of the new C++ standard. BR, WW
From: Erik on 23 Nov 2009 11:50
White Wolf wrote: > I think that you have not much knowledge of C++. It seems I have to > guess my way through your post, because the terminology you use has > nothing to do with C++ and I don't know it from elsewhere either, so > your text need a little intuition to translate into something that makes > sense to me. You have worked quite hard on a very eloquent and nicely put together piece of help for someone that could have used it. HOWEVER, this is just troll crossposting to everywhere and you got caught in it. Given enough time, you'll learn to disregard the babbling idiots. GL |