Re: [fpc-pascal] will be work macro with name of the unit?

2015-07-15 Thread Michael Van Canneyt



On Tue, 14 Jul 2015, ulrich wrote:


Hi,

I have this unit, but when I compile it, I get this error:

Illegal unit name XXX_Parser. The unit is saved under dfm_rrparser.pas.


The unit name must always match the file name. 
This is logical, because otherwise the compiler can never find it if a reference 
to the unit is made in a uses clause.




Second question:

Why not displayed $INFO directive in the message window (I have enabled -vi 
switch in command line)?


It shows it here:
home: fpc tm.pp -vwi
Target OS: Linux for x86-64
Compiling tm.pp
User defined: compiled with XXX_
tm.pp(10,17) Error: Illegal unit name: XXX_parser
tm.pp(16,16) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/local/bin/ppcx64 returned an error exitcode

So probably a lazarus issue ?

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


Re: [fpc-pascal] will be work macro with name of the unit?

2015-07-15 Thread Pierre Free Pascal
  {$IFDEF FPC}
{$MACRO ON}
{$IFNDEF XXX_}
  {$DEFINE XXX_:=DFM_RR} // replace prefix
{$ENDIF}
  {$ENDIF}
 
  {$INFO compiled with XXX_}
 
  unit XXX_parser;
 
  {$mode objfpc}{$H+}
 
  interface
 
  implementation
 
  end.
 Macros are only expanded on whole tokens (aka words). So XXX_ is
 expanded, but XXX_parser is not. It's the same with C preprocessors by
 the way.

  This is one of the limitation that we have against
C preprocessor macros:
  in C, you would be able to use
$define XXX_parser XXX_ ## parser
so that 
  unit XXX_parser;
would work as you want,
but I don't think that we ever implemented an equivalent 
inside the Free Pascal compiler.
  The other aspect is that, according to Michael's answer,
the information message sent to output is not passed trough
the preprocessor, because it still prints XXX_, and not DFM_RR.
I would qualify this as a feature, not a bug, but others 
might disagree on that.
  This is because the source is parsed by using readcomment method,
which will never try to replace macros.

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


Re: [fpc-pascal] question with interfaces, hooks

2015-07-15 Thread Graeme Geldenhuys
On 2015-07-15 10:21, Sven Barth wrote:
 The property could even be
 protected or private and it should still work as long as the containing
 class has the interface in its parent list.

I thought that would only work if you access the method via an interface
variable, not a class instance variable.

In his sample code fc is a class instance.

I didn't test if his sample code works under Delphi though. Then again,
if I work with Interfaces, I only ever use an interface reference to
call methods of that interface.

Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] question with interfaces, hooks

2015-07-15 Thread Sven Barth
Am 15.07.2015 09:27 schrieb Graeme Geldenhuys 
mailingli...@geldenhuys.co.uk:

 On 2015-07-15 05:06, David Emerson wrote:
  So... since t_fancy_class implements the interface i_foo, why is
  t_fancy_class.foo not available?

 Because you told it a property named hook implements it, so you need
 to call it as follows:

   fc.hook.foo;

implements should avoid the need for this. It merely tells the compiler
to look for methods using that property. The property could even be
protected or private and it should still work as long as the containing
class has the interface in its parent list.

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

Re: [fpc-pascal] will be work macro with name of the unit?

2015-07-15 Thread Sven Barth
Am 15.07.2015 08:21 schrieb ulrich rom...@cbox.cz:

 Hi,

 I have this unit, but when I compile it, I get this error:

 Illegal unit name XXX_Parser. The unit is saved under dfm_rrparser.pas.

 Second question:

 Why not displayed $INFO directive in the message window (I have enabled
-vi switch in command line)?


 {$IFDEF FPC}
   {$MACRO ON}
   {$IFNDEF XXX_}
 {$DEFINE XXX_:=DFM_RR} // replace prefix
   {$ENDIF}
 {$ENDIF}

 {$INFO compiled with XXX_}

 unit XXX_parser;

 {$mode objfpc}{$H+}

 interface

 implementation

 end.

Macros are only expanded on whole tokens (aka words). So XXX_ is expanded,
but XXX_parser is not. It's the same with C preprocessors by the way.

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

Re: [fpc-pascal] question with interfaces, hooks

2015-07-15 Thread Graeme Geldenhuys
On 2015-07-15 05:06, David Emerson wrote:
 So... since t_fancy_class implements the interface i_foo, why is 
 t_fancy_class.foo not available?

Because you told it a property named hook implements it, so you need
to call it as follows:

  fc.hook.foo;


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] will be work macro with name of the unit?

2015-07-15 Thread ulrich

Hi,

I have this unit, but when I compile it, I get this error:

Illegal unit name XXX_Parser. The unit is saved under dfm_rrparser.pas.

Second question:

Why not displayed $INFO directive in the message window (I have enabled 
-vi switch in command line)?



{$IFDEF FPC}
  {$MACRO ON}
  {$IFNDEF XXX_}
{$DEFINE XXX_:=DFM_RR} // replace prefix
  {$ENDIF}
{$ENDIF}

{$INFO compiled with XXX_}

unit XXX_parser;

{$mode objfpc}{$H+}

interface

implementation

end.

Thanks

Roman

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


Re: [fpc-pascal] question with interfaces, hooks

2015-07-15 Thread Sven Barth
Am 15.07.2015 06:07 schrieb David Emerson dle...@angelbase.com:
[snip]
 constructor t_fancy_class.create;
   begin
 inherited;
 f_hook := t_foo_base.create;
   end;

 destructor t_fancy_class.destroy;
   begin
 t_foo_base(f_hook).free;
 inherited;
   end;
[snip]

Not related to your problem, but important nevertheless: you don't need to
free interface variables. They are reference counted an freed automatically
at least if you don't mix a class reference (in your case to t_foo_base)
and interface reference (in your case i_foo) which you shouldn't do anyway
(and which you aren't doing in your example).

I haven't work with delegation much, but you could try to do (fc as
i_foo).foo;. Also you might want to take a look at TAggregatedObject.

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

Re: [fpc-pascal] question with interfaces, hooks

2015-07-15 Thread Sven Barth
Am 15.07.2015 11:51 schrieb Graeme Geldenhuys 
mailingli...@geldenhuys.co.uk:

 On 2015-07-15 10:21, Sven Barth wrote:
  The property could even be
  protected or private and it should still work as long as the containing
  class has the interface in its parent list.

 I thought that would only work if you access the method via an interface
 variable, not a class instance variable.

 In his sample code fc is a class instance.

 I didn't test if his sample code works under Delphi though. Then again,
 if I work with Interfaces, I only ever use an interface reference to
 call methods of that interface.

Ehm yes, as a class instance variable it probably only works using the
property. I'd need to test this in Delphi as well however ;)

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