Re: [fpc-pascal] Const attributes

2017-07-30 Thread Marcos Douglas B. Santos 
On Sun, Jul 30, 2017 at 5:47 PM, Sven Barth via fpc-pascal
 wrote:
> On 30.07.2017 20:55, Marcos Douglas B. Santos wrote:
>>
>> I would like to instantiate my attribute only once inside constructor
>> and then it will be "const" or "final", I mean, immutable.
>> Today it is not possible, right? Any thoughts to the future?
>
> With the JVM platform support for final fields was added (modeswitch
> finalfields), but that is currently only available for external classes
> (which only exist for the JVM target) as the DFA can't handle that
> correctly currently.
> (though if one would restrict the assignments to the constructors itself
> without any methods called by the constructor then we might be able to
> implement that nevertheless, don't know what Java or other languages
> with final fields allow here)

It would be great to use "modeswitch finalfields" in all possible modes.

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

Re: [fpc-pascal] Const attributes

2017-07-30 Thread Sven Barth via fpc-pascal 
On 30.07.2017 20:55, Marcos Douglas B. Santos wrote:
> On Sun, Jul 30, 2017 at 1:46 PM, Maciej Izak  wrote:
>> 2017-07-30 18:37 GMT+02:00 Marcos Douglas B. Santos :
>>>
>>> 1. Is this by design?
>>
>>
>> Yes. To disallow this you need to use {$J-} directive.
> 
> I know that we can use this "hack" in local functions/methods, but in
> an attribute... What is the goal to use it?

$J affects all kinds of constants no matter whether they are global,
inside a routine or inside a type. Though it seems that this is broken
as the compiler allows an assignment nevertheless... *sigh*

>>>
>>> 2. Is there a way to declare attributes "final" like Java does?
>>
>>
>> No for constants.
> 
> I would like to instantiate my attribute only once inside constructor
> and then it will be "const" or "final", I mean, immutable.
> Today it is not possible, right? Any thoughts to the future?

With the JVM platform support for final fields was added (modeswitch
finalfields), but that is currently only available for external classes
(which only exist for the JVM target) as the DFA can't handle that
correctly currently.
(though if one would restrict the assignments to the constructors itself
without any methods called by the constructor then we might be able to
implement that nevertheless, don't know what Java or other languages
with final fields allow here)

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

Re: [fpc-pascal] Const attributes

2017-07-30 Thread Howard Page-Clark via fpc-pascal 

On 30/07/17 19:55, Marcos Douglas B. Santos wrote:

I would like to instantiate my attribute only once inside constructor
and then it will be "const" or "final", I mean, immutable.
Today it is not possible, right? Any thoughts to the future?

It is not what you are asking for, but you can do this:

===code begin===
{$J-}
const
  INT: Integer = 9;

type

  TFoo = class
  strict private
function GetINT: Integer;
  public
property INT: Integer read GetINT;
  end;

function TFoo.GetINT: Integer;
begin
  Exit(INT);
end;
===code end===

The INT property is 'immutable' because it is read-only, and you cannot 
assign to its typed integer referent because of the {$J-}.

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

Re: [fpc-pascal] Const attributes

2017-07-30 Thread Marcos Douglas B. Santos 
On Sun, Jul 30, 2017 at 1:46 PM, Maciej Izak  wrote:
> 2017-07-30 18:37 GMT+02:00 Marcos Douglas B. Santos :
>>
>> 1. Is this by design?
>
>
> Yes. To disallow this you need to use {$J-} directive.

I know that we can use this "hack" in local functions/methods, but in
an attribute... What is the goal to use it?

>>
>> 2. Is there a way to declare attributes "final" like Java does?
>
>
> No for constants.

I would like to instantiate my attribute only once inside constructor
and then it will be "const" or "final", I mean, immutable.
Today it is not possible, right? Any thoughts to the future?

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

Re: [fpc-pascal] Const attributes

2017-07-30 Thread Maciej Izak 
2017-07-30 18:37 GMT+02:00 Marcos Douglas B. Santos :

> 1. Is this by design?
>

Yes. To disallow this you need to use {$J-} directive.


> 2. Is there a way to declare attributes "final" like Java does?
>

No for constants.

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Const attributes

2017-07-30 Thread Marcos Douglas B. Santos 
The following code is compilable.
I'm using a private const with type defined and I can change it in the
constructor.

1. Is this by design?
2. Is there a way to declare attributes "final" like Java does?

=== begin ===
type
  TFoo = class
  private
const INT: Integer = 0;
  public
constructor Create;
  end;

implementation

constructor TFoo.Create;
begin
  INT := 9;
end;

end.
=== end ===

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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

