Hi,

This weekend I tried to unify tiOPF's Delphi and FPC code. Year back tiOPF branched to support D2009 only and do loads of code clean-up. FPC couldn't follow that branch due to all Delphi's many RTL changes and UnicodeString support. I'm now trying to see what is still missing in FPC 3.x

Normally I would use {$H+} no tell the compiler that the aliased “String” type means AnsiString instead of ShortString. But what affect, if anything, does it have when {$mode delphiunicode} is enabled too?

My first port of call was obviously the Free Pascal PDF documentation, but looking in the Programmer's Guide PDF (Section 1.2.25), it doesn't answer my question. It mentions the {$mode delphi}, but not the newer {$mode delphiunicode}.

Second port of call was the “FPC Unicode Support” wiki page [http://wiki.freepascal.org/FPC_Unicode_support], apparently now also an official source of documentation. But surprisingly, there is not a single mention of {$H+} in that wiki page either.

Could anybody here answer my question?

ps:
I hate fragmentation of information - any such info should only live in the official PDF documentation (and generated HTML pages). Please don't follow the Lazarus route by fragmenting information all over the internet! Next we'll have "official blogs" documenting FPC too.

Regards,
Graeme

Lots, such as unicodestring versions of all standard classes.

Normally I would use {$H+} no tell the compiler that the aliased “String” type means AnsiString instead of ShortString. But what affect, if anything, does it have when {$mode delphiunicode} is enabled too?

http://wiki.freepascal.org/FPC_New_Features_3.0#New_delphiunicode_syntax_mode

I hate fragmentation of information - any such info should only live in the official PDF documentation (and generated HTML pages). Please don't follow the Lazarus route by fragmenting information all over the internet! Next we'll have "official blogs" documenting FPC too.

The wiki pages are created when new features are implemented. Ideally, the official documentation will pick up all necessary information before the next release, but that obviously does not always happen. Additionally, the wiki pages can be easily updated in real time after a release when errors/omissions are seen, while the official documentation will only be regenerated when the next release is made.

Jonas

Jonas Maebe wrote

Lots, such as unicodestring versions of all standard classes.

OK, thanks. So FPC 3.0.0 is really just an interim / preview Unicode FPC (think KDE 4.0 release situation).

The other problem being? How can we contribute to bringing the Unicode Enabled RTL up to par with Delphi, when the FPC team can't decide on what the RTL must be or look like? When can we expect a decision from the dev team?

http://wiki.freepascal.org/FPC_New_Features_3.0#New_delphiunicode_syntax_mode

Thanks for that.

The wiki pages are created when new features are implemented. Ideally, the official documentation will pick up all necessary information before the next release, but that obviously does not always happen.

I'm sure Michael will not be happy about having to dig through the wiki for potential documentation updates. Plus the fact that, how much can you trust the wiki information, because anybody of any skill level can edit it.

Additionally, the wiki pages can be easily updated in real time after a release when errors/omissions are seen

Don't you have commit access to fpc_docs? ;-)

, while the official documentation

will only be regenerated when the next release is made.

True, but this could easily be automated to generate interim PDF's once a week or once a month. Cron job -> svn up -> make -> rsync with webserver.

Regards,
Graeme

Graeme Geldenhuys wrote on Mon, 09 May 2016:

The other problem being? How can we contribute to bringing the Unicode Enabled RTL up to par with Delphi, when the FPC team can't decide on what the RTL must be or look like?

See Tomas' mail for a start.

When can we expect a decision from the dev team?

You've been using using FPC for long enough that you should know this can only be interpreted as a rhetorical question.

I'm sure Michael will not be happy about having to dig through the wiki for potential documentation updates.

Before every new release, Michael asks on the core list for a list of new features that should be documented. I assume that having a complete wiki page documenting every detail is much easier than an ad hoc description written at that point based on the recollections of the person who did the work 6 months earlier.

Plus the fact that, how much can you trust the wiki information, because anybody of any skill level can edit it.

Plus the fact that if a developer points Michael to a wiki page they wrote themselves, Michael can assume that person has checked it first for its veracity. Or, in the worst case, Michael can be pointed to a particular revision of that page.

> Additionally, the wiki pages can be easily updated in real time after a > release when errors/omissions are seen Don't you have commit access to fpc_docs? ;-)

It is much easer to write a comprehensive document on a particular feature than to hunt down every corner and topic in the documentation that may have to be modified. Case in point: even Michael, who knows the documentation much better than anyone else, misses things when integrating such information in the documentation.

Conversely, it is presumably also much easier for someone who is already familiar with the language to have a single wiki page summarising all changes related to a particular feature, as opposed to having to reread the documentation from start to finish to find the differences.

That would only work if only fixes would be performed to the documentation between two releases, while all new features would only be added the day before the new release. Or if you would start branching the documentation. Those are not things we want to do.

Jonas