Naive question about Pascal && OSDEV.

[Craze Frog]

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

You're right of course, they aren't reference counted. (Except that it's not really defined as a standard as far as I know, which is part of the problem in the first place.)

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.

The following code does not require memory allocation:

Code: Select all

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

[Combuster]

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?.

[dr_evil]

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. The string "s" is allocated on the string. In here you could change "string" to "array of char" and it wouldn't make any difference (If you wrote the "write" procedure yourself).

[Craze Frog]

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 at the start of the function in case you want to modify it later (strings, unlike pchar's are not passed by reference).
I wouldn't do it this way. Freepascal compiler writers did. Yes you could change it and it would behave the same (and that's what I did in my kernel), however that does not mean the same assembly code is generated.

You two obviously don't understand the problem, which is that for the string version some undefined code will be output by the pascal compiler. 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).

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, but rather your own functions to manipulate them. Obviously I can do the same with pascal strings: use a pointer to length, char data in pascal, because all pascal compilers treat pointers the same. However, once you declare your variable as a string, the compiler starts outputting function calls to rtl functions.

I don't understand what you don't understand. Surely you must be aware of the following?
- 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.
- 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.
- Array of char or Pchar is not in way, shape or form, related to string. PChar is a transparent datatype, string is an opaque datatype (that's where the problem comes from). C/C++ does not have opaque datatypes, which is probably why don't see the difference.

[Laksen]

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?.

You haven't understood it. He's correct, unless you use the largely inferior shortstring

[JJeronimo]

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

I prefer the concept of passing references. Internally, it's the same thing, but on the high level, it's more explicit.

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

This is not true. FILE* is an opaque data type. You don't have access to the implementation (it may even not be a pointer on the low level, who knows?) and every operation must be performed through library functions.
Conceptually, it points to a file. But you have to do all the dereferencing and seeking through functions.

JJ

[Combuster]

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

Wrong again.

[leledumbo]

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

It should be necessary, the clarity in parameter passing is one fundamental concept of Pascal.

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.

(No mean to harm C, but this is the one considered as the most portable language) I don't think you would make a kernel that compiles with ANY C compiler either (of course you can, with a BUNCH of ifdefs). Most people will choose one and stick with it. About the (short)string management, almost every available Pascal compiler today treats string the same way. That is, the borland way. Today, code compatibility usually higher between Pascal compilers (despite the missing official standard) because of similar implementation.

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)

My kernel runs smoothly with a bunch of shortstrings floating around the code. Only Ansi-, Wide-, and any other special strings require memory management. ShortString does NOT.

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

So...?

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

Nope, I never had that kind of thing since the first time I develop my kernel.

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

This code is as fast as using PChar:

Code: Select all

// 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.

Use FreePascal RTL, the string management routines can be used DIRECTLY. Have you ever checked my kernel anyway? See how many functions in the RTL I must (re)write in order to have my kernel compiled. As far as I can remember, it's less than 5.

[dr_evil]

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 ...

I repeat: It doesn't need an allocator. That's all I ever wrote.

Nobody ever said that FPC wouldn't add code to copy ShortStrings.

You two obviously don't understand the problem, which is ...

I never said anything else about strings. I just said that ShortStrings (or Pascal strings) work perfectly fine without a heap allocator.