TCommsBuffer = packed record
    UnitID: Byte;
    FunctionCode: TModBusFunction;
    MBPData: TModBusDataBuffer;
    Spare: Byte;
  end; { TCommsBuffer }
SendBuffer: TCommsBuffer;

--------------------------
I want to send the data in SendBuffer to serial port I define a array type:

rcvData:TDataByte;(TDataByte = array of byte)
setlength(rcvData, sizeof(SendBuffer ) );
count := datatosend;
CopyMemory( @rcvData, @ SendBuffer , count);
SeriComm.SendBuffer(@rcvData,count);

when run to "CopyMemory( @rcvData, @ SendBuffer , count);" the program crash, what's wrong with me? Thanks.

Hi,
either use "Move( SendBuffer, rcvData, count )" (recommended since its from rtl, not windows api) or
"CopyMemory( @rcvData[0], @SendBuffer, count )".
Its a common mistake to use @<dynamic array var> instead of @<dynamic array var>[ 0 ].

regards

Hi,
For the Move solution, use "Move( SendBuffer, rcvData[0], count )".. Same common mistake with <dynamic array var>[0].

sry

Solved,Thanks
there is another mistake:

    FillChar(sendData, high(sendData), 0);

change to

    FillChar(sendData[0], high(sendData), 0);

OK.

2009/10/10 Matthias K. :

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 as if it was an array? The derefencing symbol ^ should be needed here (X^[1] instead of X[1]). It's the same for PCHAR. It is a pointer and there should not be any automatic derefencing. That obscures the type origin and is not in the spirit of Pascal. And it leads to the mistakes mentioned above. It is C-like style ("the compiler will guess what you meant") which should never have crept into Pascal. If you build a complex data structure with nested pointers and arrays you get into hell with this automatic dereferencing.

Well, it is now much too late to change this but it annoys me all the time.

2009/10/10 Jürgen Hestermann :

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.

Henry

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. There is no difference in syntax which is wrong IMO. It's not wonder that many users think it *is* an array.

That's the same as if I could use square brackets for an integer and the compiler assumes I meant to pick up one of the bytes. Strict type checking was a fundamental goal of Pascal but is has now been weakended by C-style creaping into it. If you are forced to use the first element of an array in situatons where you wanted to specify the whole array it is illogical. And it's not that pascal programmers are less accustomed to pointers, but they are less accustomed to obscure compiler magic. It has become fashionable to *hide* such things ("you don't need to know the details") and the syntax doesn't tell the users either which provokes such mistakes.

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? Can you explain what would x[1] mean if it isn't dereferenced?

No, it's not weakened by C-style all of a sudden, it's _always_ been like this. As I've been trying to explain to you, there's no "obscure compiler magic", if you put the brackets there, the compiler dereferences.

Henry

2009/10/10 Jürgen Hestermann :

I have to agree 100%. This is what through me off a few days ago as well. Plus I haven't used pointers and pointers to array structures in many years. But yes, the syntax is inconsistent with other syntax rules.

2009/10/10 Jürgen Hestermann :

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

Henry

In our previous episode, Henry Vermaak said:
[ Charset ISO-8859-1 unsupported, converting... ]

That link is talking about interchangability, which is not the same as being the same.

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:

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.

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?

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));

because X *is* the array, representing the memory of the array.

Micha

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?

X is an array of char which can be accessed directly. The identifier X means the address in memory where the array elements 1..10 are stored. The address of X (@X) is the address of the array (first element).

XP is just a pointer to such a structure. It's not the array itself. The address of XP (@XP) is the address of the pointer, not the array.

Sizeof(X) is 10 bytes.
Sizeof(PX) is 4 bytes.

Still you can use X[1] and PX[1]. That's illogical.

No, it's not weakened by C-style all of a sudden, it's _always_ been like this.

It has never been like this (in Pascal). That's C-style.

Exactly!

Doesn't sound nice, does it?

To me it does, much more as it's now. It would make it clear what kind of data structure I am working with. What is not nice with it? Now all these facts are obscured by some background compiler magic and misinterpretations are generated.

