On 11/18/2011 01:37 PM, Sven Barth wrote:
Because then you don't need to rely on the point that SizeOf(Char) =
1. Now imagine you have an applications that uses strings as buffers
and port that from lets say Delphi 7 to Delphi 2009. Have fun finding
the bugs if you don't remember that you used a String as buffer.
I don't see what you mean here. My suggestion regarding "new string
types" was to provide all thee Types RawByteString, RawWordString,
RawDWordString, for this purpose.
Why implement another String type to ease something strings weren't
intended for?
In C it is very common to use an int for a pointer. :)
My understanding of the word "String" just does not include the
definition that this is necessarily something providing a "visual" content.
Implement your own type that handles all this and then you don't even
have a problem should FPC decide to switch String from AnsiString to
UnicodeString.
Why invent yet another time, when an existing one is perfectly suitable ?
I don't see how a user can define a type that provides reference
counting and lazy copy. I gather that this needs compiler magic.
With this in mind I feel that (regarding the proceedings regarding the
new string type definition) it would be a nice thing to provide
RawByteString, RawWordString, RawDWordString that don't ever trigger a
conversion and (at a later time) additionally consider to do FiFo String
types that, are optimized for allowing deleting from position 0.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
