Graeme Geldenhuys <gra...@mastermaths.co.za>: [FillChar] > As for the COM usage requirement (which I honestly believe is the > minority use case in FPC).
AFAIK, the different semantic of "out" parameters applies to all reference counted types. That's especially unfortunate with dynamic arrays, where you lose transparency, because static and dynamic arrays behave differently under such circumstances. > Then create a different FillChar -type > procedure to handle those corner cases, or create a different procedure > which allows structure types to be initialized without compiler hints. Why don't you create your own initialization routine together with the type? I often did this, especially because zeroing out some structure may help in having deterministic values in the fields, but I'd debate the general "initialization equals setting it to zero" approach (which I personally refer to as "paranoia initialization" - in practice it merely hides the bugs than to avoid them). As a simple and stupid example: The code around an expression "a/b" remains wrong, no matter if "b" has been "initialized" to zero or contains some random "unitialized" value. If there are range types involved, the so-called initialized value may even be invalid, because the 0 is not necessarily inside the defined range. Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
