Quick Modern Object Pascal Introduction, for Programmers

[molly]

Okay, the thing is that I believe that it actually didn't work in the past, so I was confused when I saw the example and tried to compile it and it just worked.

In understand and i apologize for the confusion i might have caused.

In case you feel 'betrayed' because the official documentation regarding the is operator does not state specifically that it also works with corba, then please feel free to file a bugreport on mantis ?

Okay, bug report 30308.

Thank you very much Zoran. It seems it is already addressed as well.

[michalis]

Yes, that is the advantage of having ansistring, you can call the functions who takes pchars.

But not the other way around, thus it is better, if all your functions take pchars.

You *can* convert PChar to AnsiString easily. But it involves copying the characters (if you want to do it 100% safely), so it may have a speed penalty.

RTL and LCL convert back and forth between PChar and AnsiString, to interface with WinAPI, GTK... It definitely works. The only question is performance, but it's not as critical in my experience.

What I just realized last week, when you use strings the entire function gets wrapped in a try .. finally block, at least on linux amd64. That is really bad.

It has always been this way, and is necessary on all platforms. You can turn it off like Thaddy writes, but be careful -- if the routine exits with exception, the AnsiString will not be correctly finalized.

See also http://wiki.freepascal.org/Avoiding_implicit_try_finally_section (man, an old wiki page that I myself started > 10 years ago...

The real issue are slices. E.g. you have a 1000 character string s and want to do something with the middle, characters s[400] to s[600]. With a pchar, you can just point in the middle and use a smaller length. With a string, everything in that range needs to be copied.

If you do it naively, using Copy on a string, then indeed it will have a cost.

Then again, doing it naively on PChar also has a cost.

Your solution with addressing something in the midde can be used with PChar or AnsiString, no matter. You can take a pointer to the middle of AnsiString contents, and iterate over it. In all cases, it requires special treatment, since the result has to be bounded by some variable specifying slice length, not by a #0 character.

In general, I do agree that PChars can achieve higher performance. As often, if you do things manually, then you can squeeze much better performance than a solution that tries to manage memory automatically.

I just don't feel that doing this for the whole application, and resigning from AnsiStrings everywhere, is justified. I would limit this only to the actual bottle-neck in your application.

Anyway, this depends on the type of applications you're writing (whether your bottle-neck does any string processing).

One minor correction. "As in all object-oriented languages", should be "most" instead of "all" in section 4.5

Fixed. Indeed, at least Python doesn't have them:)

[mangakissa]

I like the idea to have documentation online for beginners.

I'm not a beginner and I'm still confused by some paragraphs. Sometimes you're talking deeply into subjects and otherwise its very compact. Why TList, ObjectList and (packed) records are discouraged your're not telling. As far As I know it's still uses for over 80% of applications by many developers.

I still don't understand why all examples are written in console. Ask a beginner what console/DOS/cmd/command is and they look at you like a crazy person. My point of view should using GUI demo's

 

[rvk]

I still don't understand why all examples are written in console. Ask a beginner what console/DOS/cmd/command is and they look at you like a crazy person. My point of view should using GUI demo's

I do see a lot of beginners (I mean real beginners to programming) using the command line. Usually they come in contact with Pascal through lessons and are instructed to use fp.exe or even Dev-Pascal (or similar).

But in the second chapter there is an explanation:

The rest of this article talks about the Object Pascal language, so don’t expect to see anything more fancy than the command-line stuff. If you want to see something cool, just create a new GUI project in Lazarus (Project → New Project → Application). Voila — a working GUI application, cross-platform, with native look everywhere, using a comfortable visual component library.

And even in the first post it is explained that this document is for programmers (so not beginners) who are not that familiar with Pascal. For those users it becomes clear at chapter 2 that this document only covers the language basics and not the GUI.

This is directed at programmers (who know a bit of some programming language, though not necessarily Pascal). Which is really an excuse to not explain in detail some basic stuff ("what is a variable", "what is a class"). I tried to explain more the "advanced" stuff, and illustrate everything with examples.

Look at it another way... think of a language you don't know that well (java, C++. C# or anything) and think of how you want a document like this to be for that language. I think first covering the basics about the language constructs is a really nice way to get to know the language. After that, if you take the GUI-IDE from that language a lot become clear at once.

Maybe GUI-elements could be described in another document
And yet another document could go deeper into some elements not mentioned in this one because they are too complex (or confusing at this point).

[Graeme]

I like the idea to have documentation online for beginners.

I prefer offline documentation I can read at a location where I might not have internet access. eg: 30,000 feet on a long haul flight, night time reading while on vacation, on a train to work or meetings etc. And its incredible [in this day and age] how often I am at a location where there is no internet access.

I'm not a beginner and I'm still confused by some paragraphs.

From what I've seen, reading that text should be taken with a pinch of salt - meaning in is the personal opinion of the author. Your and my oppinions might be different. eg: I see absolutely nothing wrong with using TList, TObjectList and packed records. In fact I have code where the usage of them are vital.

I still don't understand why all examples are written in console. ...snip... My point of view should using GUI demo's

It is very simple. Is it a tutorial about the Object Pascal language or a GUI toolkit? It's the former. Introducing a GUI toolkit into the sample code means you are now speaking only to say Lazarus LCL developers. What about FPC developers using Web Services, Unix daemons, MSEgui, fpGUI etc?  Console demos don't introduce an extra [unnecessary] dependency or complexity. The information is about Free Pascal's programming language, Object Pascal, and the RTL and FCL. Console demos make perfect sense and should not be changed. This is also why FPC includes only console demos.

[marcov]

Wow, thank you everyone for the comments! Here's a large answer:)

