Board index » delphi » Re: Argh! Delphi 2005! Argh! (part 2)

Re: Argh! Delphi 2005! Argh! (part 2)


2004-11-30 05:47:54 AM
delphi120
Quote
"Hrvoje Brozovic" <XXXX@XXXXX.COM>wrote in
news:XXXX@XXXXX.COM:

>type Numbers = array of integer;
>
>for Number in Numbers do Number := Number shr 1;
Problem is we already proved that you cant do that, the for <variable>
in.. the variable is basically read only :(
 
 

Re: Argh! Delphi 2005! Argh! (part 2)

Hrvoje Brozovic writes:
Quote
Deeply disappointed.
Assignments to a for-to loop variable are not allowed either.
In your case, if Number were assignable, you would not be iterating
over the array.
--
Rudy Velthuis [TeamB]
"Chaos Theory is a new theory invented by scientists panicked by the
thought that the public were beginning to understand the old ones."
-- Mike Barfield.
 

Re: Argh! Delphi 2005! Argh! (part 2)

marc hoffman writes:
Quote
>with using for in loop, I am telling
>compiler that I give up knowledge of
>of element index, meaning that as I am
>concerned, all elements are independent of all other,
>so it can produce code to access them
>in any order it sees fit, use SIMD instructions,
>unroll the loop and whatever is best for the couse.

hmm. I would certainly expect "for in" to process items in the correct
order...
Of course that order depends on how the enumerator is coded, i.e. what
is the "correct" order? For hashtables, or bags, that can be any order.
For arrays, it is /probably/ from low index to high index. The only
guarantee you have is that each item will be visited, and only once.
--
Rudy Velthuis [TeamB]
"Ever notice when you blow in a dog's face he gets mad at you, but
when you take him in a car he sticks his head out the window?"
-- George Carlin
 

Re: Argh! Delphi 2005! Argh! (part 2)

Rudy Velthuis [TeamB] writes:
Quote
Of course that order depends on how the enumerator is coded, i.e.
what is the "correct" order? For hashtables, or bags, that can be any
order. For arrays, it is /probably/ from low index to high index. The
only guarantee you have is that each item will be visited, and only
once.
Yes, you may be in for a surprise if you try foreach on a DataView in
.Net, for example. Even when sorted, the items appear by index. The
DataRows however, appear as sorted, to complicate the matter...
In general, one just expects it to iterate the same way as it would
from low index to high index, I really doubt the use of "probably" is
required here.
--
Ingvar Nilsen
 

Re: Argh! Delphi 2005! Argh! (part 2)

Hrvoje Brozovic writes:
Quote
Deeply disappointed.

I saw that together with inline as a vehicle for real codegen
improvements.
For me, foreach (and for in) come in handy with "real" objects.
And those objects' methods can be called inside the loop.
If an indexed integer were allowed to be altered, it would practically
mean that you could replace the pointer to the object too (in case the
variable is an object) which would have no meaning at all.
In your case, I wouldn't be deeply disappointed, just slightly
surprised :)
--
Ingvar Nilsen
 

Re: Argh! Delphi 2005! Argh! (part 2)

Ingvar Nilsen writes:
Quote
In general, one just expects it to iterate the same way as it would
from low index to high index, I really doubt the use of "probably" is
required here.
Oh, I guess that is the most propable way, but not necessarily the only
way.
--
Rudy Velthuis [TeamB]
"I choose a block of marble and chop off whatever I don't need."
-- Francois-Auguste Rodin (1840-1917), when asked how he managed to
make
his remarkable statues
 

Re: Argh! Delphi 2005! Argh! (part 2)

"Rudy Velthuis [TeamB]" <XXXX@XXXXX.COM>wrote in
Quote
For arrays, it is /probably/ from low index to high index. The only
guarantee you have is that each item will be visited, and only once.
Considering what the optimizer does to normal for loops, I would probably
expect it to go from high index to low.
Jeff.
 

Re: Argh! Delphi 2005! Argh! (part 2)

Jeffrey A. Wormsley writes:
Quote
"Rudy Velthuis [TeamB]" <XXXX@XXXXX.COM>wrote in
news:xn0dqd3rpgfndlj002rudys-toshiba@www.teamb.com:

>For arrays, it is probably from low index to high index. The only
>guarantee you have is that each item will be visited, and only once.

Considering what the optimizer does to normal for loops, I would probably
expect it to go from high index to low.
II didn't look what happens in Win32, but I know that the enumerator
returned by the Array class in .NET doesn't.
--
Rudy Velthuis [TeamB]
"Ever stop to think, and forget to start again?" -- bumper sticker
 

Re: Argh! Delphi 2005! Argh! (part 2)

"Rudy Velthuis [TeamB]" <XXXX@XXXXX.COM>wrote in
Quote
I didn't look what happens in Win32, but I know that the enumerator
returned by the Array class in .NET doesn't.

In Win32, a simple for loop will work backwards instead of forwards. I
believe there are warnings about it in one of the help files, because it
can be disconcerting when you set a breakpoint in the loop and watch your
index variable go the other way. It only seems to do this for simple
loops, though.
Check this thread...
tinyurl.com/46dxv
Jeff.
 

Re: Argh! Delphi 2005! Argh! (part 2)

Jeffrey A. Wormsley writes:
Quote
In Win32, a simple for loop will work backwards instead of forwards.
I know.
Not sure what happens in a for-in loop, though. To me it looks as if it
always counts from low to high.
--
Rudy Velthuis [TeamB]
"Barabási's Law of Programming: Program development ends when the
program
does what you expect it to do ?whether it is correct or not."
-- Albert-Lászl?Barabási
 

Re: Argh! Delphi 2005! Argh! (part 2)

"Liz" <XXXX@XXXXX.COM>wrote in
Quote
>"Hrvoje Brozovic" <XXXX@XXXXX.COM>wrote in
>news:XXXX@XXXXX.COM:
>
>>type Numbers = array of integer;
>>
>>for Number in Numbers do Number := Number shr 1;

Problem is we already proved that you cant do that, the for <variable>
in.. the variable is basically read only :(
Right, which is why I had said it had to be this way:
for Number := Low(Numbers) to High(Numbers) do Numbers[Number] :=
Numbers[Number] shr 1;
Jeff.
 

Re: Argh! Delphi 2005! Argh! (part 2)

Quote
Make sure you vote in QC on bugs you would like fixed, or at least
provide us with a list. Sysops are on the prowl for popular QC bugs to
promote...
Sorry to break into the discussion. But why waisting time putting people
managing QC bugs. Teach them coding and send them fix bugs as well. Imho
there are so many atm I would need about 30 votes for the urgent ones..
:/
 

Re: Argh! Delphi 2005! Argh! (part 2)

Ximian writes:
Quote
>Make sure you vote in QC on bugs you would like fixed, or at least
>provide us with a list. Sysops are on the prowl for popular QC
>bugs to promote...

Sorry to break into the discussion. But why waisting time putting
people managing QC bugs.
QC, being a community project, needs sysops. These are usually not
Borland people, they are volunteers, customers like you and me.
--
Rudy Velthuis [TeamB]
"Friends applaud, the Comedy is over." - Ludwig von Beethoven, dying
words
 

Re: Argh! Delphi 2005! Argh! (part 2)

Rudy Velthuis [TeamB] writes:
Quote
QC, being a community project, needs sysops. These are usually not
Borland people, they are volunteers, customers like you and me.
And know how to code or at least pretend they do...
--
** Currently looking for a couple of testers.
** More information in my blog!
+++++++++++++++++++++++++++++++++
Sneak Peek: JED, QC - IDE Edition at
www.alphalink.com.au/~jed/QC/
Blog: jedqc.blogspot.com/
 

Re: Argh! Delphi 2005! Argh! (part 2)

JED writes:
Quote
Rudy Velthuis [TeamB] writes:

>QC, being a community project, needs sysops. These are usually not
>Borland people, they are volunteers, customers like you and me.

And know how to code or at least pretend they do...
Don't we all? <g>
--
Rudy Velthuis [TeamB]
"The right to swing my{*word*128}ends where the other man's nose begins."
- Oliver Wendell Holmes (1841-1935)