During the recent FPC hackathon, Michael van Canneyt and I created a branch to switch some RTL routines to unicode. (to be exact, rawbytestring and unicodestring versions). This scheme is compatible with all dynamic string types as long as the encoding is properly set. Be careful with pointers (pchar), since they don't have encoding.

It is still all very simple, but people wanting to explore the 2-byte Windows API can find it in FPC svn fpc/branches/unicode.

However, and this is the main reason of this post, that branch also changes the windows unit to 2-byte "W" mode on Windows. Some Winunits-base units will also flip.

I tried to compile Lazarus with it, but that fails because Lazarus uses "general" functions (no -A and -W) but passes them p(ansi)char. IOW when the default changes to -W this breaks on errors like:

graphic.inc(155,66) Error: Incompatible type for arg no. 3: Got "PChar",
expected "PWideChar"

since the units are compiled in objfpc mode, and not in mode delphiunicode

Probably for now, it is best to change those issues all by appending a -A.

To build a 2-byte windows unit (and the new RTL),

1) checkout fpc/branches/unicode
2) do a make cycle to get a fresh 2.7.1
3) compile the snapshot (make all in toplevel) with -dFPC_UNICODE_RTL and FPC_OS_UNICODE (and OVERRIDEVERSIONCHECK=1 obviously)

4) compile Lazarus with the resulting snapshot.

Patches to improve 2-byte compatibility of the windows unit are welcome too.

08.06.2013 21:53, Marco van de Voort ?????:

graphic.inc(155,66) Error: Incompatible type for arg no. 3: Got "PChar", expected "PWideChar"

Stream := TResourceStream.CreateFromID(Instance, ResID, ResType);

ResType is of type TResourceType which is declared in lcltype.pp as

   {$ifdef UNICODE}
   TResourceType = PWideChar;
   {$else}
   TResourceType = PChar;
   {$endif}

since the units are compiled in objfpc mode, and not in mode delphiunicode Probably for now, it is best to change those issues all by appending a -A.

This particular issue will not be solved this way.

Best regards,
Paul Ishenin

Where is UNICODE defined ?

Because the RTL is compiled with the FPC_UNICODE_RTL define.

Michael.

10.06.2013 14:55, Michael Van Canneyt ?????:

That define was made in FPC RTL for windows CE. I think now we simple need to replace it with something new.

Best regards,
Paul Ishenin

08.06.2013 21:53, Marco van de Voort ?????:

During the recent FPC hackathon, Michael van Canneyt and I created a branch to switch some RTL routines to unicode. (to be exact, rawbytestring and unicodestring versions).

Does your branch also includes Jonas cpstrrtl branch?

Best regards,
Paul Ishenin

Yes, we used his patches as a start.

Michael.

UNICODE is now reserved for Delphiunicode mode afaik. So we use FPC_OS_UNICODE as global define to signal that FPC expects API units in two-byte value. (because there is simply more Delphi code that tests for 2009+ with unicode than 3rd party API units)

In headers that already have unicode we've added
{$IFDEF FPC_OS_UNICODE}{$define unicode} {$endif}
to the top, since that is local only.

This will get hard in places where FPC/Lazarus redefines API structures for own purposes. E.g. if you fix this, further down it redefines wndclass.

The general directories only. Not (yet) the target specific ones.

need to replace it with something new.

Nope, WinCE uses FPC_OS_UNICODE ;)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130610/4a611139/attachment.html>

10.06.13, 23:20, Sven Barth ?????:

Nope, WinCE uses FPC_OS_UNICODE ;)

Not in FPC 2.6.2 which must be supported by Lazarus too.

Best regards,
Paul Ishenin

Of course not, because the WinCE target was only broken a few weeks ago. There the define wasn't FPC_UNICODE_RTL either, but plain UNICODE (which WinCE used to define by default to switch Windows unitvto -W imports).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130611/579e29ae/attachment.html>

Paul Ishenin wrote

> Nope, WinCE uses FPC_OS_UNICODE ;) Not in FPC 2.6.2 which must be supported by Lazarus too.

If you add the

{$ifdef FPC_OS_UNICODE}{$DEFINE UNICODE}{$endif}

