[fpc-other] [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 23 May 2017, noreply at z505.com wrote:

> Pascal and C are actually twin brothers with slightly different
> syntax...

Fortunately, they really aren't. :) And this goes both ways.

> But my biggest hate for C is not C itself but just the one fact that it
> lacks strings.

Strings are a library feature, with syntax sugar on top of it. Nothing
stops you to implement Pascal-alike strings in C, minus the syntax sugar.
In fact I'm willing to bet, there are some libs out there already, ready
to be used. In fact, see what someone wrote about UTF-8 later in the
thread, pretty sure you can just pull in an UTF-8 string library in your
project and run with it...

There are a bunch of things in C, which are a lot more WTF.

1., no standard way to determine the length of an array compile time.
sizeof() returns the length in bytes, not the number of elements.
Basically you have to do sizeof(array)/sizeof(elementtype), where the
elementtype has to be the same as when you declare an array.

2., I cannot make an enum type, and make an array which matches that enum
type, and has the same number of elements, other than arbitarily defining
the "max" item in an enum (no low()/high()/length(), etc). Same with
standard types, actually (talking about things like array[boolean] of
<type>). Also, the compiler makes no checks that if indexing this
array[type] is out of bounds when used. This single thing alone makes it
super robust to write all kinds of low level Pascal code, when used
properly. Which is of course also possible in C, but you don't get the
safety-net of the compiler/language, so you end up writing a billion tests
for all kinds of edge cases, which cannot even happen in Pascal.

3., While we're at enums, the size of enumeration type is not defined,
except it's "int" which varies wildly from platform to platform. Which
means if you cannot really have enumeration types in structs which are
involved in I/O, otherwise you're up for surprises. There are ways around
this, but it's very cumbersome, so usually people just go "whatever" and
hardwire an int type of arbitary size instead. But then again, you lose
all kinds of compiler checks.

4., The whole weakly typed thing. You can have all your types defined, but
when you mess up, the compiler just says "well okay" (even with -Wall),
especially when you pass around various pointers, and you end up
scratching your head, what makes your code explode.

I'm working as an embedded software engineer these days, in C/C++, these
were the just the things I ran into recently. Strings are the least of the
problem, when it comes to defining an architecture in C in a safe/sane
way. :)

Charlie

(Ps: BTW, fixme on any of the above, I don't even claim I'm good at C, so
at least I learn something. Also, I know C++ fixed some of these, which is
among the reasons why people stick to a subset of C++. "C with classes",
as they say, I say, it's "C with classes and stronger typing." ;) )