Re: [fpc-pascal] Getting the state of a TRTLCriticalSection

2013-10-07 Thread Mark Morgan Lloyd 

Benito van der Zander wrote:


In the end I stuck in code to increment/decrement a counter, and 
looked for it to be explicitly 0 or 1.


Do you need to put a memory barrier around that, or does the critical 
section take care of that?


I used the interlocked increment/decrement, which- as I understand it- 
should handle membar itself on architectures that can benefit from it.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] use cwstring or fpwidestring on linux

2013-10-07 Thread Michael Schnell 

On 10/04/2013 11:02 PM, Sven Barth wrote:


If you want to share Unicode- or AnsiStrings between library and 
application you need to use a common memory manager. For example you 
could use unit "cmem" as one of the first units of both programs. It 
will work on Unix based systems and *should* work on Windows ones as well.


BTW.:

For my embedded C projects, I use different memory managers, dependent 
on the complexity of the project. Either a straight forward one, that 
just allocates blocks in a linked list or a more sophisticated one that 
uses different strategies for different block sizes (small: allocate 
equally sized blocks, medium: use a linked list within a preoccupied 
area, large: one area for each block.


AFAIK the fpc RTL memory manager is similarly "sophisticated", no Idea 
what cmem does.


I do know that for Delphi a third-party memory manager exists that works 
similar and on top oft hat allows for unifying the memory management of 
a program and the dlls called (which Delphi also does out of the box 
with dynamic packages).


Can "cmem" (or some other fpc aware memory manager) also unify the 
memory management of a program and dlls (e.g. in order to allow for 
"plugins to fpc programs) ?


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

Re: [fpc-pascal] Getting the state of a TRTLCriticalSection

2013-10-07 Thread Jonas Maebe 


On 07 Oct 2013, at 09:14, Mark Morgan Lloyd wrote:


Benito van der Zander wrote:


In the end I stuck in code to increment/decrement a counter, and  
looked for it to be explicitly 0 or 1.
Do you need to put a memory barrier around that, or does the  
critical section take care of that?


I used the interlocked increment/decrement, which- as I understand  
it- should handle membar itself on architectures that can benefit  
from it.


They do not include any memory barrier. The only thing those routines  
guarantee on all platforms, is that the value is atomically  
incremented/decremented.



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

Re: [fpc-pascal] Getting the state of a TRTLCriticalSection

2013-10-07 Thread Marco van de Voort 
In our previous episode, Jonas Maebe said:
> > I used the interlocked increment/decrement, which- as I understand  
> > it- should handle membar itself on architectures that can benefit  
> > from it.
> 
> They do not include any memory barrier. The only thing those routines  
> guarantee on all platforms, is that the value is atomically  
> incremented/decremented.

(btw that depends on which functions you mean, our own assembler versions
probably.

The Windows
functions of the same name are guaranteed to have memory barriers afaik,
but do require alignment. (probably to avoid crosssing cache lines)
)

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683614%28v=vs.85%29.aspx
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Getting the state of a TRTLCriticalSection

2013-10-07 Thread Mark Morgan Lloyd 

Jonas Maebe wrote:

On 07 Oct 2013, at 09:14, Mark Morgan Lloyd wrote:


Benito van der Zander wrote:


In the end I stuck in code to increment/decrement a counter, and 
looked for it to be explicitly 0 or 1.
Do you need to put a memory barrier around that, or does the critical 
section take care of that?


I used the interlocked increment/decrement, which- as I understand it- 
should handle membar itself on architectures that can benefit from it.


They do not include any memory barrier. The only thing those routines 
guarantee on all platforms, is that the value is atomically 
incremented/decremented.


Thanks Jonas, noted. For completeness, is there a way to force one?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Getting the state of a TRTLCriticalSection

2013-10-07 Thread Jonas Maebe 


On 07 Oct 2013, at 11:33, Marco van de Voort wrote:


In our previous episode, Jonas Maebe said:

[interlocked increment/decrement]

They do not include any memory barrier. The only thing those routines
guarantee on all platforms, is that the value is atomically
incremented/decremented.


(btw that depends on which functions you mean, our own assembler  
versions

probably.

The Windows
functions of the same name are guaranteed to have memory barriers  
afaik,

but do require alignment. (probably to avoid crosssing cache lines)
)


That's why I wrote "on all platforms". They also always require a  
native alignment on all platforms, because those are cpu limitations  
for atomic instructions.



On 07 Oct 2013, at 11:40, Mark Morgan Lloyd wrote:


Thanks Jonas, noted. For completeness, is there a way to force one?


See http://www.freepascal.org/docs-html/rtl/system/ 
readwritebarrier.html and the pages linked from there.



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

Re: [fpc-pascal] Getting the state of a TRTLCriticalSection

2013-10-07 Thread Mark Morgan Lloyd 

Jonas Maebe wrote:

On 07 Oct 2013, at 11:33, Marco van de Voort wrote:


In our previous episode, Jonas Maebe said:

[interlocked increment/decrement]

They do not include any memory barrier. The only thing those routines
guarantee on all platforms, is that the value is atomically
incremented/decremented.


(btw that depends on which functions you mean, our own assembler versions
probably.

The Windows
functions of the same name are guaranteed to have memory barriers afaik,
but do require alignment. (probably to avoid crosssing cache lines)
)


That's why I wrote "on all platforms". They also always require a native 
alignment on all platforms, because those are cpu limitations for atomic 
instructions.



On 07 Oct 2013, at 11:40, Mark Morgan Lloyd wrote:


Thanks Jonas, noted. For completeness, is there a way to force one?


See http://www.freepascal.org/docs-html/rtl/system/readwritebarrier.html 
and the pages linked from there.


Thanks for that, I mistakenly thought that the code generator was 
inserting implicit membars but I see from my notes relating to bug 23390 
that it's an RTL (>2.2.2) detail.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] use cwstring or fpwidestring on linux

2013-10-07 Thread ko paka 
When I used both managers, like in example, program doesnt work as
expected. Should I report it as error ? For now I will stay with cwstring
manager, but good to know that there is native implementation(first I need
to study something about unicode and collation though) . In fpc sources I
found fpwidestring used only in windows builds.

regards tomas

Example - linux i386, fpc 2.7.1 r25610

program fpwidestring_stringlist;

uses

// 3 possible combination of cwstring, fpwidestring
// 1) only cwstring - program works as expected and writes 4
// 2) only fpwidestring - error, because compareunicodestring function is
not implemented
// (current_Collation is nil in my case in
fpwidestrign.CompareUnicodeString)
// 3) both units - program writes -1 - which si really not expected


  cwstring,
  fpwidestring,
  classes;

var
  m: TStringList;
begin
  m := TStringList.Create;
  try
m.Add('{E13ABA32-1328-4AFA-B21D-438AD054C0A5}');
m.Add('{019D0AA0-915E-41CA-9145-05E6FC2D967C}');
m.Add('{02591FA7-202B-4D63-BEC7-636B00BA1A8C}');
m.Add('{23884961-80F8-4130-B60C-A5CF540A67C1}');
m.Add('{3B3C9C24-0E23-44ED-8466-3024DF24011F}');
m.Add('{398F240E-8809-4CE7-9175-983B96189526}');
m.Add('{661979DB-C38D-4348-A617-59DD28D3327B}');
m.Add('{87AC64E0-87FF-4CA5-B81C-AD494942703D}');
Writeln('IndexOf {3B3C9C24-0E23-44ED-8466-3024DF24011F} is ',
m.IndexOf('{3B3C9C24-0E23-44ED-8466-3024DF24011F}'));
  finally
m.Free;
  end;
end.



On Mon, Oct 7, 2013 at 9:27 AM, Michael Schnell  wrote:

> On 10/04/2013 11:02 PM, Sven Barth wrote:
>
>>
>> If you want to share Unicode- or AnsiStrings between library and
>> application you need to use a common memory manager. For example you could
>> use unit "cmem" as one of the first units of both programs. It will work on
>> Unix based systems and *should* work on Windows ones as well.
>>
>
> BTW.:
>
> For my embedded C projects, I use different memory managers, dependent on
> the complexity of the project. Either a straight forward one, that just
> allocates blocks in a linked list or a more sophisticated one that uses
> different strategies for different block sizes (small: allocate equally
> sized blocks, medium: use a linked list within a preoccupied area, large:
> one area for each block.
>
> AFAIK the fpc RTL memory manager is similarly "sophisticated", no Idea
> what cmem does.
>
> I do know that for Delphi a third-party memory manager exists that works
> similar and on top oft hat allows for unifying the memory management of a
> program and the dlls called (which Delphi also does out of the box with
> dynamic packages).
>
> Can "cmem" (or some other fpc aware memory manager) also unify the memory
> management of a program and dlls (e.g. in order to allow for "plugins to
> fpc programs) ?
>
> -Michael
>
> __**_
> fpc-pascal maillist  -  
> fpc-pascal@lists.freepascal.**org
> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] [OT] sealed?

2013-10-07 Thread silvioprog 
Hello,

I was surfing the internet and came across this structure Delphi:


TJSONPair = class sealed(TJSONAncestor)


So, what is this?

Link:

http://docwiki.embarcadero.com/Libraries/XE3/en/API:Data.DBXJSON.TJSONPair

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [OT] sealed?

2013-10-07 Thread Sven Barth 

On 07.10.2013 19:29, silvioprog wrote:

Hello,

I was surfing the internet and came across this structure Delphi:


TJSONPair=  class  sealed(TJSONAncestor)


So, what is this?


Simple: You are not allowed to create child classes of sealed classes 
(the compiler enforces this). FPC supports this since 2.4.2.


Regards,
Sven

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

Re: [fpc-pascal] [OT] sealed?

2013-10-07 Thread silvioprog 
2013/10/7 Sven Barth 

> On 07.10.2013 19:29, silvioprog wrote:
>
>> Hello,
>>
>> I was surfing the internet and came across this structure Delphi:
>>
>>
>> TJSONPair=  class  sealed(TJSONAncestor)
>>
>>
>> So, what is this?
>>
>
> Simple: You are not allowed to create child classes of sealed classes (the
> compiler enforces this). FPC supports this since 2.4.2.
>
> Regards,
> Sven


Perfect!

It tested it:

  TBaseClass = class
  end;

  TOtherClass = class sealed(TBaseClass)
  end;

  TFooClass = class(TOtherClass)
  end;

and:

unit1.pas(24,32) Error: Cannot create a descendant of the sealed class
"TOtherClass"

It is wonderful, thank you very much Sven! :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [OT] sealed?

2013-10-07 Thread Sven Barth 

On 07.10.2013 20:38, silvioprog wrote:

2013/10/7 Sven Barth mailto:pascaldra...@googlemail.com>>

On 07.10.2013 19:29, silvioprog wrote:

Hello,

I was surfing the internet and came across this structure Delphi:


TJSONPair=  class  sealed(TJSONAncestor)


So, what is this?


Simple: You are not allowed to create child classes of sealed
classes (the compiler enforces this). FPC supports this since 2.4.2.

Regards,
Sven


Perfect!

It tested it:

   TBaseClass = class
   end;

   TOtherClass = class sealed(TBaseClass)
   end;

   TFooClass = class(TOtherClass)
   end;

and:

unit1.pas(24,32) Error: Cannot create a descendant of the sealed class
"TOtherClass"

It is wonderful, thank you very much Sven! :)


Well, the opinion whether this feature is wonderful or not differs among 
FPC/Delphi users :P


Regards,
Sven

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

Re: [fpc-pascal] [OT] sealed?

2013-10-07 Thread silvioprog 
2013/10/7 Sven Barth 

> On 07.10.2013 20:38, silvioprog wrote:
>
>> 2013/10/7 Sven Barth > >
>>
>> On 07.10.2013 19:29, silvioprog wrote:
>>
>> Hello,
>>
>> I was surfing the internet and came across this structure Delphi:
>>
>>
>> TJSONPair=  class  sealed(TJSONAncestor)
>>
>>
>> So, what is this?
>>
>>
>> Simple: You are not allowed to create child classes of sealed
>> classes (the compiler enforces this). FPC supports this since 2.4.2.
>>
>> Regards,
>> Sven
>>
>>
>> Perfect!
>>
>> It tested it:
>>
>>TBaseClass = class
>>end;
>>
>>TOtherClass = class sealed(TBaseClass)
>>end;
>>
>>TFooClass = class(TOtherClass)
>>end;
>>
>> and:
>>
>> unit1.pas(24,32) Error: Cannot create a descendant of the sealed class
>> "TOtherClass"
>>
>> It is wonderful, thank you very much Sven! :)
>>
>
> Well, the opinion whether this feature is wonderful or not differs among
> FPC/Delphi users :P
>
> Regards,
> Sven
>

:D

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [OT] sealed?

2013-10-07 Thread Dennis Poon 

> It is wonderful, thank you very much Sven! :)


Well, the opinion whether this feature is wonderful or not differs 
among FPC/Delphi users :P


Regards,
Sven

May I know the usual use of such feature?  I can only think of library 
vendors want to seal a class to prevent users from modifying it without 
paying for an upgraded/better version of such class.


Dennis



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


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3408 / Virus Database: 3222/6731 - Release Date: 10/07/13



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

Re: [fpc-pascal] [OT] sealed?

2013-10-07 Thread Dmitry Boyarintsev 
A well written class doesn't need to be sealed. As well as doesn't require
an inheritance.

IIRC, "sealed" was added to delphi language at the time of the delphi
.nettism. Correct me, if I'm wrong but Delphi-net is dead (replaced by
Oxygen, which is not delphi or pascal).
However, since the keyword was introduced in the some point of the
language, the support was provided in the next versions of the Delphi
language/compiler.
Since FPC announces Delphi-compatibility on syntax level, the keyword was
introduced in FPC as well.

Usefulness of the "sealed" (as some other .nettish syntax, i.e. class
helpers) is questionable and further discussion is probably better for
fpc-other list. So feel free to use it for good or bad.

thanks,
Dmitry


On Mon, Oct 7, 2013 at 11:22 PM, Dennis Poon  wrote:

> > It is wonderful, thank you very much Sven! :)
>
>>
>> Well, the opinion whether this feature is wonderful or not differs among
>> FPC/Delphi users :P
>>
>> Regards,
>> Sven
>>
>>  May I know the usual use of such feature?  I can only think of library
> vendors want to seal a class to prevent users from modifying it without
> paying for an upgraded/better version of such class.
>
> Dennis
>
>
>  __**_
>> fpc-pascal maillist  -  
>> fpc-pascal@lists.freepascal.**org
>> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal
>>
>>
>> -
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2013.0.3408 / Virus Database: 3222/6731 - Release Date: 10/07/13
>>
>>
>>  __**_
> fpc-pascal maillist  -  
> fpc-pascal@lists.freepascal.**org
> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [OT] sealed?

2013-10-07 Thread Dmitry Boyarintsev 
Actually, it's useful when used a platform-specific keyword (i.e. for
declaring an external Java-class, which can be finalized).
It was introduced for platform-specific needs (delphi.net), but became a
part of the language.

thanks,
Dmitry



On Tue, Oct 8, 2013 at 12:14 AM, Dmitry Boyarintsev <
skalogryz.li...@gmail.com> wrote:

> A well written class doesn't need to be sealed. As well as doesn't require
> an inheritance.
>
> IIRC, "sealed" was added to delphi language at the time of the delphi
> .nettism. Correct me, if I'm wrong but Delphi-net is dead (replaced by
> Oxygen, which is not delphi or pascal).
> However, since the keyword was introduced in the some point of the
> language, the support was provided in the next versions of the Delphi
> language/compiler.
> Since FPC announces Delphi-compatibility on syntax level, the keyword was
> introduced in FPC as well.
>
> Usefulness of the "sealed" (as some other .nettish syntax, i.e. class
> helpers) is questionable and further discussion is probably better for
> fpc-other list. So feel free to use it for good or bad.
>
> thanks,
> Dmitry
>
>
> On Mon, Oct 7, 2013 at 11:22 PM, Dennis Poon wrote:
>
>> > It is wonderful, thank you very much Sven! :)
>>
>>>
>>> Well, the opinion whether this feature is wonderful or not differs among
>>> FPC/Delphi users :P
>>>
>>> Regards,
>>> Sven
>>>
>>>  May I know the usual use of such feature?  I can only think of library
>> vendors want to seal a class to prevent users from modifying it without
>> paying for an upgraded/better version of such class.
>>
>> Dennis
>>
>>
>>  __**_
>>> fpc-pascal maillist  -  
>>> fpc-pascal@lists.freepascal.**org
>>> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal
>>>
>>>
>>> -
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2013.0.3408 / Virus Database: 3222/6731 - Release Date: 10/07/13
>>>
>>>
>>>  __**_
>> fpc-pascal maillist  -  
>> fpc-pascal@lists.freepascal.**org
>> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal
>>
>
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [OT] sealed?

2013-10-07 Thread Sven Barth 
Am 08.10.2013 05:23 schrieb "Dennis Poon" :
>
> > It is wonderful, thank you very much Sven! :)
>>
>>
>> Well, the opinion whether this feature is wonderful or not differs among
FPC/Delphi users :P
>>
>> Regards,
>> Sven
>>
> May I know the usual use of such feature?  I can only think of library
vendors want to seal a class to prevent users from modifying it without
paying for an upgraded/better version of such class.

That's why I implied that the usefulness is highly debated...

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