OSDev.org

dr_evil wrote:That's not true. ... Pascal strings aren't reference counted.
...
Having good support for pascal strings however is useful.

procedure PANIC(s: string);
begin
    write(s);
    HaltProcessor;
end;

procedure PANIC(s: pchar);
begin
    write(s);
    HaltProcessor;
end;

Craze Frog wrote:Combuster, here's an example code:

Code: Select all

procedure PANIC(s: string);
begin
    write(s);
    HaltProcessor;
end;

That code requires memory allocation and if you call it before that is setup properly you're doomed.

Why this code would require "memory allocation" (assuming this means allocating memory from a heap) is beyond me.

Imagine, why can I use BStrings properly (they are pointers to {length, allocated size, char data} structures) and you can't use pascal strings?.

Combuster wrote:That only proved you aren't worth the discussion.

Imagine, why can I use BStrings properly (they are pointers to {length, allocated size, char data} structures) and you can't use pascal strings?.

Craze Frog wrote:- You can pass characters around using pchar (pointer to array of char). This is much faster than strings.

C/C++ does not have opaque datatypes, which is probably why don't see the difference.

Imagine, why can I use BStrings properly (they are pointers to {length, allocated size, char data} structures) and you can't use pascal strings?.

Because, when you use BStrings you don't use any intrinsic compiler support

It's beyond me as well. It shouldn't be necessary ...

Now if you ever want to change your compiler, you're screwed, because each compiler may treat the string type as it wishes, thus if you hack together some functions that behave like the string management routines used by freepascal you can't use them with any other pascal compiler. So you're stuck with a kernel tailored to a particular compiler.

And also you can't use your strings before memory management is up and running (if you doubt me, take a look at the generated assembly code)

However, once you declare your variable as a string, the compiler starts outputting function calls to rtl functions.

Declaring a variable as string instantly breaks kernel compilation unless huge compiler-specific remedies are made

You can pass characters around using pchar (pointer to array of char). This is much faster than strings.

// you can also use var, depending on what the procedure should do to the string
procedure DoSomething(const s: String);
begin
  ...
end;

If you need to concatenate pchars you need to write your own functions to do it, so strings are better. However, since the run-time-library doesn't work in your kernel unless you rewrote it, you'll have to write the functions either way.

Craze Frog wrote:

Why this code would require "memory allocation" (assuming this means allocating memory from a heap) is beyond me.

It's beyond me as well. It shouldn't be necessary. Freepascal does however output assembly to make a copy of the string parameter ...

Craze Frog wrote:You two obviously don't understand the problem, which is ...