Imagine a highly nested structure of pointers to arrays of pointers to arrays of pointers..... If you try to write code to access the data you will soon get lost what to write if you mean some of the arrays or mean the pointers.

2009/10/10 Jürgen Hestermann :

Right, I see what you mean, now. Contrary to what I thought arrays are not pointers (in syntax, at least), this is indeed confusing. I hardly ever use pointer arithmetic in pascal, though, so it doesn't really bother me.

Henry

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 it works?

Just like "a : integer" -> reserve the needed number of bytes and let the programmer access the associated memory via the identifier "a".

Can you explain what would x[1] mean if it isn't dereferenced?

Access the memory at address of "x + 1 * (size of element)".

Just like you do

array4 : record a1, a2, a3, a4 end;

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 pointers. Or maybe, you're confusing Pascal and C.

As I've been trying to explain to you, there's no "obscure compiler magic", if you put the brackets there, the compiler dereferences.

The dereferencing operator in Pascal is "^".

Vinzent.

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 other programming language than C.

So technically, C is the one who got it wrong.

Same for "Array subscript numbering begins at 0." - which simply isn't true for Pascal.

Vinzent.

In our previous episode, "Vinzent H�fler" said:

Wrong and right are absolute terms. C chose a deliberate other way, mostly based on the need to keep as little possible state in memory to be able to compile an as large program as possible on early seventies hardware.

So from C's THEN requirements, it was sane. C has to live with the both the advantage (looking at the huge unix codebase) and the disadvantage (the sorry state of typing and importing) of being a production language right from the start.

Same for "Array subscript numbering begins at 0." - which simply isn't true for Pascal.

Except for dyn arrays, open arrays etc. See ISO pascal's conforming arrays.

2009/10/10 "Vinzent Höfler" :

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?

Henry

In our previous episode, Henry Vermaak said:

This is an extension of Borland dialects, of a much later period, where OS apis and examples are specified at C level.

Other such examples are enums with gaps, the ability to have fieldnames with the same name as types etc.

2009/10/10 "Vinzent Höfler" :

Yes, I am aware of this (at least with the languages I've worked with).

So technically, C is the one who got it wrong.

Huh? Are you saying something is wrong because the majority does it differently?

Same for "Array subscript numbering begins at 0." - which simply isn't true for Pascal.

Except when you define an array[0..9], for instance, or for dynamic arrays. I can think of only strings that always start with [1], but I'm often mistaken :)

Henry

Yes. And first mixing arrays with pointers and then telling everybody that this is just the same is - wrong. Absolutely. ;)

Vinzent.

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 of the problem, if not the problem itself.

Vinzent.

Henry Vermaak :

No. I'm saying it's wrong because this "majority" _proves_ it can be done differently. So the concept seems flawed at least.

type CharMap = array['a' .. 'z'] of Char;

It doesn't even have to be a number at all. :)

Vinzent.

2009/10/10 Jürgen Hestermann :

I've tested this now and could only get this behaviour with {$mode delphi}.

Henry

2009/10/11 "Vinzent Höfler" :

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).

Henry

So what did the other modes return? objfpc?

2009/10/11 Graeme Geldenhuys :

It produced a compilation error:

array_test.pas(17,27) Error: Can't read or write variables of this type

You have to dereference the pointer to the array, i.e. pia^[x].

Henry

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.

One can discuss if it was smart of later languages to promote similar features, but for C, more crucial requirements prevailed.

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.

In 1.0.x times headers were often "pascalized", but if you have answered several tens of bugreports where people converted a C example and pass a pointer to a formal parameter, you get tired of it. Likewise you also get tired when you need to update some header (or code like zlib,jpeg) and have to guess what the purpose and consequences of some pascallization are.

2009/10/11 "Vinzent Höfler" :

quite well for me, but so does pascal. I'm not prepared to call either of them "wrong". Confusion and consistency were what this discussion was about.

Henry

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 that "right" is one of them. ;)

