If you have not seen it, users of Delphi XE2 may be interested to read Delphi Product Manager JT's blog about what Embarcadero are working on for native Android and iOS development (which won't be in the forthcoming XE3 release - it's all further ahead than that), dropping FPC in favour of another open source toolchain and their own new debugger, revamped FireMonkey etc.

http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/

Howard

Howard Page-Clark wrote

dropping FPC in favour of another open source toolchain and their own new debugger, revamped FireMonkey etc.

Why do you say "another open source"? I haven't seen anything saying that the new toolchain is open source. And I don't know any open source toolchain which could do what they offer.

Howard Page-Clark wrote

http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/

Besides, technically, I read that Objects will become reference counting and thus ".Free" gets obsolete (like in Prism).

-Michael

They plan to use LLVM (though this is not mentioned in that roadmap article).

Regards,
Sven

Sven Barth wrote

They plan to use LLVM (though this is not mentioned in that roadmap article).

Regarding the multiple request I read in the past in the FPC forums to move FPC to use a "standard" backend (such as LLVM), this seems like a rather logical move (also regarding that it seems to be rather undoable to use GNU as a backend for an Object Pascal compiler).

-Michael

Sven Barth wrote

They plan to use LLVM (though this is not mentioned in that roadmap article).

I wonder if this means that the resulting compiler will be open source. I don't know anything about the licensing of LLVM, but they could require front-ends to be open source.

It wont. The license is very permissive. All it requires you to do is retain the copyright notice. Essentially you have to say 'I made this compiler using LLVM' somewhere.

http://llvm.org/releases/3.1/LICENSE.TXT

Anders

LLVM is extensively used and supported by Apple... that should give you an answer ;)

Regards,
Sven

Free Pascal will never move solely to a backend like LLVM. A part of the reason is that not all platform-os combinations are supported by LLVM that are supported by FPC. Also Florian does not look like he wants to give up fiddling around in the backend ^^

Regards,
Sven

Sven Barth wrote

Free Pascal will never move solely to a backend like LLVM.

That is what I learned in the forum already long ago :). I did not intend advocate LLVM over the current Pascal based backend, but I wanted to state that it seems like a logical move for Embarcadero, given that they don't already have an ARM compiler of their own.

-Michael

Sorry for a newbie question, but how is FPC connected to gcc anyways? Doesn't it translate the (object) pascal code directly into the various machine languages for the different platforms (Or into assembler and then machine language)? Pascal, only needs a one-pass compiler, making it by nature much faster to compile than C based languages, so why would FPC use anything C or C++ (except for external function calls to the OS API)?

Chavoux Luyt wrote

Sorry for a newbie question, but how is FPC connected to gcc anyways?

It is not.

Doesn't it translate the (object) pascal code directly into the various machine languages for the different platforms (Or into assembler and then machine language)?

It converts to assembler and then to machine code.

Pascal, only needs a one-pass compiler, making it by nature much faster to compile than C based languages, so why would FPC use anything C or C++ (except for external function calls to the OS API)?

LLVM is not made only for C/C++, it is multi-language. Check wikipedia on LLVM

They plan to use LLVM (though this is not mentioned in that roadmap

article).

I've read this somewhere before, but AFAIK only for the C++ builder (they might create a Delphi frontend though, should be easy for them since Delphi compiler is written in C++).

Howard Page-Clark wrote

If you have not seen it, users of Delphi XE2 may be interested to read

And the big news is that the soon to be launched XE3 will not ship with FireMonkey or FPC or any iOS development tools for that matter. Wow, I can see quite a few ISV's (eg TMS) being pretty pissed of now, spending lots of money building 3rd party components for FireMonkey - all for nothing!

Don't you just hate it when companies like Embarcadero use our hard earned cash for their experiments.

Now you know why FPC tries to take backwards compatibility seriously ;)

Regards,
Sven