to the top, it will work in both the old situation (UNICODE is already defined globally on wince) as the new (FPC_OS_UNICODE will set UNICODE locally)

Michael Van Canneyt wrote

Where is UNICODE defined ?

Isn't the define "UNICODE" a heritage from Delphi (> version xyz) ?

I suppose FPC and Lazarus need to stay compatible on that behalf.

-Michael

Is there already published (or somehow definable) road map for a string-wise Delphi XE compatible FPC / Lazarus combination ?

I am eager to (finally !!) show my colleagues - who always use the current Delphi release - a way to port their projects to Linux....

-Michael

It has a different meaning.

I suppose FPC and Lazarus need to stay compatible on that behalf.

Not necessarily. Compatible concerning Language/rtl functions, yes. Defines, this is debatable.

Michael.

Michael Van Canneyt wrote

Not necessarily. Compatible concerning Language/rtl functions, yes. Defines, this is debatable.

I do know that my colleagues use "UNICODE" a lot when porting their (huge) code-base from pre-Unicode Delphi to Unicode aware Delphi versions.

So yes it is absolutely essential to them that this define stays in it's inherited meaning when they one port their code to Lazarus / FPC to make it run on Linux.

-Michael

Simple:

Add

{$IFDEF FPC}
{$DEFINE UNICODE}
{$ENDIF}

to your source, or, alternatively, fpc -dUNICODE

Both do the trick.

Michael.

I'm not sure if this is the trick requested, as the target is to automatically modify their source code in a way that it works on the compiler used.

Of course there are many workarounds, but the porting of course should be as straight forward as possible.

They can compile their source files both on pre-Unicode Delphi (UNICODE not defined) and on Unicode aware Delphi (UNICODE is defined).

In fact they use 8 Bit characters when UNICODE is not defined and 16 Bit characters when it is.

Thus with the currently released fpc they would need UNICODE undefined.