Vinzent.

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 of sloppy C-programmers. Keywords like "const" to express intent exist for more than 10 years now.

Likewise you also get tired when you need to update some header (or code like zlib,jpeg) and have to guess what the purpose and consequences of some pascallization are.

That simply means, the code is not documented. Again: Not entirely C's fault.

Vinzent.

In our previous episode, "Vinzent H�fler" said:

The problem of C is that the language is so poor that large codebases always resort to macros and other tricks that make automated conversion unreliable.

But this was not meant as a problem of either C or Pascal, just a reality of conversion from C to Pascal.

Docs. Like anybody reads them.

2009/10/11 "Vinzent Höfler" :

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.

It's simply more readable and a shortcut.

> 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.

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 readers to have a minimum bit of Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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 you realy don't need to reply anymore, there is nothing more to say...

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 language? That sounds as if we are talking about the brainfuck language. ;-)

Modern languages contain a lot of stuff which is simply syntactic sugar. If you want strict logic, you should really use something like brainfuck :)

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 (which make coding and debugging much easier) but having all these illogical C-style things creeping in makes it less Pascal.

if you have

var p : pchar;

what do the following contructs mean?

p
p^
@p
p[2]
@p[2]

If it were pure Pascal I could immediately tell you but with this C-style notation I am always doubting about the meaning. To put one on top, the meaning is even context dependent (using it in an expression or as a paramater of a function may give it have different meanings).

I am not sure why following the strict logic would generate more work. Of course, automatic translation from C to Pascal is getting more difficult, because you then face the drawbacks of C. If you transfer C's flaws into Pascal there is no need for changes. But what are you getting? You get C.

And the solution was to introduce the same C design flaws into Pascal so there was no need to change code (other than replacing { by begin and } by end)? Then what is the difference between Pascal and C anymore?

> 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. Enumerating a pointer makes you think that you are enumerating an array. That was the origin of the whole threat because someone was not clear about what to use as parameter in MOVE. It is no longer logical what a written identifier means: A pointer or an array.

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.

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.

In our previous episode, J�rgen Hestermann said:

I like Pascal because it makes me more productive.

(depends on delphi version, in D2009+ it is a pwidechar, before a pansichar)

p

The value of a pchar.

p^

the char pointed to.

@p

The address where the pointer is stored

p[2]

The 3 third char starting from the address the pointer points to (1 based)

@p[2]

The adress of the above.

If it were pure Pascal I could immediately tell you but with this C-style notation I am always doubting about the meaning.

I don't think you can say anything from pure syntax without bringing in the typing. The fact that the pointer type required ^ in the past so that you could make the distinction in this case is therefore negiable.

To put one on top, the meaning is even context dependent (using it in an expression or as a paramater of a function may give it have different meanings).

True, but that is due to additional conversions in the expression, not the strict meaning of the notation.

I am not sure why following the strict logic would generate more work.

Because when you are converting, (and then I mean manual or semi-automatic, because reliable automatic conversion is hard), then the small errors that this leads to can cost you days of debugging work.

Of course, automatic translation from C to Pascal is getting more difficult, because you then face the drawbacks of C. If you transfer C's flaws into Pascal there is no need for changes. But what are you getting? You get C.

That bit of code: yes. However not having these is not an option either, since it makes interfacing costly and hard to maintain, which is why these features trickled in. And you are incompatible with Delphi and also MUST convert there.... (not entirely true, some of them were in FPC first, due to its own particular needs)

If it hadn't been for Delphi compatibility, the extensions maybe could be limited to a certain mode, or unit type. (since modes are nowadays global per unit, if there was no delphi compatibility, the dialect selection could be in the unit declaration)

I don't think a handful of extensions are that bad. If it bothers you so much, submit patches for directives to turn them on/off.

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.

> 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 in the typing. The fact that the pointer type required ^ in the past so that you could make the distinction in this case is therefore negiable.

I don't understand what you mean here. If I write a constuct (like "p") it should mean the same in all circumstances. Otherwise it's becoming tricky when you need to think about the context too when writing code.