2017-07-30 Thread Sven Barth via fpc-pascal 
Am 30.07.2017 12:37 schrieb "Bo Berglund" :
>
> On Sun, 30 Jul 2017 09:33:59 +0200, Sven Barth via fpc-pascal
>  wrote:
>
> >> The application was started back in Delphi7 times when "string"
> >> actually meant AnsiString and was a 1-byte per element container.
> >
> >You could always use RawByteString or a string with a fixed codepage
> >instead if plain AnsiString.
>
> I asked about this problem over at Embarcadero too, but was flamed for
> even thinking about using any kind of string for storing binary data.
> THeyn did suggest RawByteString too, though so I went over the
> application changing all buffers to RawByteString and it did work.
> I also tried to set a fixed codepage for the application, but it is
> hard to check if it actually does help.

Not a fixed codepage for the application, but a string with fixed codepage,
e.g. "String(CP_1242)" or so...

> The root problem is what happens with string conversions on different
> locales and some functions could not be easily modified to use
> RawByteString.
> So I decided to bite the bullet and convert the whole unit to TBytes
> instead. Some 7000 code lines to go over...
>
> It has taken a good many hours now and I still have some intricate
> problems to solve. It still won't compile without errors.
>
> >
> >Just declare a type alias so that you can keep it compatible with older
> >Delphi versions as well.
> >
>
> Do you mean:
> type
>   TMyString = RawByteString;

Yes.

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

Re: [fpc-pascal] XML: Differences between Delphi and FPC

2017-07-30 Thread Marcos Douglas B. Santos 
On Sun, Jul 30, 2017 at 5:06 AM, Michael Van Canneyt
 wrote:
>
>
> On Sat, 29 Jul 2017, Marcos Douglas B. Santos wrote:
>
>> FPC/Lazarus always tried stay compatible with Delphi... thus, why the
>> FPC XML classes is so different than Delphi classes?
>
>
> Because the FPC classes predate the Delphi classes. They were based directly
> on the W3 DOM specifications.

Ah, now it is clear.
I use XML classes in Delphi since version 4~5, whether I remember
correctly. I didn't know that FPC XML was older.

> The interfaces are needed only because Delphi uses the MS XML library, which
> is interface based. Since FPC does not use the MS XML library, it has no
> need of the interfaces.

Well, we can use interfaces even if we're not working with MS libraries.
Interfaces and ref-count helps a lot but... anyway.

> If I remember correctly, the WST project has a wrapper for delphi which acts
> like the FPC version. It's called wst_delphi_xml.

I saw. There are some alias and functions:
  TDOMNode = IDOMNode;
  TDOMNodeList = IDOMNodeList;
  //...
  function FindNode(ANode : TDOMNode; const ANodeName : string):TDOMNode;
  function GetNodeItemsCount(const ANode : TDOMNode): Integer;
  //...

I can do the same using interfaces and objects, providing just one API
for the users, no matter they are Delphi or FPC programmers.
Thanks for the tip, anyway.

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

Re: [fpc-pascal] XML: Differences between Delphi and FPC

2017-07-30 Thread Marcos Douglas B. Santos 
On Sun, Jul 30, 2017 at 4:30 AM, Sven Barth via fpc-pascal
 wrote:
>> I have a FPC/Lazarus project that will be compatible with Delphi. I
>> would like to know whether I need to create wrappers to encapsulate
>> the differences between them or there is a simple way to do that.
>>
>> A 3rd lib could be an option too.
>
> You could provide wrappers that provide the same interfaces as the Delphi
> ones backed by FPC's library...

I'll probably do it. Thanks.

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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

2017-07-30 Thread Bo Berglund 
On Sun, 30 Jul 2017 09:33:59 +0200, Sven Barth via fpc-pascal
 wrote:

>> The application was started back in Delphi7 times when "string"
>> actually meant AnsiString and was a 1-byte per element container.
>
>You could always use RawByteString or a string with a fixed codepage
>instead if plain AnsiString.

I asked about this problem over at Embarcadero too, but was flamed for
even thinking about using any kind of string for storing binary data.
THeyn did suggest RawByteString too, though so I went over the
application changing all buffers to RawByteString and it did work.
I also tried to set a fixed codepage for the application, but it is
hard to check if it actually does help.

The root problem is what happens with string conversions on different
locales and some functions could not be easily modified to use
RawByteString.
So I decided to bite the bullet and convert the whole unit to TBytes
instead. Some 7000 code lines to go over...

It has taken a good many hours now and I still have some intricate
problems to solve. It still won't compile without errors.

>
>Just declare a type alias so that you can keep it compatible with older
>Delphi versions as well.
>

Do you mean:
type
  TMyString = RawByteString;


-- 
Bo Berglund
Developer in Sweden

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

Re: [fpc-pascal] XML: Differences between Delphi and FPC

2017-07-30 Thread Michael Van Canneyt 



On Sat, 29 Jul 2017, Marcos Douglas B. Santos wrote:


Hi,

FPC/Lazarus always tried stay compatible with Delphi... thus, why the
FPC XML classes is so different than Delphi classes?


Because the FPC classes predate the Delphi classes. 
They were based directly on the W3 DOM specifications.




Delphi XML is interface-based. There exists IXMLDocument, IXMLNode and so on.
FPC has just classes.


The interfaces are needed only because Delphi uses the MS XML library, which
is interface based. Since FPC does not use the MS XML library, it has no
need of the interfaces.



I have a FPC/Lazarus project that will be compatible with Delphi. I
would like to know whether I need to create wrappers to encapsulate
the differences between them or there is a simple way to do that.


If I remember correctly, the WST project has a wrapper for delphi which acts
like the FPC version. It's called wst_delphi_xml.

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

Re: [fpc-pascal] XML: Differences between Delphi and FPC

2017-07-30 Thread Sven Barth via fpc-pascal 
Am 30.07.2017 09:30 schrieb "Sven Barth" :
>
> Am 30.07.2017 02:01 schrieb "Marcos Douglas B. Santos" :
> >
> > Hi,
> >
> > FPC/Lazarus always tried stay compatible with Delphi... thus, why the
> > FPC XML classes is so different than Delphi classes?

Addendum: FPC's XML library probably also comes from a time when Delphi
didn't have a standard library to deal with XML.

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

Re: [fpc-pascal] XML: Differences between Delphi and FPC

2017-07-30 Thread Sven Barth via fpc-pascal 
Am 30.07.2017 02:01 schrieb "Marcos Douglas B. Santos" :
>
> Hi,
>
> FPC/Lazarus always tried stay compatible with Delphi... thus, why the
> FPC XML classes is so different than Delphi classes?
>
> Delphi XML is interface-based. There exists IXMLDocument, IXMLNode and so
on.
> FPC has just classes.

Of I remember correctly IXMLDocument and the others are based on
Microsoft's XML library. The authors of FPC's XML library probably didn't
want to feel restricted by that.

> I have a FPC/Lazarus project that will be compatible with Delphi. I
> would like to know whether I need to create wrappers to encapsulate
> the differences between them or there is a simple way to do that.
>
> A 3rd lib could be an option too.

You could provide wrappers that provide the same interfaces as the Delphi
ones backed by FPC's library...

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

[fpc-pascal] BlockWrite of dynamic arrays

2017-07-30 Thread Bo Berglund 
I am converting older code to move from AnsiString to TBytes as
non-text data container. While doing it I am using conditionals so I
don't destroy the working code until I have verified that the TBytes
usage is OK.

Now I have encountered use of BlockWrite where I would like to do the
following:

1) Change variable definitions from

F: File of AnsiChar;
{$IFDEF USE_ANSISTRING}
Buffer: AnsiString;
{$ENDIF}

to
F: File;
{$ELSE IFDEF USE_TBYTES}
Buffer: TBytes;
{$ENDIF}

2) Specifically set the record length to 1 using
Reset(F, 1);
and
Rewrite(F,1)

3) Change the BlockWrite command from
BlockWrite(F, Buffer[1], Length(Buffer));
to
BlockWrite(F, Buffer, Length(Buffer));

Note that I would like to *not* specify the index of the first element
of the array so that the same code can work for both cases depending
on conditional setting.
But I am worried that Buffer will reference a different memory
location than Buffer[0].

So are these two calls equivalent when Buffer is an AnsiString or a
TBytes array:
BlockWrite(F, Buffer[0], Length(Buffer));
BlockWrite(F, Buffer, Length(Buffer));


-- 
Bo Berglund
Developer in Sweden

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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

2017-07-30 Thread Bo Berglund 
On Fri, 28 Jul 2017 16:35:05 +0200, Michael Schnell
 wrote:

>On 25.07.2017 10:54, Bo Berglund wrote:
>>   so I need to write efficient replacements for certain string functions 
>> (Delete, Insert, Copy etc).
>Why do you think the string function (if using strictly just a single 
>UTF-8 or RawByte branded String type) are not efficient ?
>
>If all string encoding brands in an operation are the same there will be 
>no conversion.

Sorry,
I was not clear in my question...

What I meant to say is that I need to convert an existing application
that uses strings (AnsiString) as binary data buffers to instead use
TBytes buffers. Thus my quest is for functions operating like the
convenient string functions but on TBytes arrays.

All of this is because I have found that using AnsiString is
triggering data changes when the application is running in certain
countries (locales) and processing certain data values...

The application was started back in Delphi7 times when "string"
actually meant AnsiString and was a 1-byte per element container.

By efficient I meant that I probably would write inefficient code if I
had to create things like the mentioned functions myself and if the
compiler did the job it would be more efficient.


-- 
Bo Berglund
Developer in Sweden

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