With the upcoming fpc they supposedly would need UNICODE defined (in case that "String" now is 16 Bit coded on default.

-Michael

It is bad practice to rely in code on the defines defined by the compiler.

Most component suites have an include file that creates a set of defines based on more or less known version defines.

{$IFDEF VERXYZ}
{$DEFINE THISORTHATFEATURE}
{$ENDIF}

The code then uses THISORTHATFEATURE in code to distinguish between various 'features'.

Your programmers should do the same.

In each case, FPC will not define the same defines as Delphi.

Michael.

Michael Van Canneyt wrote

It is bad practice to rely in code on the defines defined by the compiler.

Of course I do know this (and many more similar portability-paradigms). But my colleagues do coding only with Delphi (and thus Windows) in mind. I can't help this. But now "suddenly" (since some 5 years) the company wishes to support Linux.

I do research on that but I can't force them to to modify their hundred thousands of code lines on that behalf (_Again_ after they needed to do this because of the move of Delphi to Unicode). If it's to difficult they will just say the move towards Linux is impossible.

In each case, FPC will not define the same defines as Delphi.

Of course not, but there are instances like this that are rather obvious and limited, thus supposedly doable.

-Michael

The issue exists even if you only code for Delphi. See the example of component suites.

I do research on that but I can't force them to to modify their hundred thousands of code lines on that behalf (_Again_ after they needed to do this because of the move of Delphi to Unicode). If it's to difficult they will just say the move towards Linux is impossible.

Adding -dUNICODE on the fpc commandline is difficult ?

Let's be serious.

> In each case, FPC will not define the same defines as Delphi. Of course not, but there are instances like this that are rather obvious and limited, thus supposedly doable.

Anything is doable. Doesn't mean we should. In this case: I don't think so. The scope of the UNICODE define is not "well defined".

Michael.

Michael Van Canneyt wrote

Adding -dUNICODE on the fpc commandline is difficult ?

problem would arise, if fpc or Lazarus would define UNICODE in _a_different_ way than Delphi does, and thus simply doing " -dUNICODE" would be not allowed or not possible.

I agree. The problem is even deeper.

As I was told by my colleagues the implementation of the quasi-dynamically coded strings in Delphi is far from perfect (it seems to be at least decently usable as of XE2).

So I suppose (and hope) fpc and Lazarus will do significant enhancements to the concept, concerning usability and flexibility (we already discussed some of them here and in the fpc-dev group). Of course for m<y colleagues they would need to be fully compatible to Delphi, as they need to compile their projects on both systems without too much additional effort. (They claim to be 150 % busy anyway, and the Linux stuff is added on top of this.)

-Michael

Yes, and if you chose the explicit compatibility mode for that version, $mode delphiunicode, it _is_ defined.

Michael Schnell wrote

Is there already published (or somehow definable) road map for a string-wise Delphi XE compatible FPC / Lazarus combination ?

No. This is part of that, but only the most initial level. Much is not yet decided.

... including how compatible it will be. (and more importantly, how portable the compatibility will be)

Now why on earth would we do that ?
We don't define VERXYZ either in mode delphi ??

Michael.

Marco van de Voort wrote

Yes, and if you chose the explicit compatibility mode for that version, $mode delphiunicode, it _is_ defined.

Great. I see my concerns about this kind of compatibility seem already to be cared for.

Thanks !
-Michael

As, String-wise, Delphi (as of version xyz) is not compatible to itself, IMHO it does make perfect sense to provide the $mode delphiunicode, additional to former Delphi compatibility mode(s).

-Michael

As I followed (an took part in) several discussions on the move to (quasi-) dynamically encoded Strings. I perfectly do understand this. l always stated that it is not a good idea to just do "some" implementation before decently agreed definitions have been nailed down. The final product needs to fulfill some contradicting needs such as
- "easy to use even for beginners" i.e. providing automatic conversions when necessary,
- "architecture independent",
- "decent performance" at least when used appropriately thoughtful: avoiding unnecessary automatic conversions by not mixing different subtypes..
- "backwards compatibility" not breaking legacy fpc / Lazarus user code
- "Delphi compatibility" at least when an appropriate mode is set. This includes Delphi XE and pre-Unicode Delphi versions
- Unicode Details like handling of ambiguous code points and code-point combinations in "=" compare. "Upcase". Also case insensitive compare, "<" / ">" compare which seems to be language depending even for Unicode.
- "versatility" maybe extended vs. Delphi. Here I would like to see String-Sub-Types like non-encoded ( never auto-converted / "RAW") Byte, Word, DWord and QWord Strings and fully dynamically coded (not forcing a conversion when assigned to) Strings.
- "extensibility": it should be doable - even for the end-user - and appropriately documented, to create an additional (auto converting) String Subtype for propriety encoding schemes (e.g. html entity) by providing appropriate conversion functions.
- ...

For me. a big question still is, what to do with the ambiguous MyString[n] notation. I am sure that Mr Wirth meant it like "take the n the printable character from the string", which with the Unicode-driven support for non-western languages does not make too much sense any more. (Maybe someone should ask him ?!?!?!). But as (western) beginners never will accept that MyString[n] works in terms of sub-code (which works rather well for them with UTF-16, but usually not with UTF-8), I vote for dropping it altogether, unless enabled by a "take care" $mode setting.

-Michael

The motivation was exactly the point that Delphi versions where String=UnicodeString define "Unicode" while former versions do not, so the definition of the UNICODE switch was linked to modeswitch unicodestrings (and thus to mode delphiunicode). This was also the reason why WinCE compilation got broken (it defines UNICODE by default which got undefined after mode ObjFPC was encountered) and I added the FPC_OS_UNICODE define.

Regards,
Sven

All the more reason not to try to emulate Delphi defines.

Currently the following can be found:
FPC_HAS_UNICODESTRING
FPC_WIDESTRING_EQUAL_UNICODESTRING
FPC_UNICODESTRINGS
UNICODE

The UNICODE define is simply superfluous. Those that need it can do a

{$IFDEF FPC_UNICODESTRINGS}
{$DEFINE UNICODE}
{$ENDIF}

And they'll need defines anyway because widestring unicodestring on windows.

But it is all water under the bridge.

Michael.

Michael Van Canneyt wrote

And they'll need defines anyway because widestring unicodestring on windows.

The compiler does know whether it compiles for Windows or not. Doesn't it ?

-Michael

The problem is not in the compiler.
The problem is that IF your code assumes that WideString=UnicodeString then you will need to differentiate the 2 cases.

You can do this based on the OS define (bad practice, because it encompasses an implicit assumption) or introduce a new define (as FPC did).

You can set this new define based on the OS, but this is secondary.

Michael.

FPC_HAS_UNICODESTRING can be removed, because that was needed for bootstrapping after the introduction of UnicodeString which was either in 2.2 or 2.4 series, so long gone already.

Regards,
Sven

Michael Van Canneyt wrote

The problem is not in the compiler. The problem is that IF your code assumes that WideString=UnicodeString then you will need to differentiate the 2 cases.

I suppose you are correct. But if I understand correctly what my Delphi addicted colleagues state: Delphi-User use just "String" as their string type, as they never learned to be careful about the code. Delphi is assumed to be Windows only, and thus if a Unicode version of Delphi is used (i.e. "UNICODE" is set) "String" is Unicode with UTF16 coding and for non-Unicode Delphi (i.e. "UNICODE" is not set) "String" is 8 bit ANSI code in the local language variant. If anybody uses "Widestring" (not ref-counted in Delphi AFAIR) he should know what he does.

This is what Lazarus / fpc should not break (of course no problem to have the user select an appropriate mode in the project setting).

-Michael

Michael Van Canneyt wrote

> ObjFPC was encountered) and I added the FPC_OS_UNICODE define. All the more reason not to try to emulate Delphi defines.

Why? We define "Windows" and "MSWindows" too?
Maybe not use "linux" because Kylix does ? :-)

Yes. And anybody wanting Delphi compatibility can just use {$mode objfpc} and start subsituting.

I don't see a problem whatsoever defining a Delphi define in a delphi compatibility mode.

And they'll need defines anyway because widestring unicodestring on windows.

No. Since on Delphi those are different too. They don't need additional defines for that.

Michael Van Canneyt wrote

The problem is not in the compiler. The problem is that IF your code assumes that WideString=UnicodeString

That is Delphi incompatble. Simply don't enable Delphi compatibility mode then.

Those represent the OS, using the name of the OS is natural.

Whereas UNICODE indicates an internal compiler feature. We use FPC_XYZ for those.

But as I said, it's all water under the bridge.

Michael.

Which Delphi version ?

Michael.

Any D2009+, the Delphi versions that $mode delphiunicode supports?!?!

UnicodeString was introduced in Delphi 2009 and already there UnicodeString WideString was the case (because Delphi was still Windows only at that time and thus the seperate WideString type managed by Windows was needed).

Regards,
Sven

2013/6/8 Marco van de Voort

I did a make all at the top level directory, which ignores my fpc.cfg (good) and calls make cycle in the compiler dir (good). It fails.

C:/FPC/2.6.2/bin/i386-Win32/ppc386.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi..
/win -FE.
-FUC:/lazarus/jenkins/workspace/buildfpc_branch/platform/i386-win32/fp c/branches/unicode/rtl/units/i386-win32 -di386 -dRELEASE -Us -Sg system.pp -Fi..
/win
astrings.inc(1429,11) Error: overloaded functions have the same parameter list
astrings.inc(1435,11) Error: overloaded functions have the same parameter list
system.pp(709) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/unicode/rtl/inc/astrings.inc?r1=24715&r2=24885&diff_format=lseems an unnecesary change which I suspect breaks compilation

Vincent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130620/d071289c/attachment.html>

I just have been told that Embarcadero plans to do away with the stuff fpc is just implementing in the "Unicode branch" and is on the verge to change to a completely new String type that is
- UTF-16-only,
- Zero-Based, and
- immutable.
And thus completely incompatible with any "String" Type ever known in Pascal.

So
- why do we discuss compatibility at all ?
- do we like this (rather complex and not at all "straight forward") String type that much that it is viable to implement, debug and decently document this library ?

-Michael

They also make TObject reference counted...

UnicodeString has been introduced in D2009, i.e. we are a couple of years behind with compatibility.

Once this has been implemented, we can spend some more years with updating the RTL and LCL - or continue using UTF-8 instead of UTF-16.

When we can start implementing further changes, we should look whether Delphi exists at all, at that time. I wouldn't hold my breath ;-)

