[fpc-pascal] Implementing an interface force me to add _AddRef, _Release

2010-04-15 Thread Zaher Dirkey
IMyIntf = interface
  function GetValue: Variant;
end;

TMyObject=(TList, IMyIntf)
  
end;

Can not compile becuase it need to add this functions to TMyObject

 function QueryInterface(const iid : tguid;out obj) : longint;stdcall;
 function _AddRef : longint;stdcall;
 function _Release : longint;stdcall;

While i am not inherit IMyIntf from IUnknown or IInterface, Is there a
way to not add unnecessary functions (for me at least).

Sorry for my bad English, and Thanks in advance.

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


Re: [fpc-pascal] Implementing an interface force me to add _AddRef, _Release

2010-04-15 Thread Michael Van Canneyt



On Thu, 15 Apr 2010, Zaher Dirkey wrote:


IMyIntf = interface
 function GetValue: Variant;
end;

TMyObject=(TList, IMyIntf)
 
end;

Can not compile becuase it need to add this functions to TMyObject

function QueryInterface(const iid : tguid;out obj) : longint;stdcall;
function _AddRef : longint;stdcall;
function _Release : longint;stdcall;

While i am not inherit IMyIntf from IUnknown or IInterface, Is there a
way to not add unnecessary functions (for me at least).


All interfaces inherit from IUnknown, unless you use corba interfaces:
{$INTERFACES CORBA}

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


Re: [fpc-pascal] Implementing an interface force me to add _AddRef, _Release

2010-04-15 Thread Zaher Dirkey
On Thu, Apr 15, 2010 at 11:09 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
 {$INTERFACES CORBA}

{$INTERFACES CORBA}

It is resolved my problem, Is there any limit to use it (except it is
not work in Delphi)?

Thank for your replay.

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


Re: [fpc-pascal] Implementing an interface force me to add _AddRef, _Release

2010-04-15 Thread Michael Van Canneyt



On Thu, 15 Apr 2010, Zaher Dirkey wrote:


On Thu, Apr 15, 2010 at 11:09 AM, Michael Van Canneyt
mich...@freepascal.org wrote:

{$INTERFACES CORBA}


{$INTERFACES CORBA}

It is resolved my problem, Is there any limit to use it (except it is
not work in Delphi)?


Not that I know of :-)

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


[fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Graeme Geldenhuys
Hi,

Does FPC include a general purpose object pascal parser we can use
in our own projects? Obviously the FPC compiler itself has a parser,
but is that a free-standing unit or class we can use in other
projects? I know fpdoc needs to parse source code as well, but I don't
know if it uses the same parser as the FPC compiler.

I don't want to create 'yet another object pascal parser', and I can't
use existing Delphi ones, because it needs to support the FPC language
syntax (and support for include files) specifically.

-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Adriaan van Os

Graeme Geldenhuys wrote:

Hi,

Does FPC include a general purpose object pascal parser we can use
in our own projects? Obviously the FPC compiler itself has a parser,
but is that a free-standing unit or class we can use in other
projects? I know fpdoc needs to parse source code as well, but I don't
know if it uses the same parser as the FPC compiler.

I don't want to create 'yet another object pascal parser', and I can't
use existing Delphi ones, because it needs to support the FPC language
syntax (and support for include files) specifically.


Have a look at fpc/packages/passrc.

Regards,

Adriaan van Os

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


Re: [fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Marco van de Voort
In our previous episode, Graeme Geldenhuys said:
 
 Does FPC include a general purpose object pascal parser we can use
 in our own projects? Obviously the FPC compiler itself has a parser,
 but is that a free-standing unit or class we can use in other
 projects? I know fpdoc needs to parse source code as well, but I don't
 know if it uses the same parser as the FPC compiler.

No, it uses fcl-passrc.

A third, more limited parser exists inside ptop and other highlighting and
source beautifying tools.
 
 I don't want to create 'yet another object pascal parser', and I can't
 use existing Delphi ones, because it needs to support the FPC language
 syntax (and support for include files) specifically.

Afaik include files are compatible to Dlephi, except that FPC afaik
recompiles units if they change.  But yes, I agree that on average Delphi
tools don't support comfortably what the delphi compiler suports.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Graeme Geldenhuys
On 15 April 2010 12:58, Marco van de Voort mar...@stack.nl wrote:
 projects? I know fpdoc needs to parse source code as well, but I don't
 know if it uses the same parser as the FPC compiler.

 No, it uses fcl-passrc.

Perfect, thanks. Now my next question is, how up-to-date is the parser
[compared to the FPC parser]? Looking at the repository history for
the fcl-passrc directory, it looks like things are being updated.
February had a large update from Mattias.


 A third, more limited parser exists inside ptop and other highlighting and
 source beautifying tools.

I would prefer to use something included with FPC - that at least
promotes the idea that it will stay updated as new language features
get added to FPC.


-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Michael Van Canneyt



On Thu, 15 Apr 2010, Graeme Geldenhuys wrote:


On 15 April 2010 12:58, Marco van de Voort mar...@stack.nl wrote:

projects? I know fpdoc needs to parse source code as well, but I don't
know if it uses the same parser as the FPC compiler.


No, it uses fcl-passrc.


Perfect, thanks. Now my next question is, how up-to-date is the parser
[compared to the FPC parser]? Looking at the repository history for
the fcl-passrc directory, it looks like things are being updated.
February had a large update from Mattias.


Yes. It now parses the whole of the packages directory.
That was the contract for Mattias.


A third, more limited parser exists inside ptop and other highlighting and
source beautifying tools.


I would prefer to use something included with FPC - that at least
promotes the idea that it will stay updated as new language features
get added to FPC.


This is the idea for passrc.

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


Re: [fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Marco van de Voort
In our previous episode, Graeme Geldenhuys said:
 
  No, it uses fcl-passrc.
 
 Perfect, thanks. Now my next question is, how up-to-date is the parser
 [compared to the FPC parser]? Looking at the repository history for
 the fcl-passrc directory, it looks like things are being updated.
 February had a large update from Mattias.

It roughly works, but there are problematic constructs. IIRC it doesn't
support some of the deprecated options.
 
  A third, more limited parser exists inside ptop and other highlighting and
  source beautifying tools.
 
 I would prefer to use something included with FPC - that at least
 promotes the idea that it will stay updated as new language features
 get added to FPC.

The rest was mentioned to be complete. I think fcl-passrc is the most sane
choice by far, both the parser, and because it is set up as a library.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Michael Van Canneyt



On Thu, 15 Apr 2010, Marco van de Voort wrote:


In our previous episode, Graeme Geldenhuys said:


No, it uses fcl-passrc.


Perfect, thanks. Now my next question is, how up-to-date is the parser
[compared to the FPC parser]? Looking at the repository history for
the fcl-passrc directory, it looks like things are being updated.
February had a large update from Mattias.


It roughly works, but there are problematic constructs. IIRC it doesn't
support some of the deprecated options.


That has been fixed in trunk meanwhile, I think.

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


Re: [fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Graeme Geldenhuys
Marco van de Voort het geskryf:
 
 It roughly works, but there are problematic constructs. IIRC it doesn't
 support some of the deprecated options.

:-)  Isn't that a good thing. After all, something marked as deprecated can
be removed at any time. The parser simply promotes the idea of cleaning up
your code. ;-)


Thanks to all that replied, I'll definitely use fcl-passrc in my project.
And looking at fpdoc source code, I have a nice example of how to use it too.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

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


Re: [fpc-pascal] FPC Object Pascal parser?

2010-04-15 Thread Marco van de Voort
In our previous episode, Graeme Geldenhuys said:
  
  It roughly works, but there are problematic constructs. IIRC it doesn't
  support some of the deprecated options.
 
 :-)  Isn't that a good thing. After all, something marked as deprecated can
 be removed at any time. The parser simply promotes the idea of cleaning up
 your code. ;-)

Hmm, I'd rather call that an extremely bad thing, since deprecated is mainly
useful for documentation. Moreover, if that were the case, the compiler
should forbid that, not the doc parser.

Seriously however, these are exceptions, rather than the rule. Mattias fixed
really a lot. Except maybe all the constructs recently added to FPC. (Paul's
D2006 features, case of string etc). 

If I understand Michael's remarks, about what Mattias goals were, correctly,
that's logical, since those features are not used in packages/
 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Initializing a record-type variable to get rid of the false-positive compiler hint

2010-04-15 Thread Bart
 FillByte(oSearchOptions, SizeOf(oSearchOptions), 0);

oSearchOptions := []; //It's an empty set

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


Re: [fpc-pascal] Initializing a record-type variable to get rid of the false-positive compiler hint

2010-04-15 Thread Bihar Anwar
Thanks Bart, forget my silly comments before, you did it cleverly.



- Original Message 
From: Bart bartjun...@gmail.com
To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
Sent: Thu, April 15, 2010 10:02:33 PM
Subject: Re: [fpc-pascal] Initializing a record-type variable to get rid of  
the false-positive compiler hint

 FillByte(oSearchOptions, SizeOf(oSearchOptions), 0);

oSearchOptions := []; //It's an empty set

Bart
___
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[2]: [fpc-pascal] Initializing a record-type variable to get rid of the false-positive compiler hint

2010-04-15 Thread José Mejuto
Hello FPC-Pascal,

Thursday, April 15, 2010, 6:43:41 AM, you wrote:

BA Thanks for your reply José, but what is the philosophy behind
BA the solution? and What are the reasons for $PUSH and $POP? Also, I
BA tried to remove the $HINTS directive, and it worked fine without
BA it. Could you explain this?

Rec parameter is qualified as out so, the enter values is
non-important and the compiler will not generate the non initialized
hint.

The $PUSH pushes in fpc stack the current settings about hints,
warnings, alignement, etc, then I change the hints to off, because
FillByte could produce (not sure with formal parameter) the hint
message and then $POP restores previous settings about hints and other
directives.

-- 
Best regards,
 José

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


Re: Re[2]: [fpc-pascal] Initializing a record-type variable to get rid of the false-positive compiler hint

2010-04-15 Thread Bihar Anwar
Thank you very much Jose, that's a detail explanation. Forget my wrong 
observation before.



- Original Message 
From: José Mejuto joshy...@gmail.com
To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
Sent: Thu, April 15, 2010 10:11:03 PM
Subject: Re[2]: [fpc-pascal] Initializing a record-type variable to get rid of 
the false-positive compiler hint

Hello FPC-Pascal,

Thursday, April 15, 2010, 6:43:41 AM, you wrote:

BA Thanks for your reply José, but what is the philosophy behind
BA the solution? and What are the reasons for $PUSH and $POP? Also, I
BA tried to remove the $HINTS directive, and it worked fine without
BA it. Could you explain this?

Rec parameter is qualified as out so, the enter values is
non-important and the compiler will not generate the non initialized
hint.

The $PUSH pushes in fpc stack the current settings about hints,
warnings, alignement, etc, then I change the hints to off, because
FillByte could produce (not sure with formal parameter) the hint
message and then $POP restores previous settings about hints and other
directives.

-- 
Best regards,
José

___
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] nested procedure as parameter question

2010-04-15 Thread Bruce Bauman
I am porting a large amount of existing Pascal code (MetaWare) to Free
Pascal. Unfortunately, this code makes extensive use of nested
procedures, and the nested procedures often reference variables in the
enclosing scope.

I know that I can't pass the nested routine by address to another
procedure; I get errors like the following:

intjob4_intday.pas(400,47) Error: Incompatible type for arg no. 3: Got
address of local procedure(StdStr04);Register, expected procedure
variable type of procedure(StdStr04);Register

Can I get around this restriction by inlining the procedure which is
being passed the nested procedure as an argument?

For example, let's say the A is the enclosing procedure, B is the nested
procedure, and B is being passed as a parameter to C.

Procedure A;
Procedure B;

Begin
C(@B);
End;

