Language problem with properties ?!?
Skybuck Flying
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.
mans
Give a training about opengl that's interest me.
Bye
Maarten Wiltink
news:d374e$4adc78f6$d53372a9$30...@cache6.tilbu1.nb.home.nl...
> I have the following code
>
> SomeArray[SomeIndex].SomeField := 5;
>
> I would like to do special processing when SomeField gets assigned.
Write a property accessor.
> However I would also need the index parameter to know what needs to
> be assigned.
No. SomeArray[SomeIndex] should return an object. No problem.
Also, SomeArray should be SomeProperty.
> Currently with properties this is problematic.
Challenge your assumptions.
Groetjes,
Maarten Wiltink
Skybuck Flying
"Maarten Wiltink" <maa...@kittensandcats.net> wrote in message
news:4adcc436$0$83251$e4fe...@news.xs4all.nl...
> "Skybuck Flying" <Blood...@hotmail.com> wrote in message
> news:d374e$4adc78f6$d53372a9$30...@cache6.tilbu1.nb.home.nl...
>
>> I have the following code
>>
>> SomeArray[SomeIndex].SomeField := 5;
>>
>> I would like to do special processing when SomeField gets assigned.
>
> Write a property accessor.
I already wrote that's not possible since the accessor would give access to
a record...
The property will make a copy of that record when it's accessed... after the
.field assignment the record will be gone again so the results will not be
stored.
You assumed an object was being returned while in reality a record is being
returned.
As they say: "assumption is the mother of all fuck-ups LOL" ;)
Replacing the record with an object would not be desirable because of the
extra overhead of objects... especially the pointer overhead which would be
huge in this case ;)
Now you may come again ? ;)
Bye,
Skybuck.
Maarten Wiltink
> "Maarten Wiltink" <maa...@kittensandcats.net> wrote in message
> news:4adcc436$0$83251$e4fe...@news.xs4all.nl...
>> "Skybuck Flying" <Blood...@hotmail.com> wrote in message
>> news:d374e$4adc78f6$d53372a9$30...@cache6.tilbu1.nb.home.nl...
>>> I have the following code
>>>
>>> SomeArray[SomeIndex].SomeField := 5;
>>>
>>> I would like to do special processing when SomeField gets assigned.
>>
>> Write a property accessor.
>
> I already wrote that's not possible since the accessor would give
> access to a record...
And I wrote 'Challenge your assumptions.' Things will be different
from what they were in the past.
> The property will make a copy of that record when it's accessed...
> after the .field assignment the record will be gone again so the
> results will not be stored.
>
> You assumed an object was being returned while in reality a record
> is being returned.
I assumed no such thing. I told you, and I will tell you again, that
if the write accessor is important to you, you must _make_ SomeField
a property of an object, rather than a field of a record.
> As they say: "assumption is the mother of all fuck-ups LOL" ;)
Let's not discuss mothers. I might say something regrettable.
> Replacing the record with an object would not be desirable because
> of the extra overhead of objects... especially the pointer overhead
> which would be huge in this case ;)
>
> Now you may come again ? ;)
Why thank you. You are too kind.
If you 'desire' to link code into the assignment to SomeField, the
record has to become an object. The alternative is to rewrite all
the assignments, and stick to the new discipline of explicitly calling
the event dispatcher inline.
You are faced with a choice. Make it, and live with it. Every alternative
has consequences, and whining about what is or is not 'desirable' will
not change them. It's simply the cost of doing business. You want to
inject code into assignments, there will be limitations, and there will
be overhead.
You cannot have your cake and eat it. Records are more lightweight than
objects because they do not offer all the same features. If you have a
record and want a feature that objects have but records don't, you either
do without or you switch.
Or you write your own compiler and change the features of records until
they are no different from objects, and offer no advantages over them.
I will be most impressed if you write your own compiler - but I will not
be using it. My choice is to work with what Delphi (the versions I have
access to) offers now, and my advice is based on that.
Groetjes,
Maarten Wiltink
Piranha
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;
}
Skybuck Flying
Anyway properties is on of those language features which I miss the most in
c/c++/cg/etc ;)
Bye,
Skybuck.
White Wolf
> 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
Erik
> 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
Francis Glassborow
That is terribly condescending. This is a group for novices and very
often (especially if English is not their first language) their posts
are nearly incomprehensible. The fact that the OP cross-posted to a
fairly large number of groups is again symptomatic of the newbie.
Answering unknown posters who happen to be trolls is one of the risks we
take. I am not sure on the evidence that this one was a troll rather
than someone who found great difficulty in expressing himself.
Erik
> That is terribly condescending. This is a group for novices and very
> often (especially if English is not their first language) their posts
> are nearly incomprehensible. The fact that the OP cross-posted to a
> fairly large number of groups is again symptomatic of the newbie.
>
> Answering unknown posters who happen to be trolls is one of the risks we
> take. I am not sure on the evidence that this one was a troll rather
> than someone who found great difficulty in expressing himself.
No, this is a habit of the OP, it is not a mistake
or a misunderstanding, it is a constant habit. He
realizes exactly what he's doing, he's just a troll.
He has regularly posted in NGs for the past few
years, he is no n00b.
It's no fault of the extraordinarily kind response
that was generated above, I was just letting him know.
I have no problem being condescending to OP troll.
No problem at all.
Erik
Oh, and this was a Borland/Codegear Delphi question posted
to a C++ newsgroup, as well. That's why the replier was
confused as to the syntax of the posted question.
Rudy Velthuis
> > Given enough time, you'll learn to disregard the
> > babbling idiots.
>
> That is terribly condescending. This is a group for novices and very
> often (especially if English is not their first language) their posts
> are nearly incomprehensible.
Sure, but Skybuck Flying is not a novice, he is an idiot who trolls
these groups since I don't know when.
--
Rudy Velthuis http://rvelthuis.de
"I wouldn't mind dying - it's the business of having to stay
dead that scares the shit out of me." -- R. Geis.
White Wolf
> Francis Glassborow wrote:
>
>>> Given enough time, you'll learn to disregard the
>>> babbling idiots.
>> That is terribly condescending. This is a group for novices and very
>> often (especially if English is not their first language) their posts
>> are nearly incomprehensible.
>
> Sure, but Skybuck Flying is not a novice, he is an idiot who trolls
> these groups since I don't know when.
I have given a non-violent, non-emotional (once in my life I have
managed) answer to a confusing but IMHO valid post that represents a
likely newbie problem (newbie running alongside his false assumptions).
The problems the guy describes may be faced by any novice.
You and Erik vehemently oppose me answering the OP. Because that feeds
the troll. I have to disagree. If the OP is a troll, your off-topic,
kinda emotional posts are the ones feeding the troll. Erik has managed
to write 3 and trigger an additional 3 posts that are off-topic; at
least for the thread.
Even if the OP was a troll, answering him politely won't do any harm.
The answer, if at all helpful, may help those who are not trolling and
honestly looking for help.
However "troll alerts" of the kinds you guys made here sound a bit like
kindergarden. :) Perhaps it is better to do such "alerts" with proof:
with links (on Google Groups) to threads the person was trolling in.
If the OP is a troll, he won. He has got the 4 of us arguing, even
without writing a single additional post. :)
--
BR, WW
Richard Heathfield
wrote:
> Erik wrote:
<snip>
>> Given enough time, you'll learn to disregard the
>> babbling idiots.
>
> That is terribly condescending.
On this occasion, it seems to be justified.
> This is a group for novices and very
> often (especially if English is not their first language) their
> posts are nearly incomprehensible. The fact that the OP cross-posted
> to a fairly large number of groups is again symptomatic of the
> newbie.
Except that, in this case, he's no newbie.
> Answering unknown posters who happen to be trolls is one of the
> risks we take. I am not sure on the evidence that this one was a
> troll rather than someone who found great difficulty in expressing
> himself.
Skybuck Flying is a known troll, going back years - in this group and
in others.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Rudy Velthuis
> > > That is terribly condescending. This is a group for novices and
> > > very often (especially if English is not their first language)
> > > their posts are nearly incomprehensible.
> >
> > Sure, but Skybuck Flying is not a novice, he is an idiot who trolls
> > these groups since I don't know when.
>
> I have given a non-violent, non-emotional (once in my life I have
> managed) answer to a confusing but IMHO valid post that represents a
> likely newbie problem (newbie running alongside his false
> assumptions). The problems the guy describes may be faced by any
> novice.
No problem, and that is a nice thing to do.
People are just warning you and the other groups who see this for
Skybuck, who probably never grew up. He thinks he is a genius, he does
not take advice, he is very gratuitous with insults and he is a pest to
every group he infiltrates. He never reads documentation and thinks
everything he finds is a great new invention of his. IOW, he is an
extremely vitriolic, dumbass troll. But he is not a newbie.
--
Rudy Velthuis http://rvelthuis.de
"There are people in the world so hungry, that God cannot appear
to them except in the form of bread."
-- Mahatma Gandhi (1869-1948)
Zathras
<newsg...@rvelthuis.de> wrote:
>People are just warning you and the other groups who see this for
>Skybuck, who probably never grew up. He thinks he is a genius, he does
>not take advice, he is very gratuitous with insults and he is a pest to
>every group he infiltrates. He never reads documentation and thinks
>everything he finds is a great new invention of his. IOW, he is an
>extremely vitriolic, dumbass troll. But he is not a newbie.
While striving to be overly polite about Harald Houppermans, you
forgot to mention his unbelievable trolling persistence and only
hinted at his uncanny ability to remain the perpetual newbie.
I enjoyed your use of the word 'infiltrates' as a particularly
accurate and insightful observation. ;-)
Things are nice since he entered my killfile but he still plies his
trade suckering good people..as he always will.
--
Z
Rudy Velthuis
He's in my killfile as well, but sometimes I catch the fallout of his
presence in the form of replies to him. <g>
--
Rudy Velthuis http://rvelthuis.de
"The chain reaction of evil -- wars producing more wars -- must
be broken, or we shall be plunged into the dark abyss of
annihilation." -- Martin Luther King, Jr.
Erik
> You and Erik vehemently oppose me answering the OP. Because that feeds
> the troll.
Not at all. I admired the amount of work you put into that
and I tried to express that.
I was merely trying to let you know this guy's posting habits.
Zathras
<newsg...@rvelthuis.de> wrote:
>He's in my killfile as well, but sometimes I catch the fallout of his
>presence in the form of replies to him. <g>
I don't think there's much to be done about that - I'm in that same
boat. :-(
--
Z
White Wolf
That's all right. My reply may help someone else, who really looks for
help. :)
--
BR, WW
n00m
In Python we can do smth like this:
===========================================
class Foo:
def __init__(self, x, y):
self.x = x
self.y = y
def __setattr__(self, name, val):
if name == 'x':
self.__dict__[name] = val * 2
else:
self.__dict__[name] = val
===========================================
f = Foo(5, 8)
print '1:', f.x, f.y
f.x = 666
f.y = 111
print '2:', f.x, f.y
===========================================
1: 10 8
2: 1332 111
===========================================
How can it be done in C++?
Can we overload " = " for assignments to ***data*** members?
Any minimalistic sample..?