DoDi

For the very little that it's worth, I abandoned Delphi (10) because I was sick of Embarcadero's approach to strings at that time, which forced a rework of *a lot* of my old code and components.

Adopted Lazarus and never looked back.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130624/bb4f62c4/attachment.html>

FPC is a community approach so compatibility is implemented by those being interested in it.

AFAIK This is only for the new nextgen compiler, for the Win32 target, nothing changes.

Michael.

lol! That's ridiculous ... they will just keep changing and changing? And expect people to rewrite their codebases every 4 years?

And for me a key advantage of Pascal was always that it is (was?) so backwards compatible...

Michael Van Canneyt wrote

AFAIK This is only for the new nextgen compiler, for the Win32 target, nothing changes.

the win32 platform is already de-facto deprecated, so I don't think this makes it any better.

Florian Kl?mpfl wrote

FPC is a community approach so compatibility is implemented by those being interested in it.

Yes, but such backwards incompatible changes such as changing the string type, changing TObject, they cannot be added as simply another feature which exists in parallel with the rest ... everyone has to migrate into the new thing. For very large codebases the change might not be
Felipe Monteiro de Carvalho

Michael Van Canneyt wrote

AFAIK This is only for the new nextgen compiler, for the Win32 target, nothing changes.

When you say Win32 do you mean Windows (as in 32 & 64-bit) or only 32-bit Windows?

So what platforms with the nextgen compiler target? OS X, iOS, Android, Windows Phone, Linux? All but Windows?

Regards,
- Graeme -

Hans-Peter Diettrich wrote

They also make TObject reference counted...

I did read about this. So ".Free" is going to be obsolete ?

When we can start implementing further changes, we should look whether Delphi exists at all, at that time. I wouldn't hold my breath ;-)

Regarding the changes they are tying to force to their customers (yet another string paradigm, Firemonkey), instead of trying to offer an as smooth migration path as possible, and not even trying to support Linux and Android (that now has a lot greater market share than IOS) obviously recommends a decent

Michael Van Canneyt wrote

AFAIK This is only for the new nextgen compiler, for the Win32 target, nothing changes.

To me it makes absolutely no sense to force the programmers to use different paradigms for different platforms. A decent programming system should hide this diorty stuff from the application programmer. Only who wants to dig deeper (for performance or to implement really platform specific stuff) should be forced (and able to) get there.

Win32 is dead anyway. (IMHO soon the main platforms to be supported will be LINUX in ARM 64 and Android. No notion of either with Embarcadero.)

-Michael

Yes, that's the only way to make people buy new Delphi versions. In theory at least, in practice it may make people stop buying new

Michael Schnell wrote

On 06/24/2013 05:14 PM, Hans-Peter Diettrich wrote: > > They also make TObject reference counted... I did read about this. So ".Free" is going to be obsolete ?

Yes, it will merely be an empty method then.

Regards,
Sven

As far as I know that was all to be limited to their mobile offering.

Graeme Geldenhuys wrote

So what platforms with the nextgen compiler target? OS X, iOS, Android, Windows Phone, Linux? All but Windows?

There is a note in the XE4 related documentation, that desktop Delphi/nextgen will be compatible with the current situation a long time.

I took that as the whole thing being a cheap shot at avoiding the platform/architecture dependent parts of legacy implementation on the new mobile targets, and a sign that the mobile targets are more a quick buck than a fundamental new addition.

Fixed.

Because then classes work like COM interfaces. Shudder.

Martin

Sven Barth wrote

Yes, it will merely be an empty method then.

If this really works and does not break anything, I wonder why this has not been implemented since long...

-Michael

Marco van de Voort wrote

As far as I know that was all to be limited to their mobile offering.

As stated earlier by several contributors, splitting the language into two separate branches for different architectures seems like an utterly bad idea. I do hope Lazarus will be able to provide a better alternative :-) .

-Michael

Martin Schreiber wrote

> Because then classes work like COM interfaces. Shudder.

Yeah, that change is going to be a nightmare to lots of existing code. I hope Delphi developers enjoy debugging!

Regards,
- Graeme -

Michael Schnell wrote

