On Wed, October 5, 2016 9:54 pm, Martin Schreiber wrote: > On Thursday 06 October 2016 00:16:22 Tony Whyman wrote: > >> On 05/10/16 23:03, Graeme Geldenhuys wrote: >> >>> Martin Schreiber recently mentioned in another Interface discussion >>> that there is a very good reason he doesnât use COM style >>> interfaces⦠Reference Counting! >>> >> >> Used properly reference counted interfaces are very powerful and allow >> for some very elegant programming. Do you complain about AnsiStrings? >> They are reference counted. Would you really want to have to free every >> string explicitly? Dynamic arrays are similarly reference counted. >> > Reference counting is great for simple types like strings and dynamic > arrays but is a nightmare with the venturesome mixture of COM-interface > and classes from Delphi. Even reference counting for complex classes is no > good idea IMO, I fear the times when FPC will implement ARC. > I don't think that a programming language should hide more and more of the > internal working of the code he writes from the programmer. Take a look > at the modern C++ programs; the LLVM-compiler is a good example. It is > horrific slow. Stepping through the code shows that there are complex > multi-level dynamic type conversion and dataaccess routines at almost > every statement. The typical C++ programmer does not need to care about > because the programming language takes care for the boring tasks. The > typical C++ programmer actually *does* not care about performance because > competing programs are not faster; they are written in a modern > programming language too... Recently I had to revive my stone old AMD-K6 PC > with Windows 95. What marvel, that relict with its age-old applications > provides a better user experience, is snappier, more convenient and more > productive than my newest Linux machine with the modern desktops and > applications. > > Martin
Replying to an old thread in my inbox. Apologies if it's obsolete as it is a month old. Martin, as you know, Windows 95 is mostly coded in plain C, so guess what that meant: you had to reboot your pc every day to reset all the memory leaks. So your idea that we should not be hiding code with more abstraction layers is a double edged sword. Windows 95 is a very zippy, fast, snappy operating system. But it also was not garbage collected so had memory leaks due to poor programming in plain C. Remember when people migrated over to Windows 2000 and Windows XP and found that they no longer needed to restart their PC daily to reset the memory leaks? Sometimes my windows 98 computer would last for a week, and that was about it before I had to restart. Usually I had to restart every 1-3 days. And why is that? Because windows 95/98 did not have an abstract programming language in place which hid details. It's all manual memory management which causes tons of bugs. And these bugs are the same issue seen in all kinds of delphi/lazarus apps.... Admitting, however, that Windows 2000 and XP did not migrate to any garbage collected language, they just improved the old buggy code so that there were less memory leaks and now instead of rebooting your PC every day or 3 days, you can wait a month before rebooting, or sometimes a couple weeks, or sometimes a week. But there are still bugs in win2000/windows10/windows7 which cause me having to reboot my PC. And wow, Firefox needs to be constantly restarted, as the memory leaks grow out of control. But that's not a plain C app. At the same time, I'm also scared of reference counting as you are, for classes, as garbage collection mechanism. But since you are against hiding details from the programmer, what's your opinion of Oberon garbage collection that Wirth designed, if it was somehow implemented in FPC? Likely that won't happen. However you say you are against hiding too many details from the programmer (abstraction) so you think Oberon's garbage collection system is too high level and would prefer to free and create? To keep it on topic, related to fpc, and to not divert to oberon discussion only: are you saying that if somehow and oberon like garbage collection was implmented in fpc you'd be against that as it is too abstract, or are you saying you are just against reference counting, but would accept an Oberon like garbage collection? Unfortunately, that means more like a new programming language rather that continuing fpc as it is, likely. As oberon is designed to be that way, to handle garbage collection and even module unloading/loading at run time, whereas fpc not so much. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
