Mr. Biehl learns C

[FluffyMcDeath]

But there's more....

One of the most fun things you can do with pointers is screw yourself over in mysterious and dangerous ways.

e.g.

int *bob;

*bob = 12;

You have now written the value 12 into a totally unknown location in memory. If bob is global it'll probably be 0 but it might not be. If bob is on the stack (local to a function) it could point any old place. If you have memory protection and you have written to some memory that doesn't belong to you, or is inappropriate for writing data then you will get a grim reaper. If you don't have mem protection or you get unlucky and write to memory you own, you get a mysterious and bizarre failure that doesn't seem like it is anything to do with this code and maybe only sometimes! FUN!!!

Always make sure your pointer points at something sensible before you use it. Aim THEN fire.

Also, watch out if you are pointing at stuff on the stack.

This is OK:

int func1()
{
   int val = 4;
   return func2(&val);
}

int func2 (int* val)
{
    return *val * 2;
}

val is on the stack. You get a pointer to the stack address of val. You call the next func and the stack grows, val stays where it is, you still have the address, all is fine. The answer is 8.

If you try this:

int * func1()
{
    int num = 4;
    return #
}

int func2()
{
    int val*;
    val = func1();
    return func3(val);
}

int func3(val)
{
    int brianTheStrangeNumber = 23;
    return *val * 2;
}

now the answer could be 46, or it could be twice the value of the address of num, or something else depending on how the stack frames are laid out. That's some cool stuff.

[koaftder]

C is a lot of fun. Lately ive been doing some development with an 8052 microcontroller. I have a situation where i need to buffer data coming in various interrupts, and i need to get to that data in the order it was received, and with minimal delay. I've implimented a ring buffer, which is 16 bytes in length and resides in near memory for fast access.

One of the fun things about c is trying to put together the most efficient algorithms you can come up with. This is the most efficient way i could figure to impliment a ring buffer:

Code: [Select]


[font=Courier]
char buf[16];
int head ;
int tail ;

void put ( char data ) {
if ( ++head > 16 )
head = 0 ;
if ( head == tail ) {
if ( ++tail > 16 )
tail = 0 ;
}
buf[head] = data ;
}

char snatch ( void ) {
char c ;
if ( head == tail ) {
// this queue is empty
} else {
if ( ++tail > 16 )
tail = 0 ;
}
c = buf[tail] ;
return c ;
}[/font]

[Cymric]

ottomobiehl wrote:
Just a quick question though, I've noticed that alot of you have mentioned C++ in your replies.  I had made the decision to learn C first before diving into C++ but have got to thinking that maybe I should be trying to learn that instead or in tandem.  Is this wise or should I stick it out with C and move to C++ a little later?

There is no genuine good answer to that: the languages were designed with different things in mind, and you might not like the style of coding either forces upon you. You can write exceedingly good, nearly C++-style programs with C, but you can also break all the rules and create a C-like mess in C++.

However, since you are still struggling with pointers and other elementary issues, my advice would be: don't do C++, but at the same time: do ANSI-C (or C99). The reason for this advice is that you will have your hands full learning to translate human ideas into program code and figuring out what C does well and what it is bad at; you do not need the added complexity of object oriented programming, C++'s very strict typechecking rules, templates, and sometimes very arcane class and inheritance definitions at this point. Admittedly, if you have a good C++ library, you can dive in straight away and just go from there. But good C++-libraries are hard to find. What I usually see is that people program in C++ with a C mindset (known as 'C with syntactic candy'), and that is not the way to be doing things.

Most self tutorials do a great job of teaching you the syntaxis of C++, but absolutely stink at teaching you how to program object orientedly. C's procedural approach is much simpler, but will still give you very decent results, especially for programs of small to moderate size. Only when you feel that approach is not giving you what you want, or when the last pointer problem left you with little hair on your head, or when the program is growing out of your control, should you consider migrating to C++. The disadvantage is that it will feel like learning to program all over again (you're in effect learning to speak a new language, even though C++ and C are very much alike), but at the same time it will give you a much better insight in when you need C++'s native features and when not.

But this is, of course, just my opinion.

[Cymric]

@koaftder:

Actually, that code can still be made more efficient. Your buffer is growing in an 'upward' direction, necessitating a comparison against a non-zero value all the time. It is easier and faster to have it grow 'downward' so you can compare against 0 all the time. Most CPUs give you a zero-comparison 'for free' (the MC680x0 set the Z-flag automatically, and I'll eat my shoe if that other brand does not), so that means there's a few mnemonics less in the final code. If the code is heavily used, that will add up in the long run.

Perhaps an optimising compiler can rewrite the code so the loop is traversed in the other direction, but that requires quite a clever compiler.

[minator]

BeOS is the only OS that I know of where 99% of the entire OS (including the lowest level stuff)was written in C++. It has a lovely API too if you are a C++ developer.

I believe the kernel was written in C but everything else was mostly C++.

The API is wonderful and clean, it's probably a pretty good place to learn OOP and C++.

Just don't go crazy with OOP. It was developed to solve a certain number of problems and it helps to know when not to use it.  

I wrote an audio editor for BeOS, it was in (very bad) C++ but the effects were all pure C.

I'm writing a modular synth at the moment on OS X and it'll be part Objective-C but the audio processing parts will still be pure C (actually C with AltiVec extensions).

[Einstein]

DethKnight wrote:
more power to ya here

I still prefer asm

who needs syntax rules when you can just "flip the switches"
metaphorically speaking

I couldnt agree more.

[Karlos]

Gah! Damn it I have been too long confined to PHP and DHTML coding at work. I missed this entire thread. Oh well :-)

Must get back into C/C++ and ASM...

Karlos wrote:
Gah! Damn it I have been too long confined to PHP and DHTML coding at work. I missed this entire thread. Oh well :-)

Must get back into C/C++ and ASM...

HTML? Coding? :-?

Never! ;-)

[Karlos]

PHP with Javascript/CSS for client side stuff. HTML is just the result ;-)

But I agree. Its a pile of bollocks next to proper coding. I have to degrade myself with the above in order to pay the bills and eat and stuff :roll:

-edit-

On the plus side, I managed to work a tiny amount on my old C++ stuff recently. Got a fledgling linux port, but I am not looking forward to the graphics side of it.

Karlos wrote:
PHP with Javascript/CSS for client side stuff. HTML is just the result ;-)

But I agree. Its a pile of bollocks next to proper coding. I have to degrade myself with the above in order to pay the bills and eat and stuff :roll:

A corporate slave like the rest us! :-D