On 06/25/2013 03:14 PM, Sven Barth wrote: > Yes, it will merely be an empty method then. If this really works and does not break anything, I wonder why this has not been implemented since long...

There can be problems where the reference counting mechanism is misled. Similar to the problems that appear with reference counted interfaces.

Another problem could be circular references especially in legacy code where object A needs object B and vice versa and none does an explicit "OtherObject := Nil".

Regards,
Sven

PS: You CC'ed me again, which is why my message was sent to you only...

I don't see any relationship to COM here. Java has managed objects, C++ has, .NET has, so why not OPL too?

The management overhead is as low as for managed strings. Also a "weak" keyword has been introduced for unmanaged object references - for people who don't like reference counting.

I don't like managed (refcounted) class objects for other reasons. In detail they can easily lead to zombies, which keep each other alive by circular references. It also is not really possible to remove destructor/finalizer code in such an environment, so that no or dangerous comfort is the only result from using such a model.

DoDi

Hans-Peter Diettrich wrote

I don't see any relationship to COM here. Java has managed objects, C++ has, .NET has, so why not OPL too?

I wasn't referring to COM explicitly. But having objects being freed when the developer didn't expect it (because that was not the behaviour before), is what is going to cause troubles. When you work with reference counted Interfaces you know what to expect and coded accordingly [eg: by putting checks in place, knowing how to pass interfaces with/without incrementing/decrementing reference counts etc.].

Regards,
- Graeme -

I don't see a chance for trouble when the object is destroyed *after* the last usable reference disappears.

When you work with reference counted Interfaces you know what to expect and coded accordingly [eg: by putting checks in place, knowing how to pass interfaces with/without incrementing/decrementing reference counts etc.].

Automatic reference counting works pretty well, doing it manually is asking for trouble.

DoDi

Java and C# don't count, as safe languages, they have _ONLY_ managed types. Their choices will be hard to backport.

As far as the C++ bit goes, that is all fairly new. Which part of the standard (and which standard) do you mean exactly, and which implementation?

The management overhead is as low as for managed strings.

Where did you get that information? It is easy to see that it is somewhat doubtful as string has copy-on-write properties in addition to ref-counting.

I think Embarcadero is using the mobile version as testing ground, and maybe they are having doubts if the desktop-mobile product lines will be synchronous in the long end.

That's the whole idea, I think they expect to attract a new audience with the mobile offering, and not just sell upgrades to the old Delphi crowd.

I do hope Lazarus will be able to provide a better alternative :-) .

IMHO Delphi XE4 mobile version is an unrelated product (like 3rdrail, Delphi.NET, Delphi Prism etc) till proven otherwise.

Hans-Peter Diettrich wrote

I don't see any relationship to COM here.

Delphi "interfaces" mostly are seen as COM thingies, even though they are just straight forward language constructs that _can_ be used to attach to COM objects. but they can be happily be used for other purposes.

Supposedly ref-counted object could allow for a much more "relaxed" way of doing a Com object implementation.

-Michael

Right. The idea sounds to me like the other half-baked attempts to introduce anonymous methods, class helpers etc. into Pascal.

As far as the C++ bit goes, that is all fairly new. Which part of the standard (and which standard) do you mean exactly, and which implementation?

All local C++ objects are destroyed when they go out of scope.

> The management overhead is as low as for managed strings. Where did you get that information? It is easy to see that it is somewhat doubtful as string has copy-on-write properties in addition to ref-counting.

That's something different. While it's possible to copy strings automatically, the same is impossible with more complex objects. At least a copy-constructor were required for that purpose. Or more than one, depending on the kind of the copy (deep/shallow...).

DoDi

Hans-Peter Diettrich wrote

Automatic reference counting works pretty well, doing it manually is asking for trouble.

Sometimes it becomes trick (at least with reference counted interfaces). eg: I have code where I pass a interface around, but don't want the reference count to increment - so you need to take special precaution. Then I also have a container that holds references to interfaces, but again I don't want the container to increment reference counts - which would normally be the case. Sometimes the opposite is also true.

