OSDev.org

The only reason I don't use C frequently is because I don't understand why I should. I write high level programs with Delphi and low level with Assembly (NASM and MASM). I've never been required to write a program that required a level between these two. I would use C for OSDev and also for its portability though.

Craze Frog wrote:I know why you like the things I mentioned. That doesn't mean I do. Which was the original question.

Then write "I find C unreadable" instead of "C is unreadable"...

I can't see why some people do not understand that other people wants 4 + 1 to be 5.

Consider:
pointer pointed to index 4, you increment it, and it points to index 5. You'd be right to be peeved if this wasn't the case, no?

Colonel Kernel wrote:The problem with header files is that they force me to write every declaration twice.

Erm, no? You write the declaration in the header, you write the definition in the source.

But I see where you are aiming at. Do you think a developer who shirks at writing a parameter list twice would write Javadoc comments? Let alone comments that are more useful than a parameter list itself...

I admit it's all tastes. Sadly, all too often people turn personal opinion into "hard fact", and that doesn't do C/C++ justice. They aren't "clean" (lab) languages, and they leave much to be desired, but they proved successful, and that's a merit all in itself. I wouldn't have believed Java to go that far, for instance, but then again Java has also gone far from being as "clean" a language as it originally was.

Solar wrote:
Consider:

Code: Select all

int values[] = { 42, 23, 128, 1, 8 };
int * pointer = values[ 4 ];
pointer++;

I think you're missing a & here:
And: "C wears well as one's experience with it grows" K&R

Correct(ed), of course.

I *thought* I was pretty good in C, until I decided I wanted to learn operating systems and got myself the MINIX book. It was all reading, no coding at all, I'd never actually sat down to read so much code, let alone somebody else's code. When taking up some coding in C myself after that, I found I had learnt more about decent coding in C than with any other programming exercise before. And I suddenly find all the source code at my company crap (written by others). C code does have its charme, only you need to get used to it.

Alright, Why I don't use C.

1) Like Laksen mentioned a while back, case sensitivity. Why thould ThisVar, THISVAR, ThisVAR, and thiSvar be different variables? (Symbols, not variables, if you want to be technical.) It IS true that there is an argument against case-insensitivity, however you can use DIFFERENT CASINGS TO EMPHASIZE where a particular problem is.

2) Arrays, or rather the lack thereof. Some people will, of course defend C saying that it DOES have arrays. In fact it does not, it has a memory location pointer. {ex: array[index], (*(array+index)), and index[array] are ALL THE SAME to the compiler.}

3) Header files. While the ability to include some text from an outside file is useful sometimes, it strikes me as a much better idea to have these sort of definition/function-libraries precompiled instead of ALWAYS compiled. TP, Delphi, FreePascal get this right with their use of Units. (The unit is only recompiled on a 'compile-all' or if the unit's code has been modifyed.)

4) No range checking. Because C has no real array, it cannot really perform range-checking. I have the sneaking suspicion that THIS is the underlying reason for a majority of the buffer overflow errors that wreak so much havoc.


5) I know it's kinda arrogant. But I honestly don't like everyone in the CS dept saying "Just download the linux sources" when I mention that I'm starting up my own OS project... (The sources are, of course, in C/C++.)

There are others, I'm sure I'd have a much longer list on the top of my head if I were actually taking a class where I had to use it. (I just got back from a forced year-off of programming, and I'm trying to get back in the swing of things.)

Since I've nothing better to do, I'll respond to the previous post:

@point 1: Well, it depends. Myself, I keep all my C variable names lowercase with the occaisional underscores, and my macros in ALL CAPS. Many C programmers use this system to avoid this problem. Anyway, when would you NEED to use case insensitivity to begin with? To each their own...

@point 2: By using a memory location pointer instead of some other random abstraction, C simplifies and add flexibility to 'array' usage. This 'feature' is very useful to those who OSdev, and also to those who don't.

@point 3: Well, headers aren't solely used for standard libraries...

@point 4: Part of C's simplicity (but sometimes I wish it was available). It also allows arrays and memory pointers to be converted between each other.

@point 5: Yeah, I hate that too

I think I'm done
And I'm also wondering what programming language you're using for your OS.

1) Case insensitivity avoids namespace pollution, and simplifies grepping.

