[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] Initialization in Shared Libraries

[Mazola Winstrol]

2016-04-13 15:56 GMT-03:00 Jonas Maebe :

>
> And hence you can just initialise those variables in the initialization
> section of the library and finalize them (if necessary) in the finalization
> section of the library.
>
>
Thanks!

Can i use class constructors in shared libraries? Does unit's
initialization section and class constructors have the same behaviour in
all platforms and the same when compared with a normal program?

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 15:52 GMT-03:00 Michael Van Canneyt <mich...@freepascal.org>:

>
>
> On Wed, 13 Apr 2016, Mazola Winstrol wrote:
>
> Hello list,
>>
>> I writting a cross-platform shared library (.dll, .so). I need to
>> initialize some global variables.
>>
>> As the free pascal doesn't support library events (PROCESS_ATTACH,
>> PROCESS_DETACH), what is the correct to way to do this?
>>
>
> It does, but it catches them in the system unit; I do not think they are
> exposed.
>
>
So, what is the correct way to initialize global variables? In a normal
program i can use unit's initialization section or class constructors. But
the documentation is not clear about the the case of shared libraries.

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

[fpc-pascal] Initialization in Shared Libraries

[Mazola Winstrol]

Hello list,

I writting a cross-platform shared library (.dll, .so). I need to
initialize some global variables.

As the free pascal doesn't support library events (PROCESS_ATTACH,
PROCESS_DETACH), what is the correct to way to do this?

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

Re: [fpc-pascal] Implicit Operator Overloading

[Mazola Winstrol]

2016-03-07 3:53 GMT-03:00 Sven Barth <pascaldra...@googlemail.com>:

> Am 06.03.2016 22:09 schrieb "Mazola Winstrol" <mazofei...@gmail.com>:
> >
> > Hello,
> >
> > Fpc: 3.0
> >
> > Should the compiler to allow the definition of two operator overloading
> with the same parameters and diferent result types?
> >
> > e.g:
> >
> >  code 
> >
> >   TMyRecord record
> >  class operator Implicit(A: TMyRecord): Real;
> >  class operator Implicit(A: TMyRecord): Integer;
> >   end;
> >
> >  end 
> >
> > The code above doesn't compile. Error: function is already declared
> Public/Forward operator.
>
> Would you please test with trunk? I thought I had fixed that... If it
> doesn't work there either then please report as well.
>
> Regards,
> Sven
>
>
Tested with the trunk version of the build 2016/04/10 (i dont know the
revision number. i used the fcup tool to build). It works.

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

Re: [fpc-pascal] Framework for Objects Serialization / Deserialization

[Mazola Winstrol]

2016-04-01 3:46 GMT-03:00 Michael Van Canneyt <mich...@freepascal.org>:

>
>
> On Fri, 1 Apr 2016, Mazola Winstrol wrote:
>
> Hello list,
>>
>> Is there a fpc framework for or some standard to serialize / deserialize
>> classes and other custom types?
>>
>
> At least two units offer the base for such functionality:
> jsonrtti (fcl-json) and restbase (fcl-web)
>
> And obviously any TComponent can be streamed in the Delphi-native format.
>
>
Thanks for your reply Michael.

I can't change the actual hierarchical structure of my classes so i can't
use TComponent.

I can serialize custom types (e.g records) using fcl-json?

Delphi do have an intersting way to do with serialization: they have some
standard classes (TTypeMashaller, TConverter). If one wants to serialize to
a new format (e.g binary format), one can extended those base classes and
implement such serialization. Would be interesting if we create an
infrastructure like that.

http://docwiki.embarcadero.com/RADStudio/Seattle/en/Serializing_User_Objects
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Framework for Objects Serialization / Deserialization

[Mazola Winstrol]

Hello list,

Is there a fpc framework for or some standard to serialize / deserialize
classes and other custom types?

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

Re: [fpc-pascal] Fpc 3.0 Bug: type specialization and operator overload

[Mazola Winstrol]

2016-03-12 21:45 GMT-03:00 Sven Barth :

> It does not treat them the same, it simply picks the wrong one (as in
> "doesn't correctly respect the unit qualifier"). You should see a different
> (yet no less wrong) behavior if you turn around the units in the
> uses-clause.
>
> Please report.
>
> Regards,
> Sven
>
>
Done. #0029859. 


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

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-03-11 0:15 GMT-03:00 silvioprog <silviop...@gmail.com>:

> On Sun, Mar 6, 2016 at 7:21 PM, Mazola Winstrol <mazofei...@gmail.com>
> wrote:
> [...]
>
>> Please see the code in attachments and send your suggestions / remarks.
>>
>
> Thanks for share.
>
> How do I use the the NullableTypes.String unit?
>
> Tried:
>
> program project1;
>
> {$mode objfpc}{$H+}
>
> uses NullableTypes.String;
>
> begin
> end.
>
> Got:
>
> Fatal: Syntax error, "identifier" expected but "STRING" found
>
>
I will fix the unit names, as suggested by Sven and Michael.

The approach i used doesn't work with the current fpc 3.0 release due to
some bugs in the compiler (#0029859
<http://bugs.freepascal.org/view.php?id=29859>  and #0029792
<http://bugs.freepascal.org/view.php?id=29792>).

Please wait for the fixes. I will send a new version here.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Fpc Bug 3.0: Generics and Operator Overloading

[Mazola Winstrol]

2016-03-06 19:48 GMT-03:00 Mazola Winstrol <mazofei...@gmail.com>:


> Done. Issued as #0029792. <http://bugs.freepascal.org/view.php?id=29387>
>
>
The link is wrong. =)

Issued here: #0029792 <http://bugs.freepascal.org/view.php?id=29792>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Fpc Bug 3.0: Generics and Operator Overloading

[Mazola Winstrol]

2016-03-06 17:45 GMT-03:00 Sven Barth :

> Yes, that's a bug. Please report.
>
> Regards,
> Sven
>
>
Done. Issued as #0029792. 

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

[fpc-pascal] Implicit Operator Overloading

[Mazola Winstrol]

Hello,

Fpc: 3.0

Should the compiler to allow the definition of two operator overloading
with the same parameters and diferent result types?

e.g:

 code 

  TMyRecord record
 class operator Implicit(A: TMyRecord): Real;
 class operator Implicit(A: TMyRecord): Integer;
  end;

 end 

The code above doesn't compile. Error: function is already declared
Public/Forward operator.


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

[fpc-pascal] Fpc Bug: Type specialization with Generics and Operator Overloading in Diferent Units

[Mazola Winstrol]

Hello,

Fpc version: 3.0 (the same included with lazarus 1.6).


Please confirm if it is a bug:

If i declare a generic record with overloaded add operation, i need to
specialize the type in the same unit for the compiler recognize the
overloading.

=== Code ===

unit MyRecordDefinition;

{$mode delphi}

interface

type
  TMyRecord = record
 class operator Add(A,B: TMyRecord): TMyRecord;
  end;

implementation

class operator TMyRecord.Add(A,B: TMyRecord): TMyRecord;
begin

end;

end.

..


Unit MyRecordSpecialization;

{$mode delphi}

interface

uses
  MyRecordDefinition;

type
  TInteger = TMyRecord;

implementation

procedure TestIfCompiles;
var
  N1, N2: NullableInteger;
begin
  N1 := N2 + N2; // DOESN'T COMPILE: Operator is not overloaded: TMyRecord
+ TMyRecord
end;


end.


 END 



To get this code compiled, i need to move the specialized type TInteger to
the same unit where the generic type TMyRecord is declared.



 code ===

unit MyRecordDefinition;

{$mode delphi}

interface

type
  TMyRecord = record
 class operator Add(A,B: TMyRecord): TMyRecord;
  end;

  TInteger = TMyRecord;

implementation

class operator TMyRecord.Add(A,B: TMyRecord): TMyRecord;
begin

end;

end.

..


Unit MyRecordSpecialization;

{$mode delphi}

interface

uses
  MyRecordDefinition;

implementation

procedure TestIfCompiles;
var
  N1, N2: NullableInteger;
begin
  N1 := N2 + N2; // DOESN'T COMPILE: Operator is not overloaded: TMyRecord
+ TMyRecord
end;


end.


=== END 


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

[fpc-pascal] Fpc Bug 3.0: Generics and Operator Overloading

[Mazola Winstrol]

