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

[Jürgen Hestermann]

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 there also a switch
{$OneBasedDynArrays On}  ?
I would love it.
No more confusion about first and last element index.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Ryan Joseph]

> 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 used with one other unit. TClassB is communicating with TClassA via 
interfaces but it’s still useful standalone and distinct in nature.

This happens to me all the time actually where I need to expose some type 
information or an interface to both classes because I don’t want them merged.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Sven Barth]

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 really should
> read the “what’s new” document.

Seems like that wasn't added to the New Features 3.0.0 page anyway :/

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Graeme Geldenhuys]

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

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[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. I really should
read the “what’s new” document.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Luiz Americo Pereira Camara]

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 COM-style Interfaces, then yes you get
> memory management.


Not necessarily, you can use COM interfaces with TComponent or other class
that implements addref method but does not automatically frees the instance
when refcount is zero

Luiz
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Vincent Snijders]

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 blocks with try..finally to ensure that the instances are
>> released from memory.
>>
>> Theoretically, which solution has higher performance? The traditional
>> approach (code protected try..finally) or classes with interfaces (no need
>> to protect the code. by otherside, classes with interfaces support have
>> lock operations)?
>>
>>
> It should be exactly the same. As soon as interfaces are used the compiler
> inserts an implicit try...finally in a procedure.
> You can see this if you step through the code with GDB, the execution point
> will jump to the end of the procedure and then back to the beginning...
>
>
I would venture, that manually adding try finally would give you better
performance than using interfaces at the cost of writing more code and
therefore less clear and more error-prone source.

If you use interfaces, the compiler also adds reference counting, which you
don't have if you free the objects at the right places.

It is not sure if you can measure the difference in performance though.

Vincent
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Ewald]

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 obvious name to use for the file now.

Mutually exclusive classes are mutually exclusive to classes which have
dependencies on one another ;-)

Or am I missing something?

-- 
Ewald
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Sven Barth]

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, doesn't it? Porting will still require
> 0-based string implementation, that class implementation alone won't be
> enough.

We already have zero based strings in 3.0.0 if {$ZeroBasedStrings On} is
used (it's a local switch). It works with Ansi-, Wide- and
UnicodeString, but not with ShortString.

The following example will print

=== output begin ===
l
o
=== output end ===

=== code begin ===

program tzerostr;

{$H+}

var
  s: String;
begin
  s := 'Hello World';
  Writeln(s[4]);
{$ZeroBasedStrings On}
  Writeln(s[4]);
end.

=== code end ===

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Florian Klämpfl]

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.
> 
> Practical people use the tools at their disposal how they are meant to use.
> 
> 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.
> 

Or do it in two separate include files and add include both in the unit. FPC 
can do the C++ way :

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[leledumbo]

> 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 string implementation, that class implementation alone won't be
enough.



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Any-chance-to-add-the-TStringBuilder-to-FCL-tp5724927p5724928.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[silvioprog]

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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Ryan Joseph]

> 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 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 obvious name to use for the file now.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Michael Van Canneyt]

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


I thought that was probably the answer I’d get but I wanted to ask anyways. I 
get there’s a Pascal way but it’s making the job more difficult then it should 
be so I opt for the quick and easy hack. Maybe it’s bad form but at the end of 
the day I just want to make things work and get the job done instead of getting 
held up on small details.





The interface was probably over complicating the example actually because
the true problem is having this pattern of a parent->child relationship
where both classes need to know about each other to some extent but
putting them in the same unit causes clutter and pollution in other units
namespaces.  In this example it’s likely that many other units use TClassB
and it’s not exclusive to TClassA so putting them in the same unit doesn’t
make sense.


It certainly does make sense, if they are so intertwined.

This is not Java where you must put all classes in a single separate file.

If classes are so intertwined that they need detailed knowledge of each
other's property, put them in 1 unit.

It is as simple as that.


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.

Practical people use the tools at their disposal how they are meant to use.

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.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Marcos Douglas]

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 use COM-style Interfaces, then yes you get
> memory management. If you use CORBA-style Interface, then no you don’t
> get memory management.

You're right, well remembered.
I use only COM-style Interfaces.

Regards,
Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[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 COM-style Interfaces, then yes you get
memory management. If you use CORBA-style Interface, then no you don’t
get memory management.

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Marcos Douglas]

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 instances are released
> from memory.
>
> Theoretically, which solution has higher performance? The traditional
> approach (code protected try..finally) or classes with interfaces (no need
> to protect the code. by otherside, classes with interfaces support have lock
> operations)?

Hi,

