Re: [fpc-pascal] private type and type compatibility

[Xiangrong Fang]

2013/10/30 Martin 

>
> Since the type is part of value, and the value is public, all of the type
> that is accessed through the value is available.
> Same as you can access a private field through a public property.
>

Access a private variable via public property is analogous to function​​
calls, isn't it?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Xiangrong Fang]

2013/10/30 Jonas Maebe 

>
> This is not equivalent. A private type declaration in a class adds a new
> identifier that is visible inside that class. You then use it, still in
> that class, to declare the return type of a function. Next, in a scope
> where that type identifier is no longer visible, you call the function.
>
> My example is a complete match to that scenario as far as identifier
> visibility is concerned (you use a type in a scope where it is visible to
> declare a function return type, and then call the function in a scope where
> it is not visible). In your example, the type is not visible in the place
> where the function is declared but only where it is defined
> ​.
>

​This is logically WRONG. Because to the machine, any function return value
can be seen as an array of bytes, for example, a pointer is array[0..3] of
Byte on a 32-bit machine.  The purpose of type system is to explain what
these bytes stands for. So, if a type is out-of-scope, how do you interpret
the data?​

The current "delphi compatible" implementation IS using the type
information to compile the program, i.e. although it is not visible, it is
indeed used by the compile, which, in my opinion, violates visibility rules.

Standing on your view point, if a type is no longer visible, but a variable
(function return value) of that type is in current scope, and understood by
the program, this means, this value itself carries type information!  Is is
kind of meta data available in Pascal? If so, I think RTTI should work for
ANY kind of primitive data types.

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

Re: [fpc-pascal] same routine with different parameters?

[waldo kitty]

On 10/30/2013 5:18 AM, Sven Barth wrote:

Am 29.10.2013 20:32, schrieb waldo kitty:

On 10/29/2013 1:56 PM, Sven Barth wrote:

Am 29.10.2013 18:21 schrieb "waldo kitty" :
 > example:  procedure MyObject.MyRoutine;
 >   procedure MyObject.MyRoutine(VarA : SomeType);
 >   procedure MyObject.MyRoutine(VarA : string; VarB: integer);

[...]

Note: In mode Delphi and a few other cases (e.g. cross unit overloads,
inheritance) you'll need to add the "overload" directive.


ahhh... i believe that the library i'm using does use mode delphi all over the
place... do i add "overload;" to each of the 'duplicate' routines?

Yes.


yes, i did have to add "overload;" to both declarations... so far, tests show 
that this is working as desired... the original with no parameters is called and 
it calls itself with no parameters like it always has and my version calls 
itself with parameters as desired... it looks good...


i just wish that i had been able to do the inheritance thing so that i didn't 
have to modify the original object to add another variable and my custom 
routine... i guess i should try that again and see why... IIRC, it had to do 
with an object that is assigned as an internal routine not being registered or 
such... the compiler message i recall was about registration...



For additional information please look at the language reference guide (can't
look up the link currently).


i don't even know what to search for... although 'overload' may give me a
start...


It seems that overloading is only mentioned here:
http://www.freepascal.org/docs-html/ref/refse79.html#x163-17300014.5


yeah, i found that and i think one other but wasn't too sure i was on a proper 
track at that time...



--
NOTE: No off-list assistance is given without prior approval.
  Please keep mailing list traffic on the list unless
  private contact is specifically requested and granted.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

[Dmitry Boyarintsev]

On Wed, Oct 30, 2013 at 3:45 PM, Marco van de Voort  wrote:

> What if unitaa needs recompilation, and it is not in the dir it was
> originally
> compiled in. .\some\other\place then has a different meaning.
>
> Specially if the relative paths are short (like ..\src\ or so), there is
> still
> quite some room for clashes.
>
> That is probably the reason it is mainly used in the DPR, there relative
> paths can be interpreted relative to the .dpr, and .dpr's are generally not
> recompiled in other directories.
>

Definitely, that's not the way to go. Since a unit source can rarely be
adequate to the compilation environment.

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

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

[Marco van de Voort]

In our previous episode, Dmitry Boyarintsev said:
> I guess, technically it should be possible to use two different units with
> the same name.
> 
> I recall there was a discussion a while (few years) ago, about (re)using
> Delphi introduced 'in' syntax (afaik, it is not available in pascal).
> uses
>   unitA in 'unitA.pas'
>   ,unitAA in '.\some\other\place\unitA.pas'
> Don't remember what was the conclusion of the conversation.
> Yet again, this "in" solution is only allowed at either "program" or
> "library" units.

What if unitaa needs recompilation, and it is not in the dir it was originally
compiled in. .\some\other\place then has a different meaning.

Specially if the relative paths are short (like ..\src\ or so), there is still
quite some room for clashes. 

That is probably the reason it is mainly used in the DPR, there relative
paths can be interpreted relative to the .dpr, and .dpr's are generally not
recompiled in other directories.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

[Dmitry Boyarintsev]

On Wed, Oct 30, 2013 at 1:35 PM, Marcos Douglas  wrote:

> IMO, the problem is:
> You can not use two unit with the same name.
> So, you can point -- using -Fu -- which unit the compiler will compile
> but you can't used both at the same project.
>

I guess, technically it should be possible to use two different units with
the same name.

I recall there was a discussion a while (few years) ago, about (re)using
Delphi introduced 'in' syntax (afaik, it is not available in pascal).
uses
  unitA in 'unitA.pas'
  ,unitAA in '.\some\other\place\unitA.pas'
Don't remember what was the conclusion of the conversation.
Yet again, this "in" solution is only allowed at either "program" or
"library" units.

But from the compiler's perspective, if there're two units with the same
name, it would need to solve two problems:
1) decide the rules on what units are using what unit of these 2. (That's
why it was proposed to introduce an extension to -Fu or some other switch)
2) decide about the "object name" for each unit. "UnitA" for the first unit
and "UnitA_1" for the second one (taking into consideartion that there's no
UnitA_1.pas file used)
Linker is not using an "hierarchy" of files, so each object file should be
using a unique name.

It should not be a problem for compiler to do that, unless "precompiled"
object files are used.
Since actual object file name collides, then it just won't work, unless
object file itself is modified to produce unique names.

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

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

[Marcos Douglas]

On Tue, Oct 29, 2013 at 5:05 PM, Dmitry Boyarintsev
 wrote:
> On Tue, Oct 29, 2013 at 3:50 PM, Marcos Douglas  wrote:
>>
>> Yes, works... but the language allow hide the unit name and nobody
>> uses unit name as an identifier in 99% of cases, Am I right? So,
>> problems can be happen.
>>
> From my experience I'd say no.
> I actually had to use the explicit unit name in probably 2% of the code.
> Back from Delphi days: some of the functions between WinAPI (windows.pas)
> and VCL (sysutils.pas) are actually using the same name.
> So specifying the exact unit name is required to get the code compiled
> properly.
> There were some collisions on MacOSX (carbon) type names with LCL type
> names.
> So it's not that unrare thing to happen.
>
> And as you've given example above. If I'm writing a unit that uses two
> separate units with the same identifiers reused, I'd recommend to specify a
> unit name explicitly. (Just not to rely on a compiler doing it right for
> you).
> uses
>   windows, graphics;
>
> var
>   wb : Windows.TBitmap;
>   gb : Graphics.TBitmap.
>
> or
>
> uses
>   windows, graphics;
>
> type  // declare once, use everywhere
>   TWindowsBitmap = Windows.TBitmap;
>   TGraphicsBitmap = Graphics.TBitmap;
>
>
> var
>   wb : TWindowsBitmap;
>   gb : TGraphicsBitmap.
>
> thanks,
> Dmitry

Yep, this is a good tip if you have a couple of types and works.
But, if you have two or more units that have many types and/or
functions that have the same name, then this job -- create an alias --
is boring. I had this problem just one time in my life, I confess, but
happened.

But, little collisions happen easily -- using procedures/functions is
more easy -- because, as you said, we only use the unit name as a
prefix (2% code) only if we know, previously, that we should use.

I guess I will not convince you, right? :)
That's Ok.

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

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

[Marcos Douglas]

On Tue, Oct 29, 2013 at 4:51 PM, Dmitry Boyarintsev
 wrote:
> On Tue, Oct 29, 2013 at 8:02 AM, Marcos Douglas  wrote:
>>
>> You didn't understand.
>> The namespace we talk about is like a "dinamic namespace". The
>> programmer can choose which "names" he will use in your projects when
>> these projects are using third-party frameworks.
>> In Java, eg, you can change the path of frameworks, changing the
>> "namespace", without change the original sources.
>
> I thought I did, but named it differently.
> Isn't what you're trying to explain is suggestion #3 at this page?
> http://wiki.freepascal.org/Namespaces

Yes.

> Instead of modifying the code (i.e. by switching to namespaces)
> You would like to give then compiler a hint what unit should be used when
> compiling a unit.
>
> In other words, you'd like to unit-specific -Fu, that should override the
> project -Fu.
> Right? or am I still misunderstanding.

IMO, the problem is:
You can not use two unit with the same name.
So, you can point -- using -Fu -- which unit the compiler will compile
but you can't used both at the same project.

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

Re: [fpc-pascal] SqlDB fails under Windows to create a new Firebird database

[waldo kitty]

On 10/30/2013 8:13 AM, Graeme Geldenhuys wrote:

Here is the console output of when I run the program.

---
c:\programming\m2_system\Scripts>makedb -d
'127.0.0.1:c:\programming\data\m2_dl_3019.fdb'
Creating database... '127.0.0.1:c:\programming\data\m2_dl_3019.fdb'
exception at 00431BD8:
  : CreateDB :
  -I/O error during "open" operation for file ""
  -database or file exists.
---

I'm using FPC 2.6.2 32-bit on Windows 2000. Any clues what is wrong? And why
does this code work on Linux and FreeBSD. Also, even though the error mentions
the fact that the "database or file exits", that is definitely NOT true. There
is no existing *.fdb file.


what happens if you leave the drive designation (c:) out?

--
NOTE: No off-list assistance is given without prior approval.
  Please keep mailing list traffic on the list unless
  private contact is specifically requested and granted.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Jonas Maebe]

On 30 Oct 2013, at 15:00, Sven Barth wrote:


Am 30.10.2013 14:37, schrieb Jonas Maebe:


"Private" is just another way to define a scope, just like a unit  
interface and implementation define a scope. Neither the "private"  
section nor the interface of unit "u1" is in scope when the  
"hidden" type is used.
Using an interface uses as the analog for private types is flawed in  
my opinion. The analog code would more like this:


=== code begin ===

unit u2;

interface

function f: tdynarray;

implementation

type
 tdynarray = array of integer;

function f: tdynarray;
begin

end;

end.

=== code end ===

Which of course does not compile.


This is not equivalent. A private type declaration in a class adds a  
new identifier that is visible inside that class. You then use it,  
still in that class, to declare the return type of a function. Next,  
in a scope where that type identifier is no longer visible, you call  
the function.


My example is a complete match to that scenario as far as identifier  
visibility is concerned (you use a type in a scope where it is visible  
to declare a function return type, and then call the function in a  
scope where it is not visible). In your example, the type is not  
visible in the place where the function is declared but only where it  
is defined.



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

Re: [fpc-pascal] private type and type compatibility

[Martin]

On 30/10/2013 13:49, Xiangrong Fang wrote:

2013/10/30 Martin mailto:laza...@mfriebe.de>>


I think there is no problem with:

var
  a: array of Integer
begin
  A:= obj.proc;

You are NOT using the type. You are using the value.


pascal is strong-typed.  You are actually using type along with its 
value.  e.g.


var
  a: array of Double;
begin
  a := obj.proc;

This will emit a COMPILE time error because compiler know these 2 
types are not compatible.




Yes. But what I mean is, your code does not refer to the type directly.

Since the type is part of value, and the value is public, all of the 
type that is accessed through the value is available.

Same as you can access a private field through a public property.

However the type itself (as referenced by the identifier in the type 
declaration), that is the type without a value, is not used by your code.

You do not declare a new variable of that type.

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

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 30.10.2013 14:37, schrieb Jonas Maebe:


On 30 Oct 2013, at 14:30, Xiangrong Fang wrote:


2013/10/30 Jonas Maebe 

The tdynarray type is not visible in the program because u1 is not 
in its
uses clause (it's not in scope whatsoever), and nevertheless there 
is no

problem to use it. It's of course not exactly the same (tdynarray isn't
declared as private to u1), but at the scope visibility level it is the
same situation as far as I am concerned.


