Re: [fpc-pascal] Illogical automatic dereferencing
Feel free to create TrollPascal 1.0 :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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
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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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(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. What is the alternative? 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]". Declare things like tchar = array[0..maxint] of char; pchar = ^tchar; ? Small typo, move(p,... instead of move(p^,... and things break as well 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 >> original poster did so: using move is a dangerous operation) instead of >> reading the manual. > > 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. > 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 is a dangerous operation) instead of reading the manual. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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/type casts et. >> al. > > No. Only the logic has be kept strict. Otherwise noone realy knows what > to write when coding and starts guessing. 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. > >> 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. 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). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
> 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 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
>> 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 or assembler. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. 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 :-) 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
On Mon, Oct 12, 2009 at 22:03, "Vinzent Höfler" wrote: > BTW, the expression "@DynamicArray" should really return the address of the > first element, not the address of the pointer to the array structure. What's wrong with the current solution? "the first element" = DynamicArray[0] "address of the first element" -> @DynamicArray[0] Makes perfect sense :-) > It somehow destroys the abstraction. And I can't imagine any situation where > the pointer might be of the interest for the user of the abstraction. That really doesn't matter. What matters is consistency. Pointer to variable X is defined as address of the first byte of memory where variable X is stored. If you work with pointers to complex data types, you have to be aware of internal structure. Otherwise, don't use pointers - they are evil anyway :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
"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. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 even write a poem about it :-) :) I've been thinking about basing the script of a horror film on some of my code, but sadly, haven't got enough time. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 would have to make huge changes throughout your code, if ever you needed to change between static and dynamic arrays. 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. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 "^" 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. > > 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 even write a poem about it :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. 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. > > 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. "p" without anything could be an integer, real, string, pointer type. IOW to really read the code you need to know the typing. > >> 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. > > Again I don't understand what you mean with "additional conversions". If 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. > >> 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. 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. > > 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) > > Regarding arrays and pointers I can't see your problems. If in C a > pointer is required you can use one in Pascal too. 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) > > 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. 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. > > 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. 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 becau
Re: [fpc-pascal] Illogical automatic dereferencing
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 my experience faking arrays with dyn. size by >> using array declarations with infinite size (else you get in trouble >> with range checking) are much more error prone and unreadable than using >> pointers with an implicit dereference operator as arrays. As soon as you >> start using them like normal arrays (new, high, sizeof, passing them to >> open array parameters, no range checking) you get burned as well, even >> not taking care the extra declarations you need. > > What has the one thing to do with the other? 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. > >> 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 ... and this is good. The alternatives are that the user builds his processor and assembler himself or he uses something like brainfuck. > 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. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
On Mon, Oct 12, 2009 at 12:47, Jürgen Hestermann wrote: > No, it happens with static arrays, if you set pia := @ia, ia[x] and > pia[x] will give you the same result (in delphi mode, at least). It's simply more readable and a shortcut. >>> >>> It's definitely the opposite: It is *less* readable >> >> This is your opinion :) To my experience faking arrays with dyn. size by >> using array declarations with infinite size (else you get in trouble >> with range checking) are much more error prone and unreadable than using >> pointers with an implicit dereference operator as arrays. As soon as you >> start using them like normal arrays (new, high, sizeof, passing them to >> open array parameters, no range checking) you get burned as well, even >> not taking care the extra declarations you need. > > What has the one thing to do with the other? It would have been easy to > introduce dynamic arrays without hiding away its nature from the user. > >> E.g. ansi- and widestrings or classes use implicit dereferencing as well >> and they proved to work very well. If someone uses low level operations >> like Move he should know what he does. > > That's just the point: Most users are left unclear about the nature of data > structures and they start doing an trial and error approach (changing syntax > as long as it is compiled). Then hope it will do what they intented. That's > exactly C-style! Of course, there are some that look under the hood and know > about the details and only these people are able to avoid such things as > memory leaks or pointers pointing to freed memory and so on. The others > stumble through it praying that it runs and as long as 80% procent works > they are already satisfied. That's not the spirit of Pascal. The language > should be clear and predictable from the start. I like the fact that Pascal introduced high level data structures (like dynamic arrays, automatic reference counting on string, etc), because they make your life much easier. It is true that you have to be careful when you mix these high level data structures with low level data structures (pointers) and low level functions (Move), but once you _learn_ and understand the nature of these structures, you get used them. You could equally say that we don't need arrays at all, because they could be represented as record of pointer to the the first byte of array, number of elements in array and size of one array element, but that's exactly what arrays are during compile time :-) Plus, you get type checking. See? When you really need some feature so much that you start coding it over and over (like dynamic arrays based on pointer to array), it makes sense to improve the language and the compiler. -- Aleksa Todorovic - Lead Programmer Eipix Entertainment http://www.eipix.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. 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. 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. 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) 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
No, it happens with static arrays, if you set pia := @ia, ia[x] and pia[x] will give you the same result (in delphi mode, at least). It's simply more readable and a shortcut. It's definitely the opposite: It is *less* readable This is your opinion :) To my experience faking arrays with dyn. size by using array declarations with infinite size (else you get in trouble with range checking) are much more error prone and unreadable than using pointers with an implicit dereference operator as arrays. As soon as you start using them like normal arrays (new, high, sizeof, passing them to open array parameters, no range checking) you get burned as well, even not taking care the extra declarations you need. What has the one thing to do with the other? It would have been easy to introduce dynamic arrays without hiding away its nature from the user. E.g. ansi- and widestrings or classes use implicit dereferencing as well and they proved to work very well. If someone uses low level operations like Move he should know what he does. That's just the point: Most users are left unclear about the nature of data structures and they start doing an trial and error approach (changing syntax as long as it is compiled). Then hope it will do what they intented. That's exactly C-style! Of course, there are some that look under the hood and know about the details and only these people are able to avoid such things as memory leaks or pointers pointing to freed memory and so on. The others stumble through it praying that it runs and as long as 80% procent works they are already satisfied. That's not the spirit of Pascal. The language should be clear and predictable from the start. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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.
I like Pascal because it makes me more productive.
> if you have
>
> var p : pchar;
>
> what do the following contructs mean?
(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)
> > 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.
>
> 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?
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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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. > 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. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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.
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.
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?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 > 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 :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 humour at least. Vinzent. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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? >> Those are dynamic arrays, IOW pointers disguised as arrays. This is part of >> the problem, if not the problem itself. > > 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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. 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. > > 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. Docs. Like anybody reads them. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 >> > >> > One thing I think you don't understand is that arrays and pointers are >> orthogonal concepts in almost every >> > other programming language than C. >> >> 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? > > No. I'm saying it's wrong because this "majority" _proves_ it can be done > differently. So the concept seems flawed at least. Please don't confuse your opinion with "right" and "wrong". C works 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. ;) 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 the other modes return? objfpc?
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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?
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 pointers disguised as arrays. This is part of > the problem, if not the problem itself. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 : ^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.
I've tested this now and could only get this behaviour with {$mode delphi}.
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 understand is that arrays and pointers are > orthogonal concepts in almost every > > other programming language than C. > > 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? No. I'm saying it's wrong because this "majority" _proves_ it can be done differently. So the concept seems flawed at least. > > 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 :) type CharMap = array['a' .. 'z'] of Char; It doesn't even have to be a number at all. :) Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 are absolute terms. Yes. And first mixing arrays with pointers and then telling everybody that this is just the same is - wrong. Absolutely. ;) Vinzent. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 > orthogonal concepts in almost every > other programming language than C. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 pointers. Or maybe, you're confusing Pascal > > and C. > > 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? 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 are > orthogonal concepts in almost every other programming language than C. > > So technically, C is the one who got it wrong. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 : ^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. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Also, it is very important to make distinction between static and dynamic arrays. For static arrays, compiler knows their exact memory location at compile time (modulo situations where static array is part of another structure), but for dynamic arrays, compiler only knows where in memory is reference (akka pointer) to the contents of that array. So, if we wanted to have that distinction on syntax level, we would have to use X[1] for static arrays and X^[1] for dynamic arrays. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Also, it is very important to make distinction between static and
dynamic arrays. For static arrays, compiler knows their exact memory
location at compile time (modulo situations where static array is part
of another structure), but for dynamic arrays, compiler only knows
where in memory is reference (akka pointer) to the contents of that
array. So, if we wanted to have that distinction on syntax level, we
would have to use X[1] for static arrays and X^[1] for dynamic arrays.
Doesn't sound nice, does it?
On Sat, Oct 10, 2009 at 15:32, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
>> >
>> > That link is talking about interchangability, which is not the same as
>> > being
>> > the same.
>>
>> Yes, I'm just trying to explain that there's no magic to it,
>> illustrated by some basic pointer arithmetic.
>
> I think there are several bits that mix in this thread:
>
> 1 nearly all types that don't fit in registers are in memory, and you need
> a memory access to reference them. This makes them all
> references/pointers/addresses on assembler level, but not necessary pointers
> on language level.
> 2 The fact that Delphi mandatory skips a ^ when indexing a pointer + array.
> 3 The fact that FPC allows both in objfpc mode. (which means)
> 4 The fact that FPC and Delphi allow pchar to be overindexed.
> 5 The fact that FPC and Delphi 2009+ with {$pointermath on} also allow it
> for other pointer types.
>
> Note that I write this from memory after porting some FPC bits to Delphi
> last week. Most notably the {$pointermath on} (5) and the mandatory aspect
> of (2) might be related.
> ___
> fpc-pascal maillist - fpc-pas...@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
--
Aleksa Todorovic - Lead Programmer
Eipix Entertainment
http://www.eipix.com/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
In our previous episode, Henry Vermaak said:
> >
> > That link is talking about interchangability, which is not the same as being
> > the same.
>
> Yes, I'm just trying to explain that there's no magic to it,
> illustrated by some basic pointer arithmetic.
I think there are several bits that mix in this thread:
1 nearly all types that don't fit in registers are in memory, and you need
a memory access to reference them. This makes them all
references/pointers/addresses on assembler level, but not necessary pointers
on language level.
2 The fact that Delphi mandatory skips a ^ when indexing a pointer + array.
3 The fact that FPC allows both in objfpc mode. (which means)
4 The fact that FPC and Delphi allow pchar to be overindexed.
5 The fact that FPC and Delphi 2009+ with {$pointermath on} also allow it
for other pointer types.
Note that I write this from memory after porting some FPC bits to Delphi
last week. Most notably the {$pointermath on} (5) and the mandatory aspect
of (2) might be related.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 > > 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. > > 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 That link is talking about interchangability, which is not the same as being the same. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. There is no difference in syntax which is > wrong IMO. It's not wonder that many users think it *is* an array. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. There is no difference in syntax which is > wrong IMO. It's not wonder that many users think it *is* an array. 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. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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. There is no difference in syntax which is
> wrong IMO. It's not wonder that many users think it *is* an array.
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?
>
> 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.
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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.
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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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.
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
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 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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