Again I don't understand what you mean with "additional conversions". If I want to access a pointer or its address or the data it is pointing to I should have an unambiguous, uniform and different syntax for all these
3. But this is no longer the case.

> I am not sure why following the strict logic would generate more work. Because when you are converting, (and then I mean manual or semi-automatic, because reliable automatic conversion is hard), then the small errors that this leads to can cost you days of debugging work.

Why that? In Turbo Pascal times I often coded complex nested data structures with records, arrays and pointers pointing to them. Then it often happened that I accidentaly used a pointer where I should have used the dereferenced pointer (or vice versa) but the compiler immediately raised an error and showed it to me. Now the compiler starts beeing smarter than I am and guesses what I could have meant. That's not very debugging friendly.

Regarding arrays and pointers I can't see your problems. If in C a pointer is required you can use one in Pascal too. For function parameters you can use by reference or by value (to mimic what C does with pointers). So where is the problem?

If it hadn't been for Delphi compatibility, the extensions maybe could be limited to a certain mode, or unit type. (since modes are nowadays global per unit, if there was no delphi compatibility, the dialect selection could be in the unit declaration)

Yes, Borland was the culprit who introduced all this to Pascal. I was realy disappointed about it at that time. But Free Pascal is no longer a slave of Borland so could correct their errors.

I don't think a handful of extensions are that bad. If it bothers you so much, submit patches for directives to turn them on/off.

If I would change my code only I would have an island solution. Reading code from others (for example Lazarus source code) would still be a problem. It is already a problem that no Pascal standard exits anymore. 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.

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.

I'am not talking not about object pascal dyn. arrays (OP dyn. arrays are much more, see below) but the array<->pointer equivalence as it has C as well. As far as I can see, you suggest to declare

PChar = ^array[0..maxint] of Char;

? But be careful,
move(p1,p2,sizeof(PChar));
doesn't work as expect either.

If you don't agree, how would you like to declare pchar?

It would have been easy to introduce dynamic arrays without hiding away its nature from the user.

What's there use then if the user has to do everything by hand? Dyn. arrays are more than just an automatic dereference, they involve ref. counting, automatic destruction if needed, dynamic range checking etc.

... and this is good. The alternatives are that the user builds his processor and assembler himself or he uses something like brainfuck.

Then we would have to remove things like typecasts, move or fillchar. They are the problem because they allow the user to mess with basic structures.

In our previous episode, J�rgen Hestermann said: [ Charset ISO-8859-15 unsupported, converting... ]

The pointer. The character (the pointer is pointing to) is not of type pchar. The pointer has an own typedefinition and value too, and is a real type, not a mere syntax element

>> p^ > the char pointed to. Is this the same as p?

No.

"p" without anything could be an integer, real, string, pointer type. IOW to really read the code you need to know the typing.

When using certain types that can automatically convert to others in expressions or such types in combination with overloading, sometimes unintuitive things happen. I thought you were hinting on that.

I want to access a pointer or its address or the data it is pointing to I should have an unambiguous, uniform and different syntax for all these 3. But this is no longer the case.

I don't see your point here.

As far as I know, the additional syntax has nothing to do with error detection. This is an argument that is IMHO dragged in by the hairs.

One can argue out of orthogonality, esthetic or intuitive reasons, but afaik there is no ambiguity on the compiler level here.

C allows to drop the * by transfering to array syntax. So Pascal allows droping the ^ in places where it doesn't matter (when not at the end of the expression)

No. Compatibility is way more important to really getting things done. One can debate if it is worthwhile in implementing (bits of) the recent syntaxes, but the codebases in say the D7 dialect are simply too big to discard. It would disallow any significant exchange and communication with the Delphi community.

You could separate the kind of code that needs this (interfacing code) from code that doesn't. Removing it is no option, not now, not ever, because of existing codebases and Delphi.

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.

It never was. UCSD derivates were never fully compatible with the standard and had a more pragmatic stance.

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 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 changes throughout your code, if ever you needed to change between static and dynamic arrays.

Now, I do not say that makes it right, neither does it make it wrong. Someone defined this is the decision and to make this the standard for dyn-arrays. So now, for any pascal compiler it is the right thing to follow this standard.

And if you seek a flaw in it: The problem is not with hiding the internal pointer (works well for classes too), the problem is the exception. the pointer is not hidden, if you use "move". It would have been nice if it was hidden there too.
Then again "move" has many more dangers:
- it has now range checks
- it gets you into huge trouble, if the array you moved was an "array of string" or "array of some_other_dyn_array". Because you ref-counting gets screwed.
So using move requires you to know a lot about the internals of pascal anyway. (yes you can find examples that don't, but using move without the knowledge about the internals, makes it a matter of luck, whether you run into trouble or not. Someone without the knowledge who had success with move on an "array of integer" will eventually try it with "array of string" too)

** Besides this the discussion is pointless. It is the standard now, and it is not going to be changed. **

Martin

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.

In our previous episode, J�rgen Hestermann said:

Yes, and if I had enough time I'd even write a poem about it :-)

problem? time! reviewing half a million lines of code or more? I don't have the time.
Side effects? What side effects, if the test cases all pass afterwards, then it is good as it is.

But it;s pointless to discuss, there are two (or more) views to the topic. each side has chosen. Never mind what argument to come, no one is going to change their view on the topic anyway.

And if you look at my original post. I did not put judgement on it. I said it is not good, it is not bad, it simply is, and it is going to stay as it is.

The last bit means: live with it, or use a language different from pascal. If you choose to use something that you don't like, and that can not be altered (as to much existing code depends onit), what is the point of ranting about it? (this is a rhetorical question, no answer needed)

Martin

p.s.
this is my last post to this thread.
what ever you reply, you know what my answer would be, so I do not need to post it.
And I also have a good idea what your answer would be, even if you chose not to post it..... your choice

2009/10/12 Marco van de Voort :

:) I've been thinking about basing the script of a horror film on some of my code, but sadly, haven't got enough time.

"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 give Ada a try.

Vinzent.

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. Dynamic arrays don't retain their length then. I fell into that trap a couple of years ago.

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.

(Yes, I'm aware of that it's not going to change, so just acknowledge that as my opinion.)

Vinzent.

Hello everybody.

My message is for both "Why use pointers to arrays?" and "Illogical automatic deferencing".

I really don't understand why Pascal "should" include C-style stuff. PASCAL IS DIFFERENT LANGUAGE THAN C. STOP. Actually I hate that "C-lovers" that think all languages must use C-style stuff inside any other languages. I'm using C right now, as well as Pascal, and I really think that C is a great language for some tasks (i.e. low-level) but it isn't the panacea ("the solution for everything"). You'll never add C-style stuff inside SQL, do you? So, why do you want C-style stuff in Pascal?

As I've said, C language is useful sometimes, but it's ugly and prone to runtime errors. A lot of that runtime errors are compilation-time errors on Pascal, so they're easer to find and to fix for me (just the opposite that somebody said in this discussion). That's why I love to use Pascal. It's less frustrating. A lot.

If you have "p: PINTEGER" then you're assuming you're accessing to ONE integer. If you need to access to an array of integer then use a pointer to an array. What's the problem with "p^[3]"? I think it is better because you see you're accessing to a pointer to an array, and in most cases it's important to don't forget it.

When I use C, I try to do not use pointers as arrays. I write something as:

/* Useless example function. */
char Fn (int Ndx)
{

    char AnArray[500];
    char *Pointer;

    Pointer = &(AnArray[0]);
    return *(Pointer + Ndx);  /* instead of "return Pointer[Ndx];" */
  }

This is more readable, because "*(Pointer + Ndx)" remembers me that it's a pointer, not an array, so may be it wasn't assigned and may be it needs some test before to use it (i.e. "if ( ! Pointer) return EXIT_FAILURE;" or something).

