Hi,

There is a discussion in the tiOPF newsgroups about adding Mobile development support to the framework. A Delphi developer raised the following issue with first experimentation.

Is this issue the same for FPC? ie: is the String type zero based for mobile development?

=================================================
Creating a mobile app for iOS (and eventually Android) has hit the first stumbling block: strings are zero based.

http://docwiki.embarcadero.com/RADStudio/XE5/en/Migrating_Delphi_Code_to_Mobile_from_Desktop

Example:
tiXML.pas has a method:
TtiXMLParser.ParseForAttributes(const AStr:String; pOnFind: TtiOnXMLAttributeMethod);

This:
  for i:= 1 to lStrSize do
Needs to become:
  for i:= Low(AStr) to High(AStr)
This:
  lName := Copy(AStr, lStart+1, i - lStart - 1);
Needs to become:
  lName := AStr.Substring(lStart+1, i - lStart - 1);

etc.
=================================================

Regards,
- Graeme -

In FPC, this setting only depends on the {$zerobasedstrings on/off} directive (supported in FPC 2.7.1+). The default is "off" everywhere. You can also switch it off in Delphi for mobile targets: http://docwiki.embarcadero.com/RADStudio/XE4/en/Zero-based_strings_(Delphi)

They probably changed the default there for efficiency reasons (not having to subtract 1 from string indices all the time).

Jonas

In our previous episode, Jonas Maebe said:

(zerobasedstrings)

They probably changed the default there for efficiency reasons (not having to subtract 1 from string indices all the time).

Considering what they lug on in compatibility(and that being a key selling point), and how they went about it on other targets (e.g. IDisposable use in Delphi.NET), I doubt performance is really the reason.

They have been planning to let the language get closer to the accepted set since they initiated the "new" compiler initiative. Probably they are testing the water with a new target to not get a backlash from established business.

Graeme Geldenhuys wrote

Is this issue the same for FPC? ie: is the String type zero based for mobile development?

While I (doing a lot of C) don't like the one-based String paradigm in Pascal, I think it's absolutely horrible to introduce zero-based Strings (other than pchar) and break a many years old tradition.

Moreover, IMHO it's an extremely nasty idea to introduce any difference between a "Desktop" and a "mobile" language ! Do we want additional incompatible "embedded", "multicore", ... or whatever language dialects ???

fpc (and Lazarus) have set out for arch and platform independence, and thus the syntax (and the programming paradigms and - as far as possible
- the GUI widgets) need to compatible.

Even regarding the GUI, Lazarus does a great job trying to provide compatible widgets for all supported platforms. (If some widgets are not supported by a some platforms I don't mind if I just get an error message.)

Delphi does a very bad job on the compatibility front, not supporting VCL Widgets on so called "mobile" platforms, to me seems unacceptable. If you want "Firemonkey" as an alternate Widget Set to create a "fancy" GUI, maybe more appropriate for "mobile" use (the hell knows why this is supposed to be different on mobile vs Desktop, now as many mobile devices provide a huge screen resolution), both Widget Sets (or a decent part of the widgets) should be provided for any supported platform.

Anyway "forking" fpc in such a way seems catastrophic.

Regarding strings, there were several discussions to completely kill the "index" syntax for a strings. As with an unknown encoding, the index does not make much sense, and, with certain frameworks (such as CIL) strings are unalterable and need to be recreated when modified (which seems to make sense performance-wise in some cases). IMHO, killing the index syntax would be more acceptable than modifying the meaning of a "visible" index into a string under the hood.

-Michael

In our previous episode, Michael Schnell said:

Anyway "forking" fpc in such a way seems catastrophic.

We are not forking anything. We only accept the directive, and we don't have a FM in the first place to create a compatible fork.

IMHO a substituting bad with worse is not a good reason. Java/CIL needs this because its strings are immutable, and character access is expensive. We don't share, nor plan to share that trait.

Marco van de Voort wrote

In our previous episode, Michael Schnell said: > Anyway "forking" fpc in such a way seems catastrophic. We are not forking anything. We only accept the directive,

Great !

Of course offering the option to those who don't need compatibility is nice. But it never should be a default, encouraging users to create incompatible (non "pascalish") source code.

IMHO a substituting bad with worse is not a good reason.

I do see.

But as we all know, the "index" notation asks for never ending (and unsolvable) discussion about how "characters" are counted in all the different environments fpc supports.

-Michael

In our previous episode, Michael Schnell said:

But as we all know, the "index" notation asks for never ending (and unsolvable) discussion

Yes. Mostly from you though :-)