Then there is also the question of when does the interface or object get freed - timing is sometimes important too. eg: I can't use some of the code I used to use in Delphi with interfaces, because the code "apparently" relies on undocumented Delphi language behaviour (even some commercial apps rely on that same behaviour). Free Pascal frees the Interface instances at different times to Delphi - so the code in my application under Free Pascal had to be changed. More info: Google mouse cursor management with Interfaces, or look at CodeSite's method tracing abilities.

Reference counting is a double-edged sword.

Regards,
- Graeme -

I see no valid reason for doing so.

I don't see how this is related to managed objects.

DoDi

I

>>> hope Delphi developers enjoy debugging! >> >> I don't see any relationship to COM here. Java has managed objects, C++

has, .NET has, so why not OPL too?

> > > Java and C# don't count, as safe languages, they have _ONLY_ managed

types.

> Their choices will be hard to backport. Right. The idea sounds to me like the other half-baked attempts to

introduce anonymous methods, class helpers etc. into Pascal.

I personally consider helper types implemented cleaner in Object Pascal than C#'s extension methods (except the "one helper only" restriction, but I want to lift that anyway :) ).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130627/2a2acaf9/attachment.html>

Hans-Peter Diettrich wrote

I don't see how this is related to managed objects.

If FPC implements managed objects, is it going to behave _exactly_ like Delphi, or slightly different to Delphi - like what happened to the Interfaces implementation.

Regards,
- Graeme -

Right, and you seem to be the only one playing around with manual refcounting, and having (consequential) problems with managed objects.

DoDi

There won't be any exact Delphi like implementation, because like with interfaces it isn't documented _when exactly_ the reference count is decreased.

Regards,
Sven

Class helpers are more a solution to a Delphi problem, namely its high binary dcu usage. Class helpers help to "add" methods, even when the mother unit is dcu only. People often confuse it with mixins and other complicated runtime object systems that it is not.

> As far as the C++ bit goes, that is all fairly new. Which part of the > standard (and which standard) do you mean exactly, and which implementation? All local C++ objects are destroyed when they go out of scope.

Yes, but if you only aim that high, just use an editor macro that autogenerates a create-try-finally-free sequence, or JCL safeguards.

True. But my point was that makes performance comparisons somewhat odd, since there are two properties that strings have that can't be emulated easily (no nesting and copy-on-write).

So I really wondered where you got the numbers on, and I note you still haven't posted anything that made that claim believable.

It is decreased whenever a reference expires. Where do you see chances for a different implementation?

DoDi

It's mostly related to temporary variables. See the old discussions about interfaces.

Regards,
Sven

(Some versions of?) Delphi deallocate interfaces at the end of a block of procedures, not immediately after first usage.

When FPC did, those programs broke.

Everybody that have used Interfaces in Delphi had already problems at least once.
It seems easiest to use "CORBA interfaces" instead "COM interfaces" because you have more control on your objects.

Marcos Douglas

first usage or last usage?

When FPC did, those programs broke.

i'm just trying to follow along and get this whole new paradigm to me understood...

waldo kitty wrote

> (Some versions of?) Delphi deallocate interfaces at the end of a block of > procedures, not immediately after first usage. first usage or last usage?

Last usage of course, sorry.

I'm somewhat confused now. When an object has an definite "last use", it should not matter when it is destroyed afterwards, sooner or later.

A problem I could imagine were a refcount dropping to zero *before* that reference is stored in another variable. E.g. in

   intfvar := intfvar;

it will be a bad idea to _Release the old reference stored in the intfvar variable while the same reference is kept in a register or stack, before assigning the new reference to the variable. This is a known aliasing problem, which must be solved properly by every compiler. I'd solve it this way (compiled code):
//tempvar added by the compiler

   tempvar := intfvar; //intfvar.AddRef
   intfvar := newvalue; //intfvar._Release; newvalue.AddRef;
   tempvar := nil; //here or on exit from the subroutine or code block

Another solution could use the property setter pattern:

   if value  newvalue then value := newvalue;

DoDi