Where is your source for this? The blogs on the Embarcadero website puts a lot of emphasis on the firemonkey components and as far as I have read the framework will ship for both Windows and OSX from the get go. The mobile platforms will be added at a later date.

Anders

This "they will be added at a later date" is exactly the point. They release a product as the successor to XE2 and leave those people in the rain that already built upon the mobile components provided by XE2.

Regards,
Sven

Well I haven't used XE2 myself, but the impression I get, both from Embarcadero and from others, was that the mobile solution was not really too userfriendly. You have to jump a not insignificant number of hoops to get it running. Keeping that in mind I would guess that the number of people that is actually affected by this delay is reasonably small. Also keeping in mind that they are not cancelling anything, but just delaying the mobile platform until they feel it is ready, I really think this is a small issue. I would actually give Embarcadero credit for realizing that part of their product is not quite ready and admitting it outright.

There are plenty of good reasons to be sceptical of Embarcaderos handling of Delphi, but this isn't one of them, in my opinion anyway.

Anders

Many big companies do things like that! E.g: Enter on Microsoft Website, they will promote Windows 7 until Windows 8 be finally released...

2012/8/23 Anders E. Andersen

I read that as that there will be ref counted objects, not that all objects will be ref counted per se.

And the TUFKAM(*) option is a skin, not native, and thus not marketstorable.

Don't you just hate it when companies like Embarcadero use our hard earned cash for their experiments.

Seems they missed their new compiler deadline twice in a row.

(*) The UI Formerly Known As Metro.

That was because for XE2 their own toolchain (compiler, linker, debugger) was also not ready, and they had to use FPC, and since FPC relies on Apple's linker etc, and probably gdbing, they invented the workaround tour.

If it can be so easily omited, you wonder why they did that for XE2.

Same goes for Firemonkey. Even FM enthusiast say that it is not really finished.

Marco van de Voort wrote

And the TUFKAM(*) option is a skin, not native, and thus not marketstorable.

I don't think the skinning is a big if you
consider that Microsoft itself created a "metro skin" for their flagship product - Microsoft Office. Yes the new MS Office is NOT a real metro app, but has the metro look.

Cheers,
- Graeme -

Yes, I know your allegiances lie with owner drawn :-)

But try to see beyond the obvious, the bit is that from what I saw they mumble over appstores and metro, but never admitting that they don't go together.

(same as that they mumble about mobile without shipping either an own or FPC's arm compiler)

Then you will also see that your Office counterexample is irrelevant, since app store rules don't apply to Office. (but they do to nearly everybody else).

And then I'm even ignoring that the scale of something like Office is beyond what nearly everybody can manage, including investments in making owner drawn UIs very close.

Marco van de Voort wrote

Then you will also see that your Office counterexample is irrelevant,

If skinning is good enough for Microsoft itself, then it must be good enough for many other ISV's too. After all, they are just following Microsoft's example. But to get back to reality... Embarcadero is not to blame for the Metro skinning design, vs native Metro design. If you read the Embarcadero newsgroups, you would have seen that a top Embarcadero employee answered that question... With numerous attempts from Embarcadero, Microsoft kept stonewalling them and made it impossible for them to support native Metro. Skinning was their only alternative.

Well, based on Microsoft's own track record, Metro is the flavour of the month. Next month might be something else. It's easier to simply adapt your skinning code, than to redevelop your whole app for the next flavour of the month.

G.

Marco van de Voort wrote

Then you will also see that your Office counterexample is irrelevant, since app store rules don't apply to Office. (but they do to nearly everybody else).

I am not aware of any app store rule that says that people need to use native controls and cannot use controls which merely immitate native ones. I think that I would have heard if Qt apps were prohibited in the Mac app store for example, remember that Qt is not native.

So please show the rule which prohibits custom drawn apps (seriously, it would be something interresting to know if it exists). If there is no such rule, then your entire point makes no sense, since it presuposes such a rule.

Marco van de Voort wrote

I read that as that there will be ref counted objects, not that all objects will be ref counted per se. --

Ok, but if there are reef-counted objects what is the point in not using them ?

-Michael

Because you may suddenly cause bugs in code that was previously not there.

Using ref. counted objects requires that you respect certain rules. (for instance, do not use untyped pointers).

If your code does not respect these rules, you may find that your program will not work any more.

I switched from Delphi 7 to Delphi XE. One of the things that no longer worked, were strings. It took us up to 8 months after the initial release of our Delphi XE-compiled program to get rid of all bugs. And we had to revert in many places to explicitly using ansistrings.

So for all those people shouting for a new string type: be warned that there may be a lot of side effects...

Michael.

So for all those people shouting for a new string type: be warned that there may be a lot of side effects...

This is very obvious. The problem is that as soon Unicode is introduced there are side effects even if Unicode is implemented as UTF8 residing in a string type that still is called ANSIString. :-(

-Michael

I would not use them, because of my experiences with the garbage collector of .NET. After using it, I know that I should decide when a object has to be destroyed.

Michael

Does anyone know if:

1> It will be possible to choose if a class or object is to be ref-counted? How?

2> If all existing objects will suddenly be ref-counted?

I think it is an interresting addition, if it is something that one can choose on a per-class basis and should be off by default in existing classes. GC has absolutely nothing to do with mobile, so I have no idea why they mixed both.

I'd much prefer multiple inheritance if they are feeling like adding more language features.

I don't understand. While the visible effect is the same (no Free any more), I understand that the concept of garbage collecting ("at certain times, take a look what is not used any more") and fpc's reference counting (delete unused stuff at once when it is clear that nobody uses it any more) is completely different.

I understand that the reference counting works perfectly with strings, so I don't see why it should not work with Objects (even if additional issues might need to be taken into account and it might be appropriate to allow for not reference counted objects, optionally).

-Michael

2012/8/27 Michael Schnell :

consider for example this code (simplified real world example):

TConnection is a reference counted object and the only other object that holds a reference to it is its Buddy object and the following method is called by LNet which does (and can) NOT hold a reference to it, only a TMethod callback that does not affect the reference count. Now carefully watch what happens when this method is called.

procedure TConnection.OnTCPFail(ASocket: TLHandle; const Error: String);
begin
  FDisconnectLock.Acquire;
  if not FShuttingDown then begin
    FShuttingDown := True;
    //no more callbacks
    FSocket.OnRead := @Client.DummySocketEvent;
    FSocket.OnWrite := @Client.DummySocketEvent;
    FSocket.OnError := @Client.DummySocketError;
    FSocket.Disconnect();
    // remove references to the connection in all other objects.
    if Assigned(FBuddy) then begin
      if IsOutgoing then
        FBuddy.SetOutgoing(nil)
      else begin
        FBuddy.SetIncoming(nil); // bug: this will free ourselves NOW!!!
      end;
      FBuddy := nil;             // Crash because we are free already!
    end;
  end;
  FDisconnectLock.Release;
end;

The very moment we clear the (last and only) reference to ourselves in FBuddy we have committed suicide effective immediately(!) and while the method is still running its own object instance has been freed already and the next attempt to access any of our own(!) fields will segfault! The reason is the LNet component that actually called this method did not hold a properly reference counted reference!

These type of bugs are not easy to find (or to understand) if you are not fully aware who is holding a reference (and even more importantly who is not!) and when exactly the refererence counter will reach zero (and maybe from within which thread this might happen).

Instead of explicitly callling free() on all your objects in the correct order you have to make sure you set the last variable holding a reference to nil at the correct time and in the correct order to trigger the destructors in the correct order and not too early (and also not too late!), this can sometimes be even more complicated to achieve than just explicitly calling Free()

The pragmatic fix to he above problem was:

procedure TConnection.OnTCPFail(ASocket: TLHandle; const Error: String);
begin
  Self._AddRef;
  FDisconnectLock.Acquire;
  [...]
  FDisconnectLock.Release;
  Self._Release;  // <-- now we will be freed exactly here!
end;

If such behavior were suddenly the norm for *all* objects (and not only for interfaces or otherwise explicitly and knowingly reference counted objects) then I am sure most of currently existing code would completely stop working from one day to the other and large parts of many applications and frameworks would have to be rewritten from scratch.

Reference counting is one type of garbage collecting. And every type causes overhead and problems.

I understand that the reference counting works perfectly with strings, so I don't see why it should not work with Objects (even if additional issues might need to be taken into account and it might be appropriate to allow for not reference counted objects, optionally).

But how to know, if a reference is unused? Have a look at: http://en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles

It is not a problem that is caused every time. But I prefer objects which I destroy by myself, not by some magic.

Michael

I see.:-)

-Michael

So maybe this is not a good idea if Embarcadero's at all ;-) .

-Michael

Michael Fuchs wrote

It is not a problem that is caused every time. But I prefer objects which I destroy by myself, not by some magic.

Why not simply wait and see what Delphi does... FPC is bound to follow that exactly (or damn close). So no point in guessing now, or thinking up new designs etc. ? just follow the Delphi design and be one with it. [yes, there is some sarcasm in there]

G.

From https://forums.embarcadero.com/thread.jspa?threadID=76082 (Thread: Bad

morning surprise)

"From XE3 onwards, your Delphi Professional EULA will prohibit you from

using Delphi Professional for anything other than local data access." http://www.deltics.co.nz/blog/?p=1097 http://bbs.2ccc.com/topic.asp?topicid=410504

Alexsander Rosa wrote

"From XE3 onwards, your Delphi Professional EULA will prohibit you from > using Delphi Professional for anything other than local data access."

R.I.P Delphi!

G.

Because they might not only have advantages?

No. The above is all I have seen.

I think it is an interresting addition, if it is something that one can choose on a per-class basis and should be off by default in existing classes. GC has absolutely nothing to do with mobile, so I have no idea why they mixed both.

I doubt that is possible. The non GCed classes would not have the events to handle the non ref counted classes. References from non ref counted classes to ref counted classes etc would not work.

Something like that is only possible with completely separated hierarchies (like Firemonkey).

I'd much prefer multiple inheritance if they are feeling like adding more language features.

I much prefer they simply fix bugs and increase optimization.

The point is that the VCL styles are a different binary type (win32) than allowed in the store (WinRT)

=)

Marcos Douglas

The more I read about Delphi XE3 the more I have the feeling that FPC and Lazarus should leave the route laid out by Delphi...

Regards,
Sven

Yes, exactly. For me that would be the ideal. Put ref-counted classes in a completely separate hierarchy. This way no existing code is broken and only people that explicitly want it for their framework will use it.

so adding that one line negates the previous .Free line(s)??

i'm still learning all this new-fangled stuff... i'm a (very) oldschool procedural coder and having things popping into and out of existence whenever they want to is something i'm still trying to wrap my head around :/ :(

Notice the _AddRef call ? Thanks to this, the

>>>

Self._AddRef;[Self.RefCount is now 2]
[...]
FBuddy.SetIncoming(nil); //[Self.RefCount is now 1] was: bug: this will free ourselves NOW!!! <<<<
and after
[...]
Self._Release; // [Self.RefCount is now 0 and GC removes the TConnection from memory.]

BTW, Frankly, would it not be easier/less error prone if the FDisconnectLock.[Acquire|Release] did that ? (i.e. increase/decrease the RefCount of Self as well as acquire/release the lock ?) It seems /logically/ correct : there is /one/ more activity associated to this object, so it can't be freed before it's done ?

Curiously,
L.

You are using strings. Here reference counting rather obviously woks liked charm. But of course you usually don't hold references to other things in strings (I sometimes did and it did work, but .... ;-) )

-Michael

Marco van de Voort wrote

Because they might not only have advantages?

If this is that TObject.Free sometimes helps: Free supposedly still can be used.

If this is that sometimes you don't want ref counting you might be able
to do TObject.RefCounting := False;

If this is that it is error prone in certain situations: TObject.RefCounting = False by default.

If this is that it is error prone in most situations: forget about it.

-Michael

Michael Schnell wrote

If this is that it is error prone in certain situations: TObject.RefCounting = False by default.

Nonetheless to me it seems like a nice idea to have String as a sibling of TObjcet which in this case is somehow self-creating and freeing (RefCounting = True) like an interfaced Object.

-Michael

Felipe Monteiro de Carvalho wrote

This way no existing code is broken and only people that explicitly want it for their framework will use it.

No existing code would be broken if TObject would get a property RefCounting and by default TObject.RefCounting = False.

But to be really useful (e.g. as a parent for String), I feel that additionally auto-creation would be necessary.

-Michael

I think that this has been the "intention" of the Professional Version for many years else there would be no incentive to buy the Enterprise and above versions would there??
Okay so you could access work group databases with the BDE but it was always flaky with loads of data corruption. R.I.P. BDE

As Lazarus and Delphi become very much different products there is more of a case for developers to use both - as I do.

Long live L and D!

regards
Les

In the Embarcadero forum someone suggested, that the intention is to draw as much money as possible with a castrated XE3 (no IOS and Android support), and then drop the Delphi Product line altogether.

As Lazarus and Delphi become very much different products there is more of a case for developers to use both - as I do.

What now seems very important ia to talk the Delphi Third Party add on manufactures into making their products Lazarus-certified. This should not bee too much work for them at least with Windows-only versions of their stuff.

-Michael

Michael Schnell wrote

Nonetheless to me it seems like a nice idea to have String as a sibling of TObjcet which in this case is somehow self-creating and freeing (RefCounting = True) like an interfaced Object.

I'm working on exactly that (well, if I understood your message correctly). It's just an experiment at the moment, but I have implemented a IString interface which declares methods like Count(), Length(), Replace(), Compare(), .SubStr(), .CharAt(), .CodepointAt() etc...

I then have a TString object which is reference counted and implements the IString interface. I then use IString everywhere I would have used String or AnsiString. Internally the string data is in UTF-8, but later I'll make this configurable between UTF-8 and UTF-16.

All the code is unit tested so far, and works quite nicely. My next step is to extend IString to include .ToUTF8(), .ToUTF16() etc, so that it makes it very easy to pass a TString's data to external API's.

Anyway, so far it is an interesting idea [for me], and maybe this experiment will actually go somewhere. :)

Regards,
- Graeme -

Graeme Geldenhuys wrote

Anyway, so far it is an interesting idea [for me], and maybe this experiment will actually go somewhere. :)

Great !!!

If that library is working, to make it really usable, I suppose some compiler magic is necessary to allow for using these lStrings with the syntax we know for String and additionally allow for Object-Syntax for these strings.

-Michael

Leslie Kaye wrote

I think that this has been the "intention" of the Professional Version for many years else there would be no incentive to buy the Enterprise and above versions would there??

In the days of Borland, there was a clear separation between the Personal, Professional and Enterprise. The separation was based on what you get out-of-the-box, but it didn't force an artificial limitation on what you can do with each of those products.

eg:
Personal: BDE came out of the box.
Professional: Same as Personal, plus C/S support and select few DB drivers.
Enterprise: Same as Professional, plus Midas (n-tier), Web Development tools, CORBA, WebServices, UML and more DB drivers etc.

Those features were all developed and included by Borland.

In each of those products, you could implement your own C/S database code, or n-tier code, or install 3rd party components like Direct Oracle Access etc to give you that functionality. It would simply cost you your time and effort to implement such things yourself.

But now - and this is the big gripe most developers have - Embarcadero is telling developers what software they may and may not develop with Delphi. This is absolutely ridiculous, and I think probably illegal in many countries.

Either way, the future of Delphi seem pretty bleak to me. It seems there are too many "excellent" alternatives for Delphi to still make Delphi a viable money making machine. Developers are leaving Delphi in droves [if they haven't done so already].

Regards,
- Graeme -

Michael Schnell wrote

If that library is working, to make it really usable, I suppose some compiler magic is necessary to allow for using these lStrings with the syntax we know for String

In the end that would probably be the case... Just like Qt and Java implemented some compiler magic to do exactly what you described.

In the mean time I created various constructor to the TString class that takes AnsiString, PChar, WideString, UnicodeString as initial data. I've also implemented overloaded "helper" functions that instantiates the TString class and returns a IString reference.

eg:

   var
     lMyString: IString;
   begin
     lMyString := s('Some string data');
     ...
   end;

s() being the helper function, instead of having to write TString.Create('Some string data'); At least it is slightly less code to type. :)

Graeme.

2012/8/29 Lukasz Sokol :

BTW, Frankly, would it not be easier/less error prone if the FDisconnectLock.[Acquire|Release] did that ? (i.e. increase/decrease the RefCount of Self as well as acquire/release the lock ?) It seems /logically/ correct : there is /one/ more activity associated to this object, so it can't be freed before it's done ?

Yes, you are right, that would consequently be the most logical place for these calls. It was just a pragmatic quick fix to narrow down the source of the problem. I'm not yet 100% satisfied with this entire connection object and everything that surrounds it (and the multiple ways it must be able to end its life: it must be able to free itself (happens on the network thread) and it must be able to be disconnected and freed from the outside from the main thread). Athough now it seems that all crashes are gone I somehow still don't really like the code yet.

To me all this seems like a great idea and I am enlightened to see that you already invested some work on that behalf.

Re-thinking the concept of (Unicode enabled) Strings in that light would allow for another idea of mine, I expressed some months ago. I think the different strings types should be a hierarchy of increasingly specialized classes.

On top, there is a very universal string that allows for true dynamical character encoding (code and size).

Derived from same specialized types are provided (and can be created by the user) that e.g. define a fixed coding.

By that the details of the different string types and the auto-conversion is strictly implementation dependent (and even can be changed by the user if he feels like re-doing the appropriate classes) and (if correctly done) independent from the visible behavior.

Compiler magic would allow for the syntax known from Delphi and (additionally) would allow for creating functions that use the top-level (fully dynamical encoded) string class and would do conversions only if necessary. Under the hood the compiler does normal calls to (overloaded) class functions.

-Michael

Michael Schnell wrote

In the Embarcadero forum someone suggested, that the intention is to draw as much money as possible with a castrated XE3 (no IOS and Android support), and then drop the Delphi Product line altogether.

Presumably with Embarcadero retaining it for internal development, which is very much what happened to JPI/TopSpeed when it was swallowed by Clarion.

I wonder whether (whoever runs) Torry could/would help here?

We've not invested in Delphi for some while: we're not prepared to pay the asking price for something that can be crippled if the registration servers go down. From that point of view, and allowing for the number of platforms that FPC/Lazarus supports, I think the issue is whether the Delphi language and VCL remains compatible with FPC's Object Pascal and Lazarus's LCL, not vice versa.

Which was what I was assuming in my "What is a string" query in fpc-devel.

Mark Morgan Lloyd wrote

Which was what I was assuming in my "What is a string" query in fpc-devel....

... where this discussion would be located more appropriately, of course.

-Michael

Michael Schnell wrote

I think the different strings types should be a hierarchy of increasingly specialized classes.

I think we only need one "unicode string" type and be done with it. That "unicode string" type can support the official UTF-8, UTF-16 and UTF-32 encodings. That's it! No more other string types should be needed for modern applications.

