On Feb 14, 6:33 pm, Joep Suijs <[email protected]> wrote: . > It would be easy to add support for zero-terminated strings in > print.jal though. On the other hand I would advice all string routines > also handle strings without termination. > > Joep
Yes. I agree. Relying on zero Termination is the greatest evil of C, C+ +, Linux, OS X and Windows. It should be optional. also if a String represents packed BCD it will have lots of nulls :-) C, C++ greatest failing is relying on Null termination. pascal is inflexible with strings Modula-2 can use Pascal or C like strings. You can resize Arrays / Strings in Modula-2. VB6 uses "magic". It pretends strings are single byte, even though they are Unicode and also stores a current size. If you don't assign a VB string to a fixed length constant or use Space$ before an API or DLL call it will "explode" as the non-VB extends the string. Always knowing how much storage is allocated to a string is important always. With pure null terminated string & typical C libraries you don't know. I don't think we want VB6 BSTR nor Unicode. If 16bit characters/ Unicode is ever needed that should be a separate Unicode library. For 99.9% of PIC applications UNICODE/16bit is a huge waste. I think packedBCD, Characters and Strings should be in the same library as they are very related, we want to be able to myChar = MyString[n] and extract "0".."9" + "0".."9" (string) or 0..99 (byte) or "0".."9" (high or low nibble) from string or byte array of packed BCD. array of byte and array of string of same size should be assignable to each other. Also can we assign subarray of byte and/or String by having a range in [ and ] on both arrays? -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