2) Your point being? What about C's arrays do you not find fits the definition of an 'array'?

3) These have their advantages and disadvantages. I won't list them here but that's a really big can of worms.

4) If you don't need blistering speed, you shouldn't be using C in the first place. You should be using a higher level language. If you *do* need blistering speed, you don't want extra instructions inserted just to make sure you've done your job correctly. By assuming that your code is bugless the compiler can make many more optimisations.

5) There's no C++ in the linux sources - linus is really quite heavily against it.

karekare0 wrote:@point 1: Well, it depends. Myself, I keep all my C variable names lowercase with the occaisional underscores, and my macros in ALL CAPS. Many C programmers use this system to avoid this problem. Anyway, when would you NEED to use case insensitivity to begin with? To each their own...

As the next post observes, it DOES keep namespacings saner... though if you wanted to you could work around it.

karekare0 wrote: @point 2: By using a memory location pointer instead of some other random abstraction, C simplifies and add flexibility to 'array' usage. This 'feature' is very useful to those who OSdev, and also to those who don't.

Yes, that is true. However see point 4... Pointers and arrays are, in my mind, different things. Sure you CAN define things so they are not, like C does; but that isn't the point.

karekare0 wrote:@point 3: Well, headers aren't solely used for standard libraries...

That is true. But they are prevalant. And my main point was that the headers are simply treated as text includes rather than actually being precompiled info containers. (Modules in modula, Units in Pascal... objects in ASM.)

karekare0 wrote:@point 4: Part of C's simplicity (but sometimes I wish it was available). It also allows arrays and memory pointers to be converted between each other.

*nod* - You see my point then, no? To really have these things the compiler should treat an array as a different type, if just for the bounds-checking. The "everything as a pointer" model really fails in this reegard. (There is at least one language where everything really is a pointer...) (Basically, for the compiler to do some intelligent work on arrays it needs to know about the indexes.)

karekare0 wrote:@point 5: Yeah, I hate that too

Good to see that I'm not the only one afflicted with it. Though I do feel your pain... it's kinda like the mob (masses) saying: "No, don't try to be creative and do something diferent...do things our way instead!"

karekare0 wrote:And I'm also wondering what programming language you're using for your OS.

Ah. Well, right now I'm using TP7 (BP7, really: it has the RTL sources). I got it to a point where I could switch screen modes and type, and the text-interface could recognize commands... all in pure TP, save for the ~5 lines of ASM to read the keyboard.

I recently aquired Dalphi 1, so I'm thinking of applying the methods layed out in the "bp80upd.zip" hack for using TP7's RTL in Delphi1.

Now, personally, I would like to be able to use Delphi 5... but that might be a bit much to ask. The compiler may be too tied into the windows framework. (Though on the other hand, the ability to bind messages to methods to create event-hanlers with such ease might be REALLY nice to have.) Mostly because of the ability to use interfaces and also delagate objects to handle them... it seems to me that would be VERY useful on the design level for my OS. (I want to use the "Everything is an object" idea; though, ironically, I REALLY, REALLY don't like *nix's "everything is a file" ideaology.)

{As a bit of a tangential comment to the above: imagine the logical-drive object as having an interface defined and a property where that interface is implemented by an object representing the FS... that is the object equivlant of a drive holding a partition which contains a FS... seems like a good idea to me.}