Hello,

Fpc version: 3.0 (the one included with Lazarus 1.6).

Please confirm if it is a bug: it seems the compiler doesn't handle
operator overloading properly when using generic record with local
specializations.


= Code =

unit Test;

{$mode delphi}

type
  TMyRecord = record
class operator Add(A,B: TMyRecord): TMyRecord;
  end;

implementation

class operator TMyRecord.Add(A,B: TMyRecord): TMyRecord;
begin
// add implementation
end;


procedure TestIfCompiles;
type
  TInteger = TMyRecord;
var
  N1, N2: TInteger;
begin
  N1 := N2 + N2;  /// DOES NOT COMPILE: Operator is not overloaded:
TMyRecord + TMyRecord
end;

 END =



To compile this code, move the declarion of the type TInteger to the global
scope, as follows:



= Code =

unit Test;

{$mode delphi}

type
  TMyRecord = record
class operator Add(A,B: TMyRecord): TMyRecord;
  end;

   TInteger = TMyRecord;


implementation

class operator TMyRecord.Add(A,B: TMyRecord): TMyRecord;
begin
// add implementation
end;


procedure TestIfCompiles;
var
  N1, N2: TInteger;
begin
  N1 := N2 + N2;
end;

 END =


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

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-03-02 23:12 GMT-03:00 silvioprog <silviop...@gmail.com>:

> On Tue, Mar 1, 2016 at 12:08 AM, Mazola Winstrol <mazofei...@gmail.com>
> wrote:
> [...]
>>
>> I apologize, it works.
>>
>
> Do you have plan to share it in some place like Github, Lazarus-CCR or as
> Lazarus generics demo? Just a idea, because this implementation sounds good.
>
>
Yes, sure! I dont know where to place yet. What you suggests?

I will send to list the final version in the next days for discussion.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-03-01 10:07 GMT-03:00 Constantine Yannakopoulos :

>
> The only solution I have found is to implement ALL operators for
> TNullableType by defining a generic interface INullableOperatiors
> that contains methods for all operators, then implement for each type by
> means of manual interface implementation and then delegate each class
> operator implementation to the corresponding implementation using RTTI of
> the generic parameter T like in Delphi's Generics.Defaults and
> IComparer/IEqualityComparer. This way the implementation of an
> operator not supported for a specific type (e.g. negation for strings) will
> raise an exception.
>
> It's a rather tedious task though and I abandoned it half way and I'm sure
> Sven would object to such an implementation as it involves manual
> interfaces. I can send you the unfinished Delphi unit via private email if
> you want.
>
>

Can you send me?

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

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-03-01 1:48 GMT-03:00 <wkitt...@windstream.net>:

> On 02/29/2016 10:08 PM, Mazola Winstrol wrote:
>
>> There is a problem in my design. The code won't compile if i try to
>> specialize with a type which doesn'y supports arithmetic operators e.g
>> String
>> types.
>>
>
> apparently i'm missing something... why should arithmetic operators be
> recognized for strings? that doesn't make sense? arithmetic operators are
> for numerics not strings...
>
>
The operator shouldn't be recognized for strings. The problem is that we
are using a generic record for defining a nullable type. So, we can't make
a subclass to define operators applicable only for numeric types.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-03-01 9:13 GMT-03:00 Sven Barth <pascaldra...@googlemail.com>:

> Am 01.03.2016 04:08 schrieb "Mazola Winstrol" <mazofei...@gmail.com>:
> > Is there any way to overcome this? Is there any way to tell the compiler
> to ignore some operators depending on the specialization type?
>
> No, there is not. Better not use operators other than the assignment ones
> or provide different Nullable types for different purposes (that maybe can
> be assigned to each other).
>

The problem is type the same structures for the various nullable types.
Perhaps, a "ugly" solution would be:


= code =

{$mode delphi}

{$DEFINE typename:=TSimpleNullableType}
typename = record
strict private
   {$INCLUDE commonprivatedefinition.inc}
public
   {$INCLUDE commonprivatedefinition.inc}
end;

{$DEFINE typename:=TArithmeticNullableType}
typename = record
strict private
   {$INCLUDE commonprivatedefinition.inc}
public
   {$INCLUDE commonprivatedefinition.inc}
   class operator Negative(A: TArithmeticNullableType): T;