I also would remove the apologetic "reasonable", and refer to Pascal's  "declare before usage" principle. ( I assume it is somewhere mentioned near the beginning).

I reworded and shortened this part a bit. Thanks:)

It was apologetic, because indeed other languages do not have this limitation --- e.g. in Java you also usually need to declare stuff before using it, and yet two classes, in two separate files, can freely use each other.

Yes, and that part in Java is thus not declare before use. It is an exception.

I quickly scanned over the new unit system sections and that looks nice!

[marcov]

Thaddy, you know, i used pascal strings a lot in past but when needed to write code compatible with C code, turned to PChar uses. And using of PChar is much simpler for me, i can control all things, i clearly know what happens...

(btw, Proper modern C code works with a pchar and a max count (the -n- functions))

[Thaddy]

Thaddy, you know, i used pascal strings a lot in past but when needed to write code compatible with C code, turned to PChar uses. And using of PChar is much simpler for me, i can control all things, i clearly know what happens...

(btw, Proper modern C code works with a pchar and a max count (the -n- functions))

Yup But that still does not allow #0 in the middle. These are simply overflow protections. A standard  C string library  (well, array of byte ultimately) breaks on its terminator which happens to be zero or $0 or 0x0 or naught. You know that. Hence the max count... doesn't work

A Pascal Ansi string in {$H+} mode will respect the ultimate length for which it was defined, because that is stored and known. A pascal string in {$H-} state does the same but can overflow if the limit of 255 bytes is exceeded.

[Awkward]

But that still does not allow #0 in the middle.

so, lucky we what we can get #0 char in the middle of text in too rare cases.

[michalis]

From what I've seen, reading that text should be taken with a pinch of salt - meaning in is the personal opinion of the author. Your and my oppinions might be different. eg: I see absolutely nothing wrong with using TList, TObjectList and packed records. In fact I have code where the usage of them are vital.

Indeed, in some places I felt an advice "what to use, if you have these two alternatives" was necessary. I found myself unable to mention both generic lists and non-generic lists without an advice "which one to preferably use" (any why). The argument for using generic lists is type-safety: with generics, you can effectively say "this is a list of TMyClass instances". Compiler will then prevent inserting instances of other classes, and you will be able to access items on the list as ready TMyClass instances (no need to downcast them from TObject to TMyClass).

The other place where I definitely expressed my opinion are interfaces -- I explicitly encourage CORBA interfaces over COM in the article. They are closer to C# and Java interfaces. And they do not bring "automatic reference counting" (which I feel should be an orthogonal feature of the language, not entangled with interfaces).

I hope that these cases of "my opinion" are justified. And in both these cases, I do try to mention alternatives. I mention TObjectList, and dynamic arrays, and COM interfaces have their own section. So I hope it sounds fair -- I do have some opinions indeed, but they are hopefully explained, and the alternatives are presented too:)

For records -- I don't discourage them. I just suggest that "class" is the default feature-rich structural type which one usually uses in Object Pascal. I think this is generally accepted among Object Pascal programmers. Records definitely have their use when it comes to performance or predictable memory layout -- I do use records (and some old-style objects) in my game engine for this purpose. Records have their own section where I document them, mentioning also advanced records. Records are also taken into account when talking about lists (TFPGList), operator overloading etc.

Even C# language, designed much later than Pascal, has records. Much like our "advanced records", and for the same purpose: it can give more performance than a class, in certain uses.

[Graeme]

Indeed, in some places I felt an advice "what to use, if you have these two alternatives" was necessary.

I personally have no problems with that. I simply felt it should be pointed out that some of that text is opinion based. Maybe such text could be added as a "side note" or something - giving it separation from "documentation" and "opinion". Just a though. ;-)

For records -- I don't discourage them. I just suggest that "class" is the default feature-rich structural type which one usually uses in Object Pascal. I think this is generally accepted among Object Pascal programmers. Records definitely have their use...

There are indeed cases where Records are the best or only choice. eg: reading a binary file (eg: an INF help file), it is hugely beneficial to use a record structure to read such binary data. I would not dream of using a class in such a situation.

The bottom line... use the correct tool (language feature) for the job.

[BeniBela]

The other place where I definitely expressed my opinion are interfaces -- I explicitly encourage CORBA interfaces over COM in the article. They are closer to C# and Java interfaces. And they do not bring "automatic reference counting" (which I feel should be an orthogonal feature of the language, not entangled with interfaces).

Perhaps it is time to add a third kind of interfaces to FPC

Reference counted like COM, but otherwise like CORBA, without any of the COM overhead

[jwdietrich]

This is a very good introduction.

Could you add (perhaps in the "About" section at the end) a notice about the version of the document and the date of last change? This would make life easier for readers, by providing a hint if it is worthwhile to download a new version.

[michalis]

This is a very good introduction.

Could you add (perhaps in the "About" section at the end) a notice about the version of the document and the date of last change? This would make life easier for readers, by providing a hint if it is worthwhile to download a new version.

Thank you!

There is a "Last updated" date at the very bottom of the HTML version, see http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html . And the exact history of the document may be seen in the GitHub repository on https://github.com/michaliskambi/modern-pascal-introduction . The commits on https://github.com/michaliskambi/modern-pascal-introduction/commits/master document precisely what and when changed:) I update the HTML/PDF output after every commit.

[Thaddy]

The COM part is still not correct as I explained in my email to you, because it reflects the only way you should not ever never use COM.
I will do a follow up (as per email) this weekend. For starters: there are no memory leaks....

COM should be used through interface instances, not class instances as in your book. And you should respect the reference counting. TComponent is a really bad example...