That's a bold statement. COM interfaces work nice and simple as long don't try to use the implicit reference-count mechanism to hack "aspects" and other stuff, and when you use TInterfacedObject avoid using using it as a normal object (unless you know what you're doing). Not to repeat myself, but I only wish there was a way TInterfacedObject (and probably a few others) replaced the default constructor to return IUnknown... Even shadowing the default constructor with a factory (class method that casts the constructor to IUnknown, declare another protected-creatively-named-constructor) would be an improvement IMHO.

-Fl?vio

It matters when people make assumptions when the a temp. interface is released. If the temp. interface is the only left reference to a class instance, this means in turn that the class is freed at different points thus resulting in different behaviour of the program if the destructor of the class has some side effect.

Florian Kl?mpfl wrote

It matters when people make assumptions when the a temp.

Yes, people like Embarcadero themselves (even though it is not officially documented), or Embarcadero partners that ship products with Delphi (think Raize's CodeSite etc).

I seriously doubt Embarcadero will change that behaviour now - considering it has been the same for many many years, and developers and products depend on its behaviour.

But I do understand FPC's point of view - you guys only copy functionality that is documented.

Regards,
- Graeme -

Hans-Peter Diettrich wrote

I'm somewhat confused now. When an object has an definite "last use", it should not matter when it is destroyed afterwards, sooner or later.

The simplest example... You have code that executes when the Interface gets destroyed. A very simple example (you can Google for exact code or more examples) is using Interfaces to change the mouse cursor to "busy", then let the Interface set the mouse cursor back to what it initially was when the Interface finally goes out of scope.

eg: [not really code - ]

procedure SomeLongProcedure;
begin
  SetBusyMouseCursor;
  // <----------------------- (2)
  ... long running code here
end;   //  <------------------ (1)

(1) is where Delphi will release the interface, and the mouse cursor will be reset. Always at the end of a code block.

(2) is where FPC will release the interface, and the mouse cursor will be reset [at the undesired place].

Like I said, this is a very simple example - but the Delphi behaviour is consistent since forever, and allows for some very nifty code (eg: debugging call stacks etc) - and without the need to define local interface variables.

Regards,
- Graeme -

Such coding style is asking for trouble :-(

DoDi

Such coding style is asking for trouble :-(

DoDi

Working with autodestroyed objects is asking for trouble. ;-)

Martin

Florian Kl?mpfl wrote

It matters when people make assumptions when the a temp.

If an interface indeed is used as an "interface" externally of the program, Destroying it might result in a crash when the external program writes something back to the interface object (because it had been provided with a pointer so a field in same) later.

(I know of something similar when a friend of mine used a call to a (converted) c library to an external system. Here a var parameter was provided that (not "obviously") provided a pointer the the external system. The actual variable was just a local variable and thus on the stack. Now the external system stored the pointer and minutes after the call had been executed it decided to save some value at that location making the pascal application crash.)

Do you think something like that could happen with ref counted objects (that unlike interfaces can't be associated with external stuff) ?

-Michael

Martin Schreiber wrote

> Working with autodestroyed objects is asking for trouble. ;-)

+1

:)

Regards,
- Graeme -

Hans-Peter Diettrich wrote

Such coding style is asking for trouble :-(

Hardly, but maybe our advanced applications and coding has moved past your level of knowledge of the language. That doesn't make us wrong or "asking for trouble".

G.

That would be much clearer to use, if Pascal had scope local variables and auto created stack objects:

begin
    var x: SetBusyMouseCursorObject;
end;

That would also make the ref-counted classes at language level unnecessary, because you could just use

       type TObjectWithRefCounting=  specialize TRefCountingObject<TObjectWithoutRefCounting>;

Benito

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130701/708a4e77/attachment.html>

No, abusing non documented features is not advanced programming nor advanced applications. On the contrary.

That doesn't make us wrong or "asking for trouble".

Then when you got into trouble, your testsuite revealed this problem immediately? Since if you didn't even know you were on thin ice, it is more a sign that this belonged into the "accidentally happened to work and I didn't even know it was wrong" rather than "a high level of knowledge of the language" :-)

Marco van de Voort wrote

Then when you got into trouble, your testsuite revealed this problem immediately?

Yes it did, and I promptly reported it to FPC. Somehow I thought [at the time] FPC was "delphi compatible", as advertised. But I quickly learned that "delphi compatible" was a term used very loosely. Neither FPC or Lazarus are very Delphi [XE to XE4] compatible at this point.

Regards,
- Graeme -