Don't get me wrong - C/C++ is great and has many uses, but using it can be sometimes a chore.

Why? Because of pointer hell. In C/C++ pointers are used literally everywhere, even where passing by value would be enough. Like here:

int WINAPI MessageBox(
  _In_opt_  HWND hWnd,
  _In_opt_  LPCTSTR lpText,
  _In_opt_  LPCTSTR lpCaption,
  _In_      UINT uType
);

That's right. This is WinAPI's message box function. LPCTSTR in case you don't have WinAPI experience, is pointer to string. WTF? This function doesn't even NEED pointer to where string is stored as it doesn't change it. It only show standard Windows message box.

Such quirks aren't even specific to WinAPI (which, admittedly, is poorly written). Most of C/C++ APIs I had even "pleasure" to work with are littered with things like that. Like Qt:

void QMessageBox::about(QWidget * parent, const QString & title, const QString & text)

Same sin as in case of WinAPI.

But we want to make games, don't we? Let look into some game API, say, SDL:

SDL_LoadBMP

Name SDL_LoadBMP -- Load a Windows BMP file into an SDL_Surface.

Synopsis

#include "SDL.h"

SDL_Surface *SDL_LoadBMP(const char *file);

Description

Loads a surface from a named Windows BMP file.

Return Value

Returns the new surface, or NULL if there was an error.

See Also

SDL_SaveBMP

(from http://www.libsdl.org/docs/html/sdlloadbmp.html)

Why it even returns pointer, when returning value (SDL surface) would be enough?

Such approach results in things like memory leaks and other sort of "fun" stuff. Pointers should be only used when you need write access to variable you are passing and can't afford working on a copy (passing by value).

Finding joy

Above thing which I've dubbed "Pointer Hell" was thing that made me chose Pascal (Object Pascal specifically) as language of choice when developing games. In Pascal you only use pointers when you actually need them. Which is almost never as most things you can do without touching them.

Unless, of course, you are interfacing with some c/c++ library, like I'm doing with Allegro.

Pascal also provide syntax that any human (or non- human ;)) being who happen to know English can read and in many cases comments aren't even needed to understand what code does. Unless you reading code from some obfuscation contest or written by first-time programmer.

Also when coding in Pascal you can really enjoy this. You don't have to worry about memory leaks and for the most part logic bugs are easy to fix. There is also helpful community related to game making ready to help when you happen to have some issues. It's mostly because of them I could progress so far when writing Super Heli Land.

Notable games and software written with Pascal:

- Original Jazz Jackrabbit (Turbo Pascal 7.0)

- RPG Maker 2003 (Delphi, not sure about version)

- Resource Hacker

- BlockCAD (Delphi)

- Hedgewars, the Worms clone - freepascal (engine, rendering) plus some c++ bits mainly because there was no good Qt bindings for Pascal when project was started.

- This.

Whatever programming language you are comfortable and productive in is a good language.

Now, where is up arrow when you need it?

That's right. This is WinAPI's message box function. LPCTSTR in case you don't have WinAPI experience, is pointer to string. WTF? This function doesn't even NEED pointer to where string is stored as it doesn't change it. It only show standard Windows message box.

I don't think you even know what the point of pointers are...

What has changing the string to do with anything?

Why should you copy the entire string around in the function call, and mess with dynamically sized data, when all the function need is a pointer to a string to use?

That would be a massive waste of time.

I'm pretty sure Object Pascal use pointers most of the time too, it just hides the fact better...

For c++, you can use references to get a bit nicer syntax, but they are still just pointers with some extra rules. (like inability to be un-initialized)

Why are you so scared of asterisks anyway?

Nothing wrong with pascal though, keep on using it.

I do wish C++ had some nicer syntax for smart pointers...

Still havn't really gotten used to using them. Probably because I'm too used to the simplicity of raw pointers...

Doesn't help that my debugger seem to have problems showing them correctly too...

Nothing wrong with pascal though, keep on using it.

:=

Nothing wrong with pascal though, keep on using it.

:=

==, ->

If you don't have any substantial things to say, don't post.

Nothing wrong with pascal though, keep on using it.

:=

