Re: [fpc-pascal] Get all caller adresses of a procedure/function
On Mon, Aug 6, 2012 at 9:48 PM, Rainer Stratmann
rainerstratm...@t-online.de wrote:
Am Monday 06 August 2012 21:26:24 schrieb Jonas Maebe:
It doesn't work like that. Regular calls use relative offsets on most (if
not all) architectures we support. And in some cases we generate
position-independent code, so then you'll have look at GOT entries to
figure out the address. Then there are of course calls via procedure
variables. And there's probably a ton more special cases I'm not thinking
of right now.
Would it then be possible to implement a counter (const) which is increased at
compile time?
p1( increasedcounteratcompiletime , 'Textsnippet' ) ?
I guess it is not possible.
Out of curiosity: why don't you use resourcestrings?
It seems that is has not the flexibility and simplicity (in its entirety)
that I want.
I would not call your method simple
It may is in the beginning more difficult to implement, but if it runs once I
would say this can not get much more simpler.
You only have to put p1( ) around your text snippet. That is it!
The function returns the right language.
and would also strongly recommend to
use resourcestrings instead. Their purpose is exactly to make it easy to
translate the strings in a program.
That means more work to give every text snippet explicitly a name which is not
necessary with my solution. And that means also less flexibility.
The resourcestring solution does not record the date and time when a text was
changed and so on...
How about using memory for string constant to store pointer to
localized version - something like example below? Note: target
platform needs to support writable string constants, and there should
be enought ~ characters at the beginning of the string to store value
of pointer (4x~ for 32-bit pointers, 8x~ for 64bit pointers). If you
can meet these two conditions, you don't need to know internals of
compiler or any implementation detail.
program test_str_36;
uses
sysutils;
function s(str: pchar): pchar;
var
str2: pchar;
begin
if str[0] = '~' then
begin
// string is not localized
str2 := strnew('numero'); // localized version
ppchar(str)^ := str2;
end;
result := ppchar(str)^;
end;
var
i: integer;
begin
for i := 1 to 10 do
begin
writeln(s('number'), ' ', i);
end;
end.
___
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] Converting code from C++ to FP....
On Sat, Mar 19, 2011 at 06:07, Bo Berglund bo.bergl...@gmail.com wrote: 1) The second line in the loop contains the command std::max, how can that be translated? I have not found any class definition for std with a method max There is function Max in unit Math, so you could say: jBegin := Max(k-band, 1); 2) The parameter into the function is a pointer *A of type double. To me that indicates a value of some kind, but in the code it suddenly seems to appear as an array with indexing. What would be the proper pascal translation of this? Indeed. C doesn't actually have difference between pointer to some data and arrays. You could use open array: procedure Decompose(var A: array of double); ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Converting code from C++ to FP....
On Sat, Mar 19, 2011 at 13:03, Bo Berglund bo.bergl...@gmail.com wrote: Now I have found another very strange construct: void ForwardModel::SetMixedBoundaryCondition(const int iElec, const double* SX0, const double* SY0, const double* SZ0, double* SX, double* SY, double* SZ) Now it seems like the variable type declaration itself is a pointer Instead of double *Name it is double* Name. What is the difference? It is still being used as an array: SX[n1] = SX0[n1] * (1.0 - w1); Does C++ allow any placement of the * operator with the same meaning? And what does const double* mean? Pointer to some object but not allowed to change that object Having programmed Delphi for 16 years this is hard to wrap ones head around. :-( Welcome to the world of Chell ;-) I (unfortunately) have to use it daily. Ok, not let's be helpful. In the situation above, const has similar meaning as the one in Pascal - you have some value which you are not allowed to change. So, your header should be something like: procedure ForwardModel.SetMixedBoundaryCondition(const iElec : Integer; const SX0, SY0, SZ0 : array of double; var SX, SY, SZ : array of double); Hint: if you use trunk version of FPC, I suggest you use constref to ensure SX0, SY0 and SZ0 are passed as pointer. procedure ForwardModel.SetMixedBoundaryCondition(const iElec : Integer; constref SX0, SY0, SZ0 : array of double; var SX, SY, SZ : array of double); As Jeppe suggested, you can also use pointers: procedure ForwardModel.SetMixedBoundaryCondition(const iElec : Integer; const SX0, SY0, SZ0 : pdouble; SX, SY, SZ : pdouble); ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Read-only global references
On Sun, Mar 6, 2011 at 02:14, Marcos Douglas m...@delfire.net wrote:
On Sat, Mar 5, 2011 at 7:05 PM, Mark Morgan Lloyd
markmll.fpc-pas...@telemetry.co.uk wrote:
Marcos Douglas wrote:
On Sat, Mar 5, 2011 at 8:24 AM, Mark Morgan Lloyd
markmll.fpc-pas...@telemetry.co.uk wrote:
Where a unit exports an instance of an object, what's best practice for
making this read-only? I'm referring to the object reference itself here,
not properties of the object.
Where I've done this in the past I've used a function:
interface
function InitText: TFormattedString;
implementation
var xInitText: TFormattedString= nil;
function InitText: TFormattedString;
begin
result := xInitText
end { InitText } ;
Is there a better way using e.g. global properties that doesn't
necessitate
both a property and an explicit function?
property InitText: TFormattedString read xInitText;
The obvious problem here is that xInitText is a forward reference to an
unexported variable.
Make a function to return a global variable does not make it read only.
If I use your function like this:
o := InitText;
o := nil; //this is the same xInitText = nil
Disagree. You are changing the value of o, not of xInitText. xInitText is
initialised once somewhere in the unit exporting it, subsequently its
properties etc. can be used elsewhere e.g. InitText.AppendFormatted(...).
I was right.
The o points to xInitText. If you release o the xInitText will
be release too.
But if you do:
o:=nil
...isn't the same xInitText:=nil, of course.
I did another test, see:
program test2;
{$mode objfpc}{$H+}
type
pmyrec = ^myrec;
myrec = record
a: integer;
p: pmyrec;
end;
var
r1: pmyrec;
r2: pmyrec;
begin
New(r1);
r1^.a := 1;
New(r1^.p);
r1^.p^.a := 44;
r2 := r1;
r2^.a := 2;
writeln(r2^.a);
writeln(r2^.p^.a);
Dispose(r1);
writeln(r2^.a); //ok, because a is an simple integer
In fact, this is not ok. Here you access memory which has been freed,
so the result is completely undefined (hence difference between Delphi
and FPC in your example above).
writeln(r2^.p^.a); // error, because p was released when r1 was
relesead too.
Just to be clear - memory pointed to by p has not been release, it is
still out there (you have to New-s and one Dispose), but you lost
reference to that memory because memory holding value of p was
released.
readln;
end.
I can access to primitive variables... but not to pointers.
Marcos Douglas
___
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] dynamic array contents and system.move
On Wed, May 5, 2010 at 07:34, Jürgen Hestermann juergen.hesterm...@gmx.de wrote: So why is it a problem, that one is a pointer, and the other not? Because it is easier, or more often overlooked. The problem is not that one is a pointer (to an array) and the other one is the array itself. That would be fine if it is told to the programmer that way and if it would be consistent. But then why am I not able to derefference this pointer with MyArray^? Why can I use an index on that pointer? In these cases it does *not* behave like a pointer but like an array. That's what makes it ambiguous. You do not use index on *pointer* but on *dynamic array* (as already explained). As of copying/moving array elements, why don't you use simple for loop for that, because that's what you actually want to do? I have used dynamic arrays for years, and didn't have these problems, because, when I want to say address of the first element, I write it: a[low(a)]. I don't *guess* nor I want compiler to *guess*. And thinking that address of dynamic array variable should be address of it's first element is plain *guess*. Unfortunately, wrong in this case. Move and Fillchar are low-level system functions, and they are perfectly logical, although little hard to understand :-) Just try to create dynamic array of dynamic arrays and used those functions on them, and you will understand. I, also, agree that FPC is far from simple Pascal language, but that fact is that FPC team needs to: 1) follow Borland/Inprise/Embercadero/... in their decisions; 2) try to add new language features which will give more power to the language; 3) maintain crossplatform-ness of the compiler (including adding platform-specific features); 4) keep RTL, FCL and other packages in a good and usable shape; ... Not really nice environment to mess around with such low level functions by adding special cases, isn't it? :-) -- Aleksa Todorovic - Lead Programmer Eipix Entertainment www eipix com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] deprecated syntax is inconsistent.
During my experiments with FPC, I had to to exactly that - support two lookahead symbols - to implement (in)famous semicolon before 'else'. One of problems I had was combination of macros and include files with two lookahead symbols - I fixed it in a dirty way, but I'm not completely sure that solution covered all possible situations. Just think of include directive which includes file in which there is macro which expands to 'deprecated'. That wouldn't be that easy with two lookahead symbols, because you would have to keep lots of data about both symbols (they could be in two different files, for example). Now, just think of refactoring in FPC on such low level - doesn't smell good at all :-) I would rather stick to on lookahead symbol even if that means inconsistent (subject to this discussion) syntax. On Thu, Apr 29, 2010 at 14:55, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On 29 April 2010 14:51, Florian Klaempfl flor...@freepascal.org wrote: Having a bigger lookahead makes a lot more things far more complex epecially in combination with include files, macros, generics. Why? You only apply the extra lookaheads where needed (code that could be ambiguous). All other parts of the code will be parsed as normal - as it is done now. So far I know of only two examples where extra lookaheads need to be used. * wiki example where 'default' is used * my example to fix the inconsistent syntax for hint directives (deprecated). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pas...@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Aleksa Todorovic - Lead Programmer Eipix Entertainment www eipix com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics problem/question
On Tue, Jan 19, 2010 at 18:35, Aleksa Todorovic alexi...@gmail.com wrote:
On Mon, Jan 18, 2010 at 04:07, Aleksa Todorovic alexi...@gmail.com wrote:
One (not very nice) way to have generic list of records is using
macros. I've extracted definition of TFPGList, made it ordinary type,
and did some search/replace, so I get:
[SNIP]
Just to report how I managed to (ab)use FPC and Lazarus to have both
generics of records and full code-completition (note I turned C-style
macros on for the whole project):
in interface:
TMessageParameter = record
...
end;
TMessageParameters = TList; // this makes Lazarus code completition
actually work; maybe better to use TFPSList
operator = (const A, B: TMessageParameter): Boolean;
{$DEFINE _TFPGList_Type_ := TMessageParametersFPGList}
{$DEFINE _TFPGList_ItemType_ := TMessageParameter}
{$INCLUDE fpglist_h.inc} // copied and adapted interface from FGL
{$DEFINE TMessageParameters := TMessageParametersFPGList}
// last line is used to make it all actually work
in implementation:
operator = (const A, B: TMessageParameter): Boolean;
begin
Result := ...;
end;
{$DEFINE _TFPGList_Type_ := TMessageParametersFPGList}
{$DEFINE _TFPGList_ItemType_ := TMessageParameter}
{$INCLUDE fpglist.inc} // copied and adapted implementation from FGL
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics problem/question
On Mon, Jan 18, 2010 at 04:07, Aleksa Todorovic alexi...@gmail.com wrote:
The proper solution for this problem is not simple. Somehow, you will
have to make operator = (const A, B: TPar) visible inside FGL unit
(because of the way generics are currently implemented), or make
compiler think that TPGList is implemented in the place where
specialization occurs (so compiler first searches specialization
space, and after that generic-declaration space).
One (not very nice) way to have generic list of records is using
macros. I've extracted definition of TFPGList, made it ordinary type,
and did some search/replace, so I get:
type
_TFPGList_Type_ = class(TFPSList)
type public
TCompareFunc = function(const Item1, Item2: _TFPGList_ItemType_): Integer;
TTypeList = array[0..MaxGListSize] of _TFPGList_ItemType_;
PTypeList = ^TTypeList;
PT = ^_TFPGList_ItemType_;
[original code from FGL unit goes here]
end;
constructor _TFPGList_Type_.Create;
begin
[...]
end;
[...]
Now, you insert code like this:
type
TPar = record
I: Integer;
end;
operator = (const A, B: TPar): Boolean;
begin
Result := (A.I = B.I);
end;
{$MACRO ON}
{$DEFINE _TFPGList_Type_ := TParList}
{$DEFINE _TFPGList_ItemType_ := TPar}
{$INCLUDE fpglist.inc}
{$MACRO OFF}
And you get list of TPar records!
Now, The Question is: should specialize construct also search
symbols defined in the place where specialization occurs, not just
those defined in the place where generic type is defined?
On the other hand, the only problem so far (regarding this matter) is
operator = on records. Maybe there should be special rule for this
situation?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics problem/question
On Fri, Jan 15, 2010 at 09:00, leledumbo leledumbo_c...@yahoo.co.id wrote:
Ah... I can see it now:
711 function TFPGList.IndexOf(const Item: T): Integer;
712 begin
713 Result := 0;
714 {$info TODO: fix inlining to work! InternalItems[Result]^}
715 while (Result FCount) and (PT(FList)[Result] Item) do
716 Inc(Result);
717 if Result = FCount then
718 Result := -1;
719 end;
This is where the = operator is required ( is derived from = ).
I continue the discussion in mantis, so that this can be solved (hopefully).
I've attached patch to mantis bug which makes compiler print error
about missing operator TPar = TPar. This could, at least, give
user some hint about what is wrong.
The proper solution for this problem is not simple. Somehow, you will
have to make operator = (const A, B: TPar) visible inside FGL unit
(because of the way generics are currently implemented), or make
compiler think that TPGList is implemented in the place where
specialization occurs (so compiler first searches specialization
space, and after that generic-declaration space).
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC class syntax was extended to support delphi code
On Wed, Jan 13, 2010 at 19:13, David Emerson dle...@angelbase.com wrote: d.2. wrt class methods, can they be virtual? (This strikes me as being closely related to d.1) Definitely, yes! (and I believe that was available before class vars/consts) I use this great feature for (de)serialization of messages in my client/server communication: TMessage = class public constructor Create; virtual; class function GetCode: Word; virtual; Code: Word; ... end; constructor TMessage.Create; begin Code := GetCode; end; So, when I want to create new message, I just call TLoginMessage.Create or TChatMessage.Create or whatever (those classes override GetCode, and everything works perfect). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is $fpctarget defined on all targets?
On Sun, Dec 6, 2009 at 17:13, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 06 Dec 2009, at 17:01, Aleksa Todorovic wrote: I've just started porting an application from Java to FPC (current targets are Win32 and Linux). I can successfully compile and run initial tests on both targets. The problem I have is with -FU parameter. When I execute fpc -FUunits/$fpctarget test_client on Windows, it correctly outputs .o, .ppu, .a and other generated files to units/i386-win32 (btw, I need to create directory i386-win32 manually). On Unix platforms, $x is used in shells to denote the contents of shell variable x. If x is undefined, it's considered to be empty. You therefore have to escape the $: fpc -FUunits/\$fpctarget test_client Ok, I understand. Thanks for your help! ___ 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 f...@xgelb.de 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] How to solve variable does not seem to be initialized compiler hint.
On Wed, Nov 18, 2009 at 17:58, Jonas Maebe jonas.ma...@elis.ugent.be wrote: What is the problem with fillchar? (other than that it prints a wrong hint in some cases. Also note that the difference between hints and warnings is exactly that hints are not guaranteed to be 100% correct or relevant in all situations; if they were, then they would be warnings. Hints are mainly intended to help you scrutinise your code more closely in case there's a problem you can't find, by flagging things that *might* indicate a problem. Getting all code hint free is probably not even possible (or desirable). You're completely right about that - there is nothing _wrong_ about fillchar. But if you have fillchar in, say, 20 places in your code, then you'll have to check all of those 20 places every time you build your project. And the idea of notices and hints is they are not to be ignored, but checked, isn't it? :-) As of myself, I don't really care if there will be new safe_fillchar_with_no_hints function or not - it is easy to encapsulate fillchar, as JoshyFun pointed out. Aside from that, fillchar is unsafe by its nature, so having hint whenever one uses it is good idea (as a side effect of uninitialized variable in this case). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve Conversion between ordinals and pointers is not portable
On Tue, Nov 17, 2009 at 10:05, Jonas Maebe jonas.ma...@elis.ugent.be wrote: Replace the PtrUInt types casts with PByte (or Pointer) type casts. Does that mean that (PByte(p) + N) = (Pointer(p) + N) for pointer-castable p and integer N? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar - AnsiString - PChar = memory leak?
On Thu, Oct 29, 2009 at 14:00, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Hi, Do I create a memory leak if I cast a PChar it a AnsiString. Then append text to the AnsiString and then cast it back to the original PChar? eg: var Text: Pchar; -- global var containing text. procedure AppendText(const AText: string); var s: string; begin s := Text + AText; Text := PChar(s); end; No, you don't create memory leak. But your code neither works, because s is local to AppendText, and PChar(s) becomes void after call to AppendText - memory used by s will be deallocated, and since PChar(s) = @s[1] Text would be invalid pointer. You will either need to convert Text to SomeString, or do manual (de)allocation. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Creating text files with TFileStream
On Fri, Oct 23, 2009 at 12:25, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Anyway, so now I'm back to square one - unable to create a plain text
file with TFileStream. :-(
What about:
TFileTextStream = class(TFileStream)
constructor Create...;
procedure WriteStr(const fmt: String; const args: array of const);
procedure WriteStr(const s: String);
end;
procedure TFileTextStream.WriteStr(const fmt: String; const args:
array of const);
var
temp: String;
begin
temp := Format(fmt, args);
Write(temp[1], Length(temp));
end;
procedure TFileTextStream.WriteStr(const s: String);
begin
WriteStr('%s', [s]);
end;
[written out of head, but it should work]
--
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] WORD (2 bytes) to String conversion
On Fri, Oct 23, 2009 at 14:10, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Hi, I'm reading in a WORD (2 bytes) from a binary file. I can display the Hex format of that value without a problem, but I would also like to display the String value of that WORD variable. It's the first 2 bytes of a file, which contains the magic number of the file. I would like my program to output the following: - Header Section header.ID (5348h = HS) ... - w: WORD ... YourString := Chr(Lo(w)) + Chr(Hi(w)) or YourString := Chr(Hi(w)) + Chr(Lo(w)) (depending on endianness) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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] Division by Zero: EDivByZero and EZeroDivide
On Sun, Oct 18, 2009 at 18:49, Jorge Aldo G. de F. Junior jagf...@gmail.com wrote: Wouldnt a NaN (Not a number) be more matematically correct result (I saw that on an old book about i387) Matematically division by zero is an mathematical impossibility, so NaN would be more logical Is there a way to deal with NaN's and other i387 (and similars) conventions directly in Pascal ? Take a look at SysUtils, functions IsNaN, IsInfinite. 2009/10/18 Tom Verhoeff t.verho...@tue.nl On Sat, Oct 17, 2009 at 01:57:28PM +0200, Bart wrote: Is there a reason why in fpc both floating point and integer division by zero raise an EDivByZero exception? See: http://docwiki.embarcadero.com/VCL/en/SysUtils.EZeroDivide SysUtils.EZeroDivide exception is raised when an application attempts to divide a floating-point value by zero. Note: Integer divide-by-zero errors raise the SysUtils.EDivByZero exception. Maybe because is more consistent to have one type for both exceptions - when you see it, you know what it means. How could anybody make distinction between EDivByZero and EZeroDivide without looking at documentation? It would be nicer if one had the ability to make floating-point division by zero return an IEEE 754 plus/minus infinity, without raising an exception. This is e.g. useful when one needs to evaluate rational functions. Without such an infinity, you need to make a nasty case analysis, which furthermore depends on the rational function. There is function SetExceptionMask in SysUtils which you can use to control which exceptions will be thrown at runtime. I haven't used it, but looks like a good place to start... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
On Mon, Oct 12, 2009 at 22:03, Vinzent Höfler jellyfish.softw...@gmx.net wrote: BTW, the expression @DynamicArray should really return the address of the first element, not the address of the pointer to the array structure. What's wrong with the current solution? the first element = DynamicArray[0] address of the first element - @DynamicArray[0] Makes perfect sense :-) It somehow destroys the abstraction. And I can't imagine any situation where the pointer might be of the interest for the user of the abstraction. That really doesn't matter. What matters is consistency. Pointer to variable X is defined as address of the first byte of memory where variable X is stored. If you work with pointers to complex data types, you have to be aware of internal structure. Otherwise, don't use pointers - they are evil anyway :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
On Mon, Oct 12, 2009 at 12:47, Jürgen Hestermann juergen.hesterm...@gmx.de wrote: No, it happens with static arrays, if you set pia := @ia, ia[x] and pia[x] will give you the same result (in delphi mode, at least). It's simply more readable and a shortcut. It's definitely the opposite: It is *less* readable This is your opinion :) To my experience faking arrays with dyn. size by using array declarations with infinite size (else you get in trouble with range checking) are much more error prone and unreadable than using pointers with an implicit dereference operator as arrays. As soon as you start using them like normal arrays (new, high, sizeof, passing them to open array parameters, no range checking) you get burned as well, even not taking care the extra declarations you need. What has the one thing to do with the other? It would have been easy to introduce dynamic arrays without hiding away its nature from the user. E.g. ansi- and widestrings or classes use implicit dereferencing as well and they proved to work very well. If someone uses low level operations like Move he should know what he does. That's just the point: Most users are left unclear about the nature of data structures and they start doing an trial and error approach (changing syntax as long as it is compiled). Then hope it will do what they intented. That's exactly C-style! Of course, there are some that look under the hood and know about the details and only these people are able to avoid such things as memory leaks or pointers pointing to freed memory and so on. The others stumble through it praying that it runs and as long as 80% procent works they are already satisfied. That's not the spirit of Pascal. The language should be clear and predictable from the start. I like the fact that Pascal introduced high level data structures (like dynamic arrays, automatic reference counting on string, etc), because they make your life much easier. It is true that you have to be careful when you mix these high level data structures with low level data structures (pointers) and low level functions (Move), but once you _learn_ and understand the nature of these structures, you get used them. You could equally say that we don't need arrays at all, because they could be represented as record of pointer to the the first byte of array, number of elements in array and size of one array element, but that's exactly what arrays are during compile time :-) Plus, you get type checking. See? When you really need some feature so much that you start coding it over and over (like dynamic arrays based on pointer to array), it makes sense to improve the language and the compiler. -- 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] Illogical automatic dereferencing
Also, it is very important to make distinction between static and
dynamic arrays. For static arrays, compiler knows their exact memory
location at compile time (modulo situations where static array is part
of another structure), but for dynamic arrays, compiler only knows
where in memory is reference (akka pointer) to the contents of that
array. So, if we wanted to have that distinction on syntax level, we
would have to use X[1] for static arrays and X^[1] for dynamic arrays.
Doesn't sound nice, does it?
On Sat, Oct 10, 2009 at 15:32, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
That link is talking about interchangability, which is not the same as
being
the same.
Yes, I'm just trying to explain that there's no magic to it,
illustrated by some basic pointer arithmetic.
I think there are several bits that mix in this thread:
1 nearly all types that don't fit in registers are in memory, and you need
a memory access to reference them. This makes them all
references/pointers/addresses on assembler level, but not necessary pointers
on language level.
2 The fact that Delphi mandatory skips a ^ when indexing a pointer + array.
3 The fact that FPC allows both in objfpc mode. (which means)
4 The fact that FPC and Delphi allow pchar to be overindexed.
5 The fact that FPC and Delphi 2009+ with {$pointermath on} also allow it
for other pointer types.
Note that I write this from memory after porting some FPC bits to Delphi
last week. Most notably the {$pointermath on} (5) and the mandatory aspect
of (2) might be related.
___
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] two small ?s - high(real) and nearest 2^x
On Sat, Oct 10, 2009 at 20:58, Matthias K. maka...@googlemail.com wrote: On Sat, Oct 10, 2009 at 7:14 PM, David Emerson dle...@angelbase.com wrote: 2. For the purposes of reserving memory in block sizes that can be easily reallocated, I like to use powers of two. So if I have, e.g., a dynamic array, I might start with a size of 1024 and then double it when it hits capacity. Hopefully this smoothes memory management, as I am using a lot of memory... Anyway, what I'd like is a simple function that can quickly identify the next power-of-two larger than an arbitrary number. So if I feed the function 472, it will return 512. Thus far I haven't been able to figure out how to do this without a big if-then-else nest. Is there some clever way to request that the processor return the position of the leftmost '1' in 00101101? invalue := 412; -- outvalue := 1; while invalue 0 do begin invalue := invalue div 2; outvalue := outvalue*2; end; -- On x86 processors, there is bsr instruction which finds index of the most significant bit set. You just need some simple asm coding to use it. regards, Matthias ___ 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] $IF documentation - missing help
Maybe
{$IF Defined(VER2_3) or Defined(VER2_4))
...
{$ENDIF}
?
On Tue, Sep 15, 2009 at 13:26, Graeme Geldenhuys
grae...@opensoft.homeip.net wrote:
Hi,
Where is the extended $IF directive documented. The prog.pdf has 2
paragraphs on $if and then referes you to the conditionals section.
But the Conditionals section is incomplete.
I look through all these docs...
prog.pdf ref.pdf user.pdf
What I am looking for is something I used years ago, but can't find an
example of it now. I can't remember the exact syntax, but is was
something like this:
{$IFDEF FPC $IF Defined(VER2_3) or )
...
{$ENDIF}
Due to the mishaps with UnicodeString in FPC 2.3.1, I need to IFDEF some
tiOPF code so that certain code will only work with FPC 2.2.5 and
earlier, and other code will only work with FPC 2.3.1 and greater. How
do I write this?
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
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
[fpc-pascal] IE 200307043
Hi, all! I've just tried to compile some of my old Pascal code, and got IE 200307043. I've tried both 2.2.4 and svn trunk versions. Simple program to generate it: program test; var p: Pointer; begin p := nil + 1; end. I couldn't find issue about this in bug tracker, should I report it? Best, Aleksa ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
So, the situation is like this: 1) Target ARM architecture needs to be told to FPC since FPC needs this information to do correct code generation. 2) FPC does not inform GNU assembler of intended ARM architecture for which assembler code is generated for, which doesn't prevent GNU as from generating correct binary. 3) GNU as doesn't check if FPC-generated instructions are valid, because it does not know target architecture for which it is assembling. But (as stated in previous point), GNU as is still able to generate correct binary. Correct? Greets, Aleksa On Mon, Dec 8, 2008 at 22:18, Jonas Maebe [EMAIL PROTECTED] wrote: On 08 Dec 2008, at 22:00, Prince Riley wrote: Answer: it does not inform the GNU assembler back end of which ARM architecture is intended. The code generator is not the GNU assembler backend. 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] Any good Pascal interpreter?
Have you tried PascalScript? http://www.remobjects.com/ps.aspx -- Aleksa Todorovic Lead Programmer Eipix, Game Develoopment Company www.eipix.com On Wed, Nov 5, 2008 at 07:46, leledumbo [EMAIL PROTECTED] wrote: Better if it supports FPC dialect, too. -- View this message in context: http://www.nabble.com/Any-good-Pascal-interpreter--tp20336843p20336843.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ 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] Can I make this with Free Pascal?
On Tue, Sep 23, 2008 at 08:46, Graeme Geldenhuys [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 11:38 PM, markweber [EMAIL PROTECTED] wrote: I have thought graphics software needed to deal with video card and so, and needed to make very powerful calculations. If you say it's a software as any other, so that's right. CAD type programs take video card hardware into account to speed up the calculations considerabley. The GPU is very powerful and fast, when it comes to graphic calculations. But in the end, those calculations could also be done with your normal CPU and software - although somewhat slower. As well as games. I'm using FPC fpImage in my multimedia/game engine, and it works perfectly - PNGs, JPEGs, BMPs, TGAs - you name it, fpImage works flowlessly. One thing that could be improvemed in fpImage is it's internal format - it would be really helpful if one could choose between bytes and words (maybe even Longwords/Qwords ?), as well as order of components (RGBA vs BGRA). Several defines (plus lot of changes) should do the job. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
