gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

C/C++ > Things to know about C (typdedef struct, weird pointers)

#34509 - Dullin - Thu Jan 20, 2005 7:25 pm

I have done a C course in college and wanted to start some GBA development but it seems that my knowledge is insufficient on certain aspects and I'd like to ask your help.

It seems that the course I took overlooked a couple of things in C that I would like to know before I try myself at some little exercise.

Let's first go into pointers. I learned that pointers point to an adress and know how to use them in a program (or so I thought) but when I see stuff like this

Code:
#define REG_DISPCNT (*(volatile unsigned short*)0x4000000)


I don't know what it's supposed to mean. Especially about the * after the short.


Now onto another problem.

I have not seen struct at all (they just said that they existed) so when I stumble upon this

Code:
typedef struct tagOAMEntry
{
            u16 attribute0;
            u16 attribute1;
            u16 attribute2;
            u16 attribute3;
} OAMEntry, *pOAMEntry;

// Sprite rotation information

typedef struct tagRotData
{
            u16 filler1[3];
            u16 pa;
            u16 filler2[3];
            u16 pb;
            u16 filler3[3];
            u16 pc;
            u16 filler4[3];
            u16 pd;
} RotData, *pRotData;


I am even more lost than before. Can anyone point me to what is this supposed to do or at a little tutorial explaining struct so that I can continu on my journey to make games :-)

#34511 - tepples - Thu Jan 20, 2005 7:34 pm

Dullin wrote:
I learned that pointers point to an adress and know how to use them in a program (or so I thought) but when I see stuff like this

Code:
#define REG_DISPCNT (*(volatile unsigned short*)0x4000000)


I don't know what it's supposed to mean. Especially about the * after the short.

Let's take this apart:

0x04000000 is a number.
(volatile unsigned short*) is a cast operator that maps numbers to pointers.
(volatile unsigned short*)0x04000000 is a pointer to a memory location.
*(volatile unsigned short*)0x04000000 is the value of that memory location.

Quote:
I have not seen struct at all (they just said that they existed)

You may have to get a better C book, one that explains structs.

Quote:
so when I stumble upon this

Code:
typedef struct tagOAMEntry
{
            u16 attribute0;
            u16 attribute1;
            u16 attribute2;
            u16 attribute3;
} OAMEntry, *pOAMEntry;

This makes an 8-byte record, the first two bytes being attribute0, the second two bytes being attribute1, etc. Once you've read more about structs, you may understand the second one yourself.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#34531 - MumblyJoe - Fri Jan 21, 2005 1:07 am

I would reccomend ditching that way of typing structs, its more past-friendly but doing it this way is FAR clearer to beginners:

Code:

struct whatever
{
     int  a;
     int b;
};

whatever c;

_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!

#34541 - sajiimori - Fri Jan 21, 2005 4:17 am

That's only legal in C++, but I agree that it's better.

#34564 - MumblyJoe - Fri Jan 21, 2005 3:19 pm

Really? I thought most C compilers accepted it now (although I haven't actually compiled anything in C for quite some time).
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!

#34567 - sajiimori - Fri Jan 21, 2005 7:09 pm

If a compiler is truly a C compiler, then it will accept what the C language allows, and it does not allow that form.

#34568 - tepples - Fri Jan 21, 2005 7:18 pm

A compiler that is truly a C compiler will probably also not allow use of inline assembly, CODE_IN_IWRAM, or any other extension to the C language necessary to effective GBA programming.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#35926 - mtg101 - Sun Feb 13, 2005 1:41 am

tepples wrote:
Quote:
I have not seen struct at all (they just said that they existed)

You may have to get a better C book, one that explains structs.


I've always relied on "The C. Programming Language" by Brian W. Kernighan & Dennis M. Ritchie (the guys who invented the C language).

This book won't teach you to program games, or any other specific type of software for that matter. However it does cover the entire C language and is an invaluable reference book.

The 'equivalent' book for C++ is "The C++ Programming Language" by Bjarne Stroustrup (once again the creator of the language).
_________________
---
Speaker for the Dead

#36246 - LOst? - Wed Feb 16, 2005 1:58 pm

MumblyJoe wrote:
I would reccomend ditching that way of typing structs, its more past-friendly but doing it this way is FAR clearer to beginners:

Code:

struct whatever
{
     int  a;
     int b;
};

whatever c;


You must make whatever a struct when declaring c. Like this:
Code:

struct whatever
{
     int  a;
     int b;
};

struct whatever c;


That's why "typedef" is used, so that you can skip writing struct in front of every declaration. Am I right?

#36310 - sgeos - Thu Feb 17, 2005 5:13 am

LOst? wrote:
You must make whatever a struct when declaring c. Like this:
Code:

struct whatever
{
     int  a;
     int b;
};

struct whatever c;


That's why "typedef" is used, so that you can skip writing struct in front of every declaration. Am I right?

Many people typedef structs to save typing. I've heard the argument that you should not typedef struct away. If you always use struct type instead of just type, the people reading your code will know that it is a struct.

Not the best example... Anyway, this could get confusing:
Code:
typedef struct hsv {
     int h;
     int s;
     int v;
} hsv;

typedef u16 rgb;

void my_function(void)
{
    rgb my_rgb;
    hsv my_hsv;

    /* do stuff here */
}


Both rgb and hsv conceptually have 3 members. hsv is a struct, because it is easier to deal with. rgb is a u16, because that is what the gba uses.

You should only typedef struct away if the underlying type is a struct now, but might be changed to something else later.

-Brendan

#36314 - tepples - Thu Feb 17, 2005 6:16 am

sgeos wrote:
If you always use struct type instead of just type, the people reading your code will know that it is a struct.

Implementations of stdio.h often implement the FILE type as a struct. Likewise, GBFS_FILE and GBFS_ENTRY types in my appended asset loader are structs internally, but all the program using the library sees are opaque pointers of type (const GBFS_FILE *). There exist other naming conventions for user-defined types, such as all-caps.

Quote:
You should only typedef struct away if the underlying type is a struct now, but might be changed to something else later.

It's best to get in the habit of abstracting away implementation details such as what's behind an opaque pointer, so that if you do eventually change a smallish struct into a long int or a union for speed purposes, you don't have to go back and fix everything that calls your library.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#36318 - sajiimori - Thu Feb 17, 2005 7:47 am

I think user-defined types should mesh cleanly with built-ins. The more ways that built-ins are special, the harder it is to extend the language to fit your needs.

The most flexible (and long-lived) languages are the ones that explicitly attempt to make the built-in features unspecial. You can often tell how well the language achieves that goal by how hard it is to implement the language in itself.

To answer that question, you ask things like: If the language didn't have feature-X, could I write the feature as a library? If I couldn't write it as a library, how hard would it be to implement as a preprocessor? Would the language even be able to stand on its own without the feature?

Try answering those questions about C regarding:

sprintf
enums
structs
functions

Then go here to see what is possible:

http://www.paulgraham.com/rootsoflisp.html

#36323 - tepples - Thu Feb 17, 2005 9:43 am

sajiimori wrote:
you ask things like: If the language didn't have feature-X, could I write the feature as a library? If I couldn't write it as a library, how hard would it be to implement as a preprocessor? Would the language even be able to stand on its own without the feature?

  • sprintf(): multiple calls to individual formatting instructions
  • enums (the C kind, not the C++ kind): #define
  • structs: arrays (which you already have to handle manually when serializing stuff)
  • functions outside main(): handle them like in asm; push a return label to a software stack before you call a function and then have the called function pop a return address and "goto" it
By then you've reduced C to a portable assembly language, and a C compiler becomes a preprocessor for this.

Quote:
Then go here to see what is possible:

http://www.paulgraham.com/rootsoflisp.html

To read it if you have Adobe Reader but not ghostscript: ps2pdf.com
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#36341 - sajiimori - Thu Feb 17, 2005 8:13 pm

Right, the point is that sprintf can be entirely implemented in C, enums can be added fairly easily with preprocessing, structs can be added with much more challenging preprocessing, and the language simply cannot stand without functions because main() is required.