why shortstring in Delphi cannot used in our Programs using New IDE?

[Joseph MItzen 251]

14 hours ago, Dalija Prasnikar said:

Delphi is much more low level than C# or Java or JS.  It has all those string types for a reason and for interacting with particular OS and other APIs.

D has three types - string is UTF-8, wstring is UTF-16, and dstring is UTF-32. Rust has two types - string, and a type that is a slice into a string (it considers this to count as a second string type in the documentation). It still remains that Delphi is the only language to feel the need for so many different types. Heck, Python is the ultimate "glue" language to shove data around between OSes and APIs, and it has one string type and one bytes type and this is sufficient to interface with everything, deal with Windows and COM, wrap C code, etc.

 

 

Quote

We have different integer types

Don't get me started on that too! 😉 No complex number type, no fraction type, no arbitrary precision library, but so many integer types.... At least when I learned Turbo Pascal in Catholic high school I could declare all my types Cardinal....

 

[Dalija Prasnikar 1396]

4 hours ago, Joseph MItzen said:

D has three types - string is UTF-8, wstring is UTF-16, and dstring is UTF-32. Rust has two types - string, and a type that is a slice into a string (it considers this to count as a second string type in the documentation). It still remains that Delphi is the only language to feel the need for so many different types. Heck, Python is the ultimate "glue" language to shove data around between OSes and APIs, and it has one string type and one bytes type and this is sufficient to interface with everything, deal with Windows and COM, wrap C code, etc.

 

 

Delphi string types not only differ in bitness, but in memory management. I don't know how Python shows data to the APIs, but as I previously said that part usually requires converting data back and forth. Ability to work with particular representation directly enables you to write faster code, to avoid unnecessary conversions.

 

4 hours ago, Joseph MItzen said:

Don't get me started on that too! 😉 No complex number type, no fraction type, no arbitrary precision library, but so many integer types.... At least when I learned Turbo Pascal in Catholic high school I could declare all my types Cardinal....

 

Python does not work on such low level Delphi can. That is why half of libraries that do stuff are written in C or C++ 

[Dalija Prasnikar 1396]

 

4 hours ago, Joseph MItzen said:

C#, Javascript, Python, Ruby, Swift, Go, R, PHP (but still no native Unicode support!), Kotlin... you'd think if 29 string types were useful, more languages would have at least two...

Don't get me started with Swift... (besides the fact you can use other string types there like NSString and NSMutable string) 

 

Original Swift string representation storage was UTF16. Swift string, just like with current Delphi string wastes memory and loading and storing (UTF8 is most common storage encoding) performs conversion. Recently Swift string was optimized and UTF16 was replaced with UTF8- This reduced memory consumption and also increased performance. But that is something that had to be done in compiler. Before that you would either have to live with worse performance or you had to fiddle with C++ strings. And working with Swift strings is often #$%&@! because you cannot do simple things in simple way, because you have to got through Unicode consistency layer.

 

Now it is probably simpler to have single string type (if it is well optimized) but that requires completely different string handling and compiler support. Changing that would have immeasurable impact on existing code. Starting new language fresh and designing it with single string type is possible, but old language that has been built on 50 years old roots cannot change its internals that easily.

[David Champion 48]

3 hours ago, Dalija Prasnikar said:

Don't get me started with Swift

@Dalija Prasnikar.  I'm curious. Do you use Delphi to write your mobile apps, XCode or both? What is your current thinking?

[Fr0sT.Brutal 900]

16 hours ago, Dalija Prasnikar said:

More problematic are plethora of "compatibility" functions named AnsiXXX that work on string and not on AnsiString.

Yeah, these ones are dumb remnants. Things are changing with string helper though. Alas, for new compilers only. I wonder why Emba didn't declare these functions as XXX(string) naturally and declare AnsiXXX(string) as deprecated aliases. Instead we got something crazy like 64-bit System32 & 32-bit SysWOW64

16 hours ago, Dalija Prasnikar said:

Not really, because LOGI expects pointer to a string not TBytes. So that code does not compile. Not everything can be squeezed in TBytes and not everything makes sense to be bytes. LOGD logs text messages, the fact there is conversion to UTF8 involved is just example. You might as well have API that would directly use UTF-16 encoded string, or you may already work with UTF8 encoded strings.

I've no idea what LOGD expects... I'd say it's the flaw of Log's API to not provide convenient overloads with language-native types

[Fr0sT.Brutal 900]

4 hours ago, Dalija Prasnikar said:

Ability to work with particular representation directly enables you to write faster code, to avoid unnecessary conversions.

Well... if you have a pointer to memory, you can't deal with it as with string or array. Direct Ansi processing IMHO goes into history and I won't miss it. So one anyway has to copy data to a string or even convert from buffer to something convenient. So what's the sense in those types.

[Dalija Prasnikar 1396]

23 minutes ago, Fr0sT.Brutal said:

Well... if you have a pointer to memory, you can't deal with it as with string or array. Direct Ansi processing IMHO goes into history and I won't miss it. So one anyway has to copy data to a string or even convert from buffer to something convenient. So what's the sense in those types.

You are overly focusing on Ansi. I am more talking about differences between processing in UTF-8, UTF-16 and UTF-32.  

 

Depending on what you are doing you might want to use particular string type to avoid unnecessary conversions. For instance on Linux UTF-8 is most commonly used encoding, it makes sense to load data stored in UTF-8 and process it in UTF-8 before storing it back or sending it to client in UTF-8 encoding. Using UTF-16 string type there is utmost waste or resources. On Windows where Windows API-s use UTF-16 that is much less important and you could use regular string type and don't care. But even on Windows you could have situation where you are not interested in UTF-16 representation and where you will do all processing in UTF-8. So all those types very much make sense. 

[Dalija Prasnikar 1396]

1 hour ago, David Champion said:

@Dalija Prasnikar.  I'm curious. Do you use Delphi to write your mobile apps, XCode or both? What is your current thinking?

No. I am using Xcode and Android Studio. I am also keeping my eye on Delphi side, but I am not using it for anything beyond some test projects.

 

This is a long story, and originally when Delphi added Android support I couldn't use it because it didn't supported all devices I needed to support so I had to use Android Studio. Also Delphi was less interesting for some projects because it removed 8-bit string support and it was crucial for my codebase because I am using UTF-8 based strings for processing since Delphi 7. For those project(s) it was eventually simpler and cheaper to use Windows tablets than switching to Android.

 

Using Delphi definitely makes sense if you have plenty of common business code. Since unification of memory management and bringing 8-bit strings back, that is now even more viable. It all depends on particular situation. It is hard to give general advice.

 

Of course, switching tools is never easy and once you have significant investment in any toolset it is much harder to justify moving to something else - even if it means using same language and UI for all.

[Lajos Juhász 293]

2 hours ago, Fr0sT.Brutal said:

Yeah, these ones are dumb remnants. Things are changing with string helper though. Alas, for new compilers only. I wonder why Emba didn't declare these functions as XXX(string) naturally and declare AnsiXXX(string) as deprecated aliases. Instead we got something crazy like 64-bit System32 & 32-bit SysWOW64

They left the function names to make the codebase compatible with pre D2009 versions. Some libraries unfortunately still support those versions.