Page 2 of 2
Posted: Fri Sep 14, 2007 8:04 am
by speal
pcmattman wrote:Array bounds checking, delegates (like function pointers, but for class instances), array slicing, contract programming (asserts that will dump source-file line numbers to screen), nicer templates, and tuples are all great things to play with.
Out of interest... which of these you consider to be not easily doable in C++/STL?
Just asking, because I don't know myself (others may benefit), but where could we find a version of the STL that we could port to our own kernels (or possibly userland programs?).
I would imagine those features are all possible to implement in C++, but you don't get the fancy language support they're wrapped in for D. I'd have to say the tuples and templates make for really easy to read code. For example:
Code: Select all
void printf(A...)(A a)
{
foreach(arg; a)
{
//Do the printing here
}
}
But again, nothing you COULDN'T do before. It's just a personal preference on my part, and to some degree a "let's see if I can do this" situation. I've gotten attached to some of the language features at this point, but I never decided to switch because I just couldn't do something in C or C++.
Posted: Fri Sep 14, 2007 9:53 am
by Solar
speal wrote:I'd have to say the tuples and templates make for really easy to read code. For example:
The example that follows doesn't exactly herald "easy to read" to me. I guess I read C++ functors or iterator code with the same ease. It all comes down to experience, I guess.
Posted: Fri Sep 14, 2007 3:19 pm
by speal
I guess I should have explained it a little better. That code is a substitute for the vararg code you would have to write in C to implement printf. Each of the arguments carries type information, so you can write a type-safe printf with relative ease.
But like you said, personal preference. Things I'll be doing a lot of seem more natural to me in D, so I'll use it.
I think a programming language also causes you to think about a problem in a certain way. It would be interesting to see what unique concepts come up in operating systems written in different languages (albeit, you'll see few differences in a D OS, simply because of its similarities to C, C++, and Java). LISP OS anyone? (not me)
The OS development community has a tendency to dismiss proposals that work with languages other than C and assembly. What's equally frustrating is that many people who issue these proposals don't understand the underlying features of the languages they suggest. Perhaps there should be some real discussion as to how suitable certain languages are to OS Development.
Five categories I might suggest are:
1. Native code, no overhead or runtime support required (c, asm)
2. Native code, runtime support for specific language features (C++, D)
3. Non-native code, simple runtime can be ported (LISP, erlang, ...?)
4. Non-native code, complex runtime can be ported (maybe) (Java, Python (?), ...)
5. Proprietary or very complicated, non-native (C#, VB, ...)
Perhaps this should go to another thread.
Posted: Mon Dec 17, 2007 11:08 am
by LibertyTrooper
Going back to the original question:
Objective-C is very suitable because it is a strict superset of C, unlike C++ which is a C like language whose compiler can also compile C.
As an example, in the beginning, Objective-C was not a language per-se, but a set of compiler directives that expanded into scaffolding that allowed OO concepts to be expressed in C. Later those directives were rolled into the compiler itself.
The biggest fault of Objective C is that it's Smalltalkisms are unfamiliar to "mainstream" programmers. However, beyond the those "isms" is a very well developed language with a great deal of flexibility in the same spirit as basic C.
I would love to see some discussion of using High Level Assembly to develop a portable operating system. I guess, however, the first thing is that HLA should be portable itself.
Posted: Mon Dec 17, 2007 5:10 pm
by AndrewAPrice
pcmattman wrote:Array bounds checking, delegates (like function pointers, but for class instances), array slicing, contract programming (asserts that will dump source-file line numbers to screen), nicer templates, and tuples are all great things to play with.
Out of interest... which of these you consider to be not easily doable in C++/STL?
Just asking, because I don't know myself (others may benefit), but where could we find a version of the STL that we could port to our own kernels (or possibly userland programs?).
STLport? Porting it to your kernel would be no harder than porting it to userland (wrap it around function calls instead of system calls)!
Posted: Fri Apr 04, 2008 2:08 pm
by narke
AFAIK a HelenOS project member tried to port Obj-C inside the kernel to do some stuff in Obj-C but I don't know what happened then.
http://www.helenos.eu/
Apple also did the IO stuff in Obj-C but switched to C++.
Posted: Sat Apr 05, 2008 10:43 pm
by inx
The problem with Objective C, as far as I understand it, is the runtime. ObjC isn't quite like normal C with the runtime mostly being run-once setup code. The runtime takes care of message dispatching between objects. A lot of things aren't hardcoded into the executable in Objective C and are instead deferred to the runtime. I'm currently reading a short book written by the NeXT people back in the day, and if I can figure out the mechanics of the GNU runtime, I'm going to try and write a kernel-mode boilerplate for it and convert the architecture independent parts of my kernel to ObjC before my first release. If I have any success, I'll repost with my observations.
Posted: Mon Apr 07, 2008 12:39 am
by robos
I've done a bit of Objective-C programming under OS X and thus far I'm not impressed. Here's why:
1) I can compile succesfully with a mismatching header definition of method and the actual definition of it (in the .m(m) file). If I remember correctly GCC didn't even give me a warning / error.
2) I can compile code that calls a function that doesn't exist (mis-typed the function name). It does issue a warning but it completes the compile and link and then crashes when you run it. This leaves me to believe it's dynamically resolving things at runtime which might not be the fastest way to have your kernel run
3) For #2 above it needs to export the full symbol table (Apple states you can't remove it if you want your Obj-C program to work) which depending on what you might be doing is not so good either
I still have to get into the language itself. After years of C/C++/C# it looks quite strange sometimes and while I do like naming function parameters that can be a downside as well (longer code lines and weird naming as you have to double name things).
I really dislike #1 & #2 in my list above since that means the compiler has a hard time helping you out which I try to avoid. I've even seen a case where part of OS X were broken where Apple's engineers try to call a function that doesn't exist. Auch.
Maybe I'm missing something? Like more stringent compiler options?
Posted: Mon Apr 07, 2008 3:17 am
by jal
The main problem with D is I think the integrated garbage collector. Although it is possible to shut it off and do explicit memory management for certain modules, you'd need a modified version for your kernel. I've looked at it but decided it was a bridge too far for now.
JAL
Posted: Mon Apr 07, 2008 10:30 am
by Colonel Kernel
robos wrote:I've done a bit of Objective-C programming under OS X and thus far I'm not impressed. Here's why:
1) I can compile succesfully with a mismatching header definition of method and the actual definition of it (in the .m(m) file). If I remember correctly GCC didn't even give me a warning / error.
2) I can compile code that calls a function that doesn't exist (mis-typed the function name). It does issue a warning but it completes the compile and link and then crashes when you run it. This leaves me to believe it's dynamically resolving things at runtime which might not be the fastest way to have your kernel run
Yes, dispatch in Objective-C is dynamic, just like Smalltalk on which it is based. There is a performance hit to this that is probably worse than that of virtual function dispatch in C++, although it isn't too bad (1.7 times slower than a straight function call with a hot method cache).
Just a few of the benefits of dynamic dispatch include being able to send messages to nil (so you get a known result instead of a crash), and being able to implement proxies trivially by handling the doesNotUnderstand message.
This dynamism is very flexible and useful for application development, but I don't see it as being a good tool for kernel development. As you say, the lack of type safety is a concern
in kernel development.
Posted: Tue Apr 08, 2008 12:34 pm
by z180
I downloaded XNU 123.5 (the oldest version on the Apple Server,
I did not ask what happened to darwin 1.0 which was available via CVS)
this is a mix of c,c++ and objc sources from darwin 1.3.1 .the drivers are mostly in OO language but there are a few more in C then now.A few comments tell of the rewrite of the Obj-c DriverKit to the IOkit.I dont know where else on web i could look for objc os example code