Strings and Binary data types

[ohgreat]

1. Don't mix them! (ie. don't use strings to store binary data)

Why? Because in the future each character may be multi-byte, not single-byte ascii as it is now.

Imagine this structure per variant: (or something similar)

- Type (Null, String, Char, Byte, Int16, Int32, Int64, Double, DateTime, Boolean, Variant, Object, etc)

- Is array? + Number of dimensions (max n) plus size of used dimensions

- Data (if not null), being repeated if array

- - a Unicode Char, Byte, IntXX, Double, DateTime, Boolean, or

- - a ptr to String data (null if empty) plus length, or

- - variant (used only if an array of variants)

- - a ptr to an object reference

- - etc

We can then have a bunch of new binary handling functions, similar to strings:

BinMid(...), BinLeft(...), BinRight(...), BinInBin(...), BinToString(b, encoding method), StringToBin(s, encoding method), etc, plus concatenation, b &= b2

(encoding method is UTF8, UTF16, 2-byte Unicode, ..).

Your thoughts?

[DaveF]

I don't have any strong feelings about the need for native binary data functionality in AutoIt, because I've never had the need to mangle non-text buffers at that granular a level. This could change, though, depending on how MSH / Monad integrates with the console and standard input / output...

[Valik]

ohgreat, thats looking at things at a low-level and that is something we should be avoiding. A "character" is a character no matter if it's composed of 1-byte, 2-bytes or 38-bytes. It may take 2-bytes or 16 bits to store one character but at the end of the day it is still just one character so as long as the internal code makes no assumptions, there should not be any problems with AutoIt as a language.

Also, I wouldn't hold your breath about UNICODE support. It would be a tremendous undertaking to retrofit several tens of thousands of lines of code from using char to TCHAR and updating all functions to use the TCHAR equivalent.

[DaveF]