{$H+} meaning with compiler {$mode DELPHIUNICODE}

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

{$H+} meaning with compiler {$mode DELPHIUNICODE}

Graeme Geldenhuys-6
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

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: {$H+} meaning with compiler {$mode DELPHIUNICODE}

Jonas Maebe-2
Graeme Geldenhuys wrote:

> 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

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: {$H+} meaning with compiler {$mode DELPHIUNICODE}

Graeme Geldenhuys-6
On 2016-05-09 11:42, 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

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: {$H+} meaning with compiler {$mode DELPHIUNICODE}

Jonas Maebe-2

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.

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

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal