Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

Am 2016-04-14 um 23:22 schrieb Graeme Geldenhuys: > On 2016-04-14 19:27, Sven Barth wrote: >> We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is >> used (it's a local switch). > Wow, learnt something new again. Never new that existed. Me too. Though I will not use it. Is

Re: [fpc-pascal] A better way?

> On Apr 15, 2016, at 1:23 AM, Ewald wrote: > > Mutually exclusive classes are mutually exclusive to classes which have > dependencies on one another ;-) > > Or am I missing something? In the example I gave TClassB may be used by many other units but TClassA is only

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

Am 14.04.2016 23:22 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-04-14 19:27, Sven Barth wrote: > > We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is > > used (it's a local switch). > > Wow, learnt something new again. Never new that existed. I

Re: [fpc-pascal] try..finally vs interfaces performance

On 2016-04-14 21:45, Luiz Americo Pereira Camara wrote: > other class > that implements addref method but does not automatically frees the instance > when refcount is zero I always considered that a bit of a hack. But yes, you are right. Regards, Graeme

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

On 2016-04-14 19:27, Sven Barth wrote: > We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is > used (it's a local switch). Wow, learnt something new again. Never new that existed. I really should read the “what’s new” document. Regards, Graeme

Re: [fpc-pascal] try..finally vs interfaces performance

2016-04-14 10:58 GMT-03:00 Graeme Geldenhuys : > On 2016-04-14 14:15, Marcos Douglas wrote: > > because you gain more than just automatic memory release. > > It is also worth noting that not all Interface usage means “automatic > memory release”. If you use

Re: [fpc-pascal] try..finally vs interfaces performance

2016-04-14 10:50 GMT+02:00 Michael Van Canneyt : > > > On Thu, 14 Apr 2016, Mazola Winstrol wrote: > > Recently i did some maintenance in a code of a colleague. I realized that >> he designed several classes with interface support so he do not need to >> protect the code

Re: [fpc-pascal] A better way?

On 14/04/16 16:46, Ryan Joseph wrote: > I think I prefer using type casting or abstract classes more than mixing 2 > mutually exclusive classes into one unit even though they may have > dependancies on each other. Editing and navigating the files would be > confusing for one since there’s no

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

On 14.04.2016 19:36, leledumbo wrote: >> Is there any chance to add a class like Delphi's TStringBuilder to FCL? It > would be very useful to port Delphi code libraries to Free Pascal. > > That exists mainly to overcome the read-only, 0-based string implementation > limitations in Delphi NextGen,

Re: [fpc-pascal] A better way?

Am 14.04.2016 um 16:25 schrieb Michael Van Canneyt: >> >> That would be a solution but it’s not very pretty. Having 2 classes in the >> same unit that need knowledge of each other but are still mutually >> exclusive is also bad design in my opinion. > > Each is entitled to his opinion. > >

Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

> Is there any chance to add a class like Delphi's TStringBuilder to FCL? It would be very useful to port Delphi code libraries to Free Pascal. That exists mainly to overcome the read-only, 0-based string implementation limitations in Delphi NextGen, doesn't it? Porting will still require 0-based

[fpc-pascal] Any chance to add the TStringBuilder to FCL?

Hello, Is there any chance to add a class like Delphi's TStringBuilder to FCL? It would be very useful to port Delphi code libraries to Free Pascal. Thank you! -- Silvio Clécio

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 9:25 PM, Michael Van Canneyt > wrote: > > In this case the tool tells you that the 2 classes should be in 1 unit. > So, you can waste your time looking for a way out, or just use the tool as > it is meant. I think I prefer using type casting or

Re: [fpc-pascal] A better way?

On Thu, 14 Apr 2016, Ryan Joseph wrote: On Apr 14, 2016, at 6:09 PM, Michael Van Canneyt wrote: So, put bluntly, you are unwilling to do things properly, and then complain that the language does not allow you to do this easily enough ? No, you need to do things

Re: [fpc-pascal] try..finally vs interfaces performance

On Thu, Apr 14, 2016 at 10:58 AM, Graeme Geldenhuys wrote: > On 2016-04-14 14:15, Marcos Douglas wrote: >> because you gain more than just automatic memory release. > > It is also worth noting that not all Interface usage means “automatic > memory release”. If you

Re: [fpc-pascal] try..finally vs interfaces performance

On 2016-04-14 14:15, Marcos Douglas wrote: > because you gain more than just automatic memory release. It is also worth noting that not all Interface usage means “automatic memory release”. If you use COM-style Interfaces, then yes you get memory management. If you use CORBA-style Interface, then

Re: [fpc-pascal] try..finally vs interfaces performance

On Thu, Apr 14, 2016 at 5:19 AM, Mazola Winstrol wrote: > Recently i did some maintenance in a code of a colleague. I realized that he > designed several classes with interface support so he do not need to protect > the code blocks with try..finally to ensure that the

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 6:09 PM, Michael Van Canneyt > wrote: > > So, put bluntly, you are unwilling to do things properly, and then complain > that the > language does not allow you to do this easily enough ? > > No, you need to do things properly. I thought that was

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 5:51 PM, Tony Whyman > wrote: > > unit unitA; > > interface > > type > > class TClassA > private > FClassBObject: TObject; > public > procedure SomeProc; > end; > > implementation > > uses unitB; > > Maybe I’m doing something stupid

Re: [fpc-pascal] A better way?

On Thu, 14 Apr 2016, Ryan Joseph wrote: On Apr 14, 2016, at 5:00 PM, Michael Van Canneyt wrote: You should not need TClassB here. You defeat the point of using an interface. I’m using the interface for specific communication I want denoted in the interface but

Re: [fpc-pascal] A better way?

Ryan, Maybe I’m doing something stupid but other languages have forward declarations so I wonder why Pascal isn’t doing this also since it seems like the obvious solution. Pascal does have forward declarations e.g. class TClassB; class TClassA private FClassBObject: TClassB; end; class

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 5:00 PM, Michael Van Canneyt > wrote: > > You should not need TClassB here. You defeat the point of using an > interface. I’m using the interface for specific communication I want denoted in the interface but I’m still typically using properties

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 4:14 PM, Sven Barth wrote: > > When was Delphi 3 released? Before '96? In that case it would indeed be more > than 20 years ;) I was using CodeWarrior back then (coming from a Mac background) and I didn’t switch to FPC until 2004 maybe. It

Re: [fpc-pascal] A better way?

On Thu, 14 Apr 2016, Ryan Joseph wrote: On Apr 14, 2016, at 2:56 PM, Graeme Geldenhuys wrote: If you can give an actual example we can help. I've used TP then Delphi and now Free Pascal for more than 20+ years. I can probably count on one hand how many

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 2:56 PM, Graeme Geldenhuys > wrote: > > If you can give an actual example we can help. I've used TP then Delphi > and now Free Pascal for more than 20+ years. I can probably count on one > hand how many circular reference issues I had. So I

Re: [fpc-pascal] A better way?

Am 14.04.2016 10:45 schrieb "Ryan Joseph" : > > > > On Apr 14, 2016, at 3:02 PM, Tony Whyman wrote: > > > > Reading through your post, I hope that you are aware that most circular dependencies can be avoided by referencing other units

Re: [fpc-pascal] try..finally vs interfaces performance

On Thu, 14 Apr 2016, Mazola Winstrol wrote: Recently i did some maintenance in a code of a colleague. I realized that he designed several classes with interface support so he do not need to protect the code blocks with try..finally to ensure that the instances are released from memory.

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 3:02 PM, Tony Whyman > wrote: > > Reading through your post, I hope that you are aware that most circular > dependencies can be avoided by referencing other units from the "uses" clause > in the "implementation" section and keeping the

Re: [fpc-pascal] try..finally vs interfaces performance

On 2016-04-14 09:19, Mazola Winstrol wrote: > Theoretically, which solution has higher performance? Interesting question. As for the answer I have no idea. Why don't you put a quick test together. Loop the code 10,000 or 100,000 times and time the results. Please share your test code and answer

[fpc-pascal] try..finally vs interfaces performance

Recently i did some maintenance in a code of a colleague. I realized that he designed several classes with interface support so he do not need to protect the code blocks with try..finally to ensure that the instances are released from memory. Theoretically, which solution has higher performance?

Re: [fpc-pascal] Initialization in Shared Libraries

2016-04-13 16:48 GMT-03:00 Sven Barth : > > Yes and mostly yes. The finalization sections might not be called in the > context of the same thread as the initialization sections, because if > the thread that does the last unload of the library (if it is > dynamically

Re: [fpc-pascal] A better way?

Ryan, Reading through your post, I hope that you are aware that most circular dependencies can be avoided by referencing other units from the "uses" clause in the "implementation" section and keeping the "uses" clauses in "interfaces" down to those references strictly necessary for the unit's

Re: [fpc-pascal] A better way?

On 2016-04-14 05:29, Ryan Joseph wrote: > The most annoying problem I have with Pascal currently is with > circular unit dependanices and “global” If you can give an actual example we can help. I've used TP then Delphi and now Free Pascal for more than 20+ years. I can probably count on one hand

Re: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more?

On Wed, 13 Apr 2016, Michael Schnell wrote: On 04/13/2016 09:04 AM, Michael Van Canneyt wrote: It uses the DefaultSystemcodepage. If the system codepage is UTF8, then it will use UTF8. (Sorry for replying yet another answer to the same message of yours)

Re: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more?

On 04/13/2016 09:04 AM, Michael Van Canneyt wrote: It uses the DefaultSystemcodepage. If the system codepage is UTF8, then it will use UTF8. (Sorry for replying yet another answer to the same message of yours) http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus says: On the other

Re: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more?

On 04/13/2016 09:04 AM, Michael Van Canneyt wrote: It uses the DefaultSystemcodepage. If the system codepage is UTF8, then it will use UTF8. Thanks for the enlightenment. Am I right assuming that the DefaultSystemcodepage is determined when compiling the RTL and/or the compiler) ? (As the