AFAIK there has to be some fixed part before the variant, e. g.
TFigure = record
name: string;
case TShapeList of
Rectangle: (Height, Width: Real);
Triangle: (Side1, Side2, Angle: Real);
Circle: (Radius: Real);
Ellipse, Other: ();
end;
The program could then
Jorge Aldo G. de F. Junior schrieb:
type ifreq = record
ifr_ifrn : record
case longint of
0 : ( ifrn_name : array[0..15] of char );
end;
ifr_ifru : record
case longint of
0 : ( ifru_addr : sockaddr
IIRC, there is a difference. With the second declaration the compiler
can add a run-time check that the correct memebrs are accessed based
on the value of X.
Unfortunately, I cannot find the compiler switch.
FPC has no support for this.
And I don't know any other Pascal Compiler who does any
Given that the OP was asking about learning, maybe it would be worth
mentioning that the way we normally have data structures which hold
different data these days is by polymorphism in objects or classes.
Instead of having an array of variant records, each of which might hold
a description of a
And I don't know any other Pascal Compiler who does any checks in this
direction. Do some?
I don't know, but ADA reportedly does.
I don't know the differences to Pascal. Does it have the same syntax for
variant records?
Such a feature definitely seems useful to me.
Of course it would
Its a common mistake to use @dynamic array var instead of @dynamic
array var[ 0 ].
IMO this happens because of an illogical design flaw (which seems to be
introduced by Borland). If I have a variable that is a *pointer* to an
array then why is it possible to use the square brackets to use it
This behaviour comes from C syntax. The array is a pointer, which you
dereference by using the square brackets. This is well defined
syntax, nothing automatic or illogical about it. The only reason
pascal programmers make mistakes with this is because they are less
accustomed to using
I can't understand what you are trying to say. An array is a pointer
to where the elements of the array resides in memory. How else do you
think it works?
just look at:
type ArrayType = array[1..10] of char;
var X : ArrayType;
PX : ^ArrayType
What is the difference between X and
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
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
You said C did it wrong, because you think that arrays and pointers
should be different things. That is indeed you opinion, not a fact.
I don't even know why I'm replying any more, it's clearly futile.
Huh? Are you seriously trying to tell us that pointers and arrays are
the same? Ok, then
As said it depends from your viewpoint. C's original viewpoint was to keep
the state of a compilation unit as small as possible, to maximize the size
of a program with limited memory.
You mean they gave saving one character in the source code a higher
priority than having a strict logic in the
And the criticism about introducing Cisms in FPC/Delphi is also old. In the
past I would have joined you, but after a few non-trivial header conversions
and library conversions that pretty much died out.
But why are you then using Pascal at all? I love this language because
of its strict logic
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 because it leaves it
unclear what data you are operating with.
Remember, Pascal is merely a TEACHING language, unsuitable for commercial
software development, which is why we have C. :)
And why should that be the case? What are the outstanding feature of C
that make it so supperiour? It's illogical and hard to maintain syntax?
Or is it just that it was
Yes, it is available everywhere.
And it is easier to copy unix code then.
Remember that it is still not easy to come to freepascal.
You have to configure a debian testing system and apt-get lazarus and so on...
Nearly nowhere the lazarus package is preinstalled.
Yes, these are the reasons for
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.
p
The value of a pchar.
What do you mean by value? The pointer or the character it is pointing
to? It seems that p sometimes means the first and sometimes the latter.
p^
the char pointed to.
Is this the same as p?
I don't think you can say anything from pure syntax without bringing
C is popular *even though* it is an awful concept.
It is like the video cassettes.
Betamax and Video2000 were the better quality,
but VHS was the most popular cassette.
Yes, sadly this is true (same with Microsoft pressing one awfull OS
after the other into the market). Not always the best
The beauty of the current solution is that static and dynamic arrays can
be substituted with each other, simple by changing the declaration, and
adding/removing a setlength. All other code can be left as it is.
If you needed the ^ for dyn arrays everywhere, then you would have to
make huge
Guillermo Martínez Jiménez schrieb:
I really don't understand why Pascal should include C-style stuff.
PASCAL IS DIFFERENT LANGUAGE THAN C. STOP.
I fully agree with all you said but Borland created these Pascal
extensions and now we cannot go back (as others say) because we need
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]
You only find this
About pointer arithmetic:
IMO memory is an array. So for me it is quite natural that P^ and P[0]
are the same.
You are missing the point. If you already *know* that you are dealing
with a pointer (to an array), then of course you may use this workaround
(it's nothing else, because if I want
Florian Klaempfl schrieb:
Great power comes with great responsibility.
Yes. Then use C or assembler. You are responsible for everything and
you cannot expect any help from the compiler.
So the consequence would be to forbid pointers/@-operator/type casts et.
al.
No. Only the logic has be
Now I know why vendors of newer languages (Dephi, Java etc) are trying
to hide pointers from programmers. They are very tricky to work with -
and give errors without warning!
Especially when compiler and programmer are both trying to outsmart each other.
:D
Yes. But I never needed pointer
There is not even a proper open one for Delphi. At least there wasn't till a
while back.
That may be because it is no longer possible to write a BNF grammar for
these compilers due to the c-style extensions.
___
fpc-pascal maillist -
Sorry, I misread the mail, I thought it was about bitpacked arrays.
Plain packed arrays are no different from regular arrays in FPC (we
basically ignore that modifier, except in MacPas mode where it's an
alias for bitpacked), so the packed monicker can simply be left out
when declaring the
You can post an ad for a C
programmer and get 1,000 applicants, if you post an ad for a Pascal
programmer you might get 5, at least where I live.
Yes, that maybe true. But how has all this started? As far as I know, C
was not that popular in past (at least not on Windows). Instead (Turbo)
A quick study of some language reference docs and a few examples
should be all you need to get started.
The general rules are easy to learn. But to be productive you also need
to know about environments (IDE etc.), available libraries and their
usage (which already differ between Delphi and
Is there a way to deal with NaN's and other i387 (and similars)
conventions directly in Pascal ?
Yes, if not yet possible (I didn't have a closer look) I would like to
have that too. But I think it's heavily depending on the processor...
(Details about NaN's and infinity at
I would like my program to output the following:
-
Header Section
header.ID(5348h = HS)
...
-
Wouldn't it be more direct to use
Blockwrite(file,header.ID,sizeof(header.ID));
That would make it robust against changes of ID size and would avoid the
many
As Marco suggested... Char size might not always be the same.
Why that? I hope noone changes the meaning of such long-time types some
day. If a new type is needed, then it should get a new name too.
___
fpc-pascal maillist -
is there actually someone using INDY10 with FPC on other
platforms than windows? version of IINDY, FPC, OS?
If not - is there someone interested in it - or are the alternatives
suiting your needs? If so - what are you using?
I use Ararat Synapse (http://ararat.cz/synapse/doku.php). Works fine
function SerRead(Handle: TSerialHandle; var Buffer; Count: LongInt): LongInt;
begin
Result := fpRead(Handle, Buffer, Count);
end;
i don't understand the
declaration for buffer in the function below, because no type is
declared for buffer.
I believe that the type is irrelevant, you
In
general we try to be Delphi compatible as much as time and
backward compatibility permits.
I hate it if bugs or illogical things are copied from Delphi. It may be the
case that Delphi vanishes one day. Then we still would have all these bugs in
FPC/Lazarus cast in stone forever. I think
In my humble opinion, there are no problems with the FillChar declaration. But
the way you wrote your _absolutely correct_ code produced a hint. You shold use
$HINTS OFF, for amendment to the FillChar declaration seems to be done unlikely.
But there is a reason for the hints. It should point
begin
{$PUSH}
{$HINTS OFF}
FillChar(x,count,Value);
{$POP}
end;
Shouldn't this code too raise a warning?
No, that's what the {$HINTS OFF} is used for - hiding the compiler hints
warnings.
But isn't the warning raised when x is used as a parameter of a function? The
problem is, that
But I agree with Jonas. The problem is the obsession to eliminate each and
every warning, not the hint/warning.
In general this is true. But in this particular case (fillchar) it should be
easily possible to avoid the hint message. I am not sure why it is such a
problem to change the
That's the idea of hints. Telling you you need to look at the code once,
and if it's ok = good. But if the hint was correct = fix it.
But if you later change your code it may become not ok again. I don't think
that this is good working practice. I would prefer to have the compiler
recognize
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
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
I have been trying to compile a simple test program and I keep getting
the following errors:
c:\lazarus\fpc\2.2.4\bin\i386-win32\windres.exe: can't open file
`project1.manifest': No such file or directory
I am about a week ahead of you with Lazarus, and I struggled
with that error too. It seems
Juha Manninen schrieb:
const
a: array of string = ('aaa', 'bbb', 'ccc');
It looks like a dynamic array, but obviously is not dynamic because it is
constant. :-)
The indexing would start from 0 like with dynamic arrays.
It would not break the existing syntax and would be very intuitive.
Rainer Stratmann schrieb:
Pascal has better ways to deal with array bounds.
But at this moment it is not possible to make a const array with auto
calculated range ( [ 1..] ). It would be easy to implement, I think.
But these things are not related. Calculating array bounds should
not be
y := case Other of
bla : 'hello';
foo : 'bye';
baz : 'adius';
end;
What do you gain with this?
Doesn't look much different to
case Other of
bla : y := 'hello';
foo : y := 'bye';
baz : y := 'adius';
end;
y := case Other of
bla : 'hello';
foo : 'bye';
baz : 'adius';
end;
What do you gain with this?
Doesn't look much different to
case Other of
bla : y := 'hello';
foo : y := 'bye';
baz : y := 'adius';
You are looking at the wrong example! Clearly, for variable assignment
you don't gain anything. But for a function argument you do!
Realy?
WriteLn('The value is ',(if X then 'true' else 'false'),
' at the moment.');
Well, *this* can be done much easier ;-):
Frank Church schrieb:
I recently posted a question about problems involving the use of
string and AnsiString when converting a Delphi program. Are the some
situations where substituting AnsiString for string will result in
errors?
The string type is a generic type and can be ShortString or
Jorge Aldo G. de F. Junior schrieb:
actually, for most porpuses, ansistring is a lot faster than normal
strings with size 255...
you pass around 4 bytes instead of 256...
That would be only true if you have multiple variables pointing to the same
string without changing each instance. I don't
{$i-} reset(dat);{$i+}
if ioresult 0 then
rewrite(dat);
Although not wrong, the purpose of this construction is not clear to me.
In every case you will end up overwriting all data in the file.
In that case you could simply do with a rewrite(dat). The reset(dat)
is really not
Although I don't see the purpose of the above code snippet there is a
difference between existing and non-existing file:
If dat exists (and can be opened without error) then the rewrite is not
done. So in this case dat is only opened for reading and existing data is
not deleted (yet).
That
David Emerson schrieb:
I *am* checking sizes before the move, which is why it surprised me that things
were going out of bounds -- the trouble is I forgot the array index [0]
Yes, that happens quite often. Unfortunately, Borland gave up the clear und
predictable context independend Pascal
Florian Klaempfl schrieb:
Simply because dereferencing a dyn. arrays makes no sense because
it is more than just a simply data collection.
Realy? What else is happening in the background?
This is plainly wrong. When indexing a dyn. array, the compiler
generates the correct code to access the
It would be possible to allow this syntax :
move(data ...
in addition to the current :
move(data[0] ...
There is no fundamental reason why it wouldn't be possible.
There is: there is no reason why move should be handled differently than other
procedures.
But currently move *does* handle
Simply because dereferencing a dyn. arrays makes no sense because
it is more than just a simply data collection.
Realy? What else is happening in the background?
Reference counting (also of the stored data), automatic length storage.
But that has nothing to do with the fact that the
But currently move *does* handle dynamic arrays differently than other
procedures.
It handles it exactly the same as any other function/procedure that takes a
untyped/formal var parameter. Formal var parameters always take on the
address of whatever you pass.
That's not true! There is a
I think there is a great difference between normal arrays and dynamic ones
Yes, but it should not be like that. If you first declare a static array and
then decide to make it a dynamic array then *no* code change should be
required. But now it is for move and fillchar.
is OK, but in
True. As I said: There is no common logic what the identifier MyArray
means if it is a dynamic array (but there is for static arrays).
It means the whole array (which is an opaque type). No more no less.
Then it should be possible to use MyArray as a parameter for move/fillchar
but obviously
But currently move *does* handle dynamic arrays differently than other
procedures.
It handles it exactly the same as any other function/procedure that takes a
untyped/formal var parameter. Formal var parameters always take on the
address of whatever you pass.
That's not true!
Well, it is.
Then it should be possible to use MyArray as a parameter for
move/fillchar but obviously this is not the case.
No. Because it does not mean the *array's data* but the *array*.
So it doesn't mean anything? What exactly is the *array* if not it's data?
There is a lot of ambigouity with dynamic arrays.
There certainly is if you expect them to work like regular arrays. They are a
quite different datatype.
At least it should always mean the same independent from context.
It does always mean the same, just like a class instance always means the
A file type is actually also a record and you cannot access the fields
without an explict type cast.
At least a file identifier always means the same memory address (where the
record data is stored). If needed (for some special purpose) I *can* typecast
it because I know the address of the
I agree that the introduction of managed data types is inconsistent with
previous Pascal data types. Perhaps it is a design flaw to have changed
the semantics of reference-counted data types. Perhaps not.
Nevertheless, it has been this way for many, many years and will not be
changed at this
At least a file identifier always means the same memory address (where
the record data is stored). If needed (for some special purpose) I *can*
typecast it because I know the address of the data (@myfile). But when
using the identifier of a dynamic array then this identifier does not
always mean
At best, one day we may add GPC-compatible array schema types (see
http://www.gnu-pascal.de/gpc/Schema-Types.html, the part under As a GNU
Pascal extension, the above can also be written as). These don't hide
anything.
Yes, that looks good as it does not violate the rule that an identifier
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
And as also explained in my original mail: An array does not guarantee
that the identifier(stand alone) can be used for the first element.
That's just the root cause of the problem: An idenifier should *always* mean
the same address in memory. Otherwise you cannot use such low level functions
I personally hate 0-based counting because no
human counts 0, 1, 2 etc.. so why must computers?
Yes. That's my feeling too. Zero-based arrays/lists always generate trouble
because of substracting or adding one in many places. It makes code much less
readable.
But because 0-based is so
In the first place it is. But if it would be available, the crowd may
change its mind.
No, she won't. She never did.
Of course she did! Just look at trends in programming languages (and styles) of
the past. How can you say that nothing will change ever.
Jonas Maebe schrieb:
...
Of course she did! Just look at trends in programming languages (and styles) of
the past. How can you say that nothing will change ever.
Please take this sort of discussions to the fpc-other list.
What sort of discussion? Is it only me or do you censore other mails
Roger Bailey schrieb:
OK, I give up. How do you handle standard input and output files in FPC? When I
write something like:
nextcharacter := input^
I get error: 1: Illegal qualifier. Does FPC not support this standard Pascal
feature?
I have never seen such a syntax before.
Jonas Maebe schrieb:
because a directory on a unix platform can perfectly contain
a semi-colon.
That applies to Windows too.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
e:)
* What is type checking _actually_ useful for?
I would be lost without type checking,
especially when using sophisticated data structures
like pointers to arrays of records (which again
contain pointers to other complex structures).
An example:
type ArrayType = array[1..10] of SomeType;
Now, it is easy for the compiler to guess such cases.
I don't want the compiler to guess at all.
Some languages perform automagic deferencing of pointers to structured types
(record/object, array), meaning eg
p.x
is interpreted as
p^.x
and
p[i]
is interpreted as
p^[i]
Paul Michell schrieb:
I realise that 'Array Of Single' declares a dynamic array, but is there
any equivalent syntax for static data arrays in the same way that
strings litterals are in effect, variable length static declarations.
You have to realize, that dynamic arrays are actually
spir schrieb:
Sure, but this is just a matter of convention and support by a given compiler:
typeIntegers = array of Integer;
var ints : Integers = [1,2,3];
could work as expected by automatically sizing, allocating and initialising.
How else could work languages that have an
stefan...@web.de schrieb:
My experience is that linked lists with pointers are much slower than linked lists realized by arrays.
That's my experience too. I converted a few programs from linked lists to array
of pointers and the speed increase was always dramatically.
Sven Barth schrieb:
It's enough code, because FillByte (and others) are defined with a var
parameter and such the hint (not a warning) won't go away.
It's an old topic already and we have just to live with it (regarding
the Fill* functions). ^^
But why not simply change the definition of the
Sven Barth schrieb:
But why not simply change the definition of the variable to out?
Then the
Fill* functions would be recognized as initializing routines.
No, see http://bugs.freepascal.org/view.php?id=17020
@Jürgen:
That's what I meant, when I said it's an old topic. ;)
Yes, I see now.
Sven Barth schrieb:
FPC requires the full declaration to be repeated. Can this be avoided
somehow? I have many functions/procedures without full declaration in
the implementation part.
Add
{$mode delphi}
I would not suggest to use {$mode delphi}
but {$ModeSwitch REPEATFORWARD+} instead.
This
Reimar Grabowski schrieb:
for (int i = 0;...)
Can't see anything wrong. I use declaration of variables inside blocks quite often in Java and C++
but have never missed it in pascal. Please enlighten me. What is so bad about creating temporary variables
inside blocks instead of the beginning of
Rob Kennedy schrieb:
Write that into your local coding guidelines and
enforce it in code reviews, not the language spec.
This argument can be used to promote each and every change, no matter how
obscure it is.
But you forget that you may be forced to read code from other people in which case
andrew.benn...@ns.sympatico.ca schrieb:
After using BlockRead to fill a 2D dynamic array, I get an access violation on the
very first reference. A 2D array with only one dimension dynamic works OK.
What am I missing?
Maybe you blundered into the same trap as so many others who do not know
Matt Emson schrieb:
Native is bad, and only come in to existence to compete with other
platforms with purely native compilation -
I disagree. Just the opposite. There were already lots of attempts to
create a processor independend programming layer (i.e. USCD-Pascal with
the p-code in the
STat = Array[0..W-1] Of Single ; { Static array }
DST = Array Of STat ; { One dimension dynamic, the other static }
D2T = Array Of Array Of Single ; { Two dynamic dimensions }
STat always means the address starting with STat[0] (context
independend).
Also DST always means the address where
Luis Fernando Del Aguila Mejía schrieb:
p:=pointer(cad1);
p:=p-8;
Write('memory address : ',longint(p),'='); //Must show Size, but
shows reference count
Writeln(longint(p^));
I fail to see why you need to mess with the internals of ansistrings at all.
What is the reason to access
Luis Fernando Del Aguila Mejía schrieb:
My intention is to understand the inner workings of the compiler
I agree with you that such knowledge is imponderably useful.
Any help information should explain this in detail. Then
you can predict much easier what happens in the background
and decide
In the file \lazarus\fpc\2.4.3\source\rtl\inc\systemh.inc I found the
following definitions:
{ file input modes }
fmClosed = $D7B0;
fmInput = $D7B1;
fmOutput = $D7B2;
fmInOut = $D7B3;
fmAppend = $D7B4;
Filemode : byte = 2;
If I assign Filemode := fmInOut I get a constant range check
Jonas Maebe schrieb:
On 17 Mar 2011, at 19:07, Jürgen Hestermann wrote:
If I assign Filemode := fmInOut I get a constant range check error (at
compilation time) which is clear because all constants are larger than byte.
Is this a bug?
No. See http://www.freepascal.org/faq.var
Jonas Maebe schrieb:
I didn't find fminout and the other constants mentioned at this link.
It describes the values you can assign to filemode and their effect.
Does that mean, that only 3 values for filemode (0, 1 and 2) exist?
Then it is quite confusing to group the filemode declaration and
Ingemar Ragnemalm schrieb:
Converting bad C code (that means almost any C code)
to good FPC code is a great thing to do, converting to bad FPC code is
not as much fun.
Yes, when already in progress of converting to Pascal then get rid of C
design flaws and convert to clear Pascal code.
I just wanted to post a warning for everybody who wants to
(block)write/read dynamic arrays to/from file. All the documentation
about dynamic arrays I found only told me what I *can* do with them but
none said what I can *not* do. And there was no detailed information
about the internal works.
Jonas Maebe schrieb:
If you Blockwrite a dynamic array pointer to file (i.e. because it
is part of a large record) and read it back later with Blockread then
the pointer value is invalid of course. BUT, if you now try to set it to
nil as in
DynArray := nil;
then Free Pascal seems to free
I would never expect an assignmet to nil changing anything else than
just the value of the pointer. And for (all?) other pointers this
expectation is valid.
That expectation is not valid for any reference counted type (be it a
dynamic array, ansistring, unicodestring, COM-style interfaces).
DaWorm schrieb:
IMO, a dynamic array should never be part of a structure that is
passed to BlockWrite in the first place. Not that I use many dynamic
arrays in the first place, but to me they pass over the border between
simple data types (that are fine for BlockWrite) and managed data
Jonas Maebe schrieb:
If you don't want the compiler to interfere with anything you do, do
not use automated types such as ansistring, unicodestring, dynamic array
and COM-style interfaces. The whole point of these types is that the
compiler will do lots of stuff behind your back, because
Darius Blaszyk schrieb:
Is there any way to initialize object variables, other than writing an init
method?
So something like:
myobj = object
myvar: word = $;
end;
I don't think so.
An object is a pointer to a data structure on the heap.
At compile time, this data structure is not
Luis Fernando Del Aguila Mejía schrieb:
Var LCad:^ansiString;
AnsiString is already a pointer. LCad is now a pointer to a pointer.
That should read
Var LCad: AnsiString;
getmem(LCad,5*3); //ansistring is a pointer 4 bytes
The memory allocation and freeing is done by the compiler
José Mejuto schrieb:
Add at beginning {$H+} to switch on ansistrings, otherwise you are
using shortstrings which are 255 characters in length at most, and
your lines are around 300 chars.
Instead of using obscure compiler switches (where you never know for
sure the scope and whether they
ZHANG Dao-yuan schrieb:
E.g.
function f0: boolean;
begin
f0:= false;
end;
begin
f0;
end;
the returned value f0 is dropped.
Compile it and the compiler won't print any warning.
Yes, of course. What do you expect? If you don't use the return value
for any purpose it is dropped.
101 - 200 of 384 matches
Mail list logo
