OSDev.org

Colonel Kernel wrote: I think you'll have to lose some of your distrust of GC's, because IMO they're here to stay.

Of course they are. But I will always keep a stick handy to poke 'em or beat the crap out of 'em. I don't like it when a runtime does strange stuff "automatically", especially not when it's a production server I have to maintain.

GC also makes many lock-free algorithms a lot easier to implement...

Can't really comment.

...and it makes memory management much more scalable on multiprocessor systems (allocation is much faster...

Huh? How so? I'd be interested in this bit of information.

...deallocation can happen asynchronously.

Which sometimes is not what you want - for example, when you're caching your memory yourself because what the language gives you by default eats too much performance. (Consider paperweight patterns and custom allocators working on preallocated memory in C++.)

Take a step back and ask yourself: Why do we need destructors?

Funny enough, I have almost never used new / delete in years of C++ development. To the contrary, I found it to be somewhat of a warning pointing to bad use of the language. But I've seen destructors that close transactions, files, connections - and perhaps even more importantly, printing debug information about the lifetime of an object...

10 or 15 years ago, the answer most people would give is "to free memory"...

Because they were used to the malloc'ish ways of C. In my experience, transition from C to C++ sharply reduced the number of pointers in a program. Partially replaced by references, partially replaced by clever class layouts.

The truth is, we will always need deterministic destruction, but IMO for non-memory resources only.

Full ACK on the first, partial ACK on the latter. I like to have the option to do something. (Which makes me loathe Java all the more.)

The best approach I've seen is in the upcoming C++/CLI extensions. You can still write destructors that get called deterministically for so-called "unmanaged resources", but you also have the GC to free memory. I think this is a pretty good balance.

Options are A Good Thing (tm), as long as there's One Obvious Way To Do It (tm). (Yes, I also loathe Perl. )

I know next to nothing about D, but MS Research wrote a kernel in a variant of C#, so IMO anything is possible...

Some here are writing their OS in Pascal, an endeavour that makes my hairs stand on end.

Solar wrote: As for D... that "comparison table" pretty much disqualifies the language in my eyes. Why do people keep comparing their respective language to C++ without taking the standard library into account?. C++ does have resizable arrays (<vector>), it has associative arrays (<map>). It does have a for_each. It does have "typeof".

They haven't really done their homework, and if I hate something it's biased advertising disguised as "comparison".

you should really read the specs and perhaps the faq (in the specs). Quoting:

Doesn't C++ support strings, bit arrays, etc. with STL?

In the C++ standard library are mechanisms for doing strings, bit arrays, dynamic arrays, associative arrays, bounds checked arrays, and complex numbers. Sure, all this stuff can be done with libraries, following certain coding disciplines, etc. But you can also do object oriented programming in C (I've seen it done). Isn't it incongruous that something like strings, supported by the simplest BASIC interpreter, requires a very large and complicated infrastructure to support? Just the implementation of a string type in STL is over two thousand lines of code, using every advanced feature of templates. How much confidence can you have that this is all working correctly, how do you fix it if it is not, what do you do with the notoriously inscrutable error messages when there's an error using it, how can you be sure you are using it correctly (so there are no memory leaks, etc.)? D's implementation of strings is simple and straightforward. There's little doubt how to use it, no worries about memory leaks, error messages are to the point, and it isn't hard to see if it is working as expected or not.

eek ...

Note: all D users agree that by downloading and using D, or reading the D specs, they will explicitly identify any claims to intellectual property rights with a copyright or patent notice in any posted or emailed feedback sent to Digital Mars.

that's kinda scary ... what do they exactly mean by this ?

bluecode wrote: It does not "feature" a preprocessor, which normally screws up your source.

It allows you to parameterize your code. I'd be in a tight pinch if I'd have to write a (portable) PDCLib without heavy use of the preprocessor.

There is also stronger type checking, that means e.g. that typedef really creates a new type, which was a problem in C++ when it comes to overloading functions.

Point for you.

Another thing that comes to my mind are functions declared as "synchronized" (or was it "multithreaded"... not sure), which means that the compiler automatically puts a mutex around these functions.

Depending on your OS' threading API, also possible in C/C++, even more fine-grained than on function level.

Imho also contract programming _seems_ to be a powerfull concept, but I'm not yet sure of that (I'm not sure if these contracts are also included in the "release version" of your programm, which imho would make no sense).

Usually not compiled into the release. Also possible in C/C++ and other languages using appropriate library frameworks.

And perhaps the "unittesting" is also somehow usefull, but I didn't read about it yet.

There's JUnit and CppUnit readily available. (And yes, it is useful.) Another point where they fudged their "comparison" table.

I also think that single inheritance + interfaces are better than this complex multiple inheritance in C++.

In the real world, multiple inheritance is very seldom used in C++. Smart designers always have only one of the base classes not being purely virtual, which ends up as being the same as single inheritance + interfaces. Multiple inheritance is just another option in the C++ world.

What makes D not very good for osdev is, that the most/interessting parts of the D ABI are to be defined (but that's also an improvement over C++ - an ABI that is specified is better than one that is not.

Most if not all vendors settled for the Itanium ABI as de-facto "standard" ABI for C++.

Well and the thing about garbage collection... but you mustn't (wait: is it really mustn't here or is it needn't ??? ) use it in D.

"need not". "must not" means you are strongly discouraged to do something.

You "just" have to overload new/delete if you don't want to use it.

You know there are GC libraries available for C++?

Solar wrote:

bluecode wrote: It does not "feature" a preprocessor, which normally screws up your source.

It allows you to parameterize your code. I'd be in a tight pinch if I'd have to write a (portable) PDCLib without heavy use of the preprocessor.

Well as I said: There are something called version statements, but I don't know whether this would be enough for you.

Another thing that comes to my mind are functions declared as "synchronized" (or was it "multithreaded"... not sure), which means that the compiler automatically puts a mutex around these functions.

Depending on your OS' threading API, also possible in C/C++, even more fine-grained than on function level.

Well sure. But this is something that is so low level, that it should be part of the language imho. Tomorrow aren't these times where you won't see multiprocessor computer. And imho this simplyfies programming a lot. And about fine-graindness (does that word really exist ) I can just say, that in D nested funtions exist, which imho can be declared to be "synchronized". Or did I misunderstand your point?

Usually not compiled into the release. Also possible in C/C++ and other languages using appropriate library frameworks.

Yeah, libraries..
I really hate (I'm really sorry for the next word) f***ing libraries. I hate to install thousands of libraries (which usually depend on each other) to just compile two lines of code. That's why having it in the language is imho an important point.
btw. which library framework?

There's JUnit and CppUnit readily available. (And yes, it is useful.) Another point where they fudged their "comparison" table.

libraries the 2nd ... but thanks for your comment about unittesting.

In the real world, multiple inheritance is very seldom ...

That is exactly the point. It is not used and it is one if not the most difficult feature to implement (properly) for a compiler and also for a standard library implementation (ever seen dynamic_cast<> implementation ).

Most if not all vendors settled for the Itanium ABI as de-facto "standard" ABI for C++.

imho vc++ is not using this ABI, but I don't know. As I said above, it is a very complex one.

"need not". "must not" means you are strongly discouraged to do something.

Oh , I never knew that there's such a big difference.
btw. is "needn't" (instead of "need not") really colloquial language?

You know there are GC libraries available for C++?

libraries the 3rd...

[edit: Why do you think that using new/delete in C++ is a kind of design flaw (if I understood you correctly?)]

Pype.Clicker wrote: well, iirc, having a garbage collector in your language requires that you cannot do pointer arithmethic, right ? but in the case of a kernel we rather _need_ pointer arithmetics, be it only for the memory allocation functions ...

i'm not quite sure of how page tables and the like could be manipulated from a GC'd language. Yet i should admit i haven't tried it, so it might be possible anyway ...

In Singularity, they use the "unsafe" portion of C# for that. If you declare a method with the "unsafe" modifier, you can use pointers. Basically, in C# you can create type-safe abstractions with type-unsafe implementations if you really need to. I guess D must be similar, but I'm not familiar enough with it to say for sure...

Quote:
...and it makes memory management much more scalable on multiprocessor systems (allocation is much faster...

Huh? How so? I'd be interested in this bit of information.

For stop & copy collectors, you can allocate memory by doing little more than incrementing a "top-of-heap" pointer. I'm not really familiar with concurrent mark-sweep, so I can't really comment... I plan to read up on it (and other GC algorithms) when I have time . Everything I've read about GC has focused on stop & copy, so that's what I know best. I wouldn't want to use it in a kernel, though.

I will comment more after work...

Great. 20 minutes of typing, annoying my wife in the process (dinner is waiting), and this f***ing forum tells me "too long, go back and resubmit". Not as if my text would still be there, oh no...

So I'll just throw in that there's a design-by-contract lib named "C2" around somewhere. There's even a link on the "design by contract" wikipedia page.

@solar: ctrl+a->ctrl+c->ctrl+v. just for the next time you gonna type something *really* long. *fg*

hm, a already saw C2 (read it in the german wikipedia page, but already forgot about that ), but imho the syntax is plain & simple ugly: Pre-/post-conditions and invariants being declared in comments ::) doesn't sound too good...

@solar: bad day, he or are you using linux, where copy&paste seems (to me) to work only if the application you copy from is still alive... Perhaps this is different, when just switching the displayed page in your browser?

Pype.Clicker wrote: eek ...

Note: all D users agree that by downloading and using D, or reading the D specs, they will explicitly identify any claims to intellectual property rights with a copyright or patent notice in any posted or emailed feedback sent to Digital Mars.

that's kinda scary ... what do they exactly mean by this ?

I think they mean that they "invented" the language and hold copyright / intellectual property rights on it. In other words, don't think about making your own D language or saying you invented it.

I'm pretty sure your free to actually use the language

I am beginning to think what I've done. Haha, but discussion is good. I basically just wanted to point out 'D' since I never heard of it before. It's definitely not something you want to use for kernel / OS dev (too much to adapt).

However, their C compiler is free and might come in handy for us Windows users perhaps. Always good to know what is around.

Trying to recap what I wrote yesterday, real quick:

bluecode wrote:

Another thing that comes to my mind are functions declared as "synchronized" (or was it "multithreaded"... not sure), which means that the compiler automatically puts a mutex around these functions.

Depending on your OS' threading API, also possible in C/C++, even more fine-grained than on function level.

Well sure. But this is something that is so low level, that it should be part of the language imho.

I disagree. Putting stuff like that in the language means that everyone will work with the common denominator. That's great for the programmers, but a pain for the platform maintainer (who has to twist his OS functionality to suit the runtime) and the end user (who has to live with what the language defines instead of what the OS offers).

Thread models, IPC mechanisms, GUI look & feel. They are the domain of the OS, IMHO.

And imho this simplyfies programming a lot.

Absolutely, that's why the software companies love it so much.

And about fine-graindness (does that word really exist ) I can just say, that in D nested funtions exist, which imho can be declared to be "synchronized". Or did I misunderstand your point?

I think you got it correctly. But still it's not as if you couldn't easily do MT programming in C++. (Yes I know you hate libs, but that's your problem, not mine. Even Java has a standard lib, it's only hardwired into the compiler. And even with Java you use third-party libs like log4j...)

I really hate (I'm really sorry for the next word) f***ing libraries. I hate to install thousands of libraries (which usually depend on each other) to just compile two lines of code.

You don't hate libraries, you hate how poorly your OS "supports" dependencies and library versions. That is the unsolved problem, not the languages.

That's why having it in the language is imho an important point.

With every language, you will create interdependencies. Your video software written in D will use external libs for codecs - unless you write it all yourself (and go out of business because it's so expensive / buggy). You cannot provide everything in your language-lib.

So IMHO, the language lib should restrict itself to the very basics and leave the rest to the open market. I like it when two competitors struggle for the best networking package, or the best GUI package, or even the best standard library. Much better than relying on the compiler from one vendor to cater for all your needs.

Competition drives business.

btw. is "needn't" (instead of "need not") really colloquial language?

All those concatenations / apostrophies are, more or less. Noteable exception is "can't", which is "cannot" originally (note this is one word).

[edit: Why do you think that using new/delete in C++ is a kind of design flaw (if I understood you correctly?)]

In my experience, it is very seldom necessary, and because pointers are such a pain if used incorrectly, veteran programmers avoid using them. So, liberal use of them usually points to someone trying to write C or Java in C++. (Especially the Java types think they have to use "new" whenever they're creating an object.)

Solar wrote:

[edit: Why do you think that using new/delete in C++ is a kind of design flaw (if I understood you correctly?)]

In my experience, it is very seldom necessary, and because pointers are such a pain if used incorrectly, veteran programmers avoid using them. So, liberal use of them usually points to someone trying to write C or Java in C++. (Especially the Java types think they have to use "new" whenever they're creating an object.)

In my experience, there are cases (and not just very seldom) in which you do want pointers and in which they aren't complicating things.

Most of my sets, vectors and so on are filled with pointers to objects. Objects that I place in one of these containers are usually fairly large objects that you don't really want to copy around. The nice thing about pointers is that each object exists at only one location, you have that location and if you pass it on to somebody else, he'll change that object too. If you store objects in a vector, you won't ever duplicate objects etc.

I'm starting to think it's more of a personal preference. I could probably do the same (except the copy-to-vector-etc) with objects and references. I just don't like them.

One exception however, when using composition, don't use a pointer. It's pointless since the object will always contain exactly one of the other object and you'll only saddle yourself up with pointer management.

Then again, most of my c++ stuff was at a fairly low level (compilers, OS level stuff) so it might not be entirely representative for generic software industry stuff.

Candy wrote: Most of my sets, vectors and so on are filled with pointers to objects. Objects that I place in one of these containers are usually fairly large objects that you don't really want to copy around.

How (over-?) simplification can shift the subject... The starting point of the discussion was destructors and the use of them for cleaning up memory. I would dare a guess that the objects in your vector are not deleted in a destructor?!

I would never argue that pointers aren't useful, to the contrary. It's another of those 80-20 things: in 80% of the time, you'd avoid them in C++ because the better performance isn't worth the headaches.

Then again, most of my c++ stuff was at a fairly low level (compilers, OS level stuff) so it might not be entirely representative for generic software industry stuff.

Compilers and kernels usually are the other 20%.

Solar wrote: How (over-?) simplification can shift the subject... The starting point of the discussion was destructors and the use of them for cleaning up memory. I would dare a guess that the objects in your vector are not deleted in a destructor?!

Each destructor iterates through the vector/set/etc to clean up the objects. I kind of like the advantages . Also, it gives me a feeling of actually controlling the objects plus I can debug it easier (just write down the address). Yes, I'm designing my new framework around not using pointers but objects, although the objects then contain even larger contents. They'll have to be optimized anyway, I think through use of handle-like objects.

Most people that I see using pointers don't know how else to solve it and use pointers as a swiss army knife. They are a swiss army knife, but when you only need a spoon you can cut yourself quite badly (metaphorically speaking).

Colonel Kernel wrote: For stop & copy collectors, you can allocate memory by doing little more than incrementing a "top-of-heap" pointer. I'm not really familiar with concurrent mark-sweep, so I can't really comment...

that's okay enough for userspace. in kernel space, we usually have slabs and the like providing similar "constant-time" allocation out of pre-sliced chunks. I have network processing in mind: you need a new buffer for each packet you receive, and you usually release that buffer everytime the packet has been fully processed.

Letting the GC do its business here might require a too high priority when network gets more busy ... At least, if i was in charge, i'd be using my own pool of buffer here even in a language that supports garbage collection ...