Marco van de Voort wrote

In our previous episode, Michael Schnell said: > But as we all know, the "index" notation asks for never ending (and > unsolvable) discussion Yes. Mostly from you though :-)

Very wrong.
I never initiated one of those, but I often answered, and hence prevented some "ending".
-Michael

IMHO a substituting bad with worse is not a good reason. Java/CIL needs

this

because its strings are immutable, and character access is expensive. We don't share, nor plan to share that trait.

I hope so, and with Delphi plans on making strings immutable in the future, I hope FPC doesn't follow. Otherwise, simple string concatenation loop will need to be changed to use string buffers, which makes it more error prone, more typing and more resource eating.

leledumbo wrote

I hope so, and with Delphi plans on making strings immutable in the future, I hope FPC doesn't follow.

+1
-Michael

In our previous episode, leledumbo said:

(doesn't it already for the jvm port?)

Otherwise, simple string concatenation loop will need to be changed to use string buffers, which makes it more error prone, more typing and more resource eating.

Such things would invalidate half of my codebases, private and work. I don't see the synergy of such new versions with the current products (FPC or Delphi). Same problem I had with e.g. PRISM.

future,

I hope FPC doesn't follow. Otherwise, simple string concatenation loop

will

need to be changed to use string buffers, which makes it more error prone, more typing and more resource eating.

If at all such changes (including having ZeroBasedStrings on by default) would be bundled in a new mode... Afterall they don't really affect cross unit code.

Regards,
Sven

1-based for "desktop") contradicts the concept of high-level language. http://en.wikipedia.org/wiki/High_level_language
"In computer science, a high-level programming language is a programming language with strong abstraction from the details of the computer.".

It goes as stupid as this: If my computer fits into a palm and/or looks fancy, it's 0-based, otherwise it's 1-based string.

To make things worse, it actually has nothing to do with a target computer... but with the language marketing
What was the term for it? "High level trend language"?

thanks,
Dmitry

Sven Barth wrote

If at all such changes (including having ZeroBasedStrings on by default) would be bundled in a new mode...

(In effect creating a new language) ... to be activate once in the remote future.

Very OK, if all archs/OSes support both.

-Michael

No, but changing an individual character of a unicodestring is obviously very inefficient there. Changing an individual character of an ansistring however is just as inefficient on the JVM target, because there's no way to keep track of or request the reference count at the RTL level, so we always have to make a deep copy.

Many of those cases, especially the critical ones in tight loops, can in theory be optimised by the compiler (which would also result in a speedup on other platforms, because it would eliminate a lot of automatically inserted uniquestring calls), but there's no support for that yet.

Jonas

Delphi stopped to be a high level language when XE was released.

fpc is ready to take over the leadership :-)

-Michael

would be bundled in a new mode...

> (In effect creating a new language) ... to be activate once in the remote

future.

Very OK, if all archs/OSes support both.

Definitely. Afterall we propose "Write once, compile anywhere" ;)

Regards,
Sven

(doesn't it already for the jvm port?)

Can it be done without for jvm? AFAIK this immutable string thing is part of jvm executable code, though in theory you can just implement mutable strings as array of byte, but I believe that would be harder to implement than using java strings which has support for constant string pool.

Jonas Maebe wrote

In FPC, this setting only depends on the {$zerobasedstrings on/off} directive (supported in FPC 2.7.1+). The default is "off" everywhere.

Very nice to know. Thanks for the information.

As for Delphi, after some more internet searching after I posted here, I also found discussions on the {$zerobasedstrings} directive. So this makes things a lot easier.

Regards,
- Graeme -