OSDev.org

I tried to search for "D programming language". The answer was:

"The following words in your search query were ignored because they are too common words: language programming d.
You must specify at least one word to search for. Each word must consist of at least 3 characters and must not contain more than 14 characters excluding wildcards."

Great, no?

JJ

64 and 64-bit get thrown out as well. I think the filtering parameters are set a little too strict.

It is not a feature I added in. PHPBB doesn't search on single letters, the search database would be huge. We'll be adding a Google based search feature soon.

chase wrote:It is not a feature I added in. PHPBB doesn't search on single letters, the search database would be huge. We'll be adding a Google based search feature soon.

Not if it searched only for whole words.
And also, it was not only "d" but also "programming" and "language".

JJ

I could picture where phpBB looks at the search index, sees that it would get thousands of positives, and stubbornly refuses to attempt displaying them for performance reasons. This is only a single webserver, after all, not a Google cluster.

If you really need to find, why not try "d programming language site:forum.osdev.org"? Works beautifully. Clicky.

nice google skills.
that will deffinately come in handy.

Solar wrote:If you really need to find, why not try "d programming language site:forum.osdev.org"? Works beautifully. Clicky.

Thanks.
Anyway, I was trying to see whether anyone had already to do kernel land programming in D, but looks like the language is too new and too complex (aka runtime dependent) for anyone to consider the idea.

JJ

Or perhaps unheard of. WTF is D? I never heard of it? What compiler compiles it? It needs a runtime... lame! I rather write code in VB if I am going to use a runtime environment.

http://www.digitalmars.com/d/

It's supported by GCC.

And if you are opposed to runtimes - what do you think "crt0.o" is for?

Well, it's not really supported by GCC since the GDC front-end is maintained separately by another community.

I myself sometimes prefer D over C++ and C because it's really a clean and well thought-out language that's based on C++'s design but without some of its kludges. The first time I tried working with it and found out there was no preprocessor I almost gave up. (For those interested, here's how D deals with these issues: http://www.digitalmars.com/d/2.0/pretod.html)

However, the main reasons I think D will never be half as widespread as C and C++ is because it's not supported by GCC (the latest version of GDC only compiles with versions up to 4.0.x IIRC, and that's with some patching), and so I couldn't get a D cross-compiler to work for the x86_64 targets, it's got two main libraries (Tango and Phobos) that compete with each other (but that's still MUCH better than the current state with 'standard' C libraries), and having to implement a fair amount of a runtime (i.e. garbage collection), all of which were the main reasons I gave up on trying to use D for my OS and reverting, not to C++, but to C. If anyone would be willing to give me some pointers on getting GDC to work successfully so I can program my OS in D, I'd really appreciate that.

And about the search issues, I completely agree. We should replace the search feature with a Google Custom Search form!

Zenith wrote:The first time I tried working with it and found out there was no preprocessor I almost gave up. (For those interested, here's how D deals with these issues: http://www.digitalmars.com/d/2.0/pretod.html)

I think designing a modern programming language with a preprocessor is plain dumb. What does the preprocessor do that cannot be already accomplished by "const" qualifiers, inline functions, a fairly good importing feature and an optimizing compiler? The first 3 are just syntax, and the last one is commonplace nowadays.
Quoting the ReactOS Wiki about Rbuild (their custom build system), "string pasting is evil".
In particular, C macros force you into lazy evaluation and a bizarre form of dynamic typing, mixed with the nightmare of having to use tons of parenthesis so that the compiler does not misunderstand the expressions. That's not everything! Don't you know that dirty trick of the do{...}while(0) that allows you to "call" a macro as the only instruction of an if (in the line just before the else)?

and having to implement a fair amount of a runtime (i.e. garbage collection), all of which were the main reasons I gave up on trying to use D for my OS and reverting, not to C++, but to C.

Are you sure you really need to implement garbage collection if you only use local variables?
Perhaps if you abstain from creating class instances the heap in not used. And so, you can use pointers to implement the CPU initialization and the memory allocator (I suppose the compiler automatically handles the reference counting and calls the deallocation function when needed), and finally call the "main" part of the kernel, that could use the language normally to a great extent.
I don't know if this makes sense. I've not programmed in D very much.

If anyone would be willing to give me some pointers on getting GDC to work successfully so I can program my OS in D, I'd really appreciate that.

Looks like you were the first one that tried something like that.

JJ

I think designing a modern programming language with a preprocessor is plain dumb. What does the preprocessor do that cannot be already accomplished by "const" qualifiers, inline functions, a fairly good importing feature and an optimizing compiler? The first 3 are just syntax, and the last one is commonplace nowadays.

Why take out a feature? I can understand avoiding a "shoot yourself in the foot" feature in a language like Java. But in a system development language?

Let's say that you are working on a feature that absolutely needs speed... Would you really want to do a branch at run time rather than just letting the compiler handle it? Again, I agree with you in many cases, but not all.

While this is certainly OT...

C++ has never been about "cleanliness". It has taken an old, battered, but well-proven vehicle (VW Beetle - sorry, I meant "C" of course), and added servo brakes, spoilers, and one hell of a turbocharged engine. The result is something akin to the Audi S1 Quattro - ugly as hell, a ***** to drive, but boy does it fly in the hands of a pro...

Yep, I'm in love.

stephenj wrote:Let's say that you are working on a feature that absolutely needs speed... Would you really want to do a branch at run time rather than just letting the compiler handle it? Again, I agree with you in many cases, but not all.

What C macros do is often called inlining. Only, the C preprocessor does that in a dumb, antiquated and unsafe way.

JJ

That isn't allways true. There are some things (like conditional compilation) that can't be done w/o the preprocessor, at least not in a sane way. For example, I have a #define that changes the level of SSE support the OS expects from the processor at boot time. #define is also nice when you need to define a lot of numerical constants.