OSDev.org

Off topic, but something to take note of: be careful never to use uppercase lettering in BBCode markup. When I tried to post that last message, the forum kept mysteriously choking; I eventually tracked the issue down to an instance where I had written [tt][[/URL]][/tt] instead of [tt][[/url]][/tt]. HTH.

scholar how do ya insert a quote from someone else reply.I tried using the <quote> </quote> but it just inserts a plain quote what i wnat is to insert a quote like you guys do saying this quote is from this user etc..?

[ quote ] and [ / quote ] without spaces... Or press that quote button near the post you want to quote.

[ quote ] and [ / quote ] without spaces... Or press that quote button near the post you want to quote.

see this it just gives a heading of "Quote:"
and then the quote below but i've seen some of you with the heading "quote from user...."
and then the quote
how do you do this?

Insted of clicking "Reply" click the quote button on the post that you want to quote.

Pete

Pete wrote: Insted of clicking "Reply" click the quote button on the post that you want to quote.

Pete

thanks

(copied from the Factorial Calculation thread.)

If you are not certain which C data type to use for a given purpose, ask yourself:

Is it a simple data type or a complex one?

• If it is a simple type, is it a character, a number, or true/false value?
  • If it is a character, then it's type [tt]char[/tt].
  • If it is a number, is it a decimal fraction or an exact whole number?
    • If it is a whole number, then is it less than 32767, or more than 214743647?
      • If you know it is less than 32767, then you can use [tt]short int[/tt], [tt]int[/tt], or [tt]long int[/tt].
      • If you know it is less than 214743647, then you can use [tt]int[/tt] or [tt]long int[/tt].
      • If it might be more than 214743647, then you would need to use [tt]long int[/tt], or a floating-point type.
        
        Also, if you know it will never be negative, you can add the keyword [tt]unsigned[/tt] in front of the type. This has the added effect of doubling the size that the number can be (65535 for [tt]unsigned short int[/tt], 4294967295 for [tt]unsigned int[/tt]).
    • If it might be a fraction, then you would need to use [tt]float[/tt] or [tt]double[/tt].
  • If it is a true/false value, it would be [tt]int[/tt]. (In most other languages, such as Java, this would be a Boolean, or bool in C++. The lack of a separate logical type is both an advantage and a disadvantage of C; while it simplifies the language, as well as certain code idioms, it can lead to type-confusion issues).
• If it is a complex type, you would use a [tt]struct[/tt], which you would then define the parts of using simpler types.

even an unsigned int can overflow
java will not throw an exception

> more minix/smx/src/lib/posix/_exec.c
....
message m;

/* Decide how big a stack is needed. Be paranoid about overflow. */
overflow = FALSE;
npointers = 1 + nargs + 1 + nenvps + 1; /* 1's for argc and NULLs */
stackbytes = nargs + nenvps; /* 1 byte for each null in strings */
if (nargs < 0 || nenvps < 0 || stackbytes < nargs || npointers < stackbytes)
overflow = TRUE;
for (i = PTRSIZE; i != 0; i--) {
temp = stackbytes + npointers;
if (temp < stackbytes) overflow = TRUE;
stackbytes = temp;
}
ap = (char **) argv;
for (i = 0; i < nargs; i++) {
temp = stackbytes + strlen(*ap++);
if (temp < stackbytes) overflow = TRUE;
stackbytes = temp;
}
ap = (char **) envp;
for (i = 0; i < nenvps; i++) {
temp = stackbytes + strlen(*ap++);
if (temp < stackbytes) overflow = TRUE;
stackbytes = temp;
}
temp = stackbytes + PTRSIZE - 1;
if (temp < stackbytes) overflow = TRUE;
stackbytes = (temp / PTRSIZE) * PTRSIZE;

/* Check for overflow before committing sbrk. */
if (overflow) {
errno = E2BIG;
return(-1);
}

/* Allocate the stack. */
....

how can you force a program to crash in case of overflow ?
if it doesn't, its behaviour will change - grounds for buffer overflow exploits
plus i have better things to do than checking for overflows

join the dark side ..

how I learned to program:
1990(age 9): I taught myself gw-basic which came with ms-dos 2.2 on my tandy 1000hx.
basic is also a great way to get into programming. I'm not talking about visual basic. Just creating plain text games is a great way to learn the principles of variables, arrays, and logic etc.
1991-1994: Experimented with various systems basic programming such as c64, apple etc. studied the code of other basic programs written by other people(Gorilla in MS-DOS 6 was great).
1995: Being a daft 14 year old, I bought a book called "Teach Yourself Game Programming in 21 Days" by Andre Lamothe. I barely new any 'C' and basically chucked myself into the deep end.
1996-1998: After studying TYGP I finally began to understand the C Language. I didnt realise when I bought the book it assumes you already know C. BUT if you have a little knowledge of C I highly recommend this book to get the principles of Game programming.
1999: I discovered DJGPP and Allegro. I recommend these for quick and easy game creation.
2000-today: Since Allegro, I have created various small programs and games(never released), including an SCI view editor and cursor editor(before SCI studio was released).

