OSDev.org

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.



Can't really comment.



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



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



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



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.



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



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



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

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

eek ...


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

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.



Point for you.



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



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



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



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.



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



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



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

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



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?


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?


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


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


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


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


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?)]

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



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?

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:



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.



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



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



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



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.



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



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.

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.



Compilers and kernels usually are the other 20%.

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

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