Leaderboard

I don't remember anyone complaining The though process was a bit different. Mobile compilers were supposed to attract new generation of developers. To do that it needed to have some competing features. One was automatic memory management (hence ARC), another one was streamlining string and array indexing - hence zero-based strings. Short strings store length at index zero, so they were completely incompatible with that goal. AnsiStrings with ANSI encoding are not something that exists on mobile platforms, so they were deemed as unnecessary, too. So 8-bit strings were removed. Unfortunately, what they didn't take into account is impact on existing codebases. The same ones that were supposed to run on all other platforms (yes, you couldn't reuse GUI), but there is not reason to throw away non-GUI code. Zero based strings wreak havoc in string handling, causing subtle bugs all over the place. Most people after they learned about it would just turn the damn thing off. Removing all other 8-bit strings was also a mistake, because 8-bit strings make a whole a lot of sense in cross-platform, especially on Linux where UTF-8 encoding rules. So while throwing out AnsiString as such made sense, the rest did not. This is also why 8-bit strings were reintroduced, even before ARC was removed - which happened for completely different and unrelated reasons. And the last, but not the least. TBytes are completely different beast from strings. It is not that just that handling functions were missing. TBytes don't have COW, and also debugger support is extremely limited and you cannot easily inspect textual data stored within. And we all know how many new customers they attracted to Delphi because it was suddenly cross-platform.

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.

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.

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. 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++

That notice has been in the documentation since XE4. All ANSI types (P/AnsiChar, AnsiString/(N), ShortString) were disabled in the NEXTGEN mobile compilers in XE3. Under NEXTGEN, UTF8String and RawByteString were re-enabled in 10.1 Berlin, and then the rest of the ANSI types were re-enabled in 10.4 Sydney when NEXTGEN was dropped completely so mobile platforms now match desktop platforms in terms of language features. Looks like the ShortString documentation has not been updated yet to reflect that. Yes. Only in XE3 through 10.3. In 10.4 onward, ShortString can be used on mobile. No. Because ALL ANSI types were initially eliminated, as mobile platforms are Unicode-based. Then the types slowly started being re-introduced as needs arose, until eventually Embarcadero decided that having separate compiler architectures just wasn't working out. Hardly.

A TList<T> is a class, so a variable of type TList<T> being nil is not an empty list, but no list instance at all. In contrast to nil, an existing TList<T> instance can be filled. For nil you first have to create with TList<T>.Create to get a list you can work with. In contrast to that an array is not class.

I've committed my small changes to a fork here... https://github.com/gmurt/PdfiumLib

Sure, I’ll fork the repo and add my changes later today. I’ll post a link here once I’ve got it ready.

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. 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....

As old-school Delphier I understand why all these string types exist but honestly I'd cut some of them down. Ansistrings with codepages could be removed - RawBytes and Utf8 seems sufficient. Even Utf8 as string type could be avoided in some cases. Your example : Without 8-bit string compiler support procedure Output(const aMsg: string); begin LOGD(TUTF8Encoding.ToBytes(aMsg)); end;

It's Java. Very early on many C# programs were also valid Java programs.

As many of us are likely to recall from the old forums, a key perspective here is that "developers don't understand marketing." In order to consider making changes, one must first be open to the possibility that the current state of affairs could be improved.

I always though Delphi is the root ancestor to C# The only commonality C# has with C are braces.

And even without them we're now stuck with the zero based string helpers. What a turd.

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. When you need to handle such low level things in Java or any other language the whole thing usually ends up being a memory and performance hog, just like it happened in initial mobile compilers, because you cannot deal directly with particular string representation and you have to juggle data back and forth. And handling encoding and other issues is never easy there, too. Some features can be implemented through helpers, but you cannot accomplish everything in satisfactory manner. For instance getting pointer to UTF8 string to use with OS API you needed additional TMarshaller variable. And not only you need the variable, but the code behind it is slower. Without 8-bit string compiler support procedure Output(const aMsg: string); var M: TMarshaller; begin LOGD(M.AsUtf8(aMsg).ToPointer); end; With 8-bit string compiler support procedure Output(const aMsg: string); begin LOGD(PUtf8Char(Utf8String(aMsg))); end; As far as new users are concerned, they only need to know and use generic string type. If and when they get in touch with other string types, it is pretty simple to explain what is purpose of each type and how is is used. We have different integer types, we have different string types.

I've seen some articles with yells like "why Shortstring, Ansistring, Rawbytestring, WideString, Unicodestring, Utf8string, Whateverstring when you only need one Unicode string?!" Indeed, AFAIK C# only has one string type and so does JS. OTOH, any Tbytes/Buffer representation lacks ability of clean operations ("if bytes = 'foo'" etc). However, most of string features could be implemented as helpers, overloaded operators and custom IDE viewers. If only Emba introduced all that stuff together with removing string types, probably this change was accepted more gladly.

Hi guys, Thanks for all of your input. After a little more research it appears that the Pdfium wrapper from Andreas (https://github.com/ahausladen/PdfiumLib) fits my needs perfectly. I wasn't aware of this component before. The DevExpress pdf viewer worked perfectly also but as I only require the PDF viewer right now I didn't make sense to purchase the whole DevExpress component set (although these do look awesome and I hope to look at them more next year having watched some videos) I made some small tweaks to the source code to add a page border and drop-shadow and now it looks a little more polished. I'll see if I can post these changes back to the repo. Thanks again for all your suggestions, Kind regards, Graham

Many people complained "Why so many string types and what are all these for??" so Emb decided to cut them off in favor of Tbytes but they didn't provide convenient string features at that time (Pos, concat, inline init etc) so much more people started complaining they absolutely need all of that string types so Emb had to bring them back 🙂

I'm sorry about that, although I don't quite understand why you find it offensive. I'm sure Joe knows his stuff but appearance does matter. I actually looked at the site trying to find more information about the library but eventually gave up. Now that I look at it again I can see that what I thought was just more bullet points is actually links to sub pages. After that I had to read through all the FAQ to deduce that it's not a native Delphi library. If I had actually been looking to buy a PDF library (I'm not since I have a DevExpress subscription) I would have taken one look at that page and quickly moved on. Joe or not.

Marketing strategy? Really? Just because you disagree with the decision to deprecate it doesn't make it a stupid decision, driven by "marketing". The deprecation of "object" was also controversial but that wasn't driven by marketing either. I'm pretty sure management, marketing and sales couldn't care less about these things.

I hope Joe is better at coding than designing web sites 🙂

That's not really why byte is useful. Byte is primarily useful to store binary data, typically as TArray<Byte>. It's rare to use Byte to store a count for example.

JFYI HTML Office Library (including HTML Component Library) adds 4.5Mb for all supported formats - PDF, DOC, DOCX, XLS, XLSX, PPT, PPTX, SC, MD, HTML, MSG. Final exe size (when compiled in 11 release) is 6.7 Mb.

It exists to balance out my inherent sense of imminent doom.

From an old blog post from Allen Bauer (https://blog.therealoracleatdelphi.com/2009/09/: " All eligible class constructors and class destructors are invoked in sequence with unit initialization and finalization, respectively. If a given class constructor or destructor is eligible to be invoked (ie. it was linked into your application), it will run immediately before the initialization section for the unit in which the class is implemented. The class destructors will be invoked immediately after the finalization section for the unit in which the class is implemented. Class constructors in a given unit are generally invoked in the same order of declaration, except in cases described below. Class destructors are invoked in reverse order from the class constructors. For an ancestor class declared in the same unit, its class constructor will be invoked before the descendant class constructor and the class destructor is invoked after the descendant class destructor. If the implementation of given class constructor references another class in the same unit with a class constructor, the referenced class’ class constructor will be invoked before the current class’ class constructor. If the references are cyclic (ie. they reference each other in their class constructors), then they are invoked in reverse order of declaration. This means that there can be cases where a class constructor can reference an “unconstructed” class. Ancestor classes from external units used in the interface section are guaranteed to already have their class constructors run prior to any class constructors on descendant classes within the current unit. Unit cycles can break down the deterministic nature of the above rules in the same manner as unit initialization and finalization. However, for a given unit, it is guaranteed that all the class constructors declared within in it will have already run immediately before the initialization section runs. Congruent to this rule is that it is guaranteed that all the class destructors will run immediately after the finalization section. Dynamically loaded packages, using LoadPackage. Because there is no way to know exactly which classes are going to be used, just like there is no way to know which units are going to be used, all class constructors and destructors along with all unit initialization and finalizations are invoked according to the above rules. Other rules about their use are: You do not have to declare a class destructor if you declare a class constructor, and vice versa. They cannot be virtual, dynamic or message. They cannot be explicitly called. They cannot have any parameters. They do not have to be called Create and Destroy. (ie. Init and Fini are equally valid names). With this implementation, it was easier to leverage the same table that the compiler creates for unit initialization and finalization. It satisfies this requirement: “Called automatically to initialize the class before the first instance is created or any static members are referenced.” Issues with cycles are also clearly warned against in VB.NET and C#: “Avoid circular references in Shared … since it is generally impossible to determine the order in which classes containing such references are loaded.” Another benefit is that since it is running during the initialization/finalization phases, any threading implications are no different than the existing rules regarding unit initialization and finalization." What we don't know is, if the compiler behavoiur has changed since then.