downto is better, as to is simply buggy.NO 'to' is not buggy!!!
If we can say "downto is better", why we can't say "to is buggy"? :D
It's strange to me that someone understand this phrase verbatim. I think its meaning was clear in the context of discussion.
Of course I don't think that "to is buggy" by itself. And that "downto is better" always and everywhere. :D
I think it's faster to simply create an empty string with length set to the current length and then copy char to this string that is valid. At the end reset the length.
It's strange to me that someone understand this phrase verbatim. I think its meaning was clear in the context of discussion.
Of course I don't think that "to is buggy" by itself. And that "downto is better" always and everywhere. :D
In that case choose your words better: "to is /inappropriate/ in this case" is the correct way of putting it, particularly in something which is labelled as being for beginners.
MarkMLl
The answer is simply about efficient memory handling. Nothing more.
@tetrastesLook who's talking... LOL
You are a nitwit, a great pretender,
It is not about if code works, it is about why the code is extremely inefficient.
The question is really about optimization and efficient algorithms. 8)
It can work moving forwards ... :)
Well obviously less memory is allocated as things are deleted. But for explaining to a newbie I’d try to explain it in a less technical terminology. :)
Wouldn't change anything difficulty wise. Delete deletes 1 byte, so same problem.It can work moving forwards ... :)
Nice. Although, this one would be hard to adapt to work with UTF.
It is plain wrong, utf8 or not. the setlength causes a relocation.No it doesn't, the final setlength just changes the internal string length without reallocating memory.
I’m surprised to see people arguing over something so basic.Nonsense generalization. In this case, delete internally calls SetLength for each deleted character.
Downto , {descending index} is the correct way to approach anything that might be reduced in length. Only a genuine newbie would not know this.
It has nothing to do with memory allocation , it has to do with the items referenced by indices changing when an item is deleted. In fact if anything is removed your program will probably crash when you reach the last index and try to reference something that is no longer there.
Almost Correct: it has to do with memory allocation, because traversing downwards keep the location itself in place ( same pointer) traversing upwards does not do that, so you will loose speed by reallocmem. You can test that by tracking the pointer(s).Nonsense, silvercoder70's code doesn't touch the location. You didn't trace the code, the pointer to the AnsiRec doesn't change.
Well obviously less memory is allocated as things are deleted. But for explaining to a newbie I’d try to explain it in a less technical terminology. :)Just repeating the nonsense of Thaddy in the case of the original code doesn't make you look very helpful.
Wouldn't change anything difficulty wise. Delete deletes 1 byte, so same problem.It can work moving forwards ... :)
Nice. Although, this one would be hard to adapt to work with UTF.
Joanna'd, good and accurate :-)
Don't laugh, since I'm quite likely to refer to other threads as being Joanna'd: the difference is that you introduce wibble rather than otiose complexity.
MarkMLl
Silvercoder70's solution doesn't use delete.I know it doesn't use delete. It use pull down with a single final length actualization. Nearly the same code I would write.
I don’t understand how a simple question about which algorithm is better turned into all this drama. :D
OP made a good point, based on elementary Pascal, relating to a problem that I'm damn well sure has caught absolutely everybody at some point.So true !