​I don't think they are the same.  tdynarray​
is not usable in main program because you did not uses u1, NOT 
because the

type is defined as PRIVATE!


"Private" is just another way to define a scope, just like a unit 
interface and implementation define a scope. Neither the "private" 
section nor the interface of unit "u1" is in scope when the "hidden" 
type is used.
Using an interface uses as the analog for private types is flawed in my 
opinion. The analog code would more like this:


=== code begin ===

unit u2;

interface

function f: tdynarray;

implementation

type
  tdynarray = array of integer;

function f: tdynarray;
begin

end;

end.

=== code end ===

Which of course does not compile. The same should be the case for 
private type declarations used in public ones...


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

Re: [fpc-pascal] private type and type compatibility

[Jonas Maebe]

On 30 Oct 2013, at 14:49, Xiangrong Fang wrote:

pascal is strong-typed.  You are actually using type along with its  
value.

e.g.

var
 a: array of Double;
begin
 a := obj.proc;​​

This will emit a COMPILE time error because compiler know these 2  
types are

not compatible.


No, it does not cause an error. Pascal indeed does not use structural  
compatibility for record/object/class types (two record/object/class  
types with exactly the same fields are not assignment-compatible), but  
for other types such as integer/float types (because of implicit  
conversion) and arrays you have more "cross-type" compatibility.



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

Re: [fpc-pascal] Powtils: lightwebserver, lightwebserver2 or lightwebserver3?

[silvioprog]

2013/10/30 Graeme Geldenhuys 

> On Tuesday 29/10/2013 at 18:19, John Lee  wrote:
>
>> Is this assessment valid for win or linux or both? J
>>
>
> I use both equally, and for the 32-bit and 64-bit platforms.
>
> Regards,
>  Graeme
>

+1.

-- 
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] private type and type compatibility

[Xiangrong Fang]

2013/10/30 Martin 

>
> I think there is no problem with:
>
> var
>   a: array of Integer
> begin
>   A:= obj.proc;
>
> You are NOT using the type. You are using the value.
>

pascal is strong-typed.  You are actually using type along with its value.
 e.g.

var
  a: array of Double;
begin
  a := obj.proc;​​

This will emit a COMPILE time error because compiler know these 2 types are
not compatible.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Xiangrong Fang]

2013/10/30 Sven Barth 

> It's a bit annoying that the usage private/protected types in
> public/published functions is allowed... (this is however Delphi
> compatible) Maybe this should be adjusted for non-Delphi modes for language
> consistency... (maybe at least as a warning which could be elevated to an
> error if someone wants)
>

​Alternatively, consider do NOT allow access modifiers for NESTED types,
instead, the visibility of nested types follow the class they are embeded
in.  Anyway, what is the purpose of HIDE a nested type?

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

Re: [fpc-pascal] private type and type compatibility

[Martin]

On 30/10/2013 13:30, Xiangrong Fang wrote:
2013/10/30 Jonas Maebe >


The tdynarray type is not visible in the program because u1 is not
in its uses clause (it's not in scope whatsoever), and
nevertheless there is no problem to use it. It's of course not
exactly the same (tdynarray isn't declared as private to u1), but
at the scope visibility level it is the same situation as far as I
am concerned.


I don't think they are the same.  tdynarray
 is not usable in main program because you did not uses u1, NOT 
because the type is defined as PRIVATE!


As a matter of fact, if you define tdynarray as private (not in 
interface section), there is no way you can use it as a return type of 
an exported (public) function. This is a very consistent scoping rule!


In my example, if the code is like this:

generic TVector = class
private type
  TDataType = array of T;
private
  function proc: TDataType;
end;

Then I think it is ok, because this PRIVATE type is used by PRIVATE 
function.


What do you think?


I think there is no problem with:

var
  a: array of Integer
begin
  A:= obj.proc;

You are NOT using the type. You are using the value.


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

Re: [fpc-pascal] private type and type compatibility

[Jonas Maebe]

On 30 Oct 2013, at 14:30, Xiangrong Fang wrote:


2013/10/30 Jonas Maebe 

The tdynarray type is not visible in the program because u1 is not  
in its
uses clause (it's not in scope whatsoever), and nevertheless there  
is no
problem to use it. It's of course not exactly the same (tdynarray  
isn't
declared as private to u1), but at the scope visibility level it is  
the

same situation as far as I am concerned.


​I don't think they are the same.  tdynarray​
is not usable in main program because you did not uses u1, NOT  
because the

type is defined as PRIVATE!


"Private" is just another way to define a scope, just like a unit  
interface and implementation define a scope. Neither the "private"  
section nor the interface of unit "u1" is in scope when the "hidden"  
type is used.



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

Re: [fpc-pascal] Re: SqlDB fails under Windows to create a new Firebird database

[Michael Van Canneyt]

On Wed, 30 Oct 2013, Graeme Geldenhuys wrote:




I haven't tested what happens if you specify a path under Windows that 
contain spaces, but will test it later. I would imagine quotes must be used, 
but not sure how yet.


AFAIK: Windows doesn't know single quotes, you need to use double quotes.

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

Re: [fpc-pascal] private type and type compatibility

[Xiangrong Fang]

2013/10/30 Jonas Maebe 

> The tdynarray type is not visible in the program because u1 is not in its
> uses clause (it's not in scope whatsoever), and nevertheless there is no
> problem to use it. It's of course not exactly the same (tdynarray isn't
> declared as private to u1), but at the scope visibility level it is the
> same situation as far as I am concerned.


​I don't think they are the same.  tdynarray​
 is not usable in main program because you did not uses u1, NOT because the
type is defined as PRIVATE!

​As a matter of fact, if you define tdynarray as private (not in interface
section), there is no way you can use it as a return type of an exported
(public) function. ​This is a very consistent scoping rule!

In my example, if the code is like this:

generic TVector = class
private type
  TDataType = array of T;
private
  function proc: TDataType;
end;

Then I think it is ok, because this PRIVATE type is used by PRIVATE
function.

What do you think?

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

[fpc-pascal] Re: SqlDB fails under Windows to create a new Firebird database

[Graeme Geldenhuys]

Here is the console output of when I run the program.

---

c:\programming\m2_system\Scripts>makedb -d 
'127.0.0.1:c:\programming\data\m2_dl_3019.fdb'

Creating database... '127.0.0.1:c:\programming\data\m2_dl_3019.fdb'
exception at 00431BD8:
: CreateDB :
-I/O error during "open" operation for file ""
-database or file exists.
---


Ah, found the problem. In Windows it seems you mustn't wrap the -d 
command line parameter value with quotes. Removing the single quotes 
in the above command line fixed the problem. Linux and FreeBSD didn't 
mind the quoted string value.




c:\programming\m2_system\Scripts>makedb -d 
127.0.0.1:c:\programming\data\m2_dl_3019.fdb

Creating database... 127.0.0.1:c:\programming\data\m2_dl_3019.fdb
running... create_firebird.sql
running... views.sql
running... rights.sql
running... defaults.sql



I haven't tested what happens if you specify a path under Windows that 
contain spaces, but will test it later. I would imagine quotes must be 
used, but not sure how yet.



Regards,
 Graeme


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

Re: [fpc-pascal] Efficient String concatenation

[Graeme Geldenhuys]

On Tuesday 29/10/2013 at 19:51, John Lee  wrote:


Did you try any other fpc compiler optimisation settings?


No, -O2 is the only compiler optimisation I enabled.


Regards,
 Graeme


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

Re: [fpc-pascal] Powtils: lightwebserver, lightwebserver2 or lightwebserver3?

[Graeme Geldenhuys]

On Tuesday 29/10/2013 at 18:19, John Lee  wrote:


Is this assessment valid for win or linux or both? J


I use both equally, and for the 32-bit and 64-bit platforms.


Regards,
 Graeme




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

[fpc-pascal] SqlDB fails under Windows to create a new Firebird database

[Graeme Geldenhuys]

Hi,

I created a very simple little application that takes 2 parameters, 
then creates a empty FDB (firebird) database, then runs 4 script files 
to populate the database with default tables and data.


This little console application works perfectly under Linux and 
FreeBSD, but fails under Windows. Currently testing with Win2000 
(32-bit).


Here is the code that causes the AV.

---

procedure TMyApplication.CreateEmptyDatabase;
var
 LHost: string;
 LDBName: string;
 n: integer;
begin
 n := Pos(':', FDBLocation);
 LHost   := Copy(FDBLocation, 1, n-1);
 LDBName := Copy(FDBLocation, n+1, Length(FDBLocation)-n);

 conn := TIBConnection.Create(self);
 conn.Dialect := 3;
 conn.HostName := LHost;
 conn.DatabaseName := LDBName;
 conn.UserName := 'sysdba';
 conn.Password := 'masterkey';

 writeln('Creating database... ', conn.HostName + ':' + 
conn.DatabaseName);

 conn.CreateDB;
 conn.Connected := True;  // <<---   This causes the AV under 
Windows

end;
---

Here is the console output of when I run the program.

---

c:\programming\m2_system\Scripts>makedb -d 
'127.0.0.1:c:\programming\data\m2_dl_3019.fdb'

Creating database... '127.0.0.1:c:\programming\data\m2_dl_3019.fdb'
exception at 00431BD8:
: CreateDB :
-I/O error during "open" operation for file ""
-database or file exists.
---


I'm using FPC 2.6.2 32-bit on Windows 2000. Any clues what is wrong? 
And why does this code work on Linux and FreeBSD. Also, even though 
the error mentions the fact that the "database or file exits", that is 
definitely NOT true. There is no existing *.fdb file.


Regards,
 - Graeme -


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

[fpc-pascal] Re: SqlDB fails under Windows to create a new Firebird database

[Michael Van Canneyt]

On Wed, 30 Oct 2013, Graeme Geldenhuys wrote:


Hi,

I created a very simple little application that takes 2 parameters, then 
creates a empty FDB (firebird) database, then runs 4
script files to populate the database with default tables and data.

This little console application works perfectly under Linux and FreeBSD, but 
fails under Windows. Currently testing with
Win2000 (32-bit).

Here is the code that causes the AV.

---
procedure TMyApplication.CreateEmptyDatabase;
var
  LHost: string;
  LDBName: string;
  n: integer;
begin
  n := Pos(':', FDBLocation);
  LHost   := Copy(FDBLocation, 1, n-1);
  LDBName := Copy(FDBLocation, n+1, Length(FDBLocation)-n);

  conn := TIBConnection.Create(self);
  conn.Dialect := 3;
  conn.HostName := LHost;
  conn.DatabaseName := LDBName;
  conn.UserName := 'sysdba';
  conn.Password := 'masterkey';

  writeln('Creating database... ', conn.HostName + ':' + conn.DatabaseName);
  conn.CreateDB;
  conn.Connected := True;  // <<---   This causes the AV under Windows
end;
---

Here is the console output of when I run the program.

---
c:\programming\m2_system\Scripts>makedb -d 
'127.0.0.1:c:\programming\data\m2_dl_3019.fdb'
Creating database... '127.0.0.1:c:\programming\data\m2_dl_3019.fdb'
exception at 00431BD8:
 : CreateDB :
 -I/O error during "open" operation for file ""
 -database or file exists.
---


That is an interbase error. It clearly states what the problem is :)

However, it is strange that the CreateDB() does not catch this error.

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

Re: [fpc-pascal] Efficient String concatenation

[Sven Barth]

Am 30.10.2013 12:59, schrieb John Lee:

jonas wrote
'
It may indeed be possible to handle this in the compiler.

> What about llvm - (coming soon to fpc apparently) - would that fix it?

Not in the least. "soon" is also a gross overstatement.
'
What's the size/difficulty of compiler spotting this? Suppose it needs 
to be able to 'look ahead' by few statements  - which I'd thought it 
does already to some extent.

It's not about parsing. The code will be parsed the same nevertheless.

It would be a optimization on the resulting node tree however after the 
function was parsed and before the code is generated.


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

Re: [fpc-pascal] private type and type compatibility

[Michael Van Canneyt]

On Wed, 30 Oct 2013, Jonas Maebe wrote:



On 30 Oct 2013, at 13:05, Michael Van Canneyt wrote:


On Wed, 30 Oct 2013, Jonas Maebe wrote:


On 30 Oct 2013, at 12:50, Michael Van Canneyt wrote:

You must admit that in the case of a function result type, that is a bit 
awkward, since you will never be able to declare a properly typed 
variable to hold the function result. In the case of a record or class 
type, that is particularly awkward since you will be forced to use a 
"with" to access the various fields.


Absolutely, but it's always been valid in TP/Delphi/FPC-style Pascal and 
introducing a special rule would make the language less orthogonal.


I still think it is a different use case:

Like I said: in the case of an identifier from a different unit, the user 
just has to add it to her uses clause. Here this is simply impossible.


My point is that even without adding that other unit, you can still "consume" 
values that have this type even though the type declarations are not in 
scope. You can indeed not add them in the scope here, but they are still 
usable.


Yes, I understood it like that. 
I do think it is a design fault (see the remark about the TP manuals), 
but that is another issue.


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

Re: [fpc-pascal] private type and type compatibility

[Jonas Maebe]

On 30 Oct 2013, at 13:05, Michael Van Canneyt wrote:


On Wed, 30 Oct 2013, Jonas Maebe wrote:


On 30 Oct 2013, at 12:50, Michael Van Canneyt wrote:

You must admit that in the case of a function result type, that is  
a bit awkward, since you will never be able to declare a properly  
typed variable to hold the function result. In the case of a  
record or class type, that is particularly awkward since you will  
be forced to use a "with" to access the various fields.


Absolutely, but it's always been valid in TP/Delphi/FPC-style  
Pascal and introducing a special rule would make the language less  
orthogonal.


I still think it is a different use case:

Like I said: in the case of an identifier from a different unit, the  
user just has to add it to her uses clause. Here this is simply  
impossible.


My point is that even without adding that other unit, you can still  
"consume" values that have this type even though the type declarations  
are not in scope. You can indeed not add them in the scope here, but  
they are still usable.



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

Re: [fpc-pascal] private type and type compatibility

[Michael Van Canneyt]

On Wed, 30 Oct 2013, Jonas Maebe wrote:



On 30 Oct 2013, at 12:50, Michael Van Canneyt wrote:


On Wed, 30 Oct 2013, Jonas Maebe wrote:

It can, as demonstrated by the example that started this thread. The type 
identifier may not be visible, but entities that have this type can be. 
Just like in the unit example.


You must admit that in the case of a function result type, that is a bit 
awkward, since you will never be able to declare a properly typed variable 
to hold the function result. In the case of a record or class type, that is 
particularly awkward since you will be forced to use a "with" to access the 
various fields.


Absolutely, but it's always been valid in TP/Delphi/FPC-style Pascal and 
introducing a special rule would make the language less orthogonal.


I still think it is a different use case:

Like I said: in the case of an identifier from a different unit, the user just 
has to add it to her uses clause. Here this is simply impossible.


It is probably the reason why in the original TP manuals it stated that "adding 
a unit B to the interface section's uses clause of unit A makes identifiers in 
the interface section of unit B available to all code using unit A."


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

Re: [fpc-pascal] Efficient String concatenation

[John Lee]

jonas wrote
'
It may indeed be possible to handle this in the compiler.

> What about llvm - (coming soon to fpc apparently) - would that fix it?

Not in the least. "soon" is also a gross overstatement.
'
What's the size/difficulty of compiler spotting this? Suppose it needs to
be able to 'look ahead' by few statements  - which I'd thought it does
already to some extent.

Think I saw email where you said 'few' months - that is soon in context of
fpc and even more in the context of significant fpc changes, so not 'gross
overstatement'!

John



On 29 October 2013 17:32, Jonas Maebe  wrote:

> On 29/10/13 18:17, John Lee wrote:
>
>  On 29 October 2013 13:22, Graeme Geldenhuys 
>> wrote:
>>
>>  This is a very impressive little blog about efficient string
>>> concatenation
>>> in Delphi. But it also applies to Free Pascal.
>>> http://www.delphitools.info/**2013/10/28/efficient-string-**
>>> concatenation-in-delphi/
>>>
>>
> > Did you try any other fpc compiler optimisation settings? No expert, but
> > looks like it isn't too difficult for compiler to spot this.
>
> It may indeed be possible to handle this in the compiler.
>
>
> > What about llvm - (coming soon to fpc apparently) - would that fix it?
>
> Not in the least. "soon" is also a gross overstatement.
>
>
> Jonas
>
> __**_
> 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] private type and type compatibility

