Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #17195

Re: Buddy System Memory Allocator

Show all headers | View raw

"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
> Well, I've read that more than a few times from various sources.  So,
> I'm assuming there is some truth to it.  Someone coding an OS
> (operating system) in C++ must implement new and delete - custom to
> their OS.  Perhaps, that's were the problem is.

new and delete are basically syntax sugar for a typed version of malloc
and free.  The API is here:

  http://en.cppreference.com/w/cpp/memory/new/operator_new

so instead of saying
   p = (struct foo *) malloc(sizeof (struct foo));
you'd say
   p = new foo;  

The default action of "new" is to call a malloc-like library routine but
you can override it to call some code of your own, and (it occurs to me)
this might be a reasonable way to handle something like kernel buffers
in linux.  

> Who opposes using C++ for OS development?  There are enough C++
> programmers that I'm sure a few have tried.

Haiku (successor to BeOS) and Symbian were written in C++; Haiku is
trendy in a certain crowd and Symbian was highly successful for a long
time (though now pretty much crushed under the Android/iOS juggernaut).
According to Wikipedia, MacOS now contains some C++ though I don't know
specifics.

>> [...] lots of OS's are coded in C++, [...]
> No offense, but I seriously doubt that.  I wouldn't doubt that a few
> exist though.
Try a web search.  Lots are there that are not very famous.

> C and the host's assembly still seem to be the predominant languages that
> OSes are coded in.

There has to be a little bit of low-level asm in any OS, but if the OS
is more than a toy, for the past 30 years it's (almost) always written
predominantly in a HLL.  As with compilers, for projects started before
the 1990's, a lot of the time the HLL was C.  The OS's that we've heard
of (Linux, BSD, etc.) are all quite old so they fit that pattern.  

> I can't imagine an OS developer wanting to deal with additional
> complexities within their OS, such as inheritance, object oriented
> programming, polymorphism, classes and overloading of C++.

http://okmij.org/ftp/cpp-digest/toy_OS.txt

And anyway, OS's in C usually have dispatch tables for device drivers
etc. that amount to manually implemented OOP.

> At some point, an OS developer coding in a HLL (high-level language)
> will likely create their own compiler, or attempt to bootstrap an
> existing compiler.  The more complicated the compiler, the less likely
> it is that they'll succeed. 

I don't understand this.  I don't see why someone writing an OS would
write their own compiler, under normal circumstances.  If they were
writing a general purpose OS then of course they'd have to target a
toolchain to it (probably more about the linker etc. than the compiler
proper).

> For my OS project, I really don't even want C.

I thought you were writing a Forth.  You're writing an OS too?

> I want a very small C subset.  Technically, even that is a bit more
> than I really want.  If assemblers could manage variables like C, I'd
> probably use an assembler. 

Why not use the Forth you're writing?

> Well, I've never coded C++.  AIR (as I recall), C is a subset of C++.  

Pretty much so.  There are some minor deviations, like some more
keywords, so in C++ you possibly can't have a variable called "new".

> From what I've seen, "pure" C++ programs appear very different
> syntactically from C programs and C treated as C++.  E.g., from
> Wikipedia's C++ page: 'std::cout << "..."'  AIUI, std class, cout
> function, i.e., functionally equivalent to C's printf().  

cout is like stdout.  << is operator overloading, so cout << x is the
equivalent of something like fwrite(stdout,x).  It's specialized on
various datatypes so if cout << n (for an int n) prints n in decimal,
while cout << s (for string s) prints s directly, etc.  

If you write a new class, you can specify what << is supposed to do with
it, so it's better than printf in the sense that you can extend it easily.
It's uglier and clumsier in some other ways.  You can still use printf if
you want, and I sometimes do that.

> Clearly, that's not a 'superset' of C.  That's purely C++.  No C
> programmer recognizes that without being provided an explanation.

Of course it's a (near) superset.  It's just like today if you want to
go somewhere, you can walk, drive, take a taxi, buy a plane ticket, ride
a horse, etc.; while if you lived in the 18th century your choices would
have been walk or horse.  We would say your options today are a superset
of the 18th century options.  That doesn't mean an 18th century person
would understand airplanes without an explanation, and it doesn't mean
that the choices an 18th century person would have made are sensible
choices now (riding a horse in a town where cars are available would
usually be silly).  But they're still available if that's what a given
situation calls for.

> A superset would extend the existing C functionality and syntax, e.g.,
> printf::file.  A C programmer would recognize printf and might be able
> to guess that '::file' makes printf function similar to fprintf.

It's not like that--using it idiomatically really has a completely
different feeling than writing in C.  It's actually pretty easy to get
used to though; it's "well-worn" if that makes any sense.  I mean
something like: the people who designed it had clearly written a lot of
C code and the stuff that went into C++ was all invented to solve real
problems.

At least for 21st century PC-class computers (that would include things
like smartphones, which are equivalent to PC's of the early 2000's) I just
don't see much point of writing anything in pure C.  You do get code bloat
if you use idiomatic C++ and its template library, but you gain
convenience, and with some care you can avoid taking any performance hit.

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[OT] Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-04 20:10 +0000
  Re: Buddy System Memory Allocator Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-04 15:05 -0800
    Re: Buddy System Memory Allocator Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-04 22:02 -0800
      Re: Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-10 12:53 +0000
        Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-10 20:25 -0500
          Re: Buddy System Memory Allocator Josh Grams <josh@qualdan.com> - 2012-11-11 11:49 +0000
            Re: Buddy System Memory Allocator Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-11 17:43 +0100
              Re: Buddy System Memory Allocator Josh Grams <josh@qualdan.com> - 2012-11-12 01:55 +0000
            Re: Buddy System Memory Allocator "Elizabeth D. Rather" <erather@forth.com> - 2012-11-11 07:06 -1000
    Re: Buddy System Memory Allocator Alex McDonald <blog@rivadpm.com> - 2012-11-05 06:33 -0800
    Re: Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-10 12:05 +0000
      Re: Buddy System Memory Allocator Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-13 19:49 -0800
  Re: [OT] Buddy System Memory Allocator Paul Rubin <no.email@nospam.invalid> - 2012-11-04 16:55 -0800
    Re: Buddy System Memory Allocator Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-04 19:08 -0800
    Re: [OT] Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-07 08:49 +0000
  Re: [OT] Buddy System Memory Allocator Ron Aaron <rambamist@gmail.com> - 2012-11-05 08:17 +0200
    Re: [OT] Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-07 09:02 +0000
  Re: [OT] Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-05 14:10 -0500
    Re: Buddy System Memory Allocator Alex McDonald <blog@rivadpm.com> - 2012-11-05 12:58 -0800
      Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-06 20:54 -0500
        Re: Buddy System Memory Allocator Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-06 21:50 -0800
          Re: Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-07 08:36 +0000
          Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-07 19:49 -0500
            Re: Buddy System Memory Allocator Alex McDonald <blog@rivadpm.com> - 2012-11-08 04:42 -0800
            Re: Buddy System Memory Allocator Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-08 19:43 -0800
              Re: Buddy System Memory Allocator albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-09 10:48 +0000
              Re: Buddy System Memory Allocator Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-09 22:15 +0100
        Re: Buddy System Memory Allocator Alex McDonald <blog@rivadpm.com> - 2012-11-07 12:46 -0800
      Re: Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-10 13:09 +0000
        Re: Buddy System Memory Allocator Alex McDonald <blog@rivadpm.com> - 2012-11-10 07:43 -0800
    Re: [OT] Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-07 09:34 +0000
      Re: Buddy System Memory Allocator Mark Wills <forthfreak@gmail.com> - 2012-11-07 04:07 -0800
        Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-07 19:44 -0500
          Re: Buddy System Memory Allocator Paul Rubin <no.email@nospam.invalid> - 2012-11-07 16:57 -0800
            Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-07 20:14 -0500
              Re: Buddy System Memory Allocator Paul Rubin <no.email@nospam.invalid> - 2012-11-07 17:32 -0800
                Re: Buddy System Memory Allocator anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-08 12:32 +0000
                Re: Buddy System Memory Allocator Paul Rubin <no.email@nospam.invalid> - 2012-11-08 20:00 -0800
                Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-09 02:20 -0500
                Re: Buddy System Memory Allocator Paul Rubin <no.email@nospam.invalid> - 2012-11-09 00:53 -0800
                Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-09 19:10 -0500
                Re: Buddy System Memory Allocator Paul Rubin <no.email@nospam.invalid> - 2012-11-09 18:47 -0800
                Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-10 02:16 -0500
                Re: Buddy System Memory Allocator "Elizabeth D. Rather" <erather@forth.com> - 2012-11-09 17:51 -1000
                Re: Buddy System Memory Allocator Mark Wills <forthfreak@gmail.com> - 2012-11-09 22:51 -0800
                Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-10 02:26 -0500
                Re: Buddy System Memory Allocator "Elizabeth D. Rather" <erather@forth.com> - 2012-11-09 22:01 -1000
                Re: Buddy System Memory Allocator Mark Wills <forthfreak@gmail.com> - 2012-11-09 22:49 -0800
                Re: Buddy System Memory Allocator "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-10 02:15 -0500
                Re: Buddy System Memory Allocator Mark Wills <forthfreak@gmail.com> - 2012-11-09 22:57 -0800
            Re: Buddy System Memory Allocator Mark Wills <forthfreak@gmail.com> - 2012-11-08 00:22 -0800
        Re: Buddy System Memory Allocator "Mark" <mark@dibsco.co.uk> - 2012-11-10 13:43 +0000
  Re: [OT] Buddy System Memory Allocator Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 13:10 +0000
    Re: [OT] Buddy System Memory Allocator Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-07 13:31 +0000
  Re: [OT] Buddy System Memory Allocator Charles Mélice <charles.melice@gmail.com> - 2012-11-11 05:29 -0800

csiph-web