Re: [fpc-pascal] Who said Pascal isn't popular
2009/10/12 Rainer Stratmann : > Am Montag, 12. Oktober 2009 16:21 schrieb Gustavo Enrique Jimenez: >> 2009/10/12 Rainer Stratmann : >> > Am Montag, 12. Oktober 2009 11:02 schrieb Jürgen Hestermann: >> >> > Remember, Pascal is merely a TEACHING language, unsuitable for >> >> > commercial software development, which is why we have C. :) >> >> >> >> And why should that be the case? What are the outstanding feature of C >> >> that make it so supperiour? It's illogical and hard to maintain syntax? >> >> Or is it just that it was available for free on all unix systems? >> > >> > Yes, it is available everywhere. >> > And it is easier to copy unix code then. >> > >> > Remember that it is still not easy to come to freepascal. >> > You have to configure a debian testing system and apt-get lazarus and so >> > on... Nearly nowhere the lazarus package is preinstalled. >> >> You don't need Debian Testing. My system is Debian Stable (i386) since >> 2001/2002. Never have had a serious problem installing >> Lazarus/Freepascal. > > How do you install Lazarus/Freepascal with apt or else? > I am a friend of userfriendly software... Download fpc-2.2.4-3.i386.deb.tar and lazarus_0.9.28-0.i386.deb.tar tar -xf *.tar dpkg -i *.deb <- as root Gustavo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus 0.9.28 released
Mattias Gaertner escreveu: The Lazarus team is glad to announce the 0.9.28 release. This release is based on fpc 2.2.4. This release can be downloaded from the SourceForge download page: http://sourceforge.net/projects/lazarus/files/ Highlights / Major changes: LCL: *LCL now uses gtk2 as default widgetset on Linux and BSD *Windows CE: Implemented TCalendar, TFloatSpinEdit, TOpenDialog and TSaveDialog *TFrame support. Visually nesting in the IDE. *TMonitor class: multi-monitor support *New components: TShellTreeView, TShellListView and TFilterComboBox *Refactoring of LCL reduced minimum size of executables by about 15% IDE: *New IDE options dialog combines environments, editor, codetools, code explorer, debugger and help options. *Application icon has been added to the Project Options *Many source editor improvements like display of "double width" fonts (Eastern, Japanese, Chinese, Arabic, ...), better code folding, highlighting, syncro editing, persistent blocks ... *Codetools: removing empty methods, block completion, update references when renaming a unit *Debugger: assembler windows, easier exception handling, breakpoint properties And thousands of fixes and smaller changes. The list of changes can be found here: http://wiki.lazarus.freepascal.org/Lazarus_0.9.28_release_notes Known issues: - Debian packages: the default lazarus directory is wrong. The IDE detects the right one and asks on first start. Just click Ok. - When compiling a test application the compiler can not find project1.lrs. Workaround: save the project before compiling OR create an empty file /tmp/project1.lrs. Mattias Congratulations to all by the great work. :) -- Silvio Clecio -- A força do exemplo é a mais convincente e eficaz que existe no mundo. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Video4Linux access
Hi Everybody, I need video4linux support for my new project. I tried vfp unit I found in the contribute units website. But it seems very outdated. Itried all things menitioned in the forum, but I'm not able to get the things up. the code is hard to read and I found not one comment line :( Thanks for the hard work, but with some comments i possibly would be able to fix broken stuff. Is there an alternative way to use video4linux ? Thanks a lot and please use comments ;) Hartmut -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why use pointers to arrays?
On 11 Oct 09, at 10:38, Graeme Geldenhuys wrote: Hi, . . > Anyway to get to my questions, and using the code snippets shown > below. This code is all based on the code I am porting from > SpeedPascal. So maybe some strange usage is simply due to the age of > SpeedPascal etc.. > > > -- > Type > TLayoutLine = record > Text: PChar; > Length: longint; > Height: longint; > Width: longint; > MaxDescender: longint; > MaxTextHeight: longint; > LinkIndex: longint; > Style: TTextDrawStyle; > Wrapped: boolean; > end; > > > TLinesArray = array[ 0..0 ] of TLayoutLine; > -- > > > 1) Why would you use a pointer to an array and not simply a variable > what IS the array? In the program I am porting the following field > variable is defined. > > FLines: ^TLinesArray; > > Why couldn't I simply say: > > FLines: TLinesArray; > > Is there some advantage for using a pointer to the array, when passing > it around between procedures and functions? Yes, there's at least one - you cannot pass (or receive) nil if you use the array directly. Sometimes the API (e.g. OS API) needs the possibility to pass or receive nil. > 2) The TLinesArray is a dynamic array, so shouldn't I maybe change the > ported code to define the array as follows, instead of the [0..0] > idea? > > TLinesArray = array of TLayoutLine; Well, it is not a dynamic array strictly speaking, because dynamic arrays maintain number of elements as part of their definition, whereas in this case number of elements is kept elsewhere. > 3) Maybe the strange usage (to me at least) of dynamic arrays could be > explain in how the original program allocates memory for the array. In > the class where FLines is defined, it initially reserves ten empty > elements for the array in the class constructor. > > FAllocatedNumLines := 10; > GetMem( FLines, FAllocatedNumLines * sizeof( TLayoutLine ) ); > > And then later if it needs more space for elements, it redefines the > array elements as follows: > > Procedure TRichTextLayout.AddLineStart( Const Line: TLayoutLine ); > var > NewAllocation: longint; > begin > if FNumLines >= FAllocatedNumLines then > begin > // reallocate the array twice the size > NewAllocation := FAllocatedNumLines * 2; > FLines := ReAllocMem(FLines, NewAllocation * sizeof(TLayoutLine)); > FAllocatedNumLines := NewAllocation; > end; > FLines^[ FNumLines ] := Line;// * (1) > inc( FNumLines ); > end; > > > Like I said, maybe this is related to different implementations of > object pascal. By doesn't one allocate memory (array elements) via the > SetLength() procedure? > eg: > > FAllocatedNumLines := 10; > SetLength( FLines^, FAllocatedNumLines); > > > I marked on of the lines above with (1). I sometimes get "out of > range" errors there, so clearly somewhere in all this dereferencing of > arrays etc, I probably made a mistake somewhere in porting/translating > the SpeedPascal code to Free Pascal. Not really, you just use range checking whereas the original code doesn't. The type definition specifies an array with exactly one element [0..0], but you access more elements using that type definition. Technically, there are several ways for such type definitions, but all of them imply that range checking cannot be used any longer. The first one is this one. The second would be defining the upper bound as some very high value (at best as the highest possible, but even that varies e.g. between 16-bit, 32-bit and 64-bit CPUs, so it's not portable easily, and it doesn't give you any range checking either, because although type allows many elements, the real content has fewer elements and the compiler doesn't know how many). The third option (using the pointer mathematics and not available in older Pascal compilers) is declaring the pointer as a pointer to a single element of that array and accessing it as P[x] (without dereferencing this pointer; I'd personally tend to use P[x]^, but that doesn't work, i.e. in this case the pointer isn't a pointer any longer ;-) ). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why use pointers to arrays?
Andrew Brunner : > On Sun, Oct 11, 2009 at 5:25 PM, "Vinzent Höfler" > > Read up on forward declarations. The technique of declaring a typed > pointer to any data structure in FPC and Delphi was that you can use > it in fields and methods of objects and data structures w/o having to > actually have it fleshed out until later in the interface envelope of > the unit. I've found that using forward declarations is a saving > grace with complicated systems. Oh, you're talking about what I call "incomplete type"? ;) I always was under the impression that the pointed-to-type being declared must be completed in the same declaration section, has that changed? If not, I fail to see the benefit, because you still have to complete the type in the same scope. Which is technically the same as directly declaring it in the first place (unless it's self-referencing, of course). 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
[fpc-pascal] Lazarus 0.9.28 released
The Lazarus team is glad to announce the 0.9.28 release. This release is based on fpc 2.2.4. This release can be downloaded from the SourceForge download page: http://sourceforge.net/projects/lazarus/files/ Highlights / Major changes: LCL: *LCL now uses gtk2 as default widgetset on Linux and BSD *Windows CE: Implemented TCalendar, TFloatSpinEdit, TOpenDialog and TSaveDialog *TFrame support. Visually nesting in the IDE. *TMonitor class: multi-monitor support *New components: TShellTreeView, TShellListView and TFilterComboBox *Refactoring of LCL reduced minimum size of executables by about 15% IDE: *New IDE options dialog combines environments, editor, codetools, code explorer, debugger and help options. *Application icon has been added to the Project Options *Many source editor improvements like display of "double width" fonts (Eastern, Japanese, Chinese, Arabic, ...), better code folding, highlighting, syncro editing, persistent blocks ... *Codetools: removing empty methods, block completion, update references when renaming a unit *Debugger: assembler windows, easier exception handling, breakpoint properties And thousands of fixes and smaller changes. The list of changes can be found here: http://wiki.lazarus.freepascal.org/Lazarus_0.9.28_release_notes Known issues: - Debian packages: the default lazarus directory is wrong. The IDE detects the right one and asks on first start. Just click Ok. - When compiling a test application the compiler can not find project1.lrs. Workaround: save the project before compiling OR create an empty file /tmp/project1.lrs. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why use pointers to arrays?
2009/10/12 Andrew Brunner :
>>> pS[2] <<<
>
> Any idea what the compiler option is under Lazarus (that's what I use
> exclusively)?
>
> I get a compiler error when I don't use the ^ operator.
It only works with {$mode delphi} and lazarus uses {$mode objfpc}, i think.
___
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] Who said Pascal isn't popular
"Jürgen Hestermann" : > And why should that be the case? What are the outstanding feature of C > that make it so supperiour? It's illogical and hard to maintain syntax? Its "Compile anything, crash everywhere." interface. :P 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] Why use pointers to arrays?
On Mon, Oct 12, 2009 at 12:43 PM, Marc Weustink wrote: > Graeme Geldenhuys wrote: >> >> On 11/10/2009, Andrew Brunner wrote: >>> >>> FPC forces the ^ operator while accessing structures as pointers. >>> Delphi didn't force it and I even suspect that memory leaks can result >>> in NOT using the ^ to denote the reference to the pointer rather than >>> the pointer itself. >> pS[2] <<< Any idea what the compiler option is under Lazarus (that's what I use exclusively)? I get a compiler error when I don't use the ^ operator. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why use pointers to arrays?
Graeme Geldenhuys wrote: On 11/10/2009, Andrew Brunner wrote: FPC forces the ^ operator while accessing structures as pointers. Delphi didn't force it and I even suspect that memory leaks can result in NOT using the ^ to denote the reference to the pointer rather than the pointer itself. This was just discussed in another thread. This is not always forced by FPC. eg: var S: TMyArray; pS: ^TMyArray; then use them as follows: S[2] pS[2] Both work just fine without dereferencing the second line. Weird behaviour, but true. However they have a different meaning. assume TMyArray=array[1..10] of Byte; then S[2] refers to the second element of S, being the second byte, while pS[2] refers to the 3 element of pS, being the 3rd TMyArray Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why use pointers to arrays?
On Sun, Oct 11, 2009 at 5:25 PM, "Vinzent Höfler" wrote: > Andrew Brunner : > >> 1st benefit: >> >> declaring methods associated with classes before TIntArray needs to be >> defined or declared. >> eg. procedure DoSomething(Var Data:TIntArray); vs (DataP:PIntArray); > > Huh? Is there any difference other than the second one can take a NIL value? Read up on forward declarations. The technique of declaring a typed pointer to any data structure in FPC and Delphi was that you can use it in fields and methods of objects and data structures w/o having to actually have it fleshed out until later in the interface envelope of the unit. I've found that using forward declarations is a saving grace with complicated systems. >> Lastly, passing by reference rather than by value is much faster. > > That's what "const" has been invented for: Letting the compiler decide the > most efficient way. Oh I don't know about that one. I'd like someone else to comment on that. Does using "const" prohibit copies of the memory. I had memory leaks with Delphi 5 or 6 doing this way back when and I attributed it to trying to pass by reference using const... IMO it should do this but may have had lead me to believe this is not the case... But the fact it that passing by reference is faster than passing by value... That was my only point - which you made quite well. As far as the invention of const descriptor - I only use that for conventional objects since dealing with pointers to data by const or by var is trivial not organization or for maintanince or code review ;-) > Not to mention, expressing your intent: > > You don't change it, say so: "const". > You change it, say so: "var". > You initialize it, say so: "out". > > If you just take the pointer no-one knows if the value is in/in out/or out. > That's clearly not a "benefit". > Ahhh... The beauty of Pascal over C++ ;-) Buy you're getting way to particular man... You know I've never had a need for Out save for once. LOL. ___ 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] Who said Pascal isn't popular
Am Montag, 12. Oktober 2009 16:21 schrieb Gustavo Enrique Jimenez: > 2009/10/12 Rainer Stratmann : > > Am Montag, 12. Oktober 2009 11:02 schrieb Jürgen Hestermann: > >> > Remember, Pascal is merely a TEACHING language, unsuitable for > >> > commercial software development, which is why we have C. :) > >> > >> And why should that be the case? What are the outstanding feature of C > >> that make it so supperiour? It's illogical and hard to maintain syntax? > >> Or is it just that it was available for free on all unix systems? > > > > Yes, it is available everywhere. > > And it is easier to copy unix code then. > > > > Remember that it is still not easy to come to freepascal. > > You have to configure a debian testing system and apt-get lazarus and so > > on... Nearly nowhere the lazarus package is preinstalled. > > You don't need Debian Testing. My system is Debian Stable (i386) since > 2001/2002. Never have had a serious problem installing > Lazarus/Freepascal. How do you install Lazarus/Freepascal with apt or else? I am a friend of userfriendly software... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problems to compile FPC 2.3.0
On Mon, 12 Oct 2009 12:49:03 +0200, Jonas Maebe wrote: > On 11 Oct 2009, at 18:37, Matthias Klumpp wrote: >> >> I decided to use this version of FPC for now. Thank you for your help! >> But now I have problems to compile the compiler: >> First I got the error message >> >> make[7]: *** No rule to make target `/prt0.as', needed by `prt0.o'. >> Stop. > > How did you try to compile it? I don't remember seeing this error > message mentioned before. Okay, maybe this only happens if you remove all Makefiles and run fpcmake again... I tried it again and now - like magic - it works! But now I have another problem: FPC 2.3.0 does not link against the new GDB 7 debugger: (.text+0x38): undefined reference to `decimal32ToNumber' /usr/lib64/libgdb.a(dfp.o): In function `decimal_to_number': (.text+0x48): undefined reference to `decimal128ToNumber' /usr/lib64/libgdb.a(dfp.o): In function `decimal_to_number': (.text+0x58): undefined reference to `decimal64ToNumber' /usr/lib64/libgdb.a(dwarf2read.o): In function `dwarf2_read_section': (.text+0x2230): undefined reference to `inflateInit_' /usr/lib64/libgdb.a(dwarf2read.o): In function `dwarf2_read_section': (.text+0x226e): undefined reference to `inflate' /usr/lib64/libgdb.a(dwarf2read.o): In function `dwarf2_read_section': (.text+0x2282): undefined reference to `inflateReset' /usr/lib64/libgdb.a(dwarf2read.o): In function `dwarf2_read_section': (.text+0x2295): undefined reference to `inflateEnd' /usr/lib64/libbfd.a(compress.o): In function `bfd_uncompress_section_contents': /build/buildd/binutils-2.19.91.20091006/builddir-single/bfd/../../bfd/compress.c:96: undefined reference to `inflateInit_' /build/buildd/binutils-2.19.91.20091006/builddir-single/bfd/../../bfd/compress.c:103: undefined reference to `inflate' /build/buildd/binutils-2.19.91.20091006/builddir-single/bfd/../../bfd/compress.c:106: undefined reference to `inflateReset' /build/buildd/binutils-2.19.91.20091006/builddir-single/bfd/../../bfd/compress.c:108: undefined reference to `inflateEnd' fp.pas(575,1) Error: Error while linking fp.pas(575,1) Fatal: There were 1 errors compiling module, stopping Etc... Should I report a bug about this or does someone already work on this? Thank you for your help again! Matthias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problems to compile FPC 2.3.0
On Mon, 12 Oct 2009 12:49:03 +0200, Jonas Maebe wrote: > On 11 Oct 2009, at 18:37, Matthias Klumpp wrote: >> >> I decided to use this version of FPC for now. Thank you for your help! >> But now I have problems to compile the compiler: >> First I got the error message >> >> make[7]: *** No rule to make target `/prt0.as', needed by `prt0.o'. >> Stop. > > How did you try to compile it? I don't remember seeing this error > message mentioned before. Okay, maybe this only happens if you remove all Makefiles and run fpcmake again... I tried it again and now - like magic - it works! But now I have another problem: FPC 2.3.0 does not link against the new GDB 7 debugger: (.text+0x38): undefined reference to `decimal32ToNumber' /usr/lib64/libgdb.a(dfp.o): In function `decimal_to_number': (.text+0x48): undefined reference to `decimal128ToNumber' /usr/lib64/libgdb.a(dfp.o): In function `decimal_to_number': (.text+0x58): undefined reference to `decimal64ToNumber' /usr/lib64/libgdb.a(dwarf2read.o): In function `dwarf2_read_section': (.text+0x2230): undefined reference to `inflateInit_' /usr/lib64/libgdb.a(dwarf2read.o): In function `dwarf2_read_section': (.text+0x226e): undefined reference to `inflate' /usr/lib64/libgdb.a(dwarf2read.o): In function `dwarf2_read_section': (.text+0x2282): undefined reference to `inflateReset' /usr/lib64/libgdb.a(dwarf2read.o): In function `dwarf2_read_section': (.text+0x2295): undefined reference to `inflateEnd' /usr/lib64/libbfd.a(compress.o): In function `bfd_uncompress_section_contents': /build/buildd/binutils-2.19.91.20091006/builddir-single/bfd/../../bfd/compress.c:96: undefined reference to `inflateInit_' /build/buildd/binutils-2.19.91.20091006/builddir-single/bfd/../../bfd/compress.c:103: undefined reference to `inflate' /build/buildd/binutils-2.19.91.20091006/builddir-single/bfd/../../bfd/compress.c:106: undefined reference to `inflateReset' /build/buildd/binutils-2.19.91.20091006/builddir-single/bfd/../../bfd/compress.c:108: undefined reference to `inflateEnd' fp.pas(575,1) Error: Error while linking fp.pas(575,1) Fatal: There were 1 errors compiling module, stopping Etc... Should I report a bug about this or does someone already work on this? Thank you for your help again! Matthias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
2009/10/12 Rainer Stratmann : > Am Montag, 12. Oktober 2009 11:02 schrieb Jürgen Hestermann: >> > Remember, Pascal is merely a TEACHING language, unsuitable for commercial >> > software development, which is why we have C. :) >> >> And why should that be the case? What are the outstanding feature of C >> that make it so supperiour? It's illogical and hard to maintain syntax? >> Or is it just that it was available for free on all unix systems? > > Yes, it is available everywhere. > And it is easier to copy unix code then. > > Remember that it is still not easy to come to freepascal. > You have to configure a debian testing system and apt-get lazarus and so on... > Nearly nowhere the lazarus package is preinstalled. You don't need Debian Testing. My system is Debian Stable (i386) since 2001/2002. Never have had a serious problem installing Lazarus/Freepascal. Gustavo ___ 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] Who said Pascal isn't popular
C is popular *even though* it is an awful concept. It is like the video cassettes. Betamax and Video2000 were the better quality, but VHS was the most popular cassette. Yes, sadly this is true (same with Microsoft pressing one awfull OS after the other into the market). Not always the best wins. Good marketing is important. The mass does *not* look behind the scene but follows what others do or what the marketing tells them. ___ 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] Problems to compile FPC 2.3.0
On 11 Oct 2009, at 18:37, Matthias Klumpp wrote: On Sun, 11 Oct 2009 11:09:58 +0200 (CEST), mar...@stack.nl (Marco van de Voort) wrote: In our previous episode, Matthias Klumpp said: also be in 2.4.0 I do not have problems with FPC 2.3.x, but it is not allowed for me to use experimental SVN software :-( Early next year sounds good! It's not experimental anymore, it now has a "fixes" branch label :-) I decided to use this version of FPC for now. Thank you for your help! But now I have problems to compile the compiler: First I got the error message make[7]: *** No rule to make target `/prt0.as', needed by `prt0.o'. Stop. How did you try to compile it? I don't remember seeing this error message mentioned before. Jonas ___ 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] Who said Pascal isn't popular
Am Montag, 12. Oktober 2009 12:31 schrieb Jürgen Hestermann: > > Yes, it is available everywhere. > > And it is easier to copy unix code then. > > Remember that it is still not easy to come to freepascal. > > You have to configure a debian testing system and apt-get lazarus and so > > on... Nearly nowhere the lazarus package is preinstalled. > > Yes, these are the reasons for having C in the first place. But it is > not because of the beauty (stict logic) and the features of the > language. Just the opposite: C is popular *even though* it is an awful > concept. It is like the video cassettes. Betamax and Video2000 were the better quality, but VHS was the most popular cassette. http://de.wikipedia.org/wiki/Video_2000 http://de.wikipedia.org/wiki/Formatkrieg_(Videorekorder) (sorry in german language) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
2009/10/12 Marco van de Voort : >> >> Yes, it is available everywhere. > > Try compiling some Unix C code on Windows. > > Give me Free Pascal any time :-) +1 ...and Try compiling some Unix C code on Unix/Linux/etc. I always battle. Give me Free Pascal too! :-) PS: Wow, did this message thread take a turn. I was simply impressed by the "unknown to me" amount of Pascal compilers over the years. I only knew about Turbo Pascal and Virtual Pascal for OS/2, in my younger years at school. -- 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] Who said Pascal isn't popular
In our previous episode, Rainer Stratmann said: > > > Remember, Pascal is merely a TEACHING language, unsuitable for commercial > > > software development, which is why we have C. :) > > > > And why should that be the case? What are the outstanding feature of C > > that make it so supperiour? It's illogical and hard to maintain syntax? > > Or is it just that it was available for free on all unix systems? > > Yes, it is available everywhere. Try compiling some Unix C code on Windows. Give me Free Pascal any time :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
Yes, it is available everywhere. And it is easier to copy unix code then. Remember that it is still not easy to come to freepascal. You have to configure a debian testing system and apt-get lazarus and so on... Nearly nowhere the lazarus package is preinstalled. Yes, these are the reasons for having C in the first place. But it is not because of the beauty (stict logic) and the features of the language. Just the opposite: C is popular *even though* it is an awful concept. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
2009/10/12 Rainer Stratmann : > > Which editor do you use? I'm not the one you replied to, but I can answer based on my experience. I never use APT for FPC or Lazarus because they update packages to slowly. I work directly from the Git mirror repositories. * If I'm at work or home, I use Lazarus IDE. * If I remote access another PC, I use mcedit (built-in Midnight Commander's editor) or Free Pascal's Text IDE or sometimes even gEdit. * When in a pinch, I will use vi (but then I am seriously disparate). -- 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] Who said Pascal isn't popular
Zitat von Rainer Stratmann : Am Montag, 12. Oktober 2009 11:02 schrieb Jürgen Hestermann: > Remember, Pascal is merely a TEACHING language, unsuitable for commercial > software development, which is why we have C. :) And why should that be the case? What are the outstanding feature of C that make it so supperiour? It's illogical and hard to maintain syntax? Or is it just that it was available for free on all unix systems? Yes, it is available everywhere. And it is easier to copy unix code then. Remember that it is still not easy to come to freepascal. You have to configure a debian testing system and apt-get lazarus and so on... Nearly nowhere the lazarus package is preinstalled. Standard user distributions do not install any development software. This is how linux distros work and is the same for every devel software, not only lazarus. Some distros allow to create your own custom install CD/DVD. This is used for network installs or for pools. Maybe it is possible write a linux "installer", which analyzes your system and downloads and installs all needed packages. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
Am Montag, 12. Oktober 2009 12:05 schrieb leledumbo: > you don't need lazarus just to use fpc, and I don't need that debian > testing system on my kubuntu. Which editor do you use? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
> Remember, Pascal is merely a TEACHING language, unsuitable for commercial > software development, which is why we have C. :) That's what I'm going to change. I've told my friends and collegemates about Pascal superiority (suitable for any programming needs, GUI, WebApps, Server, etc.) and they don't know about it at all because what they know is what their teachers or lecturers say, (without any further research, of course), and becomes a doctrine that makes Pascal look bad in their eyes. > Yes, it is available everywhere. > And it is easier to copy unix code then. And harder to port it to Windows without Unix (POSIX?) environment emulation (including headers, etc.) > You have to configure a debian testing system and apt-get lazarus and so > on... you don't need lazarus just to use fpc, and I don't need that debian testing system on my kubuntu. > Nearly nowhere the lazarus package is preinstalled. other popular languages are often don't come preinstalled as well. -- View this message in context: http://www.nabble.com/Who-said-Pascal-isn%27t-popular-tp25848247p25853217.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
Am Montag, 12. Oktober 2009 11:02 schrieb Jürgen Hestermann: > > Remember, Pascal is merely a TEACHING language, unsuitable for commercial > > software development, which is why we have C. :) > > And why should that be the case? What are the outstanding feature of C > that make it so supperiour? It's illogical and hard to maintain syntax? > Or is it just that it was available for free on all unix systems? Yes, it is available everywhere. And it is easier to copy unix code then. Remember that it is still not easy to come to freepascal. You have to configure a debian testing system and apt-get lazarus and so on... Nearly nowhere the lazarus package is preinstalled. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
Remember, Pascal is merely a TEACHING language, unsuitable for commercial software development, which is why we have C. :) And why should that be the case? What are the outstanding feature of C that make it so supperiour? It's illogical and hard to maintain syntax? Or is it just that it was available for free on all unix systems? ___ 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] Mac OS X 10.6.1 problem
In our previous episode, Jonas Maebe said:
> > Using OS X 10.6.1, FPC 2.2.4, Xcode 3.2 on intel iMac.
> >
> > The program and units all have {$I Directives.inc} at top of each
> > file. Compile lists many errors like:
> >
> > 6: Mode switch "OBJFPC" not allowed here
> >
> > Any hints?
>
> This is unrelated to Mac OS X.
>
> A modeswitch must occur before any code is parsed. In practice this
> means right above or below the "unit" statement. Older versions of FPC
> (2.2.0?) were more lenient in checking this.
(I talked to Paul on IRC, and it was multiple $mode directives that caused
the problem. Afaik that limitation was added at that same time too)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac OS X 10.6.1 problem
On 09 Oct 2009, at 19:57, Paul Davidson wrote:
Using OS X 10.6.1, FPC 2.2.4, Xcode 3.2 on intel iMac.
The program and units all have {$I Directives.inc} at top of each
file. Compile lists many errors like:
6: Mode switch "OBJFPC" not allowed here
Any hints?
This is unrelated to Mac OS X.
A modeswitch must occur before any code is parsed. In practice this
means right above or below the "unit" statement. Older versions of FPC
(2.2.0?) were more lenient in checking this.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Mac OS X 10.6.1 problem
Using OS X 10.6.1, FPC 2.2.4, Xcode 3.2 on intel iMac.
The program and units all have {$I Directives.inc} at top of each
file. Compile lists many errors like:
6: Mode switch "OBJFPC" not allowed here
Any hints?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