[Jonas Maebe]

On 30 Oct 2013, at 12:50, Michael Van Canneyt wrote:


On Wed, 30 Oct 2013, Jonas Maebe wrote:

It can, as demonstrated by the example that started this thread.  
The type identifier may not be visible, but entities that have this  
type can be. Just like in the unit example.


You must admit that in the case of a function result type, that is a  
bit awkward, since you will never be able to declare a properly  
typed variable to hold the function result. In the case of a record  
or class type, that is particularly awkward since you will be forced  
to use a "with" to access the various fields.


Absolutely, but it's always been valid in TP/Delphi/FPC-style Pascal  
and introducing a special rule would make the language less orthogonal.



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

Re: [fpc-pascal] private type and type compatibility

[Michael Van Canneyt]

On Wed, 30 Oct 2013, Jonas Maebe wrote:



On 30 Oct 2013, at 12:09, Sven Barth  wrote:


Am 30.10.2013 11:59, schrieb Jonas Maebe:


The tdynarray type is not visible in the program because u1 is not in its uses 
clause (it's not in scope whatsoever), and nevertheless there is no problem to 
use it. It's of course not exactly the same (tdynarray isn't declared as 
private to u1), but at the scope visibility level it is the same situation as 
far as I am concerned.

Hmm... but here the compiler can not know whether the unit using u2 has unit u1 
in scope or not. In case of private and protected types the compiler can know 
however that code declared externally can never have access to it


It can, as demonstrated by the example that started this thread. The type 
identifier may not be visible, but entities that have this type can be. Just 
like in the unit example.


You must admit that in the case of a function result type, that is a bit awkward, 
since you will never be able to declare a properly typed variable to hold the function 
result. In the case of a record or class type, that is particularly awkward since you 
will be forced to use a "with" to access the various fields.


Type
  TMyClass = Class
  private
   type myrec = record
a,b : SomeOtherType;
end;
  public
function MyFunc : Myrec;
  end;

You cannot do

Var
  c : TMyClass;
  r : myrec; // will fail.

begin
  r:=c.myfunc;
  Writeln(r.a,' ',r.b);