As conclusion: I think that Pascal is good as it is. Of course it can evolve to be better, but I think it doesn't need that C-style stuff (i.e. Object Pascal has it's own approach to OOP keeping the original "Pascal-style" and I like it much more than C++ and C# [can't say the same about Objective C ;) ]).

Greetings,
Guillermo "Ñuño" Martínez

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 compatibility with Delphi programs and an "easier" (which I doubt) convertion of C header files. So noone is willing to turn back the clock and remove these illogical extensions. Sadly we now have no longer a clean language in the spirit of Pascal but a mix of Pascal and C and we will have to live with it forever.

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.

Yes, that's totaly "C-spirit": Don't follow any logic, the user can find out with trial-and-error.

"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 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 :-)

> 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 solution if you already know that "DynamicArray" is a pointer (instead of the array). Otherwise I would always use the identifier "DynamicArray" if I have to feed the array to a procedure or function (or "@DynamicArray" if I have to give the pointer to the array). I never would use the first element. Why should I? This could be even misleading if the index of the first element changes or is unknown from start.

Makes perfect sense :-)

No, it does not because it implies that you already know about the nature of "DynamicArray". It is not transparently useable if you change between dynamic and static arrays (as was claimed here a lot of times).

> 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.

Which does not exist because the identifier "DynamicArray" sometimes means the pointer and sometimes the data it points to.

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.

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 really know what he does especially on object pascal dyn. arrays which are much more than a simply pointer to the data else one wrecks anyways havoc.

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.

About pointer arithmetic:
IMO memory is an array. So for me it is quite natural that P^ and P[0] are the same. I think this is a great feature of FPC, which I don't want to miss. It's simple, unambiguous and readable - like pascal.

The only disturbing is the automatic dereferencing of pointer to record/object in Delphi mode, where you can use PtrRect^.Left and PtrRect.Left.
But that only works in delphi mode, which I avoid.

The problem is that one is playing with stuff he doesn't understand. Explict use of pointers is always dangerous and one should really know what he does especially on object pascal dyn. arrays which are much more than a simply pointer to the data else one wrecks anyways havoc.

Great power comes with great responsibility.

Mattias

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 to specify the whole array why should I use the first element only?). It was stated here many times that the user should not care about how these dynamic arrays are handled but in reality he has to.

And even if he is aware of it the syntax is not logical. If the first element of the array is not zero, you cannot use your workaround. You have to check the numbering first and if you change this later you have to change your P[0] syntax too. Or you use P[low(P)] (again I am not sure whether I can use "low(P)" in this construct or whether I have to use "low(P^)". But then it already has become realy awkward. You should be able to use an unambiuous syntax to specify the whole array which does not seem to exist anymore.

Either the (hidden) pointer to array logic is fully transparent (which means, the user can use the same syntax as for standard arrays) or the user should know about it but then it should not be hidden. Now we have a mix of both.

The only disturbing is the automatic dereferencing of pointer to record/object in Delphi mode, where you can use PtrRect^.Left and PtrRect.Left. But that only works in delphi mode, which I avoid.

Why is this more disturbig than for arrays? It's the same story.

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.

> 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 casts et.
al. If you want pointers and all dirty stuff, use C or assembler.

No. Only the logic has be kept strict. Otherwise noone realy knows what to write when coding and starts guessing.

If you want pointers and all dirty stuff, use C or assembler.

Pointers are great in Pascal (if the syntax wasn't influenced by C) but a nightmare in C. It's just that it would be very easy to handle pointers in Pascal but then the syntax and logic has to stay strict.

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 is a dangerous operation) instead of reading the manual.

They are strict. However, if one does not understand the logic, it looks indeed like magic. If you don't understand the logic it does not mean that it is an unstrict logic.

And before I continue to discuss I expect answers to my questions in my other mail (e.g. how you propose to define and use pchar).

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 said, pointers are dangerous, so you have to know what you are doing. The great thing about Pascal is that you get a mostly clean language with all the power of C/C++. Some parts are not as clean or strict as some people like, but I'd rather have some 'not-so-clean' implementation than a loss in speed or versatility. If pointers are too much for you go and play with Java or Ada.

R.

That is I mean with "Pascal can evolve", some extensions as ANSISTRING, ASM ... END, CLASS, etc. makes Pascal better. About the Delphi compatibility, I think that the "-Mdelphi" compiler option ( or "{$MODE DELPHI}" as you wish ) was a great idea if that compatibility is really needed.

I don't see what new stuff is needed for "an easier convertion of C header files". I'm the author of the Allegro library wrapper (which is a C library) and I hadn't problems to interface with it (except that it has a static part and a dynamic part, but it's a different story). Pascal has data types that can deal with the C data types and the "CDECL" keyword does help enough.

