Feel free to create TrollPascal 1.0 :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
When messing with pointers you've to know what to write because pointers
allow unlimited access to internal data structures.
That's not the point. It is very easy to use pointers if they behave
like this but not if they are used as if they are arrays. I need a fixed
and unambiguous syntax for
In our previous episode, Florian Klaempfl said:
> > understanding how pointers work, but a simple case of a typo which
> > couldn't be caught anymore by the compiler due to this extension.
> >
>
> What is the alternative?
Support D2009 {$pointermath on/off} that governs this, with the default as
Florian Klaempfl wrote on Tue, 13 Oct 2009:
Jonas Maebe schrieb:
I think that "all pointers can be indexed as arrays" can easily cause
accidentantal errors though. I can't find it anymore, but I remember
Pierre once fixed a bug in the compiler sources itself where someone
accidentally used move
Jonas Maebe schrieb:
> Florian Klaempfl wrote on Tue, 13 Oct 2009:
>
>> When messing with pointers you've to know what to write because pointers
>> allow unlimited access to internal data structures. Sorry, but I can't
>> help you if you guess wrong while playing with dangerous stuff (and the
>> o
Florian Klaempfl wrote on Tue, 13 Oct 2009:
When messing with pointers you've to know what to write because pointers
allow unlimited access to internal data structures. Sorry, but I can't
help you if you guess wrong while playing with dangerous stuff (and the
original poster did so: using move i
On Tue, 13 Oct 2009 15:10:03 +0200
Jürgen Hestermann wrote:
> Pointers are great in Pascal (if the syntax wasn't influenced by C) but
> a nightmare in C.
No they are not. C/C++ has its problems, no doubt, but I would not like to code
C/C++ without them, that would be a nightmare.
As everyone sa
Jürgen Hestermann schrieb:
>
>
>> 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/t
> 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
>> 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. If you want pointers and all dirty stuff, use C o
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
Zitat von Florian Klaempfl :
Jürgen Hestermann schrieb:
Yes, but you cannot avoid it, if you work with dynamic arrays. You are
not even told that it's a pointer. That's just the problem.
Same for classes and strings. Classes are pointers and I'm happy that
I can write A.B instead of A^.B.
Jürgen Hestermann schrieb:
>
> Yes, but you cannot avoid it, if you work with dynamic arrays. You are
> not even told that it's a pointer. That's just the problem.
The problem is that one is playing with stuff he doesn't understand.
Explict use of pointers is always dangerous and one should reall
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
On Mon, Oct 12, 2009 at 22:03, "Vinzent Höfler"
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
BTW, the expression "@DynamicArray" should really return the address of the
first element, not the address of the pointer to the array structure. 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.
Martin :
> 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.
No, because of subtle differences in the handling of "out" parameters
"Jürgen Hestermann" :
> Adding yet another variant is not good. I once thought that Pascal was
> superior to other languages because of it's clear and strict concept but
> now there is no longer *the* Pascal language anymore.
If you're searching for some stricter Pascal then maybe you should gi
2009/10/12 Marco van de Voort :
> In our previous episode, Jürgen Hestermann said:
>>
>> What is the problem with search-and-replace? If you are forced to change
>> your code you will have a closer look at it and may get aware of side
>> effects of the change.
>
> Yes, and if I had enough time I'd
Jürgen Hestermann wrote:
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 w
In our previous episode, J?rgen Hestermann said:
> > 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 "^"
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 cha
Jürgen Hestermann wrote:
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.
Easy, maybe / useful, far less
The beauty of the current solution is that static and dynamic arrays can
be substituted with
In our previous episode, J?rgen Hestermann said:
[ Charset ISO-8859-15 unsupported, converting... ]
> >> 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.
The pointer
Jürgen Hestermann schrieb:
> 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 opinio
On Mon, Oct 12, 2009 at 12:47, Jürgen Hestermann
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
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
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. si
In our previous episode, J?rgen Hestermann 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.
>
> But why are you then using Pa
Jürgen Hestermann schrieb:
>>> 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
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. Enu
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
Jürgen Hestermann schrieb:
>> 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
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
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 y
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,
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
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
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 understand is that arrays and pointers are
In our previous episode, Henry Vermaak said:
> > and access the record members respectively. It's a static address, known at
> > compile time. No dereferencing.
> >
> >> No, it's not weakened by C-style all of a sudden, it's _always_ been
> >> like this.
> >
> > No. Your confusing arrays and point
2009/10/10 "Vinzent Höfler" :
> Henry Vermaak
>
>> 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.
>
> No, not in Pascal. In Pascal an array is a variable just like any other: A
> name for some memory area where values
In our previous episode, "Vinzent H?fler" said:
> > 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 understand is that arrays and pointers
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 understand is that arrays and pointers are
orthogonal concepts in almost every o
Henry Vermaak
> 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.
No, not in Pascal. In Pascal an array is a variable just like any other: A name
for some memory area where values can be stored.
> How else do you think
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
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 refere
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 PX?
Henry Vermaak wrote:
One thing I think you don't understand is that an array _is_ a
pointer. Look at this table to visualise:
In Pascal, an array is not a pointer; at least not at the language
level. For a static array X (array[1..n] of T), you *can* write:
Move(Ptr^, X, sizeof(X));
becaus
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 referen
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
2009/10/10 Marco van de Voort :
>> http://en.wikipedia.org/wiki/C_syntax#Accessing_elements
>
> 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.
Henry
In our previous episode, Henry Vermaak said:
[ Charset ISO-8859-1 unsupported, converting... ]
> 2009/10/10 J?rgen Hestermann :
> >
> > It is illogical that I am able to enumerate a pointer as if it was an array.
> > So the brackets do the dereferencing automatically. When I write X[1] it
> > assum
2009/10/10 Jürgen Hestermann :
>
> It is illogical that I am able to enumerate a pointer as if it was an array.
> So the brackets do the dereferencing automatically. When I write X[1] it
> assumes I meant X^[1]. To the user it behaves the same as if X was an array
> instead of a pointer to an array
2009/10/10 Jürgen Hestermann :
>
> It is illogical that I am able to enumerate a pointer as if it was an array.
> So the brackets do the dereferencing automatically. When I write X[1] it
> assumes I meant X^[1]. To the user it behaves the same as if X was an array
> instead of a pointer to an array
2009/10/10 Jürgen Hestermann :
>
> It is illogical that I am able to enumerate a pointer as if it was an array.
> So the brackets do the dereferencing automatically. When I write X[1] it
> assumes I meant X^[1]. To the user it behaves the same as if X was an array
> instead of a pointer to an array
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 pointers.
2009/10/10 Jürgen Hestermann :
>> Its a common mistake to use @ instead of @> 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 brack
Its a common mistake to use @ instead of @[ 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 as if
it was an array? The derefe
71 matches
Mail list logo
