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.
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..?
Alf P. Steinbach
>
> 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++?
Depends what you want to do.
> Can we overload " = " for assignments to ***data*** members?
Yes.
> Any minimalistic sample..?
#include <stdio.h>
class Foo
{
struct X
{
int value;
X(): value( 0 ) {}
void operator=( int v ) { value = 2*v; }
operator int() const { return value; }
};
public:
X x;
int y;
Foo( int xVal, int yVal )
{
x = xVal; y = yVal;
}
};
int main()
{
Foo f( 5, 8 );
printf( "1: f.x = %d, f.y = %d\n", (int)f.x, (int)f.y );
f.x = 666; f.y = 111;
printf( "2: f.x = %d, f.y = %d\n", (int)f.x, (int)f.y );
}
And you can get more advanced by returning proxy objects.
However it's neither good design nor (for that reason) idiomatic C++.
Idiomatic C++ is to not expose member variables for a class with any kind of
behavior, only for pure PODs (C like structures).
Cheers & hth.,
- Alf
n00m
Thanks, Alf! I'll study your sample (surely it works :)).
Alf P. Steinbach
> Thanks, Alf! I'll study your sample (surely it works :)).
Depends on your definition of "works".
As mentioned it's not idiomatic C++, the whole idea of exposing data members is bad.
But anyway, even in that context the code I presented was bad, just coding down
what was discussed earlier in the thread. When not listening to old senile
rockin' chair guys who can't help but mindlessly repeat & code down what they
hear, you should prefer to centralize things in constructors instead of fiddling
with assignment operations. Like,
#include <stdio.h>
class Foo
{
struct X
{
int value;
X( int v ): value( 2*v ) {}
operator int() const { return value; }
};
public:
X x;
int y;
Foo( int xVal, int yVal ): x( xVal ), y( yVal ) {}
};
int main()
{
Foo f( 5, 8 );
printf( "1: f.x = %d, f.y = %d\n", (int)f.x, (int)f.y );
f.x = 666; f.y = 111;
printf( "2: f.x = %d, f.y = %d\n", (int)f.x, (int)f.y );
}
Cheers & hth,
- Alf
n00m
> the whole idea of exposing data members is bad
Hopefully I understand this :-)
White Wolf
We are soon going to pass a law in all virtual worlds, where exposing
your data members will be a punishable offense. ;-)