I have attempted C++ several times, but never seem to have any use for it - ie I always end up doing things the C way. I also don't have much windows or directx experience yet. But I recommend this method of getting into programming to anyone. Sure at 23 I've been programming for more than half my life now, but I reckon if you take this course over say, 1-3 years, you could be well on your way to creating some great programs.

Aspiring game developers may wish to take a look at the Centipede as a Beginner's Project page on WardsWiki. It is a pretty good idea, I think, though perhaps a bit ambitious as a first project.

In a similar vein, I was considering using the classic 'Guess the Animal' game as one of the main example programs in some beginning programming tutorials I mean to write, if I ever get around to them (that's plural; I mean to write more or less the same material for three or four different languages, similar to the How to Think Like a Computer Scientist series). If I get far enough, and can find a suitable graphics library that isn't too system-dependent, I might try the Centipede example as well.

I would give a very small, but important piece of advice: learn everything.

That means, don't be limited by language, types of languages, types of programming environments, operating systems, learn a bit graphics/image manipulation (that helps a lot when you want to develop something graphical), learn a bit psychology, learn to listen to people, learn to see how people think, learn math, learn music theory, physics, philosophy....

I don't mean that one should immediately learn everything, rather, don't let existing lines of though ever limit you. The more broadly you can look at things, to problems, to environments, the easier it is to solve stuff. Generally, learn to enjoy learning (if you don't). And experiment with what you've learn, try things, even crazy things, even things that couldn't possibly work, just for the fun of seeing how badly they fail

Other than that, I'd say it's always good idea to take the easiest solution that could possibly work. Also, try to never ever do complete rewrites.. learn to improve design instead.. (ofcourse you'll still do complete rewrites of things, but that's the point)..

Finally, do yourself a favour and learn to use some versioning system (like CVS). Those make it infinitely easier to "undo" wrong choices.. at least do regular backups (that is, several times a day) into another directory, but then again, learning to use CVS is probably less pain..

Hi everyone,

here's a couple of suggestions I haven't seen here yet (apologies if someone else posted them and I missed them):

(1) Re-use, and design for re-use (aka: abstract). Depending on whichever language you use, you might want to ask yourself whether the Skiplist you're implementing really has to be restricted to only containing character strings-- why not allow it to contain any kind of value? Or, when implementing a sort function, why focus on one particular order when you can just allow users to pass in the order they like?

(2) Publish, and get criticised. Everyone's code sucks, but yours might get just a little bit better if you have to worry about being able to defend your particular implementation against other coders of similar experience.

(3) Don't be platform-specific unless your life depends on it. I wrote a couple of small games in Turbo Pascal for the 16 bit x86, and I was quite proud of them. Nowadays, not even the DOS/PC emulators can run them for various bizarre reasons. Don't let this happen to you!
(Note to self: Maybe I should be glad about this...)

(4) Design APIs before writing code. I've found it very useful to force myself to think through the neccessary structure of a module (and to worry about where and how to encapsulate) before writing any code. Java's interfaces, C++' abstract classes, Haskell's type classes, O'Caml's module signatures etc. all allow you to completely separate interface from implementation-- even if you decide to stick with one implementation, trying to figure out the "what" before the "how" can do much good.

(5) Use meta-programming and/or domain-specific homebrew languages where needed, and there only. Sometimes you're faced with very high-level or meta-programming-ish tasks ("let's find a way to serialise all our C data structures") that the programming language you are using does not allow you to express directly. Try to see whether you can reduce the particular problem to a small set of primitives, and whether you can write a code generator (or a couple of macros) allowing you to express your intentions concisely.

And here's my 2 EuroCents on the topic of programming langages and learning them:

Having used Perl for quite a bit, I personally strongly disagree about it being a language that should be learned. It is powerful, but very ugly-- meaning that it is subject to many ad-hoc definitions. If you're looking into getting a job as a UNIX system administrator, you'll learn it one way or another, there's no way around that. If you don't need it, sticking to standard UNIX shell tools (bash/csh scripts, sort, cut, uniq, grep, sed, tr, basename, ...) and awk (mawk/gawk) will usually do the trick for you-- so far, it has almost always been sufficient for me, and I've had to do some rather hairy things.
(That being said, Perl excels at having lots of libraries. If you only have to glue together some existing libraries, you might as well do it there.)

One major suggestion I've found missing so far, however, is a suggestion to learn a language with strong, static typing, preferrably also with type inference. SML is quite nice and clean, though its type system is a bit more restricted than that of my other suggestions. O'Caml seems fairly practical, from what I've seen so far, and should have a quite useful type system. Eiffel does quite well with integrating the type system into an OO world (though it is not fully statically typesafe-- Sather takes care of the omissions, but is nowhere as popular). Haskell will be a bit too much for beginning programmers, but it has probably the most amazing type system available today (though Clean offers some fun ideas as well).

Forget about the kinds of type systems you've seen in C, C++, and Java (pre-1.5), they're quite poor compared to the state of the art. (For this, I don't consider templates to be part of the type system; if I'm not mistaken, I'm in agreement with C++ there). Personally, I've found it immensely helpful to think in terms of the types you'll encounter in the languages I've listed above. A good, powerful type system (whether it's in your programming language or just in your head) can give a lot of additional structure to your program and make your code easier to read and easier to maintain (and, with language support, you'll also find a lot more bugs at compile time). No matter whether you'll wind up using statically typed languages, this is something you might want to be aware of.

-- Christoph

Ch. Reichenbach wrote: (1) Re-use, and design for re-use (aka: abstract). Depending on whichever language you use, you might want to ask yourself whether the Skiplist you're implementing really has to be restricted to only containing character strings-- why not allow it to contain any kind of value? Or, when implementing a sort function, why focus on one particular order when you can just allow users to pass in the order they like?

Indeed, generic containers and sorting functions which can be passed arbitary functions to compare with are good examples of useful abstractions. But the art of building useful abstractions is an art of it's own. It's never a good idea to duplicate code, but too often one builds abstractions on top of abstractions, which finally result in a heap of code, which could be done with a few lines instead.

So generally, while abstractions and reuse are definitely good things, I would first write specific cases, and only when I see myself repeating the same pattern over and over again (sometimes twice is enough), I turn it into an abstraction instead.

(2) Publish, and get criticised. Everyone's code sucks, but yours might get just a little bit better if you have to worry about being able to defend your particular implementation against other coders of similar experience.

Also be humble, and accept that somebody else might have a better implementation/design/whatever. Unfortunate as it is, it happens all too often. Also, remember that people often expect things to work in certain ways, without having actually tested them. It is not uncommon that simple experiment demonstrates that an "obviously inferior" implementation strategy actually outperforms the better one.

(3) Don't be platform-specific unless your life depends on it. I wrote a couple of small games in Turbo Pascal for the 16 bit x86, and I was quite proud of them. Nowadays, not even the DOS/PC emulators can run them for various bizarre reasons. Don't let this happen to you!

It's also a LOT more fun to be able to show your programs to your friends, and when they look at them and say "WOW" you can then give them a version which runs on their favourite OS/platform.

(4) Design APIs before writing code. I've found it very useful to force myself to think through the neccessary structure of a module (and to worry about where and how to encapsulate) before writing any code. Java's interfaces, C++' abstract classes, Haskell's type classes, O'Caml's module signatures etc. all allow you to completely separate interface from implementation-- even if you decide to stick with one implementation, trying to figure out the "what" before the "how" can do much good.

This is a double-edged sword. Designing API's is usually a good thing yes, but rarely is the API what you actually want to build. Generally, I think it's usually good to start from the projects real "core" features, experiment a bit with implementing them, try to find what are the interesting aspects, and then design an API that would implement it, then adapt your code to your API. Then add other features, extending your API as you implement more code.

I'd say, plan your API's for extensibility, but don't specify APIs which you aren't going to implement right now. Otherwise you find something related to the problem of too many abstractions.

(5) Use meta-programming and/or domain-specific homebrew languages where needed, and there only. Sometimes you're faced with very high-level or meta-programming-ish tasks ("let's find a way to serialise all our C data structures") that the programming language you are using does not allow you to express directly. Try to see whether you can reduce the particular problem to a small set of primitives, and whether you can write a code generator (or a couple of macros) allowing you to express your intentions concisely.

I'd like to add here, that if you are using a code-generator, NEVER modify the generated code manually, always modify the generator (or it's source) instead!

(For this, I don't consider templates to be part of the type system; if I'm not mistaken, I'm in agreement with C++ there).

Indeed, C++ templates are a language of their own, last I checked they where turing complete.... avoid them, unless you are fairly comfortable in writing your own Lisp-compilers (or something similar).

One more advice:

The code you write has to be clean. Furthermore, be a good mathematician.