end;

you can only do

Var
  c : TMyClass;

begin
  with c.myfunc do
Writeln(r.a,' ',r.b);
end;

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

Re: [fpc-pascal] private type and type compatibility

[Jonas Maebe]

On 30 Oct 2013, at 12:09, Sven Barth  wrote:

> Am 30.10.2013 11:59, schrieb Jonas Maebe:
>> 
>> The tdynarray type is not visible in the program because u1 is not in its 
>> uses clause (it's not in scope whatsoever), and nevertheless there is no 
>> problem to use it. It's of course not exactly the same (tdynarray isn't 
>> declared as private to u1), but at the scope visibility level it is the same 
>> situation as far as I am concerned.
> Hmm... but here the compiler can not know whether the unit using u2 has unit 
> u1 in scope or not. In case of private and protected types the compiler can 
> know however that code declared externally can never have access to it

It can, as demonstrated by the example that started this thread. The type 
identifier may not be visible, but entities that have this type can be. Just 
like in the unit example.

> (though of course there might be type compatibilities like your dynamic array 
> example, but most private/protected types should be records or classes).

I'm not sure why most private types "should" be records/classes, especially 
with generic classes.


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

Re: [fpc-pascal] private type and type compatibility

[Michael Van Canneyt]

On Wed, 30 Oct 2013, Sven Barth wrote:


Am 30.10.2013 11:59, schrieb Jonas Maebe:


problem to use it. It's of course not exactly the same (tdynarray isn't 
declared as private to u1), but at the scope visibility level it is the 
same situation as far as I am concerned.
Hmm... but here the compiler can not know whether the unit using u2 has unit 
u1 in scope or not. In case of private and protected types the compiler can 
know however that code declared externally can never have access to it


My thoughts exactly.

In the case of units, the user CAN make it visible (as in : directly accessible)
by adding the unit to the uses clause. He can never do this for the private 
type.

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

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 30.10.2013 12:06, schrieb Frederic Da Vitoria:
2013/10/30 Jonas Maebe >


On 30 Oct 2013, at 10:36, Michael Van Canneyt wrote:

I think it is an error. You declare something as private, and
then you use it in a public function ? If that is not a
visibility clash, I don't know what is :)


The ability to use types in public functions that are not
necessarily visible to users of that function is quite common in
Pascal. Otherwise, for consistency you would also have to give a
compile time error when compiling this:

unit u1;

interface

type
  tdynarray = array of integer;

implementation

end.
*

unit u2;

interface

uses
  u1;

function f: tdynarray;

implementation

function f: tdynarray;
begin
end;

end.
**

program test;

uses
  u2;

var
  a: array of integer;
begin
  a:=f;
end.
***