end;

 code ==

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

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-02-29 13:16 GMT-03:00 Sven Barth <pascaldra...@googlemail.com>:

> Am 29.02.2016 16:13 schrieb "Mazola Winstrol" <mazofei...@gmail.com>:
> >
> > I have noticed that, by using generics, we can't overload arithmetic
> operators.
> >
> > E.g.:
> >
> > ...
> > class operator Negative(A: TNullableType): T;
> > ...
> >
> > class operator TNullableType.Negative(A: TNullableType): T;
> > begin
> > Result := -1 * A;
> > end;
> > 
> >
> > wouldn't compile with the error "Operator not applicable to this operand
> type".
> >
> > Is there any workaround to overcome this?
>
> As far as I am concerned that *should* work. If it does not, then it's a
> bug. Please file a bug report with a simple example program.
>
> Regards,
> Sven
>
I apologize, it works.


There is a problem in my design. The code won't compile if i try to
specialize with a type which doesn'y supports arithmetic operators e.g
String types.


 code 

{$mode delphi}

  TNullableType = record
  private
FValue: T;
  public
class operator Negative(A: TNullableType): T;
  end;

  TString = TNullableType;

.

class operator TNullableType.Negative(A: TNullableType): T;
begin
  Result := -1 * A.FValue;
end;


=== code 

Compilation error: "Operator is not overloaded: "ShortInt" * "AnsiString" ";


Is there any way to overcome this? Is there any way to tell the compiler to
ignore some operators depending on the specialization type?

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

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

I have noticed that, by using generics, we can't overload arithmetic
operators.

E.g.:

...
class operator Negative(A: TNullableType): T;
...

class operator TNullableType.Negative(A: TNullableType): T;
begin
Result := -1 * A;
end;


wouldn't compile with the error "Operator not applicable to this operand
type".

Is there any workaround to overcome this?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-02-27 14:58 GMT-03:00 silvioprog :

>
> $MODE DELPHI implies {$H ON}
> , so so you
> should remove the {$H+}.
>
>
Thanks for the tip! i will remove for the next version.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-02-27 0:49 GMT-03:00 Dmitry Boyarintsev <skalogryz.li...@gmail.com>:

> On Fri, Feb 26, 2016 at 10:38 PM, Mazola Winstrol <mazofei...@gmail.com>
> wrote:
>
>> In the code bellow, the generic type TNullableTyple is implemented (and
>> incomplete for now).
>>
> How to reset TNullableType to Null value? HasValue seems to be read-only.
>

In the last version, there is two ways:

var
   NullInt: TNullable;
begin
   NullInt.Clear; // Method 1
   NullInt := nil; // Method 2
end;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

I've implemented a new version. For this version i created a mock class to
use with FHasValue (the previous implementation uses a hack to the
interface internal layout).


unit NullableTypes;

{$mode delphi}{$H+}

interface

type

  { TMockInterfacedObject }

  TMockInterfacedObject = class(TObject, IUnknown)
  strict private
class var FInstance: TMockInterfacedObject;
  public
class constructor Create;
class destructor Destroy;
class property Instance: TMockInterfacedObject read FInstance;
function QueryInterface({$IFDEF
FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF} iid : tguid;out obj) :
longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
function _AddRef: longint; {$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
function _Release: longint; {$IFNDEF
WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
  end;

  { TNullable }

  TNullable = record
  strict private
FValue: T;
FHasValue: IInterface;
function GetValue: T;
function GetHasValue: Boolean;
procedure SetValue(const AValue: T);
procedure SetFlatInterface(var Intf: IInterface);
  public
constructor Create(const AValue: T);
procedure Clear;
function GetValueOrDefault: T; overload;
function GetValueOrDefault(Default: T): T; overload;
property HasValue: Boolean read GetHasValue;
property Value: T read GetValue;

class operator Implicit(const AValue: Pointer): TNullable;
class operator Implicit(AValue: TNullable): T;
class operator Implicit(const AValue: T): TNullable;
class operator Explicit(AValue: TNullable): T;
  end;


  TInteger = TNullable;

implementation

uses
  SysUtils;

{ TNullable }

procedure TNullable.SetFlatInterface(var Intf: IInterface);
begin
  Intf := TMockInterfacedObject.Instance;
end;

class operator TNullable.Explicit(AValue: TNullable): T;
begin
  Result := AValue.Value;
end;

function TNullable.GetHasValue: Boolean;
begin
  Result := FHasValue <> nil;
end;

function TNullable.GetValue: T;
begin
  if not HasValue then
raise Exception.Create('Invalid operation, Nullable type has no value');
  Result := FValue;
end;

function TNullable.GetValueOrDefault: T;
begin
  if HasValue then
Result := FValue
  else
   Result := Default(T);
end;

function TNullable.GetValueOrDefault(Default: T): T;
begin
  if not HasValue then
Result := Default
  else
Result := FValue;
end;

class operator TNullable.Implicit(const AValue: Pointer): TNullable;
begin
  if AValue = nil then
Result.Clear
  else
raise Exception.Create('Invalid operation, incompatible values.');
end;

class operator TNullable.Implicit(AValue: TNullable): T;
begin
  Result := AValue.Value;
end;

class operator TNullable.Implicit(const AValue: T): TNullable;
begin
  Result := TNullable.Create(AValue);
end;

procedure TNullable.SetValue(const AValue: T);
begin
  FValue := AValue;
  SetFlatInterface(FHasValue);
end;

constructor TNullable.Create(const AValue: T);
begin
  FValue := AValue;
  SetFlatInterface(FHasValue);
end;

procedure TNullable.Clear;
begin
  FHasValue := nil;
end;

{ TMockInterfacedObject }

class constructor TMockInterfacedObject.Create;
begin
  FInstance := TMockInterfacedObject.Create;
end;

class destructor TMockInterfacedObject.Destroy;
begin
  FInstance.Free;
end;

function TMockInterfacedObject.QueryInterface({$IFDEF
FPC_HAS_CONSTREF}constref
  {$ELSE}const{$ENDIF} iid : tguid;out obj): longint;
begin
  Result := E_NOINTERFACE;
end;

function TMockInterfacedObject._AddRef: longint;
begin
  Result := -1;
end;

function TMockInterfacedObject._Release: longint;
begin
  Result := -1;
end;

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

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

Hello,

In the code bellow, the generic type TNullableTyple is implemented (and
incomplete for now).

Is there any possibility of "nullable types" be added to RTL or anyother
fpc provided package?


unit NullableTypes;

{$mode delphi}{$H+}

interface

type

  { TNullable }

  TNullable = record
  strict private
FValue: T;
FHasValue: IInterface;
function GetValue: T;
function GetHasValue: Boolean;
procedure SetValue(const AValue: T);
procedure SetFlatInterface(var Intf: IInterface);
  public
constructor Create(const AValue: T);
function GetValueOrDefault: T; overload;
function GetValueOrDefault(Default: T): T; overload;
property HasValue: Boolean read GetHasValue;
property Value: T read GetValue;

class operator Implicit(AValue: TNullable): T;
class operator Implicit(const AValue: T): TNullable;
class operator Explicit(AValue: TNullable): T;
  end;

  TInteger = TNullable;


function NopAddref(inst: Pointer): Integer; stdcall;
function NopRelease(inst: Pointer): Integer; stdcall;
function NopQueryInterface(inst: Pointer; const IID: TGUID; out Obj):
HResult;

const
  FlagInterfaceVTable: array[0..2] of Pointer =
  (
@NopQueryInterface,
@NopAddref,
@NopRelease
  );
  FlagInterfaceInstance: Pointer = @FlagInterfaceVTable;

implementation

uses
  SysUtils;



function NopAddref(inst: Pointer): Integer; stdcall;
begin
  Result := -1;
end;

function NopRelease(inst: Pointer): Integer; stdcall;
begin
  Result := -1;
end;

function NopQueryInterface(inst: Pointer; const IID: TGUID; out Obj):
HResult;
stdcall;
begin
  Result := E_NOINTERFACE;
end;

{ TNullable }

procedure TNullable.SetFlatInterface(var Intf: IInterface);
begin
  Intf := IInterface(@FlagInterfaceInstance);
end;

class operator TNullable.Explicit(AValue: TNullable): T;
begin
  Result := AValue.Value;
end;

function TNullable.GetHasValue: Boolean;
begin
  Result := FHasValue <> nil;
end;

function TNullable.GetValue: T;
begin
  if not HasValue then
raise Exception.Create('Invalid operation, Nullable type has no value');
  Result := FValue;
end;

function TNullable.GetValueOrDefault: T;
begin
  if HasValue then
Result := FValue
  else
   Result := Default(T);
end;

function TNullable.GetValueOrDefault(Default: T): T;
begin
  if not HasValue then
Result := Default
  else
Result := FValue;
end;

class operator TNullable.Implicit(AValue: TNullable): T;
begin
  Result := AValue.Value;
end;

class operator TNullable.Implicit(const AValue: T): TNullable;
begin
  Result := TNullable.Create(AValue);
end;

procedure TNullable.SetValue(const AValue: T);
begin
  FValue := AValue;
  SetFlatInterface(FHasValue);
end;

constructor TNullable.Create(const AValue: T);
begin
  FValue := AValue;
  SetFlatInterface(FHasValue);
end;

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

Re: [fpc-pascal] Variable Initialization Questions

[Mazola Winstrol]

2016-02-18 18:38 GMT-02:00 Jonas Maebe <jonas.ma...@elis.ugent.be>:

> Mazola Winstrol wrote:
>
>> Just to clarify: if i have a record type with a pointer field, this
>> field will always zeroed?
>>
>
> No. As mentioned, all global variables are always zeroed. The type doesn't
> matter. Local variables are never zeroed, except if they are managed types.
> A pointer is not a managed type.
>
>
>
May i add a remark about the behavior of managed types in the
documentation?

http://www.freepascal.org/docs-html/current/ref/refse23.html#x55-730004.4

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

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-02-20 3:24 GMT-02:00 Michalis Kamburelis :

> The major problem there is that it's difficult to force it to be
> always initialized with zeroes. Currently, a non-global variable of
> unmanaged type can always be filled with memory garbage, as explained
> in other thread. The trick in
> http://blogs.embarcadero.com/abauer/2008/09/18/38869 to use interfaces
> feels ugly, it's an over-use of the "interface" specifics in Object
> Pascal.
>
>
A less "ugly" code could be to store the pointer value in an array of bytes
(TBytes). As the TBytes type is a managed type, it will always be
initialized.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Variable Initialization Questions

[Mazola Winstrol]

2016-02-17 15:16 GMT-02:00 Jonas Maebe :

> Jonas Maebe wrote:
>
>> 3 - When i declare a pointer as a global variable or as a member of a
>>> record, can i assume that its initial value is nil?
>>>
>>
>> No.
>>
>
> Correction: all global variables are always zeroed, so that includes
> pointers, records and hence also pointers in records (if those records
> themselves are global variables). Pointers, records or record fields in are
> not zeroed because they are pointers/records/record fields though (so not
> in case they are local variables).


Just to clarify: if i have a record type with a pointer field, this field
will always zeroed?

e.g

type
   TMyRecord = record
   private
 FMyPointer: Pointer;
   public
 property MyPointer: Pointer read FMyPointer;
   end;

..

procedure ShowMyPointerValue;
var
  MyRecord: TMyRecord;
begin
  writeln('My pointer value: ' + IntToStr(Integer(MyRecord.MyPointer)));
end;

end.


is correct to say that the above code will always print 'My pointer value:
0'?

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

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

Em 18/02/2016 10:12, "Marco van de Voort" <mar...@stack.nl> escreveu:
>
> In our previous episode, Mazola Winstrol said:
> >end;
> >
> >
> > Suppose that this class represent data of the Person table in a sql
> > database. Suppose that there is records where the column "BirthDate" is
> > null. How do i represent a null "BirthDate" in my object?
>
> Keep using variants instead of typed data.
>

I think this is not a good alternative. As the variant are untyped, should
the consumers of the person class assume that BirthDate are filled as a
formated date string '01/01/1980' or as a native tdatetime?

I think it would be better using record wrappers to primitive types. See
http://blogs.embarcadero.com/abauer/2008/09/18/38869.

What do you think about that?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

2016-02-18 8:00 GMT-02:00 leledumbo :

> > What do you think about it? Is there any other solution?
>
> There's a reason why
> http://www.freepascal.org/docs-html/3.0.0/fcl/db/tfield.isnull.html is
> invented
>
>
You didnt understand my point. Design classes coupled with DB framework is
not a solution.

In the following class


type
   TPerson = class(TObject)
   private
  FId: Integer;
  FName: String;
  FBirthDate: TDateTime;
   public
  property Id: Integer read FId write FId;
  property Name: String read FName write FName;
  property BirthDate: TDateTime read FBirthDate write FBirthDate;
   end;


Suppose that this class represent data of the Person table in a sql
database. Suppose that there is records where the column "BirthDate" is
null. How do i represent a null "BirthDate" in my object?

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

[fpc-pascal] Primitive Record Wrappers

[Mazola Winstrol]

Hello list,

In some situations, would be very interesting to determine whether the
value of a primitive variable is initialized or not. For example, fields in
database records can contain null values. By implementing an ORM, it would
be interesting to represent these null values in the properties of objects.

Java has the so called Primitives Class Wrappers, where each primitive type
(int, boolean ...) has a corresponding wrapper class (Integer, Boolean ...). By
using class wrappers you can represent null values in primitive types
through null class instances references.

Using class wrappers in FPC is not feasible due to memory management issues
(the programmer needs to worry about the lifetime of the instances and free
the instances manually).

Perhaps, a solution in FPC would be using primitive record wrappers with
custom records operators.

What do you think about it? Is there any other solution?

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

[fpc-pascal] Variable Initialization Questions

[Mazola Winstrol]

Hello List,

After googled and searching in the documentation,

http://free-pascal-general.1045716.n5.nabble.com/does-Advanced-Record-constructor-automatically-zero-all-the-memory-space-of-that-record-td5716755.html
http://www.freepascal.org/docs-html/ref/refse23.html

i still have doubts about variable initialization:

1 - Does the compiler automatically initialize all class fields when a new
instance is created?
2 - Does the compiler initialize record fields?
3 - When i declare a pointer as a global variable or as a member of a
record, can i assume that its initial value is nil?
4 - Is there any compiler switch regarding initialization of variables?

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

Re: [fpc-pascal] IfThen() intrinsic removed

[Mazola Winstrol]

2016-02-04 18:41 GMT-02:00 Felipe Monteiro de Carvalho <
felipemonteiro.carva...@gmail.com>:

> Disappointed :(
>
> Why was it done? I thought that pretty much everyone was in favor?
>
>
Due to the fact that we like flame, flame and flame


> It isn't very pascalish, that's true, but we could implement it like
> the proposed "inline if A then B else C" syntax... which is very
> pascalish and cool.
>
>
Lets wait for the Delphi implementation so, we will not start a new flame.

The same applies to the ARC objects.

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

Re: [fpc-pascal] IfThen() intrinsic removed

[Mazola Winstrol]

2016-02-04 19:13 GMT-02:00 Felipe Monteiro de Carvalho <
felipemonteiro.carva...@gmail.com>:

> On Thu, Feb 4, 2016 at 7:03 PM, Mazola Winstrol <mazofei...@gmail.com>
> wrote:
> > Lets wait for the Delphi implementation so, we will not start a new
> flame.
>
> You mean like "wait 5-10 years until they decide independently that
> they want to do it" or are there serious plans for Delphi to support
> this, say, in the next version?
>
> I mean we are not able to introduce new features to the compiler if these
features do not exists in Delphi. We prefer flame.



> > The same applies to the ARC objects.
>
> What's that?
>
>
Reference-counted objects. Class instances are counted by reference so, this
feature eliminates the need to manually manage memory with the
try...finally blocks to free objects from the memory.

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

Re: [fpc-pascal] FPC 3.0.0-rc2 release

[Mazola Winstrol]

I'm about to start a new project. Do you recommend to use the release
candidate version or the stable 2.6.4?

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

[fpc-pascal] Automatic Reference Counting Classes

[Mazola Winstrol]

Hello,

Sometime ago Sven have reported to the list he was working in a proof of
concept mechanism to implement ARC in FPC, a feature similar to the
Objective-C's ARC.

What's the current status of this work? Is it planned to be released in
some futture release of FPC (e.g 3.2)?

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