Jürgen Hestermann schrieb: > > >>> But currently move *does* handle dynamic arrays differently than >>> other procedures. >> It handles it exactly the same as any other function/procedure that >> takes a untyped/formal "var" parameter. Formal var parameters always >> take on the address of whatever you pass. > > That's not true! There is a lot of ambigouity with dynamic arrays. > Although an underlying pointer is used internally you use it as if it > was the array this pointer is pointing to in your code. If you first > have a static array "MyArray" then convert it to a dynamic array you > don't have to change your code (except if you use fillchar and/or move). > Why that? What exactly does "MyArray" mean?
See below. > You can't tell because it is > context dependent. That's not in the spirit of Pascal. File types are also less or more opaque. As soon as you start using move/fillchar on them without knowing exactly what you do, you're in trouble. > > True. As I said: There is no common logic what the identifier "MyArray" > means if it is a dynamic array (but there is for static arrays). It means the whole array (which is an opaque type). No more no less. > >> fillchar() and move() are equivalent to direct assembly level >> programming as far as the abstraction level is concerned because they >> ignore all type info. The fact that they ignore all type info is a mess. > > It's true that it ignores all *type* info. Still there was no ambigouity > about the starting address of a variable you give as parameter until > dynamic arrays were introduced (including AnsiStrings). The same applies to classes. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
