At 05:27 PM 10/11/2009, Mark Emerson wrote:
Remember, Pascal is merely a TEACHING language, unsuitable for commercial
software development, which is why we have C. :)
Yeah, right... >:-}
Ralf ;-)
___
fpc-pascal maillist - fpc-pascal@lists.free
Remember, Pascal is merely a TEACHING language, unsuitable for commercial
software development, which is why we have C. :)
On Sunday 11 October 2009 05:00:04 pm Ralf A. Quint wrote:
> At 03:25 PM 10/11/2009, Graeme Geldenhuys wrote:
> >I came across this link by chance. Wow, I never knew there w
At 03:25 PM 10/11/2009, Graeme Geldenhuys wrote:
I came across this link by chance. Wow, I never knew there was that
many Pascal Compiler implementations. A lot!
http://pascaland.org/pascall.htm
Well, reduce it to the compilers that are still maintained, and the
list is far less impressive...
Henry Vermaak :
> You said C did it "wrong", because you think that arrays and pointers
> should be different things.
No, I said so, because arrays and pointers *are* different things (even in C
there are subtle differences - which should sort of prove my point).
Apart from that, I expect my re
mar...@stack.nl:
> > That simply means, the code is not documented. Again: Not entirely C's
> fault.
>
> Docs. Like anybody reads them.
Well, I do. If the coder cares to write any, that is. :)
Vinzent.
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer,
I came across this link by chance. Wow, I never knew there was that
many Pascal Compiler implementations. A lot!
http://pascaland.org/pascall.htm
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net
Andrew Brunner :
> 1st benefit:
>
> declaring methods associated with classes before TIntArray needs to be
> defined or declared.
> eg. procedure DoSomething(Var Data:TIntArray); vs (DataP:PIntArray);
Huh? Is there any difference other than the second one can take a NIL value?
> Lastly, passi
On Sun, 11 Oct 2009 11:09:58 +0200 (CEST), mar...@stack.nl (Marco van de
Voort) wrote:
> In our previous episode, Matthias Klumpp said:
>> > also be in 2.4.0
>>
>> I do not have problems with FPC 2.3.x, but it is not allowed for me to
>> use
>> experimental SVN software :-(
>> Early next year soun
On 11/10/2009, Andrew Brunner wrote:
> FPC forces the ^ operator while accessing structures as pointers.
> Delphi didn't force it and I even suspect that memory leaks can result
> in NOT using the ^ to denote the reference to the pointer rather than
> the pointer itself.
This was just discuss
Henry Vermaak schrieb:
> 2009/10/11 "Vinzent Höfler" :
>> Henry Vermaak :
>>
>>> Thanks for the explanation, I was under the impression that arrays in
>>> Pascal were similar to C. How do you explain the "automatic"
>>> dereferencing with a pointer to an array that Jürgen is talking about?
>> Thos
2009/10/11 "Vinzent Höfler" :
> Henry Vermaak :
>
>> Please don't confuse your opinion with "right" and "wrong".
>
> It's not just my opinion, that arrays and pointer are different things. One
> might say it's a fact.
You said C did it "wrong", because you think that arrays and pointers
should be
In our previous episode, "Vinzent H?fler" said:
> > 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.
>
> Yes. But that's not the fault
Marco van de Voort :
> 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.
Yes. But that's not the fault of the C-language. That's the fault
Henry Vermaak :
> Please don't confuse your opinion with "right" and "wrong".
It's not just my opinion, that arrays and pointer are different things. One
might say it's a fact.
> Confusion and consistency were what this discussion was about.
Confusing code may have many properties. But I doubt
In general I use pointers to data structures and especially when they
are arrays.
Take the following
PIntArray: ^TIntArray;
TIntArray:Array of Integer;
1st benefit:
declaring methods associated with classes before TIntArray needs to be
defined or declared.
eg. procedure DoSomething(Var Data
2009/10/11 "Vinzent Höfler" :
> Henry Vermaak :
>
>> 2009/10/10 "Vinzent Höfler" :
>> > Henry Vermaak :
>> >
>> >> One thing I think you don't understand is that an array _is_ a
>> >> pointer. Look at this table to visualise:
>> >>
>> >> http://en.wikipedia.org/wiki/C_syntax#Accessing_elements
>>
On Sun, Oct 11, 2009 at 02:01:35PM +0200, "Vinzent H?fler" wrote:
> > >
> > > So technically, C is the one who got it wrong.
> >
> > Wrong and right are absolute terms.
>
> Yes. And first mixing arrays with pointers and then telling everybody that
> this is just the same is - wrong. Absolutely.
2009/10/11 Graeme Geldenhuys :
> On 11/10/2009, Henry Vermaak wrote:
>> >
>> > Sizeof(X) is 10 bytes.
>> > Sizeof(PX) is 4 bytes.
>> >
>> > Still you can use X[1] and PX[1]. That's illogical.
>>
>>
>> I've tested this now and could only get this behaviour with {$mode delphi}.
>
> So what did
On 11/10/2009, Henry Vermaak wrote:
> >
> > Sizeof(X) is 10 bytes.
> > Sizeof(PX) is 4 bytes.
> >
> > Still you can use X[1] and PX[1]. That's illogical.
>
>
> I've tested this now and could only get this behaviour with {$mode delphi}.
So what did the other modes return? objfpc?
--
Regar
2009/10/11 "Vinzent Höfler" :
> Henry Vermaak :
>
>> Thanks for the explanation, I was under the impression that arrays in
>> Pascal were similar to C. How do you explain the "automatic"
>> dereferencing with a pointer to an array that Jürgen is talking about?
>
> Those are dynamic arrays, IOW poi
2009/10/10 Jürgen Hestermann :
>> 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 : ^ArrayT
Henry Vermaak :
> 2009/10/10 "Vinzent Höfler" :
> > Henry Vermaak :
> >
> >> One thing I think you don't understand is that an array _is_ a
> >> pointer. Look at this table to visualise:
> >>
> >> http://en.wikipedia.org/wiki/C_syntax#Accessing_elements
> >
> > One thing I think you don't underst
Henry Vermaak :
> Thanks for the explanation, I was under the impression that arrays in
> Pascal were similar to C. How do you explain the "automatic"
> dereferencing with a pointer to an array that Jürgen is talking about?
Those are dynamic arrays, IOW pointers disguised as arrays. This is part
mar...@stack.nl:
> In our previous episode, "Vinzent Höfler" said:
> >
> > One thing I think you don't understand is that arrays and pointers are
> > orthogonal concepts in almost every other programming language than C.
> >
> > So technically, C is the one who got it wrong.
>
> Wrong and right
Hello,
> 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
>
In our previous episode, Matthias Klumpp said:
> > also be in 2.4.0
>
> I do not have problems with FPC 2.3.x, but it is not allowed for me to use
> experimental SVN software :-(
> Early next year sounds good!
It's not experimental anymore, it now has a "fixes" branch label :-)
__
Graeme Geldenhuys schrieb:
>
>
> 1) Why would you use a pointer to an array and not simply a variable
> what IS the array? In the program I am porting the following field
> variable is defined.
>
> FLines: ^TLinesArray;
>
> Why couldn't I simply say:
>
> FLines: TLinesArray;
Because thi
Hi,
The other "arrays" discussion got me thinking, and after working so
long with only desktop type applications that talk to database API's,
I long some knowledge of the lower lever Pascal features that was so
often used in Turbo Pascal days.
Anyway, I'm port an application that was written for
28 matches
Mail list logo