Florian Klaempfl wrote on Tue, 13 Oct 2009:

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(pstring_var[1],...) instead of move(pstring_var^[1],..). That at least was not a case of not understanding how pointers work, but a simple case of a typo which couldn't be caught anymore by the compiler due to this extension.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

What is the alternative?

Declare things like

tchar = array[0..maxint] of char;
pchar = ^tchar;

?

Small typo, move(p,... instead of move(p^,... and things break as well besides unneeded and wrong range check code being generated etc.

If you have "p: PINTEGER" then you're assuming you're accessing to ONE integer.

No, YOU assume that. I assume that I am working with a memory address. If it is a single integer or the first element of an array or the second field of a record depends on MY usage. That's the way it is and that's the way it should be. Nobody forces you to use pointers. Most of the time there are ways around pointer usage. And if not you are either dealing with C/C++ or some other low level stuff and then you should know what you are doing.

R.

Florian Klaempfl wrote on Tue, 13 Oct 2009:

Only allowing it for pchar/pwidechar, I guess. And/or printing a warning in case you are "indexing a pointer" to a type that is an indexed type itself, although I'm not sure how we could make it possible to disable this warning on a case-by-case basis using some kind of explicit syntax saying "yes, I want
(pointer+(n-1)*sizeof(pointer))^, not pointer^[n]".

The point is that it creates an extra class of small typos that can't be caught by the compiler if you allow it for all types. At least TP (and previous versions of Delphi) only allowed this for pchar/pwidechar afaik, where this particular error cannot occur (p^[i] is not valid if p is a pchar).

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

In our previous episode, Florian Klaempfl said:

Support D2009 {$pointermath on/off} that governs this, with the default as OFF in Delphi mode.

For objfpc mode you can put it on OFF too, but then you'll have to fix quite some source.

I'm really wonder if we should become stricter in this, after years of allowing it, if Codegear is finally starting to support it.

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

1.) The address of the pointer (@p)
2.) The pointer (p)
3.) The data the pointer is pointing to (p^)

What of these 3 possibilities do I have if I use the identifier "DynamicArray"? You can't say it in general because it depends on the context.

Sorry, but I can't help you if you guess wrong while playing with dangerous stuff (and the original poster did so: using move is a dangerous operation) instead of reading the manual.

Again that's not the point. The original poster was aware of what move does but was not sure what to write when meaning the array (not the pointer). The general rule that an identifier always has a (fixed) type was no longer valid.

If the syntax was unambigous there would be no need to guess. Why should I use the first element of an array when I want to specify the whole array? If I have a fixed array I don't do that either. I am forced to do illogical things because the syntax is no longer logical.

They are strict. However, if one does not understand the logic, it looks indeed like magic.

That's the point: There *is* no logic! At least you have to give several other contraints which makes it unnecessary complicated. The "DynamicArray" is the array if you index it with square brackets and it is the array if you feed it to other routines but it suddenly turns into a pointer if you use it with move.

Feel free to create TrollPascal 1.0 :)

Florian Klaempfl wrote on Tue, 13 Oct 2009:

Feel free to create TrollPascal 1.0 :)

I guess this is a sign that it's really time to move this thread to fpc-other.

Please don't post statements like the above to fpc-pascal in the future (and preferably not to fpc-other either, for that matter).

Jonas
FPC mailing lists admin

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.