I don't know the answer but I think should be exactly the same.
Even if not, I strongly recommend you to use interfaces instead
"try-finally" approach
because you gain more than just automatic memory release.

Regards,
Marcos Douglas

PS. I have a blog about Object Pascal. I write about real
object-oriented approach.
The blog is written in Portuguese but using Google Translate I guess
you won't have
problems to translate.

http://objectpascalprogramming.com/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Ryan Joseph]

> 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 probably the answer I’d get but I wanted to ask anyways. I 
get there’s a Pascal way but it’s making the job more difficult then it should 
be so I opt for the quick and easy hack. Maybe it’s bad form but at the end of 
the day I just want to make things work and get the job done instead of getting 
held up on small details.

> 
>> 
>> The interface was probably over complicating the example actually because
>> the true problem is having this pattern of a parent->child relationship
>> where both classes need to know about each other to some extent but
>> putting them in the same unit causes clutter and pollution in other units
>> namespaces.  In this example it’s likely that many other units use TClassB
>> and it’s not exclusive to TClassA so putting them in the same unit doesn’t
>> make sense.
> 
> It certainly does make sense, if they are so intertwined.
> 
> This is not Java where you must put all classes in a single separate file.
> 
> If classes are so intertwined that they need detailed knowledge of each
> other's property, put them in 1 unit.
> 
> It is as simple as that.

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.

Why is it so terrible that classes could have forward declarations outside of a 
single block anyways? It seems like a practical and efficient solution that 
requires lots of extra work in design or typecasting/interfaces.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Ryan Joseph]

> 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 but other languages have forward 
> declarations so I wonder why Pascal isn’t doing this also since it seems like 
> the obvious solution.
> 
> 
> procedure TClassA.SomeProc;
> begin
>  TClassB(FClassBObject).OtherProc;
> end;
> 
> end.
> 
> unitB is pretty similar.
> 
> As long as you make sure that FClassBObject really is a TClassB object when 
> it is assigned, the above should all work. The only extra effort is with the 
> TClassB(...) wrapper for each reference to FClassBObject.

I use forward declarations sometimes but of course they need to be in the same 
block so they don’t solve this problem.

Yeah type casting. :) Like interfaces they work but they add a significant 
overhead and clutter (especially if they need to be used with dozens of methods 
in a unit) so that’s why I’m seeing if there’s a better way. However I think I 
like your idea of using them in conjunction with the uses in the implementation 
instead of my "abstract class" solution. Thanks for the tip.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Michael Van Canneyt]

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 I’m still typically using properties of the child class in
addition to the interface.  Offloading all properties to the interface
would work but it would be making accessing them very cumbersome because
it requires using Support instead of just accessing them directly.


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.



The interface was probably over complicating the example actually because
the true problem is having this pattern of a parent->child relationship
where both classes need to know about each other to some extent but
putting them in the same unit causes clutter and pollution in other units
namespaces.  In this example it’s likely that many other units use TClassB
and it’s not exclusive to TClassA so putting them in the same unit doesn’t
make sense.


It certainly does make sense, if they are so intertwined.

This is not Java where you must put all classes in a single separate file.

If classes are so intertwined that they need detailed knowledge of each
other's property, put them in 1 unit.

It is as simple as that.



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 has forward declarations. But only inside 1 unit.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Tony Whyman]

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 TClassB
...
end;

Otherwise, if you really want to avoid defining interdependent classes 
in the same unit (not sure why you want to avoid this) then try this:


unit unitA;

interface

type

class TClassA
private
  FClassBObject: TObject;
public
  procedure SomeProc;
end;

implementation

uses unitB;

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.


procedure TClassA.SomeProc;
begin
  TClassB(FClassBObject).OtherProc;
end;

end.

unitB is pretty similar.

As long as you make sure that FClassBObject really is a TClassB object 
when it is assigned, the above should all work. The only extra effort is 
with the TClassB(...) wrapper for each reference to FClassBObject.


On 14/04/16 11:35, 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 I’m still typically using properties of the child class in 
addition to the interface. Offloading all properties to the interface would 
work but it would be making accessing them very cumbersome because it requires 
using Support instead of just accessing them directly.

The interface was probably over complicating the example actually because the true 
problem is having this pattern of a parent->child relationship where both 
classes need to know about each other to some extent but putting them in the same 
unit causes clutter and pollution in other units namespaces. In this example it’s 
likely that many other units  use TClassB and it’s not exclusive to TClassA so 
putting them in the same unit doesn’t make sense.

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.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Ryan Joseph]

> 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 of the child class in 
addition to the interface. Offloading all properties to the interface would 
work but it would be making accessing them very cumbersome because it requires 
using Support instead of just accessing them directly.

The interface was probably over complicating the example actually because the 
true problem is having this pattern of a parent->child relationship where both 
classes need to know about each other to some extent but putting them in the 
same unit causes clutter and pollution in other units namespaces. In this 
example it’s likely that many other units  use TClassB and it’s not exclusive 
to TClassA so putting them in the same unit doesn’t make sense.

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.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Ryan Joseph]

> 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 would have been smart to learn about Delphi 
and new features but I just went ahead as normal missing lots of things that 
would help me in future years, like today for example. :)

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Michael Van Canneyt]

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 circular reference issues I had. So I dont' think it is
such a big problem as you make out.

Often moving uses clause references from the Interface section to the
Implementation section solve the problem. Sometimes using a base class
in the interface works. Sometimes using Interfaces (the language
feature) is a much better approach.

So again, if you can give an actual example of the various units, and
how they relate (use each other), then we might be able to help you further.

Regards,
 Graeme



I’ve just browsed over some code and found moving uses to the implementation 
did in fact help. That’s really helpful thank you both. However I’m still 
seeing some common patterns which just don’t seem Pascal friendly. I started 
using these more often after using Objective-C on Mac frequently and I really 
like it but it requires me to hack around the compiler in Pascal.

In that example below the “main” class has children it talks to using an 
interface and returning a reference to itself for introspection. They are 
interdependent but Pascal doesn’t offer a way to expose a global namespace for 
both the units as far as I know.  In other languages I would make another 
“globals” unit and keep forward references to TClassA, TClassB and IClassA.

==

ClassB.pas:

uses
 ClassA;  // <- circular reference but I need to know about ClassA

type
 TClassB = class (IClassA)
   // when we implement this method we may need to know some things
   // about the parent (TClassA) so it must be included
   procedure ClassDidThis (parent: TClassA; action: integer);
 end;

ClassA.pas:

uses
 ClassB;

type
 TClassA = class
   child: TClassB;
 end;


You should not need TClassB here. You defeat the point of using an
interface.

  Child : IClassA;

should be sufficient.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Ryan Joseph]

> 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 dont' think it is
> such a big problem as you make out.
> 
> Often moving uses clause references from the Interface section to the
> Implementation section solve the problem. Sometimes using a base class
> in the interface works. Sometimes using Interfaces (the language
> feature) is a much better approach.
> 
> So again, if you can give an actual example of the various units, and
> how they relate (use each other), then we might be able to help you further.
> 
> Regards,
>  Graeme


I’ve just browsed over some code and found moving uses to the implementation 
did in fact help. That’s really helpful thank you both. However I’m still 
seeing some common patterns which just don’t seem Pascal friendly. I started 
using these more often after using Objective-C on Mac frequently and I really 
like it but it requires me to hack around the compiler in Pascal.

In that example below the “main” class has children it talks to using an 
interface and returning a reference to itself for introspection. They are 
interdependent but Pascal doesn’t offer a way to expose a global namespace for 
both the units as far as I know.  In other languages I would make another 
“globals” unit and keep forward references to TClassA, TClassB and IClassA.

==

ClassB.pas:

uses
  ClassA;  // <- circular reference but I need to know about ClassA

type
  TClassB = class (IClassA)
// when we implement this method we may need to know some things
// about the parent (TClassA) so it must be included
procedure ClassDidThis (parent: TClassA; action: integer);
  end;

ClassA.pas:

uses
  ClassB;

type
  TClassA = class
child: TClassB;
  end;

  // TClassA uses this interface to talk with it's “children” (TClassB)
  // and always returns a reference to itself because the children
  // often need to know about the parent also
  IClassA = interface
procedure ClassDidThis (parent: TClassA; action: integer);
  end;

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Sven Barth]

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 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
interface.
>
> I had no idea you could declare uses in the implementation! That could
probably fix 90% of the problems I’m having which I’ve used abstract
classes, dynamic method invocation and more recently interfaces to
workaround. Don’t tell me this has been around for 20 years now I just
never knew about it. ;) I should have asked sooner that’s for sure.

When was Delphi 3 released? Before '96? In that case it would indeed be
more than 20 years ;)

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[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 blocks with try..finally to ensure that the instances are
released from memory.

Theoretically, which solution has higher performance? The traditional
approach (code protected try..finally) or classes with interfaces (no need
to protect the code. by otherside, classes with interfaces support have
lock operations)?



It should be exactly the same. 
As soon as interfaces are used the compiler inserts an implicit try...finally in a procedure.

You can see this if you step through the code with GDB, the execution point
will jump to the end of the procedure and then back to the beginning...

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[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 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 
> interface.

I had no idea you could declare uses in the implementation! That could probably 
fix 90% of the problems I’m having which I’ve used abstract classes, dynamic 
method invocation and more recently interfaces to workaround. Don’t tell me 
this has been around for 20 years now I just never knew about it. ;) I should 
have asked sooner that’s for sure.

Thanks!

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Graeme Geldenhuys]

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 if you don't mind.

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Mazola Winstrol]

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? The traditional
approach (code protected try..finally) or classes with interfaces (no need
to protect the code. by otherside, classes with interfaces support have
lock operations)?

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Initialization in Shared Libraries

[Mazola Winstrol]

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 loaded) then it's called in that thread's context. But other
> then that they behave the same as for normal programs.
>
>
Thanks for the clarification!

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Tony Whyman]

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


Having probably told you something you already know, i do sometimes get 
circular reference problems and usually because a program has evolved 
rather than having been designed properly. Sometimes it's better just to 
take as a hint to structure your program better but, otherwise, the 
techniques available are:


1. Abstract classes (as you suggest)

2. Interfaces

3. Dynamic casts.

Of the three, dynamic casts are often the quick and dirty way of fixing 
the problem as they can allow you to move a problematic unit reference 
from the "interface uses" to the "implementation uses", replacing the 
class reference in the unit interface to something generic like 
"TObject" and them coercing it to the required class when you actually 
use it.


I hope this helps.

Regards

Tony Whyman
MWA

On 14/04/16 05:29, Ryan Joseph wrote:

The most annoying problem I have with Pascal currently is with circular unit 
dependanices and “global” classes that need to be referenced from many units. In 
other languages I would make a forward declaration of the class in  one file then 
implement it in another file so that all files could reference the class. It’s maybe 
a symptom of a “bad" design but sometimes it’s just faster and easier so it’s a 
problem I have to fight Pascal to make it work.

When I moved to FPC the solution I started using was this pattern below where I 
make an abstract class then override the methods I need in the global namespace 
within in the “main unit”. This is a bad hack to workaround a feature of the 
language but I wonder if there’s a better way. Does anyone have any ideas I 
could try?



"global” unit shared by many other units:

type
   TSomeClassAbstract = class (TObject)
 procedure DoSomething; virtual; abstract;
   end;
   
“main” unit which implements the class:
   
type

   TSomeClass = class (TSomeClassAbstract)
 procedure DoSomething; override;
   end;


Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Graeme Geldenhuys]

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 how many circular reference issues I had. So I dont' think it is
such a big problem as you make out.

Often moving uses clause references from the Interface section to the
Implementation section solve the problem. Sometimes using a base class
in the interface works. Sometimes using Interfaces (the language
feature) is a much better approach.

So again, if you can give an actual example of the various units, and
how they relate (use each other), then we might be able to help you further.

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Michael Van Canneyt]

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)


http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus says:
On the other hand a *String* is assumed at compile time to have 
/DefaultSystemCodePage/ (CP_ACP). /DefaultSystemCodePage/ is defined at run 
time, so the compiler conservatively assumes that /String/ and /UTF8String/ 
have different encodings.


So I was wrong assuming from your message that DefaultSystemcodepage is the 
default encoding for the type "String" (and with that for TStrings and with 
that for TSringList).


Now I still don't know whether/how the default encoding for the type "String 
(which I still assume is defined when building  the compiler)


Your assumption is wrong. 
The default encoding for the string type is determined at run-time, not at compile time.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Michael Schnell]

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 hand a *String* is assumed at compile time to have 
/DefaultSystemCodePage/ (CP_ACP). /DefaultSystemCodePage/ is defined 
at run time, so the compiler conservatively assumes that /String/ and 
/UTF8String/ have different encodings.


So I was wrong assuming from your message that DefaultSystemcodepage is 
the default encoding for the type "String" (and with that for TStrings 
and with that for TSringList).


Now I still don't know whether/how the default encoding for the type 
"String (which I still assume is defined when building  the compiler) is 
depending on the arch/OS the compiler is built for. (I only tested on 
Linux and here it rather obviously is UTF8. I assume on Windows it's 
UTF16 for Delphi compatibility).


-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Michael Schnell]

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 default code page for 
the type Strings is not dynamic, but a built-in setting.)


So Lazarus (IDE/LCL) can't do anything about that, as it will not 
enforce re-building the compiler and/or the RTL.


-Michael

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal