[fpc-pascal] Is there some disadvantages using mode Delphi?

[Sven Barth]

Am 29.04.2017 23:56 schrieb "Marcos Douglas B. Santos" <md at delfire.net>:
>
> On Sat, Apr 29, 2017 at 5:23 PM, Marco van de Voort <marcov at stack.nl>
wrote:
> >
> > In our previous episode, Marcos Douglas B. Santos said:
> > > I would like to write some packages that should work in FPC and
Delphi.
> > > I know that I will need to use {mode delphi} to do that.
> > >
> > > My ask is: Is there some disadvantages using this mode?
> > >
> > > I mean, is there something that we only can do in mode objfpc but not
in
> > > mode delphi, or is it just about syntax?
> >
> > Mostly syntax. Mode objfpc disambiguates a corner case for procedural
types
> > with an extra @ for assignment of procedural types, and a few other
> > tightenings.
> >
> > The proponents of mode objfpc make a big deal out of the differences,
but
> > IMHO it is mostly nitpicking. And worse unnecesarily incompatible
> > nitpicking.
>
> Good to know.
> I remembered something right now: Is there some problem when units
> mode objfpc have "communication" with units using mode delphi about
> Unicode?
>
> If I remember well, PChar and even String is different between these
> modes, right? The compiler will convert strings between them or this
> is not a problem? Even using LCL?

The default string type depends on two different things, namely the mode
and the H switch which is by default only set in the Delphi modes. H- means
that "String" is "ShortString". H+ means that "String" is "AnsiString" as
long as modeswitch UnicodeString is not set (which is for example the case
if the mode is DelphiUnicode). However since the latter isn't really
recommended yet anyway (since the RTL and especially its classes would
still mainly use String=AnsiString) you shouldn't really run into problems
there.
The same is true for (P)Char: only if modeswitch UnicodeString is set, then
it's an alias for (P)WideChar, otherwise it's an alias for (P)AnsiChar.
At least the conversions between the string types are handled by the
compiler, only PAnsiChar <=> PWideChar conversions you'd need to do
yourself, but the compiler would complain there anyway.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20170430/848d2736/attachment.html>