Can I inline procedure C? Will this work? (My initial test with fpc
2.4.0 suggests it doesn't work).

-- Bruce
CONFIDENTIALITY NOTICE: This e-mail is confidential and intended
solely for the use of the individual or entity to which it is addressed.  If
you are not the intended recipient, be advised that you have received 
this email in error and that any use, dissemination, forwarding, printing 
or copying of this e-mail is strictly prohibited. If you received this e-mail
in error, please delete it from your computer and contact the sender.

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


Re: [fpc-pascal] nested procedure as parameter question

2010-04-15 Thread Flávio Etrusco
On Thu, Apr 15, 2010 at 2:51 PM, Bruce Bauman
bruce.bau...@andesaservices.com wrote:
 I am porting a large amount of existing Pascal code (MetaWare) to Free
 Pascal. Unfortunately, this code makes extensive use of nested
 procedures, and the nested procedures often reference variables in the
 enclosing scope.

 I know that I can't pass the nested routine by address to another
 procedure; I get errors like the following:

 intjob4_intday.pas(400,47) Error: Incompatible type for arg no. 3: Got
 address of local procedure(StdStr04);Register, expected procedure
 variable type of procedure(StdStr04);Register

 Can I get around this restriction by inlining the procedure which is
 being passed the nested procedure as an argument?

 For example, let's say the A is the enclosing procedure, B is the nested
 procedure, and B is being passed as a parameter to C.

 Procedure A;
    Procedure B;

 Begin
    C(@B);
 End;

 Can I inline procedure C? Will this work? (My initial test with fpc
 2.4.0 suggests it doesn't work).

 -- Bruce

I don't think this will work, but why didn't you try it? It would be
very nice if the nested procedures which don't access outside vars
were allowed to be used as non-local procedure...

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


Re: [fpc-pascal] Implementing an interface force me to add _AddRef, _Release

2010-04-15 Thread Marc Weustink

Zaher Dirkey wrote:

On Thu, Apr 15, 2010 at 11:09 AM, Michael Van Canneyt
mich...@freepascal.org wrote:

{$INTERFACES CORBA}


{$INTERFACES CORBA}

It is resolved my problem, Is there any limit to use it (except it is
not work in Delphi)?


You cannot use casts like
var
  a: IMyObject;
  b: IMyOtherObject;
begin
  b := a as IMyOtherObject;

or functions like supports() (which uses queryinterface)

Marc

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


RE: [fpc-pascal] nested procedure as parameter question

2010-04-15 Thread Bruce Bauman
I did try it, and I got the same error message from the compiler. However, I 
can't be sure if the compiler didn't allow inlining for some other reason.

BTW, it would be nice if there were some equivalent to gcc's pragma 
inline_only(?) which says that the procedure MUST be inlined (or an error is 
generated).

-- Bruce

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Flávio Etrusco
Sent: Thursday, April 15, 2010 1:57 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] nested procedure as parameter question

On Thu, Apr 15, 2010 at 2:51 PM, Bruce Bauman
bruce.bau...@andesaservices.com wrote:
 I am porting a large amount of existing Pascal code (MetaWare) to Free
 Pascal. Unfortunately, this code makes extensive use of nested
 procedures, and the nested procedures often reference variables in the
 enclosing scope.

 I know that I can't pass the nested routine by address to another
 procedure; I get errors like the following:

 intjob4_intday.pas(400,47) Error: Incompatible type for arg no. 3: Got
 address of local procedure(StdStr04);Register, expected procedure
 variable type of procedure(StdStr04);Register

 Can I get around this restriction by inlining the procedure which is
 being passed the nested procedure as an argument?

 For example, let's say the A is the enclosing procedure, B is the nested
 procedure, and B is being passed as a parameter to C.

 Procedure A;
    Procedure B;

 Begin
    C(@B);
 End;

 Can I inline procedure C? Will this work? (My initial test with fpc
 2.4.0 suggests it doesn't work).

 -- Bruce

I don't think this will work, but why didn't you try it? It would be
very nice if the nested procedures which don't access outside vars
were allowed to be used as non-local procedure...

Flávio
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
CONFIDENTIALITY NOTICE: This e-mail is confidential and intended
solely for the use of the individual or entity to which it is addressed.  If
you are not the intended recipient, be advised that you have received 
this email in error and that any use, dissemination, forwarding, printing 
or copying of this e-mail is strictly prohibited. If you received this e-mail
in error, please delete it from your computer and contact the sender.

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


[fpc-pascal] Published - Public

2010-04-15 Thread José Mejuto
Hello FPC-Pascal,

If I have a class like:

TMyClassPublished=class(TObject)
published
  procedure MyProcedure; virtual;
end;

And a derived one:

TMyClassDerived=class(TMyClassPublished)
public
  procedure MyProcedure; override;
end;

Is there any difference in the derived one with less visibility in the
method ? This means, does it use less/more memory, more/less calling
speed, more/less RTTI information, ... ?

Thank you.

-- 
Best regards,
 José

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


Re: [fpc-pascal] Published - Public

2010-04-15 Thread Marc Weustink

José Mejuto wrote:

Hello FPC-Pascal,

If I have a class like:

TMyClassPublished=class(TObject)
published
  procedure MyProcedure; virtual;
end;

And a derived one:

TMyClassDerived=class(TMyClassPublished)
public
  procedure MyProcedure; override;
end;

Is there any difference in the derived one with less visibility in the
method ? This means, does it use less/more memory, more/less calling
speed, more/less RTTI information, ... ?


no, no, no, no

You cannot lower visibility, since the following example is still possible:

var
  a:TMyClassPublished;
begin
  a := TMyClassDerived.Create;
  a.MyProcedure;
end;

it will use the scope of a and not the redefined scope in TMyClassDerived

Marc

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


Re[2]: [fpc-pascal] Published - Public

2010-04-15 Thread José Mejuto
Hello FPC-Pascal,

Thursday, April 15, 2010, 11:57:01 PM, you wrote:

 TMyClassPublished=class(TObject)
 published
   procedure MyProcedure; virtual;
 end;
 And a derived one:
 TMyClassDerived=class(TMyClassPublished)
 public
   procedure MyProcedure; override;
 end;
 Is there any difference in the derived one with less visibility in the
 method ? This means, does it use less/more memory, more/less calling
 speed, more/less RTTI information, ... ?
MW no, no, no, no
MW You cannot lower visibility, since the following example is still possible:
MW var
MWa:TMyClassPublished;
MW begin
MWa := TMyClassDerived.Create;
MWa.MyProcedure;
MW end;
MW it will use the scope of a and not the redefined scope in TMyClassDerived

That was exactly my suspect, but as RTTI was in the game, maybe some
differences happend.

I had found this visibility lower warnings all along the LCLfpgui
interface, so I think I will move them to the expected published
level as parent TWSxxx classes.

-- 
Best regards,
 José

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