Re: [fpc-pascal] private integer is an illegal counter variable
And there are many reasons why there are so many string types nowadays.
True.
Simply use {mode objfpc}{$h+} like lazarus suggests.
I think the root cause of all these problems are generic types. They cause more
trouble than they avoid. I would suggest that noone never uses such generic
types but uses shortstring or ansistring (or...) as they need. Telling people
to simply use this or that compiler switch is not the solution (you have to
explain this over and over again). Generic types should be the exception and
not the norm. It begs for trouble in many situations. Using strict types also
lets the user read more about the nature of these types and therefore knows
more about possible side effects. Someone who has shortstings in mind when
using strings would surely use it in a different way as someone who has
ansistrings in mind (provided he knows how they are handled by the compiler).
And telling people clearly about the implementation of these different types is
much better than obscuring them by generic types.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interfaces via implements keyword
Hi Andrew
On Thu, Nov 26, 2009 at 4:48 AM, Andrew Hall wrote:
> 1) Always reference your host class through an interface you know will be
> implemented by the host class, therefore calling "as" from this interface
> will always find any of the interfaces your class may support. The easiest
> would be to declare "I1: IUnknown" in the code below - I haven't tried it
> but that should work.
>
Yes. At first of this too.
>
> 2) Store the host class reference in the other classes that implement the
> host and provide an "Owner: IUnknown" property in your "child" implementing
> classes to allow you to cast to any interface supported by the host class:
> "I2 := I1.Owner as IIntf2"
>
>
And that's my current solution for some classes :)
> PS - normally your host class would not support the interface you are using
> "implements" to achieve...
Normally yes. Unfortunately it's not my case.
> therefore the confusing circumstances of your first example would not
> normally happen - you'd be more likely to see this second example which is a
> little easier to decipher...
>
> Regards,
>
> Andrew Hall.
But I think I found a better solution. The only way that needed to be
changed is the way of QueryInterface works.
I just took the idea with Owner and redefined QueryInterface method to use
it. Like following:
{ TInterfacedObj }
TInterfacedObj = class(TObject, IUnknown)
private
FOwner:TInterfacedObj;
function GetInterface(const iid : tguid;out obj):longint;
public
function QueryInterface(const iid : tguid;out obj) :
longint;virtual;stdcall;
function _AddRef : longint;stdcall;
function _Release : longint;stdcall;
constructor Create(Owner:TInterfacedObj);
end;
{ TInterfacedObj }
const Err = HResult($80004002);
function TInterfacedObj.GetInterface(const iid: tguid; out obj): longint;
begin
if inherited GetInterface(IID, Obj) then
Result:=0
else
Result:=Err;
end;
function TInterfacedObj.QueryInterface(const iid: tguid; out obj):
longint;stdcall;
begin
WriteLn('QueryInterface ', ClassName);
if FOwner = nil then
Result:=GetInterface(iid, obj)
else
begin
Result:=FOwner.QueryInterface(iid, obj);
//try to find interface in itself
if Result = Err then
Result:=GetInterface(iid, obj);
end;
end;
constructor TInterfacedObj.Create(Owner: TInterfacedObj);
begin
FOwner:=Owner;
end;
Now it is possible to start interface search from the owner and only if
owner has no appropriate interface, it queries itself.
That's seems pretty nice solution.
--
Best regards,
Denis Golovan
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] readonly variables
Hello, is it possible to set a variable in a programm as a readonly variable? I would set a variable at a position in the runing programm. Since this time the variable should be readonly. The next set of the variable should produce an error. In bash programming you found a command "readonly" making this effect. Is there a command for FreePascal? Thanks, Markus program readonly; ... v:=1; // At this position it should be readonly. ... end. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
is it possible to set a variable in a programm as a readonly variable? Not that I am aware of. But for what reason do you want such a behaviour? And if I think it over, this can only work at runtime (letting the program crash on the second assignment). At compile time the compiler may not exactly know which assignment is done in what order. If you set the variable in a procedure or function the compiler would have to check when this procedure is called (which can be called by another procedure and so on). The first call (and assignment) would be ok but the second should generate an error? How should the compiler know how often the routine is called? This can even be dependend on input data. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
On Sat, 28 Nov 2009 14:58:26 +0100 Jürgen Hestermann wrote: > > is it possible to set a variable in a programm as a readonly variable? > > Not that I am aware of. But for what reason do you want such a behaviour? > > And if I think it over, this can only work at runtime (letting the program > crash on the second assignment). At compile time the compiler may not exactly > know which assignment is done in what order. If you set the variable in a > procedure or function the compiler would have to check when this procedure is > called (which can be called by another procedure and so on). The first call > (and assignment) would be ok but the second should generate an error? How > should the compiler know how often the routine is called? This can even be > dependend on input data. Same under bash. Use the following: property MyVar: integer read FMyVar write SetMyVar; And in SetMyVar you can set flag and raise an exception if set for the second time. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
On Sat, 28 Nov 2009 15:07:42 +0100 Mattias Gaertner wrote: > On Sat, 28 Nov 2009 14:58:26 +0100 > Jürgen Hestermann wrote: > > > > is it possible to set a variable in a programm as a readonly variable? > Use the following: > > property MyVar: integer read FMyVar write SetMyVar; > > And in SetMyVar you can set flag and raise an exception if set for the > second time. If the value is known in advance and if no runtime alteration of the variable is allowed you would of course declare the value as const rather than var. But this may not fit your case? Howard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
You can use read function: var DirectAccessToValue: T; function Value: T; inline; begin Result := DirectAccessToValue; end; begin ... DirectAccessToValue := ...; ... DoSomething(Value); end. On Sat, Nov 28, 2009 at 13:55, Markus Glugla wrote: > Hello, > > is it possible to set a variable in a programm as a readonly variable? > > I would set a variable at a position in the runing programm. Since this > time the variable should be readonly. The next set of the variable > should produce an error. > > In bash programming you found a command "readonly" making this effect. > Is there a command for FreePascal? > > Thanks, > Markus > > program readonly; > ... > v:=1; // At this position it should be readonly. > ... > end. > > > > > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Aleksa Todorovic - Lead Programmer Eipix Entertainment http://www.eipix.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
procedure InitMyVariable(Value: T); function MyVariable: T; implementation var PrivateMyVariable: T; PrivateMyVariableSet: Boolean; procedure InitMyVariable(Value: T); begin if not PrivateMyVariableSet then PrivateMyVariable := Value; PrivateMyVariableSet := True; end; function MyVariable: T; begin Result := PrivateMyVariable; end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
On Sat, 28 Nov 2009 12:10:48 -0500 Anthony Walter wrote: > procedure InitMyVariable(Value: T); > function MyVariable: T; > > implementation > > var > PrivateMyVariable: T; > PrivateMyVariableSet: Boolean; > > procedure InitMyVariable(Value: T); > begin > if not PrivateMyVariableSet then > PrivateMyVariable := Value; > PrivateMyVariableSet := True; > end; > > function MyVariable: T; > begin > Result := PrivateMyVariable; > end; PrivateMyVariableSet is not intialised, so will have an undefined (random) value when InitMyVariable is first called. Mattias' code given earlier avoids this problem. Howard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
> PrivateMyVariableSet is not intialised, so will have an undefined > (random) value when InitMyVariable is first called. > Mattias' code given earlier avoids this problem. Bzzzt. Wrong. Global variables (even in the implementation section) are always initialized to 0. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
On Sat, 28 Nov 2009, Anthony Walter wrote: PrivateMyVariableSet is not intialised, so will have an undefined (random) value when InitMyVariable is first called. Mattias' code given earlier avoids this problem. Bzzzt. Wrong. Global variables (even in the implementation section) are always initialized to 0. This is not guaranteed in any way. It happens to be so most of the time, but your code should never assume this is so, except for global Ansistring variables. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
> This is not guaranteed in any way. It happens to be so most of the time, > but your code should never assume this is so, except for global Ansistring > variables. If all globals weren't initialized to 0 a lot of code from lots of people would potentially be in trouble. I've been using Pascal/Delphi for a very long time. Trust me I know my stuff. >From the language specification: Section: Data Types, Variables, and Constants Sub-section: Declaring Variables Page: 102 "If you don't explicitly initialize a global variable, the compiler initializes it to 0." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
On Sat, 28 Nov 2009, Anthony Walter wrote: This is not guaranteed in any way. It happens to be so most of the time, but your code should never assume this is so, except for global Ansistring variables. If all globals weren't initialized to 0 a lot of code from lots of people would potentially be in trouble. I've been using Pascal/Delphi for a very long time. Trust me I know my stuff. I believe that. I know it is so in practice, but nowhere it says in the Pascal language specification that this is guaranteed by the compiler. From the language specification: Section: Data Types, Variables, and Constants Sub-section: Declaring Variables Page: 102 "If you don't explicitly initialize a global variable, the compiler initializes it to 0." That should be removed, actually. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
> That should be removed, actually. I'll take that as an admission that you were wrong. It's in the specification, lot's of code uses the feature, and it works the way I described. Changing the specification to match your argument is stupid. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
On Sat, 28 Nov 2009, Anthony Walter wrote: That should be removed, actually. I'll take that as an admission that you were wrong. It's in the specification, lot's of code uses the feature, and it works the way I described. I'm not admitting anything here, I am attempting to enlighten you :-) Changing the specification to match your argument is stupid. I'm not changing any specifications. They are what they are, I neither make nor control them. I did create the docs, and at that time I believed that the zero-out behaviour of the compiler/linker for certain sections in the executable could be taken for granted. It was Jonas Maebe (Jonas, correct me if I'm wrong) who pointed out (already some time ago) that this behaviour is purely coincidental (but admittedly convenient), and should not be taken for granted. At that time I should have removed the statement you refer to from the docs, but I did not (I probably forgot it was there in the first place). So: no "admissions", just a lesson in history of FPC and its docs. I'll now confer with the rest of the Core team about our 'official' attitude in this. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
Okay, I am going to call bullshit on you. This is the second time (in a few weeks) where you've replied to something I've written with wrong information. This first time concerning the topic "const records passed incorrectly" you said, "It is nowhere written in the Delphi specs that const parameters are passed by reference. It is often so, but is by no means guaranteed" That time I corrected you by pointing out the line in the help file contradicting your assertion. Martin Schreiber also chimed in, pointing out you were plainly wrong. In case you forgot, here is a refresher: http://tinyurl.com/yz8pqfv This second time regarding the current discussion you said: "This is not guaranteed in any way." and "nowhere it says in the Pascal language specification that this is guaranteed by the compiler" And I responded with the section, subsection, page number, and direct quote contradicting your assertion. I don't care if you claim to have written documentation, you clearly either don't have a grasp of the English language, good memory, research skills, or some combination those deficiencies. When we (English speakers) say "nowhere", it means "a state of nonexistence" or "not anywhere". When I, and others, then find the exact lines of said documentation proving your assertions that nothing of the sort was in the documentation, then you are wrong, and now doubly so. You have lost credibility IMO, and I foresee a trend where you are digging yourself further into a hole. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] (Generic) Container Classes
Hi, I submitted a TStringHashMap class to CCR. I also created a wiki page: http://wiki.lazarus.freepascal.org/StringHashMap I made a comprehensive demo program for it. It should be good now. I found some hashed list and similar classes from FPC sources (with no documentation) but no hash map with string -> pointer relationship. The question is why I need to search and port such container classes? Such containers should be part of libraries. Delphi didn't have them either until recently and it was a big missing feature. Generics syntax is being implemented in FPC. Containers especially would benefit from generics. Is there a concrete plan to make such generics container library? Regards, Juha Manninen ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] readonly variables
Michael - I see you are one of the authors of fpc (thank you), so I assume your statement is true by virtue of "inside knowledge". But this is a concern. As I'm sure you will know, in Delphi globals are always initialised to zero - and in my experience (almost 15 years with a 30-strong Delphi developer team) it is universally relied upon. Is this a case where FPC does not conform to Delphi behaviour? If not, why not? It would seem simple enough to ensure the global space in the heap is zeroed at allocation - or even that the compiler initialised each individually by "assuming" " = 0", " = nil", etc at the end of a global declaration if nothing else has been specified. Regards, Andrew Hall. On 28 Nov 09, at 11:58 , Michael Van Canneyt wrote: >> Global variables (even in the implementation section) are always >> initialized to 0. > > This is not guaranteed in any way. It happens to be so most of the time, > but your code should never assume this is so, except for global Ansistring > variables. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