The tdynarray type is not visible in the program because u1 is not
in its uses clause (it's not in scope whatsoever), and
nevertheless there is no problem to use it. It's of course not
exactly the same (tdynarray isn't declared as private to u1), but
at the scope visibility level it is the same situation as far as I
am concerned.


Precisely, shouldn't this trigger an error too? The code should not be 
able to reference anything for which the declaration isn't visible, 
isn't it?
But the compiler can not know whether the user of unit u2 has unit u1 in 
scope or not.


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

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 30.10.2013 11:59, schrieb Jonas Maebe:


On 30 Oct 2013, at 10:36, Michael Van Canneyt wrote:

I think it is an error. You declare something as private, and then 
you use it in a public function ? If that is not a visibility clash, 
I don't know what is :)


The ability to use types in public functions that are not necessarily 
visible to users of that function is quite common in Pascal. 
Otherwise, for consistency you would also have to give a compile time 
error when compiling this:


unit u1;

interface

type
  tdynarray = array of integer;

implementation

end.
*

unit u2;

interface

uses
  u1;

function f: tdynarray;

implementation

function f: tdynarray;
begin
end;

end.
**

program test;

uses
  u2;

var
  a: array of integer;
begin
  a:=f;
end.
***

The tdynarray type is not visible in the program because u1 is not in 
its uses clause (it's not in scope whatsoever), and nevertheless there 
is no problem to use it. It's of course not exactly the same 
(tdynarray isn't declared as private to u1), but at the scope 
visibility level it is the same situation as far as I am concerned.
Hmm... but here the compiler can not know whether the unit using u2 has 
unit u1 in scope or not. In case of private and protected types the 
compiler can know however that code declared externally can never have 
access to it (though of course there might be type compatibilities like 
your dynamic array example, but most private/protected types should be 
records or classes).


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

Re: [fpc-pascal] private type and type compatibility

[Frederic Da Vitoria]

2013/10/30 Jonas Maebe 

> On 30 Oct 2013, at 10:36, Michael Van Canneyt wrote:
>
>  I think it is an error. You declare something as private, and then you
>> use it in a public function ? If that is not a visibility clash, I don't
>> know what is :)
>>
>
> The ability to use types in public functions that are not necessarily
> visible to users of that function is quite common in Pascal. Otherwise, for
> consistency you would also have to give a compile time error when compiling
> this:
>
> unit u1;
>
> interface
>
> type
>   tdynarray = array of integer;
>
> implementation
>
> end.
> *
>
> unit u2;
>
> interface
>
> uses
>   u1;
>
> function f: tdynarray;
>
> implementation
>
> function f: tdynarray;
> begin
> end;
>
> end.
> **
>
> program test;
>
> uses
>   u2;
>
> var
>   a: array of integer;
> begin
>   a:=f;
> end.
> ***
>
> The tdynarray type is not visible in the program because u1 is not in its
> uses clause (it's not in scope whatsoever), and nevertheless there is no
> problem to use it. It's of course not exactly the same (tdynarray isn't
> declared as private to u1), but at the scope visibility level it is the
> same situation as far as I am concerned.
>

Precisely, shouldn't this trigger an error too? The code should not be able
to reference anything for which the declaration isn't visible, isn't it?

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Jonas Maebe]

On 30 Oct 2013, at 10:36, Michael Van Canneyt wrote:

I think it is an error. You declare something as private, and then  
you use it in a public function ? If that is not a visibility clash,  
I don't know what is :)


The ability to use types in public functions that are not necessarily  
visible to users of that function is quite common in Pascal.  
Otherwise, for consistency you would also have to give a compile time  
error when compiling this:


unit u1;

interface

type
  tdynarray = array of integer;

implementation

end.
*

unit u2;

interface

uses
  u1;

function f: tdynarray;

implementation

function f: tdynarray;
begin
end;

end.
**

program test;

uses
  u2;

var
  a: array of integer;
begin
  a:=f;
end.
***

The tdynarray type is not visible in the program because u1 is not in  
its uses clause (it's not in scope whatsoever), and nevertheless there  
is no problem to use it. It's of course not exactly the same  
(tdynarray isn't declared as private to u1), but at the scope  
visibility level it is the same situation as far as I am concerned.



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

Re: [fpc-pascal] private type and type compatibility

[Michael Van Canneyt]

On Wed, 30 Oct 2013, Sven Barth wrote:


Am 30.10.2013 10:36, schrieb Michael Van Canneyt:



On Wed, 30 Oct 2013, Sven Barth wrote:


Am 30.10.2013 08:47, schrieb Xiangrong Fang:
  Hi All,

  I have the following class:

  type
generic TVector = class
private type
  TDataType = array of T;
private
  FData: TDataType;
  ... ...
public
  ... ...
  function Slice(APos: Integer = -1; ACount: Integer = -1): 
TDataType;

end;

The Slice() method return a portion of the data as a dynamic array.

My question is, as I define TDataType as PRIVATE type, why it is still 
usable outside of the class?  In the main program

I did:

type
  TIntVector = specialize TVector;
var
  iv: TIntVector;
  ia: array of Integer;
begin
  iv := TIntVector.Create;
  ... ...
  ia := iv.Slice;
end.

This will assign a TDataType (is it TVector$TDataType or 
TIntVector$TDataType? I don't know) to an "array of Integer".

Why this assignment works?

i.e. how does the type system work?!

It's a bit annoying that the usage private/protected types in 
public/published functions is allowed... (this is however Delphi
compatible) Maybe this should be adjusted for non-Delphi modes for 
language consistency... (maybe at least as a warning which

could be elevated to an error if someone wants)


I think it is an error. You declare something as private, and then you use 
it in a public function ? If that is not a visibility clash, I don't know 
what is :)
I agree, but the question is should we declare this as a bug in the language 
and thus fix it which might lead to adjustments of legacy (2.6.x) code or use 
a warning. I personally would do the former (and better sooner than later).


Me too. It is a bug, and should be treated as such.

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

Re: [fpc-pascal] private type and type compatibility

[Xiangrong Fang]

2013/10/30 Sven Barth 

> I think it is an error. You declare something as private, and then you use
>> it in a public function ? If that is not a visibility clash, I don't know
>> what is :)
>>
> I agree, but the question is should we declare this as a bug in the
> language and thus fix it which might lead to adjustments of legacy (2.6.x)
> code or use a warning. I personally would do the former (and better sooner
> than later). We need to keep the current behavior in mode Delphi however...
> (Note: Delphi additionally allows to access protected types from external
> units; could be related to the point that helper types allow access to
> protected types and fields as well...)
>

​I also agree that it is a bug. That's why I am confused.​
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 30.10.2013 10:36, schrieb Michael Van Canneyt:



On Wed, 30 Oct 2013, Sven Barth wrote:


Am 30.10.2013 08:47, schrieb Xiangrong Fang:
  Hi All,

  I have the following class:

  type
generic TVector = class
private type
  TDataType = array of T;
private
  FData: TDataType;
  ... ...
public
  ... ...
  function Slice(APos: Integer = -1; ACount: Integer = -1): 
TDataType;

end;

The Slice() method return a portion of the data as a dynamic array.

My question is, as I define TDataType as PRIVATE type, why it is 
still usable outside of the class?  In the main program

I did:

type
  TIntVector = specialize TVector;
var
  iv: TIntVector;
  ia: array of Integer;
begin
  iv := TIntVector.Create;
  ... ...
  ia := iv.Slice;
end.

This will assign a TDataType (is it TVector$TDataType or 
TIntVector$TDataType? I don't know) to an "array of Integer".

Why this assignment works?

i.e. how does the type system work?!

It's a bit annoying that the usage private/protected types in 
public/published functions is allowed... (this is however Delphi
compatible) Maybe this should be adjusted for non-Delphi modes for 
language consistency... (maybe at least as a warning which

could be elevated to an error if someone wants)


I think it is an error. You declare something as private, and then you 
use it in a public function ? If that is not a visibility clash, I 
don't know what is :)
I agree, but the question is should we declare this as a bug in the 
language and thus fix it which might lead to adjustments of legacy 
(2.6.x) code or use a warning. I personally would do the former (and 
better sooner than later). We need to keep the current behavior in mode 
Delphi however... (Note: Delphi additionally allows to access protected 
types from external units; could be related to the point that helper 
types allow access to protected types and fields as well...)


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

Re: [fpc-pascal] private type and type compatibility

[Michael Van Canneyt]

On Wed, 30 Oct 2013, Sven Barth wrote:


Am 30.10.2013 08:47, schrieb Xiangrong Fang:
  Hi All,

  I have the following class:

  type
    generic TVector = class
    private type
      TDataType = array of T;
    private
      FData: TDataType;
      ... ...
    public
      ... ...
      function Slice(APos: Integer = -1; ACount: Integer = -1): TDataType;
    end;

The Slice() method return a portion of the data as a dynamic array.

My question is, as I define TDataType as PRIVATE type, why it is still usable 
outside of the class?  In the main program
I did:

type
  TIntVector = specialize TVector;
var
  iv: TIntVector;
  ia: array of Integer;
begin
  iv := TIntVector.Create;
  ... ...
  ia := iv.Slice;
end.

This will assign a TDataType (is it TVector$TDataType or TIntVector$TDataType? I don't 
know) to an "array of Integer".
Why this assignment works? 

i.e. how does the type system work?!

It's a bit annoying that the usage private/protected types in public/published 
functions is allowed... (this is however Delphi
compatible) Maybe this should be adjusted for non-Delphi modes for language 
consistency... (maybe at least as a warning which
could be elevated to an error if someone wants)


I think it is an error. 
You declare something as private, and then you use it in a public function ? 
If that is not a visibility clash, I don't know what is :)


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

Re: [fpc-pascal] same routine with different parameters?

[Sven Barth]

Am 30.10.2013 02:06, schrieb waldo kitty:


Assume that this is for value parameters only. In particular, I don't 
think

there's a way of defaulting a var parameter to a nil pointer.


hummm... the original has no parameters at all... my addition has 
two... will this be a problem? no, i've not had a chance to get back 
to the development machine and try :?


If you'd use two default parameters this would be problematic, yes, 
because a call to this overloaded function could either mean to call the 
function with no arguments or to call the other function with its two 
default values. Normally the compiler should then tell you that what 
you're trying to do is ambigous.


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

Re: [fpc-pascal] same routine with different parameters?

[Sven Barth]

Am 29.10.2013 20:40, schrieb waldo kitty:
FWIW: i decided to try this because i was unable to (hope i'm using 
the proper terms here) derive a new object from the existing one and 
override this one inherited routine with my modifications... this 
would allow me to add my own variables to the object in addition to 
what it comes with and allow me to have this routine as i need it... 
but that didn't work for some reason and i've already ripped out all 
that attempt and gone this route with my modified routine and direct 
addition of the variable... i just want to be able to provide 
something back with as little intrusion to the original as possible...
Overriding the behavior of an inherited function will only work if that 
function is a) at least "protected" (or you are in the same unit) and b) 
this function is declared as "virtual" (see also: 
http://www.freepascal.org/docs-html/ref/refsu29.html#x75-850006.3.3 )


Regards,
Sven

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

Re: [fpc-pascal] same routine with different parameters?

[Sven Barth]

Am 29.10.2013 19:35, schrieb Mark Morgan Lloyd:

waldo kitty wrote:
question: in simple language, how can i have a routine with differing 
parameters like some routines in FPC and Lazarus do? i've never 
attempted this before and it is completely alien to my experience but 
i do use the functionality quite a lot with existing routines...


description: i have a class object with an internal routine that i 
want to be able to pass no or different parameters to.


example:  procedure MyObject.MyRoutine;
  procedure MyObject.MyRoutine(VarA : SomeType);
  procedure MyObject.MyRoutine(VarA : string; VarB: integer);

at one point, the first instance would be used... at another point 
one of the other instances would be used with the only difference 
being the parameters that are passed or not... i know that i would 
have individual instances with the necessary header and code for 
each... i just don't know if there is anything else special that 
needs to be done or if it can be done with an internal class object 
routine..


Just give it a whirl as you've shown, I think you've got it right. 
Another useful variant is giving *the* *last* parameter an optional 
value, which will allow you to omit the parameter:


procedure MyObject.MyRoutine(const VarA : string; VarB: integer= -1);

Default paremeters can be used for more than the last parameter. There 
is however the following caveat: if you have e.g. a function with three 
parameters and the last two have default values, but you now have a call 
where you're fine with the default value of the second (overall) 
parameter, but not with that of the third you'll nevertheless have to 
specify the second parameter.


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

Re: [fpc-pascal] same routine with different parameters?

[Sven Barth]

Am 29.10.2013 20:32, schrieb waldo kitty:

On 10/29/2013 1:56 PM, Sven Barth wrote:

Am 29.10.2013 18:21 schrieb "waldo kitty" :
 > example:  procedure MyObject.MyRoutine;
 >   procedure MyObject.MyRoutine(VarA : SomeType);
 >   procedure MyObject.MyRoutine(VarA : string; VarB: integer);
 >
 > at one point, the first instance would be used... at another point 
one of the
 > other instances would be used with the only difference being the 
parameters that
 > are passed or not... i know that i would have individual instances 
with the
 > necessary header and code for each... i just don't know if there 
is anything
 > else special that needs to be done or if it can be done with an 
internal class

 > object routine..

The most important point to keep in mind us that the parameters need 
to be

different (the result type does not count though!).


in this specific case, it will be one without any parameters (the 
original in the 3rd party library) and one with parameters (my needed 
modifications)...

That's valid :)



Note: In mode Delphi and a few other cases (e.g. cross unit overloads,
inheritance) you'll need to add the "overload" directive.


ahhh... i believe that the library i'm using does use mode delphi all 
over the place... do i add "overload;" to each of the 'duplicate' 
routines?

Yes.


For additional information please look at the language reference 
guide (can't

look up the link currently).


i don't even know what to search for... although 'overload' may give 
me a start...


It seems that overloading is only mentioned here: 
http://www.freepascal.org/docs-html/ref/refse79.html#x163-17300014.5


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

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 30.10.2013 08:47, schrieb Xiangrong Fang:

Hi All,

I have the following class:

type
  generic TVector = class
  private type
TDataType = array of T;
  private
FData: TDataType;
... ...
  public
... ...
function Slice(APos: Integer = -1; ACount: Integer = -1): TDataType;
  end;

The Slice() method return a portion of the data as a dynamic array.

My question is, as I define TDataType as PRIVATE type, why it is still 
usable outside of the class?  In the main program I did:


type
  TIntVector = specialize TVector;
var
  iv: TIntVector;
  ia: array of Integer;
begin
  iv := TIntVector.Create;
  ... ...
  ia := iv.Slice;
end.

This will assign a TDataType (is it TVector$TDataType or 
TIntVector$TDataType? I don't know) to an "array of Integer". Why this 
assignment works?


i.e. how does the type system work?!
It's a bit annoying that the usage private/protected types in 
public/published functions is allowed... (this is however Delphi 
compatible) Maybe this should be adjusted for non-Delphi modes for 
language consistency... (maybe at least as a warning which could be 
elevated to an error if someone wants)


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

[fpc-pascal] private type and type compatibility

[Xiangrong Fang]

Hi All,

I have the following class:

type
  generic TVector = class
  private type
TDataType = array of T;
  private
FData: TDataType;
... ...
  public
... ...
function Slice(APos: Integer = -1; ACount: Integer = -1): TDataType;
  end;

The Slice() method return a portion of the data as a dynamic array.

My question is, as I define TDataType as PRIVATE type, why it is still
usable outside of the class?  In the main program I did:

type
  TIntVector = specialize TVector;
var
  iv: TIntVector;
  ia: array of Integer;
begin
  iv := TIntVector.Create;
  ... ...
  ia := iv.Slice;
end.

This will assign a TDataType (is it TVector$TDataType or
TIntVector$TDataType? I don't know) to an "array of Integer". Why this
assignment works?

i.e. how does the type system work?!

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