G.

I think very different.

We do need different string types, anyway, to be Delphi compatible. In fact for the Delphi compiler the syntax for defining a string variable does implement multiple different types that all are called String in the source code. This is necessary to avoid the overhead fully dynamical behavior of all strings would introduce, thus the compiler already knows about the string type (aka predefined encoding) when it compiles a line of source code. This is agreed to be a good thing regarding only providing fully dynamical encoding.

FPC programs need to be able to read text files encoded in many different encoding types. this includes the different string encoding types provided by Delphi but should be extensible and supposedly support for e.g. the funny html character encoding (I don't remember the name) should be added right away.

Support for fully dynamically encoded strings should be available to allow for doing functions that correctly deal with whatever encoding without necessarily doing any conversion.

For me this asks for a decent hierarchy of string types and their corresponding classes.

-Michael

2012/8/28 Sven Barth

Totally agree...

Sven Barth wrote

The more I read about Delphi XE3 the more I have the feeling that FPC and Lazarus should leave the route laid out by Delphi...

+1
I've been saying that for years.

Graeme.

I was thinking: I hope that Delphi will not make ref-counted objects mandatory. If yes, then it will essentially bring all of the problems from Java into Pascal, and loose our current memory optimization parity with C++

Felipe Monteiro de Carvalho wrote

I hope that Delphi will not make ref-counted objects mandatory. If yes, then it will essentially bring all of the problems from Java into Pascal,

The solution is simple..... stop following Delphi!

G.

Well.

From before I remember even in Delphi (maybe), calling Self.Free, or equivalent,

even as a last line ever, was an invitation to memory corruption and AV's. (LCL/VCL Forms come as example : you don't free one from within, period. You call Close, and OnClose you decide if you want to Hide it or whatsit-called-option-to-destroy - but only the parent was able to free its child - in this instance, Application's Idle loop (again, IIRC).)

So I imagine Object Pascal way would be to have the TConnection as a child of some governing object, that would only ever call its .Free destructor, and of itself never getting destroyed (the governor). And I see where the temptation to include the /common/ cases of such constructs into a Garbage Collector comes from... in programs without TApplication.

(again all this is IIRC and IMVHO)
(I sense we got a bit OT?)
L.

IMHO this can only just be a test in order to proof the concept of Strings implemented as objects.

To make it useful compiler magic is required.

-Michael

I did exactly the same thing for Delphi some time ago and encountered huge performance issues (in my case, I was using records with overloaded operators to emulate "smart types"). The code is open sourced but without compiler magic and serious optimization, it's fairly worthless.

Regards,
Simon

The intermediate results in string expressions can cause much overhead.

Standard problems in languages whose strings are immutable. Simply avoid it... don't even try to implement it... please...

Embrace yourself, people. We might get a lot of "attack" from to-be-previous-Delphi-users (assuming they finally look at Lazarus/FPC instead of moving to other dev platforms).

I appreciate your... umm... "warm" welcome.

How do you intend to implement string operators?

AFAIK string concatenation "+" in .NET (and others?) is slow, instead it's suggested to use concatenation methods directly. The intermediate results in string expressions can cause much overhead.

DoDi

Simon J Stuart [LaKraven Studios Ltd] wrote

I appreciate your... umm... "warm" welcome.

That wasn't 've arrived in the middle of a thread
about how (or whether) something could be reorganised and whether Delphi's position on it is significant, and some people's email clients aren't very good at keeping things properly threaded.

Hans-Peter Diettrich wrote

How do you intend to implement string operators?

I haven't thought or got to that part yet. I'll start with .Append(), .Equals(), .Replace(), .SubString(), .Split() etc to cover all bases.

I'm still deciding if the TString class must be immutable or not. With my strong Design Patterns background, I'm strongly leaning towards that though. So .Append() and .Replace() for example will return new instances of the class.

The classic unit test Money example explains this "immutable" reasoning well. Consider the following...

public void testMultiplication() {
    Dollar five = new Dollar(5);
    five.times(2);
    assertEquals(10, five.amount);  // Confusing!
    five.times(3);
    assertEquals(15, five.amount);  // Fail! It's actually 30 now.
}

After calling .times() the five dollar instance isn't 5 any more! Quite confusing, and probably a good thing to avoid. So the following makes a lot more sense.

public void testMultiplication() {
    Dollar five = new Dollar(5);
    Dollar product = five.times(2);
    assertEquals(10, product.amount);
    product = five.times(3);
    assertEquals(15, product.amount);
}

Now we can call five.times(x) all day long, and the five money instance is always 5.

Cheers,
- Graeme -

leledumbo wrote

Standard problems in languages whose strings are immutable. Simply avoid it... don't even try to implement it... please...

:-)

