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

[Nikolay Nikolov]

On 05/24/2017 04:56 AM, noreply at z505.com wrote:
> On 2017-05-22 18:53, Graeme Geldenhuys wrote:
>> On 2017-05-22 23:39, noreply at z505.com wrote:
>>> What about Rust or plain C? Or Digital Mars D?
>>
>> I hate C with a passion. I'll never code in that ever again.
>>
>
> Pascal and C are actually twin brothers with slightly different syntax...
>
> But my biggest hate for C is not C itself but just the one fact that 
> it lacks strings.
Yes, this is one of the horrible things I have beef with. I have several.

1) the null terminated "strings"
2) the fact that the array size is not exactly part of the type. In case 
you're wondering what this means, if you declare:

int a[5];

sizeof(a) gives you the correct size of the array. However, if you pass 
this array as a parameter to a function:

void func(int array_param[5])
{
         // inside the function, sizeof(array_param) gives you the size 
of a pointer, and not the array size
}

That's one of the reasons you can't add range checking to C compilers.

3) the fact that you can get easily burned by typing '=' instead of '==' 
(or vice versa).

Both

   if (i=5)
     do_something();

and

   i==5;

Will happily compile and _not_ do the expected thing. Modern C compilers 
give you warnings in these cases, but that doesn't change the fact that 
this is bad language design. Bonus points for the fact that writing this 
ugliness:

   if (5 == i)
     do_something();

is considered a very good practice by some people, just because it 
prevents you from being burned if you write if (5 = i) instead :)

4) the badly designed standard library. Even though C "strings" suck by 
design, the library functions, that operate on them have extra hidden 
traps. For example, using strcpy is unsafe, because it doesn't check the 
size of the destination buffer, that's why you must use strncpy. 
However, this code:

char dest[1000];
strncpy(dest, src, sizeof(dest));

is still unsafe. Why? Because if src is 1000 characters or larger, even 
though strncpy will not overwrite past the end of the dest array, it 
will _not_ put a null terminator in the dest array. On top of that, it 
is also suboptimal - if src is shorter, strncpy will fill the entire 
array past the end of the string with null characters. So, if src is a 
10 character string, strncpy will write 990 null characters, filling the 
area between dest[10] and dest[999], wasting CPU cycles on that.

Nikolay