That. And if begin end else begin end blocks. Which are madness. Then the "var" thing after procedures/functions, which is also madness. : before the type? Madness.

I also agree that -> operator is madness in C++ though.

That. And if begin end else begin end blocks. Which are madness. Then the "var" thing after procedures/functions, which is also madness. : before the type? Madness.

You will enjoy Golang.

Object Pascal is the first language I learned. Say what you will, even if it may not have been the most trendy language ever conceived (though it is actually still quite popular in Europe and Russia) the reason I really like it is that it just works. Things are straightforward, there is no 1300-page standard to endlessly debate on, and heavy development has been put in creating the two main visual component libraries which now power basically all of its GUI applications (the VCL and the FCL, Delphi & Free Pascal respectively). The GUI builder integrated in the two main IDE's is wonderful and is perfect for utility/business applications (though not everyone will like it nor need it). It's fun and enjoyable to develop in this language. Programming is fun again!

Also, cross-compiling is very good (for FPC - it is nonexistent for Delphi, obviously), inline assembly support is generally flawless (and much more elegantly integrated than how C++ does it, or at least gcc/g++) and despite people claiming otherwise, it still performs quite well in terms of performance. And, yes, cross-compiling applies to the visual library too, so you won't need to mess around with half-baked cross-platform themed GUI libraries - it's already there.

Finally, the Pascal spirit of "doing things at as high a level as possible, but seamlessly dropping to a lower level when required, all the way down to inline assembly if necessary" has always appealed to me and you will find few languages which are capable of blending those different programming levels as elegantly and idiomatically (though this is arguably subjective).

Now I'm not crapping all over C++ here. Every language has its pros and cons. And while Pascal has never gained the traction and popularity of C++, Java, or even Python, just because it's a relatively obscure language today and has a syntax that (gasp) doesn't consist of curly braces and asterisks doesn't mean it cannot be used effectively.

So, no, you can't write embedded software in Pascal or some other stuff, but what it can do, it does it very well. The only thing missing is.. well.. support. Borland dropping Delphi was basically the nail in the coffin, it's pretty obvious the language is slowly going the way of the dodo but while it's there we can still use it.

To be frank I find the whole attitude towards Pascal rather close-minded.

Hey, just because you like to fly planes over mountain ranges doesn't mean we all want to. Some of us enjoy the lung-killing climb up Mount C++.

That said, SDL and Win32 are designed for 'C'. Despite the fact that people use it with C++, it must use C-only language features, hence the pointers.

You'll notice Qt (which is C++) uses const references where appropriate, which removes the so called 'pointer hell' you are talking about.

void QMessageBox::about(QWidget * parent, const QString & title, const QString & text)

The parameter 'parent' is optional, so it's a pointer - you can pass in nullptr if you just want a message box without attaching it to any other window.

That's right. This is WinAPI's message box function. LPCTSTR in case you don't have WinAPI experience, is pointer to string. WTF? This function doesn't even NEED pointer to where string is stored as it doesn't change it. It only show standard Windows message box.

LPCSTR is not a pointer to a string. It is a string. It is an array of null-terminated characters.

C does not have a string type, so the standard way to represent a string is by using an array of characters, which decays to a pointer.

There's nothing wrong with QMessageBox::about. If the partent was passed by value, that would clone the parent and the message box would be attached to the clone instead of the original (desired) parent. The intention is to share a single object in multiple places, so a pointer is required.

The strings are passed by const-reference, which is the same as a pointer, but with the guarantee that they won't be modified, so it looks just like pass-by-value. The difference is that pass-by-value would create copies of the strings, which is a complete waste of time. If the API required that all string arguments be reallocated for no reason, it would be a bad API.

The SDL_Surface is allocated by the API and reference counted. The object that's pointed to by your return value is a shared object, more than one part of the code may be pointing to the same shared object. Returning by value would completely break this shared-asset design.

I appreciate your pascal joy and your dislike of C ... but your critiques of "bad" C code above simply show that you haven't learnt C or C++ yet and aren't qualified to critique those APIs Critique the language that results in these API designs, fine , but your supposed API flaws are not flaws.

P.S. I enjoyed using the "become equal to" / "assignment" / ":=" operator, rather than "=", which mathematically means equivalence, not assignment.