All that said, I truely admire the VCL in Delphi. It is a good example of good OO-design. (As opposed to some rather bad and rather simplistic OO/inheratance examples I've seen as taught in classes.)

Shark8, have you looked at Freepascal? It's really nice what you can do with it. If you want to talk throw me a message on IRC or messenger

I find it interesting (though hardly surprising) that most of this discussion revolves around C vs Pascal vs assembly, with few references to other languages (e.g., Forth, the Lisps, Smalltalk, the later Wirth languages, Ada) which have been used (in one capacity or another) for system development.

As a minor point in the perennial arguments regarding case sensitivity, I am surprised that no one has yet mentioned that Wirth (the original designer of Pascal) shifted to case-sensitivity in Modula and all successive languages. Also, 'case-insensitive' may mean different things; consider, for example, the default up-casing used in the majority of Common Lisp implementations. Similarly with case-sensitive: Prolog, for example, requires (er, this is from memory, I may be off on this) variables to be lowercase and rule arguments to uppercase.

My personal view is that it is a tempest in a teapot; both are roughly equal in terms of faults and advantages, and it is more or less an arbitrary choice on the part of the language designers.

Case-insensitivity originated more from technical limitations that no longer exist (e.g., not all systems supported lower-case letters even as late as the mid-1980s) than from any design intent, and has largely fallen out of favor for reasons that are essentially happenstance as well. For better or worse, case-sensitive languages outnumber case-insensitive ones currently, but that alone is not reason enough to see case-sensitivity as better.

Let me chime in my 2 cents as to why I use C.

When it comes to pointer arithmetic, 4 + 1 is not 5 because a pointer is not a number(although it may be represented as one).

Can someone also explain to me why C doesn't have arrays and why being able to convert arrays to pointers is so bad? C can't store an array in a register so it only makes sense that it stores the address of one in a register, right? So considering that in assembly, you store the address of an array in a register to access it and then use an offset , then what is wrong with the way C does things?

Sorry, but I just don't see your points against C. If you don't like C then just say that you personally don't like C, but don't give false reasons as to why it is bad.

Schol-R-LEA wrote:I find it interesting (though hardly surprising) that most of this discussion revolves around C vs Pascal vs assembly, with few references to other languages (e.g., Forth, the Lisps, Smalltalk, the later Wirth languages, Ada) which have been used (in one capacity or another) for system development..

Interesting that you should bring this up. I've been kicking around the idea of learningand-using Prolog for setting up the system configuration (DMA, IRQs, etc.) and then loading my main OS. (Kinda as a second-stage bootloader.)

And yeah... I've been meaning to learn Lisp as well, though I have no idea what I'd use it for (if anything) in my OS project.

iammisc wrote:When it comes to pointer arithmetic, 4 + 1 is not 5 because a pointer is not a number(although it may be represented as one).

Right. Let's use a fictional $100 byte memory-ed computer for the example. (That's $00 to $FF.) The reason that having a pointer incremented by the size of the pointer can be seen as undesirable is that the intervining spaces ARE valid memory locations.
ie
const
I: Integer = $01;
var
P: pointer absolute I; {Make the pointer's value the contents of I.}

begin
p:= Ptr( $01 );
Inc(p);
Writeln( 'The value of P is:', i );
end;

What is the value of P at the end? Assuming the pointer size is a word (16-bit)? You see, the reason that some people don't like that Inc to go to the pointer-size offset {ie Inc(P, SizeOf(P));} is that the memory locations: $02 & $03 are valid, though unattainable under only Inc/Dec pointer arithmitic of that style. {At least that's my oppinion.}

iammisc wrote:Can someone also explain to me why C doesn't have arrays and why being able to convert arrays to pointers is so bad? C can't store an array in a register so it only makes sense that it stores the address of one in a register, right? So considering that in assembly, you store the address of an array in a register to access it and then use an offset , then what is wrong with the way C does things?

Technically, the way C uses Arrays is usable. However, wouldn't it be nice to say, store the size of said array {Or its endpointer} in another register to make sure that you didn't write outside of it? {Anyone recognize a buffer overflow?}

iammisc wrote:Sorry, but I just don't see your points against C. If you don't like C then just say that you personally don't like C, but don't give false reasons as to why it is bad.

Really? Have I given any false reasons? (I do remember that I used to have a much bigger list of gripes when I was using it... but I haven't really programmed, in much of any sense, in about a year.)

Shark8 wrote:

iammisc wrote:Sorry, but I just don't see your points against C. If you don't like C then just say that you personally don't like C, but don't give false reasons as to why it is bad.

Really? Have I given any false reasons?

"False" would be a bit harsh.

But:

1) Pointers behave the way they do because the semantics of "++ptr" is "point to the next element". If ptr points to an integer, that means "point to the next integer". Not the second half of the current one, the next one. There is nothing "wrong" or "right" about this behaviour compared to what you would prefer, it's just the way C works. It ain't "broken", it's just not what you liked, so it's a matter of dislike, not breakage.

2) Automatic bounds checking does eat additional performance, and once you have "washed" your input you shouldn't need bounds checking like that anymore. Again, this is not better nor worse than fully-automatic bounds checking a la C++ <vector>, it's just how the language works, and if you don't like it, that doesn't mean the language is "broken".