See my response to Hans-Peter.

Graeme.

i didn't then but i do now... my eyes were attracted to the //<-- comment of which there was none for _AddRef... thanks for pointing it out :)

it would seem to be better from my perspective... i can't say that i'll ever remember to actually write Self._AddRef or Self._Release... remembering to add the lock will be enough trouble ;)

This is just what can make such classes dead slow in real life use.

Now replace "five" by "MyAccount", and feel comfortable with the continued increase :-)

In a good C++ design one would implement both "+" and "+=" operators, so that a compiler has a chance to optimize expression evaluation.

DoDi

This is just what can make such classes dead slow in real life use.

+1/0 (tried with Lua, Java, Python, etc. no more small, obvious, straight, easy to write code to load a file contents into a string variable easily. complicated techniques required)

Now replace "five" by "MyAccount", and feel comfortable with the continued increase :-)

Another +1/0. A proper naming should resemble its usage :)

Anyway Graeme, if you like the expression style, overloaded operators would be more intuitive. Or a(nother) proper naming: .Append and .Replace should NOT create new instance, however .Concat, .SubString and .Split should.

leledumbo wrote

straight, easy to write code to load a file contents into a string variable easily. complicated techniques required)

What's so difficult about:

var
   sl: TMyNewStringList;
   fn: IString;
begin
   fn := s('c:\myfile.txt');
   sl := TMyNewStringList.Create;
   sl.LoadFromFile(fn, encUTF8);  // for a UTF-8 encoded file
// ...or...
   sl.LoadFromFile(fn, encUTF16); // for a UTF-16 encoded file

Internally TMyNewStringList will use the TString type. The second parameter in LoadFromFile() is the encoding the file is in. TMyNewStringList will load the data and do the encoding conversion (if required) to store the data in the encoding used by TString.

Just because Java requires 3 classes to work together to read a text file [1], doesn't mean Object Pascal must too.

Anyway Graeme, if you like the expression style, overloaded operators would be more intuitive. Or a(nother) proper naming: .Append and .Replace should NOT create new instance,

The same confusion could arise as before, and that is what immutable objects try to avoid. For example:

var
   lUserJohn: IString;
   lFirstName: IString;
begin
   lUserJohn := s('john');
   lUserJohn.Replace('sussie');
   { now lUserJohn doesn't store the name one would expect }
// ...or...
   lFirstName := s('John');
   lFirstName.Append(' Doe');
   { now lFirstName doesn't store what the variable name suggests }

...but this is much more clear...

   lFullName := lFirstName.Append(' Doe');

lFirstName still contains what it says, and so does lFullName.

Then also throw multi-threading into the mix. With immutable strings or objects you don't need to worry about Mutexes or Critical Sections etc... This simplifies multi-threaded programming a lot.

[1]
http://www.mkyong.com/java/how-to-read-utf-8-encoded-data-from-a-file-java/

Regards,
- Graeme -

Seems like those bankers finally realized their mistake: https://forums.embarcadero.com/thread.jspa?threadID=76285&tstart=0

The restriction now applies only to dbExpress.