Re: Re[2]: [fpc-devel] Circular references and forward declarations
> > To summarize: From the language/compiler point of view, large files are > no problem. We already concluded that, and in some cases the language > even forces you to use large files. > > But, from a personal - human point of view, large files are not always > nice. At least, some people think so. They want to have some overview > over the file, or have some preference for one class in a file. (Why? > Well, people are not logic entities, they can not handle very complex > things) Yes, an IDE can help with that. This reminds me of a component (or something) I intend(ed) to implement to interactively navigate a synedit view with zoom. The usage I envisioned for it was the file comparison tool (Pariter) I started based on Angus Johnson's diff, but I think it would be interesting to any source code editor... Cheers, Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Nikolai ZHUBR schrieb: > Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote: > >> On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote: > >>> Why ? Every class in 1 file is perfectly possible with include files, and 1 >>> big unit file. > >> Ok, include files seem to solve this problem. >> I don't know why they are not commonly used in Delphi programs as source > > I don't like include files and try to not use them anywhere except > in some cross-platform libraries, along with conditional compilation, > and even then, I always try to minimize them. > > An include file by its pure nature is just an arbitary fragment. It > does not necessarily have any consistent meaning on its own, either > logically or syntactically. Therefore, compiler does not (and have > no way to) do any integrity/dependancy checking on include file as > on a separate entity. For the same reason, looking at an include file > may give absolutely no idea of its meaning unless you also open all > its including files along with. > > The concept of include files is not part of the language. It is just > a tool to mitigate the troubles of editing/storage/archiving and > such other maintenance burden tasks. From the language perspective, > include files just do not exist! They are substituted textually, just > like copy-n-paste, effectively producing one (big or not, whatever) > file anyway. Period. Yes. But the same applies to splitting C++ projects in one class per header/c-file ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Re[2]: [fpc-devel] Circular references and forward declarations
On Wed, 2010-01-06 at 16:56 +0300, Nikolai ZHUBR wrote: > Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote: > > > On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote: > > >> Why ? Every class in 1 file is perfectly possible with include files, and 1 > >> big unit file. > > > Ok, include files seem to solve this problem. > > I don't know why they are not commonly used in Delphi programs as source > An include file by its pure nature is just an arbitary fragment. It > does not necessarily have any consistent meaning on its own, either > logically or syntactically. Therefore, compiler does not (and have > no way to) do any integrity/dependancy checking on include file as > on a separate entity. For the same reason, looking at an include file > may give absolutely no idea of its meaning unless you also open all > its including files along with. > > The concept of include files is not part of the language. It is just > a tool to mitigate the troubles of editing/storage/archiving and > such other maintenance burden tasks. From the language perspective, > include files just do not exist! They are substituted textually, just > like copy-n-paste, effectively producing one (big or not, whatever) > file anyway. Period. > > On the other hand, object pascal as a language offers 2 mechanisms > for structuring code logically: units and classes. Both are > language concepts, both allow compiler to actively help programmer > by means of visibility restrictions etc. I would say, some corner > cases do exist, where the concept of units and the concept of classes > somehow clinch in unconfortable manner. IMHO this does not happen > too often and there are some known workarounds. Still probably, > the language in its current form has its limits. Maybe these could > be extended eventually, at least "out of academic curiosity". In > practice however, object pascal already provides such benefits that > it is imho quite fair to tolerate some corner rough edges. To summarize: From the language/compiler point of view, large files are no problem. We already concluded that, and in some cases the language even forces you to use large files. But, from a personal - human point of view, large files are not always nice. At least, some people think so. They want to have some overview over the file, or have some preference for one class in a file. (Why? Well, people are not logic entities, they can not handle very complex things) Yes, an IDE can help with that. Or include files. So include files are only useful for the mindset of people, the compiler doesn't care. So it's completely up to you: do you really need (not possible: want) small files? Use include files. (Are you using Delphi, bad luck;) ) Don't you need small files: there is no problem at all. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: OT: Lazarus behaviour (tabs/fold) [Re: [fpc-devel] Circular references and forward declarations]
Martin wrote:
> {$region}
> {$endregion}
>
Perfect !
I feel this should solve much the OP's problem with big source files.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
OT: Lazarus behaviour (tabs/fold) [Re: [fpc-devel] Circular references and forward declarations]
Michael Schnell wrote:
Juha Manninen wrote:
I hope Lazarus can soon edit parts of one file in many editor tabs.
http://www.lazarus.freepascal.org/index.php/topic,8304.msg39889.html#msg39889
http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/046906.html
It can compress entities (e.g. Functions) to a single line. Seems
helpful on that behalf. Maybe this feature could be extended e.g. by
recognizing {$part xxx} comments or similar.
{$region}
{$endregion}
{%region}
{%endregion}
{$region /fold} // autofold on load
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jeff Wormsley wrote: I would think any time you have two objects that need bidirectional access of any sort that you would need to define an connector object to make this link, so the data or functions that needs to be shared between the two don't reside in either object, but in the connector object. The problem at the time was that the BeAPI is C++ and uses multiple inheritance and a lot of the kinds of forward class declarations OP was asking for. The guys were trying to recreate a class for class analog of the API, so changing the API constructs was not an option. The rational was that creating a "new" API would alienate Pascal coders from the greater BeOS development community and would mean that all of the documentation would be useless as reference. This is obviously an edge case though and a self imposed restriction. M ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Wimpie Nortje wrote: > I don't want to start a AVR/PIC fight because it always ends up in a > religous war We could just as well add Renesas and whatever other such archs :) . I suppose each has it's pros and cons, otherwise it would already have died out out taken the world. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Wimpie Nortje said: > Marco van de Voort wrote: > > Yes, but from what I remember it was canceled because the amount of > > periphery on the chip is poor. I also looked at ARM, but while there is more > > choice there, it is fragmented over multiple vendors, with multiple > > toolchains (if a free one exists at all) > > > What was canceled? The AVR devices is certainly not and neither are the > GCC toolchains (one for 8b and one for 32b). Our investigation into AVR. > > PIC32 is only interesting because it is slightly faster and has more mem. > > But that would be more a future proofing thing, since we don't really lack > > it atm. > I don't want to start a AVR/PIC fight because it always ends up in a > religous war and this is the wrong list anyway. However, some of my > reasons for moving from PIC to AVR are: I've found that most of those sentiments are based on old arguments that don't go nowadays. Such discussions could be kept on track ( and interesting) if you simply name numbers. > - AVR is faster, microchip 16-bit maxes at 40 or 50MIPS. Our is 40MIPS. 32-bit goes higher, 80MIPS or so. We keep "speed" mostly in reserve for unexpected problems we have to improvise on . Most of the normal functionality ( a shift register, encoder based) is done by hardware on the chip with no blocking or polling own code, leaving the CPU power (and a lot of normal goodies like pins with special purposes and timers) free for improvising in case of trouble. > - has usually more memory, which programs faster Only if you need it. I typically use 1 - 1.5 kb of the PIC that has 8kb (and there are 16kb editions). PIC32 parts go up to 128kb (ram) iirc. All 16-bit and 32-bit mem is dual ported for DMA purposes. > - has higher code density, No idea. Don't care. The flash of the standard part is 128kb, and I use typically 7k, and haven't been above 11k. We have more flash because the motorcontrol parts are more expensive, and the more expensive parts have more flash. (typical region Eur5/chip) > - has cheaper tools (programmers etc) Microchip programmers start from Eur 20. (note that this particular bit has changed significantly in the last 2 years) > - has free toolchains for all devices Afaik all 16-bit devices are supported by the free toolchains, but have optimization disabled. > The down side is that Microchip has never to my knowledge obsoleted a > device, whereas Atmel quite often do obsolete parts which then requires > recompiling the program for the replacement part. Another important reason was the existance of high pin count (100,144) devices, since we have a lot of binary I/O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Circular references and forward declarations
Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote: > On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote: >> Why ? Every class in 1 file is perfectly possible with include files, and 1 >> big unit file. > Ok, include files seem to solve this problem. > I don't know why they are not commonly used in Delphi programs as source I don't like include files and try to not use them anywhere except in some cross-platform libraries, along with conditional compilation, and even then, I always try to minimize them. An include file by its pure nature is just an arbitary fragment. It does not necessarily have any consistent meaning on its own, either logically or syntactically. Therefore, compiler does not (and have no way to) do any integrity/dependancy checking on include file as on a separate entity. For the same reason, looking at an include file may give absolutely no idea of its meaning unless you also open all its including files along with. The concept of include files is not part of the language. It is just a tool to mitigate the troubles of editing/storage/archiving and such other maintenance burden tasks. From the language perspective, include files just do not exist! They are substituted textually, just like copy-n-paste, effectively producing one (big or not, whatever) file anyway. Period. On the other hand, object pascal as a language offers 2 mechanisms for structuring code logically: units and classes. Both are language concepts, both allow compiler to actively help programmer by means of visibility restrictions etc. I would say, some corner cases do exist, where the concept of units and the concept of classes somehow clinch in unconfortable manner. IMHO this does not happen too often and there are some known workarounds. Still probably, the language in its current form has its limits. Maybe these could be extended eventually, at least "out of academic curiosity". In practice however, object pascal already provides such benefits that it is imho quite fair to tolerate some corner rough edges. Nikolai ZHUBR > files. It may be a culture or convention also, technically it should be > possible with Delphi as well. > I must change my mindset for those include files. > Juha Manninen > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Matt Emson wrote: I would also agree. I used to use Interfaces or raise shared classes/declarations to a new unit both could use to overcome this issue myself. But I remember the Be GUI porters having loads of issues mimicing the Be API header structure because there were so many forward class declarations in the C++. It was impossible to do a unit to header file match because circular dependencies crept up at almost every turn. Without direct matching of header and unit names, the Be API documentation became hard to use. I don't know if they ever solved it, maybe if Olivier is still about, he can chime in? I would think any time you have two objects that need bidirectional access of any sort that you would need to define an connector object to make this link, so the data or functions that needs to be shared between the two don't reside in either object, but in the connector object. Because if the data or functions are needed by both, they really aren't a part of either, it is its own thing and should have its own object. Or maybe I'm not seeing the problem properly. I just know that the few times I've hit on the circular unit problem where A needed to know about B, and B needed to know about A, that's how I've solved it, by making another unit C with the parts that needed access and pointing both A and B to that new unit. Maybe my problems were trivial, though. I'm certainly no OOP expert. Jeff. -- I haven't smoked for 3 years, 4 months and 2 weeks, saving $5,572.94 and not smoking 37,152.94 cigarettes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: Yes, but from what I remember it was canceled because the amount of periphery on the chip is poor. I also looked at ARM, but while there is more choice there, it is fragmented over multiple vendors, with multiple toolchains (if a free one exists at all) What was canceled? The AVR devices is certainly not and neither are the GCC toolchains (one for 8b and one for 32b). PIC32 is only interesting because it is slightly faster and has more mem. But that would be more a future proofing thing, since we don't really lack it atm. I don't want to start a AVR/PIC fight because it always ends up in a religous war and this is the wrong list anyway. However, some of my reasons for moving from PIC to AVR are: - AVR is faster, - has usually more memory, which programs faster - has higher code density, - has cheaper tools (programmers etc) - has free toolchains for all devices The down side is that Microchip has never to my knowledge obsoleted a device, whereas Atmel quite often do obsolete parts which then requires recompiling the program for the replacement part. But motorcontrol parts (integrated quadrature encoder, preferably several) is absolutely mandatory. I have never used motor control but there are parts intended for this ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: > > I rather use FPC to substitute some of my 10-20 line programs on the > delphi side. This is what I intend to get running before I retire :) : Have an existing Delphi project of the size you mention run on NIOS/Linux. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: > In our previous episode, Wimpie Nortje said: >> Did you have a look at AVR? > > Yes, but from what I remember it was canceled because the amount of > periphery on the chip is poor. I also looked at ARM, but while there is more > choice there, it is fragmented over multiple vendors, with multiple > toolchains (if a free one exists at all) Of course ;) Called FPC :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Wimpie Nortje said: > Did you have a look at AVR? Yes, but from what I remember it was canceled because the amount of periphery on the chip is poor. I also looked at ARM, but while there is more choice there, it is fragmented over multiple vendors, with multiple toolchains (if a free one exists at all) PIC32 is only interesting because it is slightly faster and has more mem. But that would be more a future proofing thing, since we don't really lack it atm. But motorcontrol parts (integrated quadrature encoder, preferably several) is absolutely mandatory. > They use GCC, although commercial compilers are also available should > you need it. I have used GCC-AVR for years without problems. So does 16-bit microchip, and I'm using it for 2 years in production now. The 8-bit embedded ethernet part (even PHY!) is the only exception, and functions at the same time (same print) as spare part for stuff older than 2 years, so we can't get rid of it anyway and is quite cheap. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jonas Maebe schrieb: > > On 06 Jan 2010, at 13:04, Florian Klaempfl wrote: > >> Jonas Maebe schrieb: >>> >>> Another reason is probably to speed up the compilation: >>> * (re)compiling huge source files can be slow and/or require lots of >>> memory, depending on the used compiler (and debug information or >>> optimization settings) >> >> For single class c++ files, imo most of the time is spent into reading >> the huge headers which are often even not needed and a complete mess >> because nobody has an overview which classes are used and which not. > > It depends. Since these compilers only see whatever is in the current > source file (and its header files), putting more code in the same source > file can significantly slow down interprocedural optimizations (as soon > as one algorithm with quadratic complexity is involved). And inlining > can significantly increase the complexity of single routines as well, > making stuff such as register allocation much slower :) On the other hand keeping things in different files avoids these optimizations. And being honest: I think using a debug switch set without any optimization and with maximum checks and fast compilation should be used for developer builds while wpo, inlining etc. is switched on during relese builds. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 06 Jan 2010, at 13:04, Florian Klaempfl wrote: Jonas Maebe schrieb: Another reason is probably to speed up the compilation: * (re)compiling huge source files can be slow and/or require lots of memory, depending on the used compiler (and debug information or optimization settings) For single class c++ files, imo most of the time is spent into reading the huge headers which are often even not needed and a complete mess because nobody has an overview which classes are used and which not. It depends. Since these compilers only see whatever is in the current source file (and its header files), putting more code in the same source file can significantly slow down interprocedural optimizations (as soon as one algorithm with quadratic complexity is involved). And inlining can significantly increase the complexity of single routines as well, making stuff such as register allocation much slower :) At least compiling Apple's Mac OS X linker is fairly slow, even though it's only about 1MB of code. The reason is that they put virtually all of the classes into the header files, and then include those together in the main cpp file. See http://www.opensource.apple.com/source/ld64/ld64-95.2.12/src/ld/ . Pretty much the entire linker is implemented in MachOReaderRelocatable.hpp and MachOWriterExecutable.hpp (note that I'm not claiming that this is how typical C++ programs are structured, it's only to illustrate that compiling one huge file can be quite slow). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Florian Klaempfl said: > > memory, depending on the used compiler (and debug information or > > optimization settings) > > For single class c++ files, imo most of the time is spent into reading > the huge headers which are often even not needed and a complete mess > because nobody has an overview which classes are used and which not. And even if you forget that, there is the added compiler startup/initialization/finalization per compilation for gcc. Average larger files compile probably faster overall. > > * every separate C/C++ file can be compiled in parallel with all others > > That's might be a point. Only if you stuff it in one, and have no others to parallelize One big file just goes as well parallel (with other big files and smaller files). Moreover it assumes that the smaller files don't depend too much on eachother. (since that would effectively serialize them again) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Michael Schnell said: > > But I still use the PIC18F60j60 part since there is no > > 16-bit integrated ethernet part, and as spare replacement for legacy parts. > > This fried uses the (quite new) Microchip Ethernet MAC/PHY chip > (including frame buffers, doing 100MBit) that can be connected to the > PIC as an SPI slave (just three or four wires). Microsoft provides > appropriate software for this setup. He's going to give me one of his > board very soon. I'm looking forward to playing with that. Yes. I bought the pictail kit for that part, and it is lying right beside me. Trouble is that the print we have now (externally fabricated) don't connect the INT pin needed for SPI frame mode to a connector, so it'll have to wait a generation. Luckily we didn't buy a large batch of prints. But it is also a bit that the whole point of the controller is being realtime. THe ethernet stuff till now is on systems that only have to react to 1ms magnitude events, while the 16-bitters are more like pseudo realtime into the 10us magnitude. External (microchip stack) software can detract from this, and will need a lot of testing. An extra reason is that the pic18 10-mbit stuff doesn't work very well connected to gigabit switches. > > The PIC32 look interesting, but there is no motorcontrol (quadrature > > decoder) in that family yet, something that I require. > > What about using a slave-PIC coupled by SPI (this is what my friend does > all the time). That is more like what I'm planning. It will depend how good the frame-spi works. (IOW if it doesn't increase latency) > As the PIC32 is a MIPS architecture, it could benefit from the MIPS port > of FPC that quite recently was discussed here. Not for my (work) purposes, though I'd certainly play with it. While I would welcome a more forgiving syntax than C (with its == vs = problems), the avg program is small (1000 line magnitude, of which 700 lines are the same everywhere). It is not worth abondoning the supported compiler for. I rather use FPC to substitute some of my 10-20 line programs on the delphi side. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On Wed, 6 Jan 2010, Michael Schnell wrote: Include files - just like conditional defines - totally mess up all code tools. Is this true for the newest versions of Delphi, too ? I seem to remember rumors about lots of IDE improvements. Well, not yet in D2009 as far as I remember, but I don't know about D2010, since I don't own a copy yet ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
> Include files - just like conditional defines - totally mess up all > code tools. Is this true for the newest versions of Delphi, too ? I seem to remember rumors about lots of IDE improvements. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jonas Maebe schrieb: > > On 06 Jan 2010, at 12:14, Florian Klaempfl wrote: > >> Different languages, different habits. I even consider putting every >> class in its own header and implementation file as a bad habit. There is >> no reason to do anymore because modern C/C++ compiler can smartlink on a >> sub-object level which they could not for years. > > Another reason is probably to speed up the compilation: > * (re)compiling huge source files can be slow and/or require lots of > memory, depending on the used compiler (and debug information or > optimization settings) For single class c++ files, imo most of the time is spent into reading the huge headers which are often even not needed and a complete mess because nobody has an overview which classes are used and which not. > * every separate C/C++ file can be compiled in parallel with all others That's might be a point. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On Wed, 6 Jan 2010, Juha Manninen wrote: On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote: Why ? Every class in 1 file is perfectly possible with include files, and 1 big unit file. Ok, include files seem to solve this problem. I don't know why they are not commonly used in Delphi programs as source files. It may be a culture or convention also, technically it should be possible with Delphi as well. The Delphi compiler has no problems with include files, but the Delphi IDE has; Include files - just like conditioanl defines - totally mess up all code tools. Probably the reason why they are not encouraged. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: > I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very > happy with them. Same here (with PIC 24xx). A friend of mine uses the 33s very happily, too. > But I still use the PIC18F60j60 part since there is no > 16-bit integrated ethernet part, and as spare replacement for legacy parts. This fried uses the (quite new) Microchip Ethernet MAC/PHY chip (including frame buffers, doing 100MBit) that can be connected to the PIC as an SPI slave (just three or four wires). Microsoft provides appropriate software for this setup. He's going to give me one of his board very soon. I'm looking forward to playing with that. > > The PIC32 look interesting, but there is no motorcontrol (quadrature > decoder) in that family yet, something that I require. What about using a slave-PIC coupled by SPI (this is what my friend does all the time). As the PIC32 is a MIPS architecture, it could benefit from the MIPS port of FPC that quite recently was discussed here. As you are considering PIC32 the MIPS FPC might have a better chance to come into existence now I would be inclined to help on this issue, as I am intending to use NIOS which is very similar architecture to MIPS. :) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 06 Jan 2010, at 12:14, Florian Klaempfl wrote: Different languages, different habits. I even consider putting every class in its own header and implementation file as a bad habit. There is no reason to do anymore because modern C/C++ compiler can smartlink on a sub-object level which they could not for years. Another reason is probably to speed up the compilation: * (re)compiling huge source files can be slow and/or require lots of memory, depending on the used compiler (and debug information or optimization settings) * every separate C/C++ file can be compiled in parallel with all others Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Did you have a look at AVR? They use GCC, although commercial compilers are also available should you need it. I have used GCC-AVR for years without problems. Marco van de Voort wrote: In our previous episode, Michael Schnell said: Which is that then? Afaik the microchip own, and the Hitech compilers can do so perfectly? CCS Same had been the cheapest option for a C compiler to try out the PICs. Well, the microchip one academic option is free. So CCS gives money with their tools ? :-) I never switched to something else, as I am abandoning the 8 bit PICs for the 16 Bit ones that are supported by a decent gcc that can be tested in a non-payed public version and now the commercially supported version. I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very happy with them. But I still use the PIC18F60j60 part since there is no 16-bit integrated ethernet part, and as spare replacement for legacy parts. The PIC32 look interesting, but there is no motorcontrol (quadrature decoder) in that family yet, something that I require. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen wrote: > Ok, include files seem to solve this problem. > I don't know why they are not commonly used in Delphi programs as source > files. Maybe because (some old version of the) Delphi IDE's debugger could not step into include files. AFAIK, the actual Lazarus can do this with no problem. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote: > Why ? Every class in 1 file is perfectly possible with include files, and 1 > big unit file. Ok, include files seem to solve this problem. I don't know why they are not commonly used in Delphi programs as source files. It may be a culture or convention also, technically it should be possible with Delphi as well. I must change my mindset for those include files. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen wrote:
> I hope Lazarus can soon edit parts of one file in many editor tabs.
>
>
It can compress entities (e.g. Functions) to a single line. Seems
helpful on that behalf. Maybe this feature could be extended e.g. by
recognizing {$part xxx} comments or similar.
Maybe you could even do this :)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Michael Schnell said: > > Which is that then? Afaik the microchip own, and the Hitech compilers can do > > so perfectly? > > CCS > > Same had been the cheapest option for a C compiler to try out the PICs. Well, the microchip one academic option is free. So CCS gives money with their tools ? :-) > I never switched to something else, as I am abandoning the 8 bit PICs > for the 16 Bit ones that are supported by a decent gcc that can be > tested in a non-payed public version and now the commercially supported > version. I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very happy with them. But I still use the PIC18F60j60 part since there is no 16-bit integrated ethernet part, and as spare replacement for legacy parts. The PIC32 look interesting, but there is no motorcontrol (quadrature decoder) in that family yet, something that I require. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: > > Other programming languages have different cultures. See the comment from my > original post in this thread. It was from a professional programmer and I > understand it. Some development teams want to put every class into its own > file. Different languages, different habits. I even consider putting every class in its own header and implementation file as a bad habit. There is no reason to do anymore because modern C/C++ compiler can smartlink on a sub-object level which they could not for years. > C and C++ even have headers in separate files (which is messy IMO). > > So, if a professional team chooses a programming language / environment for a > project, this one feature can make a strong point against Object Pascal. Then they are not eduacated well enough because they don't know the reason why C++ programmers put (past tense) every class into it's own object file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On Wed, 6 Jan 2010, Juha Manninen wrote: On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote: Juha Manninen schrieb: Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? I must admit this is a good point. This is more of a cultural issue between programming languages. If the tool chain supports big source files and if people accept them, there is no problem. I hope Lazarus can soon edit parts of one file in many editor tabs. Other programming languages have different cultures. See the comment from my original post in this thread. It was from a professional programmer and I understand it. Some development teams want to put every class into its own file. C and C++ even have headers in separate files (which is messy IMO). So, if a professional team chooses a programming language / environment for a project, this one feature can make a strong point against Object Pascal. Why ? Every class in 1 file is perfectly possible with include files, and 1 big unit file. If someone comes from C this should not be a problem, since every C file simply is an include file, header file or not. There are no "privileged files". In pascal there are: the unit and the program. The unit is called 'unit' because it 'unites' a set of routines that are closely interrelated. Honestly, I don't understand what the fuss is all about. You can make it as complicated or as simple as you want, it is all up to you. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Juha Manninen said: > Other programming languages have different cultures. See the comment from my > original post in this thread. It was from a professional programmer and I > understand it. Some development teams want to put every class into its own > file. C and C++ even have headers in separate files (which is messy IMO). > > So, if a professional team chooses a programming language / environment for a > project, this one feature can make a strong point against Object Pascal. If we change FPC so that a C++ team that only knows C++ feels perfectly at home directly, we might as well throw away FPC and restart building a C++ system. There is no end to this kind of uninformed arguments, and when you really dig into it, there is nothing practical to be gained from it. Specially for systems like Java and C# that have a totally different concept of organizing source and finding compilation order. (for C++ you could also C#, Java, VB.NET, Ruby, Python or whatever) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: > > Which is that then? Afaik the microchip own, and the Hitech compilers can do > so perfectly? CCS Same had been the cheapest option for a C compiler to try out the PICs. I never switched to something else, as I am abandoning the 8 bit PICs for the 16 Bit ones that are supported by a decent gcc that can be tested in a non-payed public version and now the commercially supported version. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Florian Klaempfl schrieb: > Marco van de Voort schrieb: >>> (remember the people to complain about the huge amount of files of the >>> fpc rtl :)?). >> The point is that they are right from a birds-eye general application >> development view. > > I wanted only to point out that there pros and cons for small/large > units and if a design requires to put a lot of stuff into one unit > becuase it is heavily interwinded, I see no problem with it. ... and splitting the unit by external circular class types makes no use, it even makes things less readable. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote: > Juha Manninen schrieb: > > Still, best solution has been to put everything into one big file. And > > still, I don't like that compiler forces such a thing. > > The compiler forces you many other things. Still, I don't get what's the > problem with a large unit if it's really needed (and nothing like > abstract base classes or interfaces or type casts or ... helps). Stuff > closely depending on each other should end in the same unit. You even > cannot test a unit with external circular class references without the > other involved units. So why should the stuff be separated? I must admit this is a good point. This is more of a cultural issue between programming languages. If the tool chain supports big source files and if people accept them, there is no problem. I hope Lazarus can soon edit parts of one file in many editor tabs. Other programming languages have different cultures. See the comment from my original post in this thread. It was from a professional programmer and I understand it. Some development teams want to put every class into its own file. C and C++ even have headers in separate files (which is messy IMO). So, if a professional team chooses a programming language / environment for a project, this one feature can make a strong point against Object Pascal. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: >> (remember the people to complain about the huge amount of files of the >> fpc rtl :)?). > > The point is that they are right from a birds-eye general application > development view. I wanted only to point out that there pros and cons for small/large units and if a design requires to put a lot of stuff into one unit becuase it is heavily interwinded, I see no problem with it. > But wrong from the perspective of the exact requirements > on the RTL. IOW the RTL is not a normal piece of code. > >> With a good ide you don't care about this anymore: it works the same with >> a lot of small files or one huge file. > > Then I never saw a good IDE. With lazarus you don't notive in which files the code actually is? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Michael Schnell said: > I use a C compiler (for 8 Bit PICs) that can't link at all. Here you do > a kind of "linking" manually by using a main file that includes > everything else. Which is that then? Afaik the microchip own, and the Hitech compilers can do so perfectly? These compilers work roughly like gcc, from data in the project (or makefile) they generate a linker commandline. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Florian Klaempfl said: > >> cannot test a unit with external circular class references without the > >> other involved units. So why should the stuff be separated? > > > > I don't like extremely large (> few thousand lines) units from an overview > > perspective. > > One can also say a lot of small files make it hard to find stuff Yes. But I didn't say that limiting the maximum size means going to the other extreme > (remember the people to complain about the huge amount of files of the > fpc rtl :)?). The point is that they are right from a birds-eye general application development view. But wrong from the perspective of the exact requirements on the RTL. IOW the RTL is not a normal piece of code. > With a good ide you don't care about this anymore: it works the same with > a lot of small files or one huge file. Then I never saw a good IDE. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen wrote: > IMO, the compiler should not force a programmer to make a 34 000 lines source > file (like VirtualTreeView has). Programmer should have a choice to split it > if he wants. What about include files (used a lot in Lazarus LCL) ? You can e.g. separate the interface part from the installation part into separate files (which is standard in ANSI C by using .h files) I use a C compiler (for 8 Bit PICs) that can't link at all. Here you do a kind of "linking" manually by using a main file that includes everything else. GCC has an option to do a kind of "source code linking" by building a huge source from all files that usually are linked as binaries and doing a single compile process on that. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: > In our previous episode, Florian Klaempfl said: >>> Still, best solution has been to put everything into one big file. And >>> still, >>> I don't like that compiler forces such a thing. >> The compiler forces you many other things. Still, I don't get what's the >> problem with a large unit if it's really needed (and nothing like >> abstract base classes or interfaces or type casts or ... helps). Stuff >> closely depending on each other should end in the same unit. You even >> cannot test a unit with external circular class references without the >> other involved units. So why should the stuff be separated? > > I don't like extremely large (> few thousand lines) units from an overview > perspective. One can also say a lot of small files make it hard to find stuff (remember the people to complain about the huge amount of files of the fpc rtl :)?). With a good ide you don't care about this anymore: it works the same with a lot of small files or one huge file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Florian Klaempfl schrieb: > Juha Manninen schrieb: >> Still, best solution has been to put everything into one big file. And >> still, >> I don't like that compiler forces such a thing. > > The compiler forces you many other things. Still, I don't get what's the > problem with a large unit if it's really needed (and nothing like > abstract base classes or interfaces or type casts or ... helps). Stuff > closely depending on each other should end in the same unit. You even > cannot test a unit with external circular class references without the > other involved units. So why should the stuff be separated? Add: FPC can also smartlink large units so no need to split stuff into thousands of object files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Florian Klaempfl said: > > Still, best solution has been to put everything into one big file. And > > still, > > I don't like that compiler forces such a thing. > > The compiler forces you many other things. Still, I don't get what's the > problem with a large unit if it's really needed (and nothing like > abstract base classes or interfaces or type casts or ... helps). Stuff > closely depending on each other should end in the same unit. You even > cannot test a unit with external circular class references without the > other involved units. So why should the stuff be separated? I don't like extremely large (> few thousand lines) units from an overview perspective. But I'm no visibility micro-manager. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Michael Van Canneyt said: > >> projects end up copying everything into one file. Surprising... :-) > > > > I never do this, there is no need. Probably similar to the fact that 90% of > > the Delphi programs have all important code in event handlers of the GUI > > components. That still doesn't make a good thing. > > Glad you give this example. I try for years to convince my fellow > programmers that an event handler should contain at most 1 or 2 lines of > code: a call to a routine that does the actual work, and maybe some status > updating... But old habits die hard :-) I'm not that strict. It may have more code but then that code must interact with the GUI, usually to tie together various GUI components so that they become a complete abstraction. Example: a listbox, its repaint/fill events and the buttons that add/remove/edit etc make a "list of classes edit" together. But for anything more complicated than setting a field in the business code they must call other code. This is a deliberate violation of the presentation layer idea, that routs nearly every event over controller code. The reason is that while those kind of principles map perfectly to webapps, the principle makes GUI apps more complicated without really getting anything back IMHO ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: > Still, best solution has been to put everything into one big file. And still, > I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On Wed, 6 Jan 2010, Marco van de Voort wrote: In our previous episode, Juha Manninen said: - big units - type casting (in the worst case) - ... The right choice depends on the application. Abstract base classes and interfaces are recommended by many but actual projects end up copying everything into one file. Surprising... :-) I never do this, there is no need. Probably similar to the fact that 90% of the Delphi programs have all important code in event handlers of the GUI components. That still doesn't make a good thing. Glad you give this example. I try for years to convince my fellow programmers that an event handler should contain at most 1 or 2 lines of code: a call to a routine that does the actual work, and maybe some status updating... But old habits die hard :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 06 Jan 2010, at 11:14, Juha Manninen wrote:
I must try include files for this problem sometimes. Does FPC really
treat
them differently than Delphi.
No. {$i xxx} is exactly the same as copy/pasting the contents of "xxx"
into the current file at that point.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Juha Manninen said: > > - big units > > - type casting (in the worst case) > > - ... > > > > The right choice depends on the application. > > Abstract base classes and interfaces are recommended by many but actual > projects end up copying everything into one file. Surprising... :-) I never do this, there is no need. Probably similar to the fact that 90% of the Delphi programs have all important code in event handlers of the GUI components. That still doesn't make a good thing. > I must try include files for this problem sometimes. Does FPC really treat > them differently than Delphi. IIRC the only difference is that FPC recompiles on .inc change, and under Delphi you need to force a build after an .inc change. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 5 Jan 2010, at 22:40, Graeme Geldenhuys wrote: I must say, I agree with the original poster - it would be very useful. I have had many battles to try and overcome circular reference issues, and I do take care in my class designs. I would also agree. I used to use Interfaces or raise shared classes/ declarations to a new unit both could use to overcome this issue myself. But I remember the Be GUI porters having loads of issues mimicing the Be API header structure because there were so many forward class declarations in the C++. It was impossible to do a unit to header file match because circular dependencies crept up at almost every turn. Without direct matching of header and unit names, the Be API documentation became hard to use. I don't know if they ever solved it, maybe if Olivier is still about, he can chime in? M ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On keskiviikko, 6. tammikuuta 2010 10:59:36 Florian Klaempfl wrote: > Indeed, there are multiple ways to prevent the hell of circular class > references between units: > - abstract base classes > - interfases > - include files > - big units > - type casting (in the worst case) > - ... > > The right choice depends on the application. Abstract base classes and interfaces are recommended by many but actual projects end up copying everything into one file. Surprising... :-) I must try include files for this problem sometimes. Does FPC really treat them differently than Delphi. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On keskiviikko, 6. tammikuuta 2010 03:08:35 Nikolai ZHUBR wrote: > Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote: > > On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote: > >> Then do the same as in C++ and put it in different include files. > > > > Right, include files could solve this problem at least partly. They seem > > to be > > Curious enough, nobody even mentioned interfaced objects (interfaces), > though they are available in both FPC and Delphi since ages. > > Not that I would recommend this seriously, however here goes: I have tried that, too, but it doesn't solve the problem in real cases either. The problem are data members, not methods. You sometimes need to access data between dependent classes and with interface you then define Get... and Set... methods for them. That is little too much if you just want to avoid circular reference. Abstract base class is little better because you can define at least part of the data there. Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Nikolai ZHUBR schrieb: > Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote: >> On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote: >>> Then do the same as in C++ and put it in different include files. > >> Right, include files could solve this problem at least partly. They seem to >> be > > Curious enough, nobody even mentioned interfaced objects (interfaces), > though they are available in both FPC and Delphi since ages. > Indeed, there are multiple ways to prevent the hell of circular class references between units: - abstract base classes - interfases - include files - big units - type casting (in the worst case) - ... The right choice depends on the application. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Graeme Geldenhuys schrieb: > 2010/1/6 Vincent Snijders : >> You are getting old: >> http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html > > Ah, but that would explain why I don't use it. I never develop in > delphi mode, only objfpc mode - unless I work with projects like tiOPF > where both compilers (Delphi and FPC) are requirements. > Does my sentence exclude that strict works in fpc mode too. iirc it is supposed to work in all modes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
2010/1/6 Vincent Snijders : > > You are getting old: > http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html Ah, but that would explain why I don't use it. I never develop in delphi mode, only objfpc mode - unless I work with projects like tiOPF where both compilers (Delphi and FPC) are requirements. I'll double check now if objfpc mode also supports strict private/protected. If not, this thread might be a good reason for it to be supported in objfpc mode too. It shouldn't cause any harm to other developers either - if you never used it before you will not notice anything different either. Using a single big unit with loads of include files will not be a problem for me as long as I can still keep information private to specific classes. This will solve my issues regarding circular references (an acceptable work-around). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Graeme Geldenhuys schreef: On 06/01/2010, Florian Klaempfl wrote: That's why we've strict private/protected. Since when is that available in FPC? I didn't know it was. You are getting old: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Circular references and forward declarations
Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote: > On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote: >> Then do the same as in C++ and put it in different include files. > Right, include files could solve this problem at least partly. They seem to be Curious enough, nobody even mentioned interfaced objects (interfaces), though they are available in both FPC and Delphi since ages. Not that I would recommend this seriously, however here goes: //--- unit ihelper; interface type IMyClass1 = Interface; IMyClass2 = Interface; IMyClass1 = Interface function SomethingUsefull1: byte; end; IMyClass2 = Interface function SomethingMuchMoreUsefull2: longint; end; implementation end. //--- unit myunit1; interface uses classes, ihelper; type Tmyclass1 = class(TInterfacedObject, IMyClass1) public Fmyclass2: IMyClass2; FSomethingUsefull1: byte; function SomethingUsefull1: byte; function CrossFunc1: longint; end; implementation function Tmyclass1.SomethingUsefull1: byte; begin result := FSomethingUsefull1; end; function Tmyclass1.CrossFunc1: longint; begin result := Fmyclass2.SomethingMuchMoreUsefull2; end; end. //--- unit myunit2; interface uses classes, ihelper; type Tmyclass2 = class(TInterfacedObject, IMyClass2) public Fmyclass1: IMyClass1; FSomethingMuchMoreUsefull2: longint; function SomethingMuchMoreUsefull2: longint; function CrossFunc2: byte; end; implementation function Tmyclass2.SomethingMuchMoreUsefull2: longint; begin result := FSomethingMuchMoreUsefull2; end; function Tmyclass2.CrossFunc2: byte; begin result := Fmyclass1.SomethingUsefull1; end; end. //--- program circexamp; uses myunit1, myunit2; var c1: Tmyclass1; c2: Tmyclass2; begin c1 := Tmyclass1.Create; c2 := Tmyclass2.Create; c1.Fmyclass2 := c2; c2.Fmyclass1 := c1; c1.FSomethingUsefull1 := 1; c2.FSomethingMuchMoreUsefull2 := 2; writeln(c1.CrossFunc1); writeln(c2.CrossFunc2); end. //--- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 06/01/2010, Florian Klaempfl wrote: > > That's why we've strict private/protected. Since when is that available in FPC? I didn't know it was. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Graeme Geldenhuys schrieb: > On 05/01/2010, Martin Sucha wrote: >> You should be able to achieve that by putting some ifdefs around interface >> and >> implementation (and other) parts of your autogenerated programs and then for >> example > > True and I have done this before. BIG problem is that class visibility > goes out the window! All classes can access ALL private and protected > field variables or methods of other classes. NOT GOOD! That's why we've strict private/protected. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 05/01/2010, Martin Sucha wrote: > You should be able to achieve that by putting some ifdefs around interface and > implementation (and other) parts of your autogenerated programs and then for > example True and I have done this before. BIG problem is that class visibility goes out the window! All classes can access ALL private and protected field variables or methods of other classes. NOT GOOD! -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Graeme Geldenhuys said: [ Charset UTF-8 unsupported, converting... ] > On 05/01/2010, Marco van de Voort wrote: > > > > You can only not have multiple design forms in one class, but the > > That's a limitation specific to Delphi and Lazarus. Remember a Form is > also a class. So if you can have multiple classes in a unit, why can't > you have multiple form class in a single unit. Sure. The whole "design" point is that this is above the language level. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Re[2]: [fpc-devel] Circular references and forward declarations
On 05/01/2010, JoshyFun wrote:
>
> interface
> [...]
> {$I InterfaceOnly C:\.pas}
> [...]
> Implementation
> {$I ImplementationOnly C:\.pas}
> [...]
>
> I think it will not include a big penalty in the parser, or maybe I'm
> completly wrong ?
I have done with with 100's of include files. One base unit and one
include file which contains both the interface and implementation. I
had to use defines to solve the latter trick.
This gave you the impression that you are using multiple units with
circular references, but with one BIG flaw! ALL classes could access
all private fields etc. of other classes. This really broke my rules
of class design and visibility, so I stopped using that method.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 05/01/2010, Marco van de Voort wrote: > > You can only not have multiple design forms in one class, but the That's a limitation specific to Delphi and Lazarus. Remember a Form is also a class. So if you can have multiple classes in a unit, why can't you have multiple form class in a single unit. fpGUI Toolkit's UI Designer can and does handle multiple forms defined in a single unit. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 05/01/2010, Jonas Maebe wrote: > two different units can both declare a different class with the same name > (just like they can both have global variables and procedures/functions And I would bitch-slap any developer in my team that tries that! > b) add some way to specify the unit name in which this external class is > specified, or Delphi's project file already does this (kind of). The uses clause mentions the unit and the location of that unit. I must say, I agree with the original poster - it would be very useful. I have had many battles to try and overcome circular reference issues, and I do take care in my class designs. Sometimes there are truly valid designs where x-referencing is needed, and then I have to find some work-around due to the Object Pascal language - which normally ends up with lots of type casts in the implementation section, or bunching classes in a single unit. Don't ask me for an example, I can't think of one now, but it happened a few times in our current work project. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Juha Manninen said: > > You should try to separate user interface from program logic. > Do only strictly UI specific stuff in form class units. Keep program logic in > separate units (or one big separate unit :-)). > Then program logic unit can reference freely the form units, and form units > can reference the logic unit only from implementation section. > Thus, no circular reference. If you read the helpful "add language feature" faq ( http://www.freepascal.org/faq.var#extensionselect ) mentioned earlier, you'll notice that it advises to work out at least a full proposal, and keep the idle arguing to a minimum. Note that there is also an hint about making examples with multiple units. It's there for a reason, trust me. There is more to splitting source up into separately compilable files than meets the eye, since e.g. resolving the circular dependancies between classes must result in exactly the same the order of fields, no matter the what the order of files is. And orders that are not possible must be flagged as such. 7 How hard this kind of stuff is, is shown by the fact that after 25 years, and several periods of commercial sponsorship, gcc still has no precompiled headers standardly. The rules that Borland like Pascal's have (no preprocessor state per compilation but per compilation unit), and the circular dependancy rules are some of the rules to make this complex matrix of fog a bit more transparent. Which is why FPC DOES have precompiled headers since before I can remember (97/98). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On tiistai, 5. tammikuuta 2010 19:48:39 Horacio Jamilis wrote: > In my case, my classes are defined in a form unit, so I can not have > more than 1 class per file (this is a Lazarus project)... > I know that I should have more divided the visible editing and the class > itself, and I did, with some tricks, but I continue with the 1 file per > class implementation. > so the idea to have 1 big file is not possible ... and if it where, i > will not like it anyway. > When I asked for this possibility, I was told to create one big unit > with abstract classes definitions... that may help me, but never had the > time to test it... > I am casting everywhere... It´s ugly and error prone, but is what works. > > So this feature could make my life a lot easier ... but I don´t know how > to implement it... else I would do it. That is more about separating user interface from program logic which is a fundamental problem with RAD (rapid application development) tools. Many people don't like RAD for that reason. In practice that problem leads to circular reference problems, too. You should try to separate user interface from program logic. Do only strictly UI specific stuff in form class units. Keep program logic in separate units (or one big separate unit :-)). Then program logic unit can reference freely the form units, and form units can reference the logic unit only from implementation section. Thus, no circular reference. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Martin Sucha schreef: Hello, On Tuesday 05 January 2010 20:44:06 JoshyFun wrote: In the past I had some autogenerated pascal programs, but to include them in another unit I must manually split the files in interface and implementation. Would be possible to do something like: An example is: http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/gtk2/src/gtk%2B/gtk/gtk2.pas?view=markup Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Hello,
On Tuesday 05 January 2010 20:44:06 JoshyFun wrote:
> In the past I had some autogenerated pascal programs, but to include
> them in another unit I must manually split the files in interface and
> implementation. Would be possible to do something like:
>
> interface
> [...]
> {$I InterfaceOnly C:\.pas}
> [...]
> Implementation
> {$I ImplementationOnly C:\.pas}
> [...]
>
You should be able to achieve that by putting some ifdefs around interface and
implementation (and other) parts of your autogenerated programs and then for
example
interface
{$define InterfaceOnly}
{$I file.pas}
{$undefine InterfaceOnly}
implementation
{$define ImplementationOnly}
{$I file.pas}
{$undefine ImplementationOnly}
Regards,
Martin Sucha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote: > Then do the same as in C++ and put it in different include files. Right, include files could solve this problem at least partly. They seem to be used for actual program code with FPC. Are they treated differently from Delphi's include files or is it just convention? Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On tiistai, 5. tammikuuta 2010 20:58:11 Vincent Snijders wrote: > Florian Klaempfl schreef: > > Juha Manninen schrieb: > >> I think it would be EASY to implement. > > > > Then propose a patch. > > It surely would prove how easy it would be to implement. > > And if it was rejected, which I doubt, if it were implemented correctly, > I assume the maintainers of troll pascal would sure accept it :-) > > See also: > http://www.freepascal.org/faq.var#extensionselect Ok, I will study the FPC source some day to understand the problems associated with circular reference better. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On tiistai, 5. tammikuuta 2010 20:20:16 Jonas Maebe wrote: > It would have at least two consequences (there are undoubtedly more that > I'm not thinking of currently): a) all forward-declared types from the > interface would have to be resolved after the uses-clause in the > implementation has been parsed (because only at that point all classes > would be known) b) this would cause the interface crc of those units to > change (since the types change once they are resolved), which means that > every unit containing such a construct (and every unit depending on them, > even if they don't touch these types) would be recompiled at least once > (some immediately in case of circular interface-implementation unit > references, some only when you recompile the project) > > This wouldn't double the compilation time, but it would probably slow down > things quite a bit. I'm also not sure whether the ppu storing/logic logic > would still work if it could be called at a point where not all > forward-declared types are resolved. It would probably require special > code for that situation. I realize that you know the compiler better than me, but some more thoughts of mine anyway: The only information needed for the interface section is that the variable's type is object (class instance). It could be treated as TObject during the interface parsing. The same thing as when forward declaring a class inside a unit. The forward declaration only says it is a class, no mention of its ancestor, data members or methods. The class's members are used only in implementation section, but there the class's "home unit" is included in uses clause already and it is no different from the current situation. Ok, I understand the class's member info is stored somewhere at the end of interface section, the compiler would need more fundamental changes if that info was not available then. But still, the same space is reserved for a variable of any object, be it TObject or TMyClass. If I only could tell the compiler that my variable is actually TMyClass, not TObject, and then use code completion features and avoid casting. Hey, there could be an Alias syntax. First, in interface: MyVar: TObject; Then in implementation section: MyVar = alias TMyClass ... not very good. The point is anyway that my variable is basically a pointer to an object and the compiler should understand that. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Circular references and forward declarations
Hello Florian,
Tuesday, January 5, 2010, 7:06:42 PM, you wrote:
FK> I never looked at VirtualTreeView but I doubt that the 34k line source
FK> is a language problenm.
>> Programmer should have a choice to split it
FK> Good languages prevent programms to do ugly things :)
>> if he wants.
This is not 100% related with topic, but I would ask if one proposal
have sense in the Pascal "spirit".
In the past I had some autogenerated pascal programs, but to include
them in another unit I must manually split the files in interface and
implementation. Would be possible to do something like:
interface
[...]
{$I InterfaceOnly C:\.pas}
[...]
Implementation
{$I ImplementationOnly C:\.pas}
[...]
I think it will not include a big penalty in the parser, or maybe I'm
completly wrong ?
--
Best regards,
JoshyFun
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
El 05/01/2010 15:48, Marco van de Voort escribió: In our previous episode, Horacio Jamilis said: I need this feature too, and I like this proposed syntax. In my case, my classes are defined in a form unit, so I can not have more than 1 class per file (this is a Lazarus project)... It's perfectly possible to have more than 1 class per file. Also in Lazarus. You can only not have multiple design forms in one class, but the designer in those other languages almost sure can't handle circular classes either. In my project, each class is linked to one form, and defined in the same unit as the form. Horacio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Florian Klaempfl schreef: Juha Manninen schrieb: If I create a feature request issue for this, does it have any chance of being implemented? No. I think it would be EASY to implement. Then propose a patch. It surely would prove how easy it would be to implement. And if it was rejected, which I doubt, if it were implemented correctly, I assume the maintainers of troll pascal would sure accept it :-) See also: http://www.freepascal.org/faq.var#extensionselect Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Horacio Jamilis said: > I need this feature too, and I like this proposed syntax. > > In my case, my classes are defined in a form unit, so I can not have > more than 1 class per file (this is a Lazarus project)... It's perfectly possible to have more than 1 class per file. Also in Lazarus. You can only not have multiple design forms in one class, but the designer in those other languages almost sure can't handle circular classes either. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jonas Maebe schrieb: > On 05 Jan 2010, at 17:45, Juha Manninen wrote: > >> On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote: >>> The reason that they are conceptually not the same thing is that >>> in Pascal two different units can both declare a different class >>> with the same name (just like they can both have global variables >>> and procedures/functions in the interface with the same name). >>> You would at least have to do something like one of the following >>> a) use one global name space for all classes (i.e., forbid that >>> two different units used in a program declare a class with the >>> same name anywhere), or b) add some way to specify the unit name >>> in which this external class is specified, or >>> >>> There might be other solutions (maybe some kind of class-specific >>> namespace support), but it would definitely require some more >>> language features rather than merely accepting anonymous class >>> definitions anywhere. Otherwise the type checking is going to run >>> completely haywire. >> Yes, I even suggested a syntax: TMyClass = class; defined in >> "MyUnit.pas" > > You're right, sorry. > >> which would solve the namespace issue. It is the case b) you >> listed. It could also be: MyUnit.TMyClass = class; >> >> which is similar than syntax referencing global variables from >> another unit. > > It would have at least two consequences (there are undoubtedly more > that I'm not thinking of currently): a) all forward-declared types > from the interface would have to be resolved after the uses-clause in > the implementation has been parsed (because only at that point all > classes would be known) b) this would cause the interface crc of > those units to change (since the types change once they are > resolved), which means that every unit containing such a construct > (and every unit depending on them, even if they don't touch these > types) would be recompiled at least once (some immediately in case of > circular interface-implementation unit references, some only when you > recompile the project) > > This wouldn't double the compilation time, but it would probably slow > down things quite a bit. I'm also not sure whether the ppu > storing/logic logic would still work if it could be called at a point > where not all forward-declared types are resolved. It would probably > require special code for that situation. Defining forward types in a different unit breaks completly with the spirit how object pascal is designed and I fear it will break much more stuff in the compiler. Changing interface CRCs are probably only one of the prominent problems. Resolving cyclic forward class references between units will be probably a real nightmare. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 05 Jan 2010, at 17:45, Juha Manninen wrote: > On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote: >> The reason that they are conceptually not the same thing is that in >> Pascal two different units can both declare a different class with the >> same name (just like they can both have global variables and >> procedures/functions in the interface with the same name). You would >> at least have to do something like one of the following >> a) use one global name space for all classes (i.e., forbid that two >> different units used in a program declare a class with the same name >> anywhere), or >> b) add some way to specify the unit name in which this external class >> is specified, or >> >> There might be other solutions (maybe some kind of class-specific >> namespace support), but it would definitely require some more language >> features rather than merely accepting anonymous class definitions >> anywhere. Otherwise the type checking is going to run completely >> haywire. > > Yes, I even suggested a syntax: > TMyClass = class; defined in "MyUnit.pas" You're right, sorry. > which would solve the namespace issue. It is the case b) you listed. > It could also be: > MyUnit.TMyClass = class; > > which is similar than syntax referencing global variables from another unit. It would have at least two consequences (there are undoubtedly more that I'm not thinking of currently): a) all forward-declared types from the interface would have to be resolved after the uses-clause in the implementation has been parsed (because only at that point all classes would be known) b) this would cause the interface crc of those units to change (since the types change once they are resolved), which means that every unit containing such a construct (and every unit depending on them, even if they don't touch these types) would be recompiled at least once (some immediately in case of circular interface-implementation unit references, some only when you recompile the project) This wouldn't double the compilation time, but it would probably slow down things quite a bit. I'm also not sure whether the ppu storing/logic logic would still work if it could be called at a point where not all forward-declared types are resolved. It would probably require special code for that situation. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: On tiistai, 5. tammikuuta 2010 19:16:25 Florian Klaempfl wrote: See e.g. the compiler, but how does a big source file hurt anyways? Today, navigation is done by the IDE and cvs times are also gone when big files were a problem to commit. I consider class reference refering some external files not better than one big file if this is really needed. Things being interwinded can also end in the same file. Ok, that is a good point but then we are talking about a different thing already. Now the question is whether a huge source file is a bad thing or not. IMO, the compiler should not force a programmer to make a 34 000 lines source file (like VirtualTreeView has). I never looked at VirtualTreeView but I doubt that the 34k line source is a language problenm. Programmer should have a choice to split it Good languages prevent programms to do ugly things :) if he wants. Then do the same as in C++ and put it in different include files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On tiistai, 5. tammikuuta 2010 19:16:25 Florian Klaempfl wrote: > See e.g. the compiler, but how does a big source file hurt anyways? > Today, navigation is done by the IDE and cvs times are also gone when > big files were a problem to commit. I consider class reference refering > some external files not better than one big file if this is really > needed. Things being interwinded can also end in the same file. Ok, that is a good point but then we are talking about a different thing already. Now the question is whether a huge source file is a bad thing or not. IMO, the compiler should not force a programmer to make a 34 000 lines source file (like VirtualTreeView has). Programmer should have a choice to split it if he wants. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
El 05/01/2010 13:07, Juha Manninen escribió: Why is it not allowed from another unit? They are conceptually the same thing! The problem could be solved easily if there was a forward declaration saying: TMyClass = class; defined in "MyUnit.pas" I need this feature too, and I like this proposed syntax. In my case, my classes are defined in a form unit, so I can not have more than 1 class per file (this is a Lazarus project)... I know that I should have more divided the visible editing and the class itself, and I did, with some tricks, but I continue with the 1 file per class implementation. so the idea to have 1 big file is not possible ... and if it where, i will not like it anyway. When I asked for this possibility, I was told to create one big unit with abstract classes definitions... that may help me, but never had the time to test it... I am casting everywhere... It´s ugly and error prone, but is what works. So this feature could make my life a lot easier ... but I don´t know how to implement it... else I would do it. It is with no doubt in my wish list. Good luck on this Horacio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: On tiistai, 5. tammikuuta 2010 18:39:21 Florian Klaempfl wrote: I knew all the reasoning, but honestly, I don't see a point in it. I used C++ for years professionally and I always avoided circular references/implementing classes in different files than the header is named so I see no need in pascal either (and I never needed it). Hmmm... In real programs there are classes that are big and are logically their own entities (or how to put it), but still they must refer to other similar classes in other units. I don't know how you have solved this without putting everything into one big file. See e.g. the compiler, but how does a big source file hurt anyways? Today, navigation is done by the IDE and cvs times are also gone when big files were a problem to commit. I consider class reference refering some external files not better than one big file if this is really needed. Things being interwinded can also end in the same file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On tiistai, 5. tammikuuta 2010 18:39:21 Florian Klaempfl wrote: > I knew all the reasoning, but honestly, I don't see a point in it. I > used C++ for years professionally and I always avoided circular > references/implementing classes in different files than the header is > named so I see no need in pascal either (and I never needed it). Hmmm... In real programs there are classes that are big and are logically their own entities (or how to put it), but still they must refer to other similar classes in other units. I don't know how you have solved this without putting everything into one big file. I mentioned 2 examples, Virtaual TreeView and Lazarus that have huge source files. My own programs suffer from the same thing (but they are not published, can't show them now). Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
In our previous episode, Jonas Maebe said: > There might be other solutions (maybe some kind of class-specific > namespace support), but it would definitely require some more language > features rather than merely accepting anonymous class definitions > anywhere. Otherwise the type checking is going to run completely > haywire. It would also change how the compiler finds files. In Java the namespace can be distilled from the classpath hierarchies, in FPC there is no such helper. The compiler only gets some dirs and main .dpr and must be able to derive how to compile all units in the correct order. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote: > On 05 Jan 2010, at 17:07, Juha Manninen wrote: > > Forward declaration of a class is allowed inside a unit. There can > > be a > > reference to a class before it is defined! Like: > > TMyClass = class; > > > > Why is it not allowed from another unit? They are conceptually the > > same thing! > > The reason that they are conceptually not the same thing is that in > Pascal two different units can both declare a different class with the > same name (just like they can both have global variables and > procedures/functions in the interface with the same name). You would > at least have to do something like one of the following > a) use one global name space for all classes (i.e., forbid that two > different units used in a program declare a class with the same name > anywhere), or > b) add some way to specify the unit name in which this external class > is specified, or > > There might be other solutions (maybe some kind of class-specific > namespace support), but it would definitely require some more language > features rather than merely accepting anonymous class definitions > anywhere. Otherwise the type checking is going to run completely > haywire. Yes, I even suggested a syntax: TMyClass = class; defined in "MyUnit.pas" which would solve the namespace issue. It is the case b) you listed. It could also be: MyUnit.TMyClass = class; which is similar than syntax referencing global variables from another unit. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: > On tiistai, 5. tammikuuta 2010 18:07:38 Florian Klaempfl wrote: >> Juha Manninen schrieb: >>> If I create a feature request issue for this, does it have any chance of >>> being implemented? >> No. > > Well thanks, that was a quick answer. According to timestamp you answered my > mail before I sent it! > In this virtual internet reality everything is possible. :-) > > I hope you read my reasoning, too. I knew all the reasoning, but honestly, I don't see a point in it. I used C++ for years professionally and I always avoided circular references/implementing classes in different files than the header is named so I see no need in pascal either (and I never needed it). > I wrote the mail after reading many related > discussions and after being frustrated many times because of this limitation. > So, this was not one of the "me too, I found something to complain" messages > but a real problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On tiistai, 5. tammikuuta 2010 18:07:38 Florian Klaempfl wrote: > Juha Manninen schrieb: > > If I create a feature request issue for this, does it have any chance of > > being implemented? > > No. Well thanks, that was a quick answer. According to timestamp you answered my mail before I sent it! In this virtual internet reality everything is possible. :-) I hope you read my reasoning, too. I wrote the mail after reading many related discussions and after being frustrated many times because of this limitation. So, this was not one of the "me too, I found something to complain" messages but a real problem. Regards, Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
On 05 Jan 2010, at 17:07, Juha Manninen wrote: Forward declaration of a class is allowed inside a unit. There can be a reference to a class before it is defined! Like: TMyClass = class; Why is it not allowed from another unit? They are conceptually the same thing! The reason that they are conceptually not the same thing is that in Pascal two different units can both declare a different class with the same name (just like they can both have global variables and procedures/functions in the interface with the same name). You would at least have to do something like one of the following a) use one global name space for all classes (i.e., forbid that two different units used in a program declare a class with the same name anywhere), or b) add some way to specify the unit name in which this external class is specified, or There might be other solutions (maybe some kind of class-specific namespace support), but it would definitely require some more language features rather than merely accepting anonymous class definitions anywhere. Otherwise the type checking is going to run completely haywire. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: > > If I create a feature request issue for this, does it have any chance of > being > implemented? No. > I think it would be EASY to implement. Then propose a patch. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Circular references and forward declarations
Hello. My proposal: Please allow a forward declaration of a class which is defined in another unit, maybe using a new syntax for the declaration. Alternatively, allow circular references just like other programming languages do. Forbidden circular references is a major annoyance in Object Pascal and one of the main (!) reasons why it is not popular for big projects. I remember comments from other programmers like: "Delphi is not suitable for serious SW projects because the source files can't reference each other and you must put everything into one big file." Then I was arguing that no, it is not true, there are ways to go around it. Later I did some "serious SW projects" with Delphi and changed my mind. The problem is about referencing classes between units. Say you have unit MyUnit defining class TMyClass. In a typical circular reference situation you must define a variable MyVar as TObject (although it's actually TMyClass) and then cast it in the implementation section as TMyClass(MyVar). Very clumsy! And worse, you can't use the nice code completion features of your IDE when the variable is defined as "TObject". One suggestion has been to create an abstract base class into a separate unit and reference that in both the inherited class's unit and in the dependent unit. Well, I tried that. First, it creates a completely useless unit, making the code harder to understand. Second, it didn't solve the problem. In REAL programming situations I sometimes had to refer to data members in the inherited class (not included in the abstract base class to avoid circular reference). Then I again had to cast the variable which effectively nullified the whole effort. I could have used the "TObject method" as well. Finally I gave up and copy-pasted everything into one big unit. That's apparently what all "serious" Object Pascal projects must do. Virtual TreeView is one big file. Lazarus has units of almost 20 000 lines. It is really too much. Or, it would be ok if the programmer really wanted to do so but the compiler should not force it! Think of this: Forward declaration of a class is allowed inside a unit. There can be a reference to a class before it is defined! Like: TMyClass = class; Why is it not allowed from another unit? They are conceptually the same thing! The problem could be solved easily if there was a forward declaration saying: TMyClass = class; defined in "MyUnit.pas" or TMyClass = class; defined outside or whatever... That would not create a circular reference error because MyUnit would not be in uses clause. IMO, simply allowing circular reference would be the easiest solution but maybe it creates some technical problem which I don't know about... Well, most other languages can do it... Many people asked about circular reference in Delphi mailing lists. The answers were basically like: "This is the way it is defined and it will not change." Most programmers have switched to some other programming language. What a surprise! If I create a feature request issue for this, does it have any chance of being implemented? I think it would be EASY to implement. Some other features like generics and closures (anonymous functions) need much more effort. Yours, Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
