search of the:   for: 
code logs -> 2008 -> Thu, 25 Dec 2008< code.20081224.log - code.20081226.log >
--- Log opened Thu Dec 25 00:00:38 2008
00:44
<@ToxicFrog>
Necessary: linked lists, trees, and whatnot (ok ok you can fake it with larger-than-needed mallocs and pointer math, but then you're just doing structs by hand).
00:47
<@AnnoDomini>
What are linked lists and trees?
00:47
<@ToxicFrog>
Ok, first of all, dinner is about to occur, so if I vanish halfway through explaining that's why.
00:48
<@AnnoDomini>
Uhuh.
00:48
<@ToxicFrog>
A linked list is similar to an array in that it's an ordered list of items. Unlike an array, however, each list element is a discrete object with a pointer - a link - to the next one.
00:49
<@ToxicFrog>
Compared to an array, retrieving specific elements is much slower, but inserting and deleting elements, even in the middle of start of the list, is much faster
00:50
<@ToxicFrog>
(array is O(1),O(n); linked list is O(n),O(1) if you're familiar with O() notation)
00:50
<@ToxicFrog>
A linked list is also infinitely resizeable since each element is allocated and freed individually.
00:50
<@AnnoDomini>
Uhuh.
00:51
<@ToxicFrog>
There are variants - a linked ring has the last element link to the first, a doubly linked list has each element link to the next and previous rather than just the next.
00:51
<@ToxicFrog>
And now, dinner. Later: trees!
00:52
<@ToxicFrog>
(and possibly a more in depth LL tutorial)
00:52
<@AnnoDomini>
(Possibly not. I'm going to sleep sometime soon.)
00:53 KarmaBot [AnnoDomini@Nightstar-29359.neoplus.adsl.tpnet.pl] has joined #Code
00:53
< KarmaBot>
KarmaBot v2.15 online and ready. Summoned by AnnoDomini. Type "!help commands" for command list.
00:53
<@AnnoDomini>
If I vanish, feel free to talk anyway. My bot will listen. ;)
01:40 AnnoDomini [~farkoff@Nightstar-29359.neoplus.adsl.tpnet.pl] has quit [Quit: Uyo, motherfucker - do you speak it? (Hint: the correct answer is 'no.')]
01:56 You're now known as TheWatcher[T-2]
02:00 You're now known as TheWatcher[zZzZ]
06:15 KBot [AnnoDomini@Nightstar-29097.neoplus.adsl.tpnet.pl] has joined #Code
06:16 KarmaBot [AnnoDomini@Nightstar-29359.neoplus.adsl.tpnet.pl] has quit [Ping Timeout]
06:18 KBot is now known as KarmaBot
09:16 AnnoDomini [~farkoff@Nightstar-29097.neoplus.adsl.tpnet.pl] has joined #Code
09:16 mode/#code [+o AnnoDomini] by ChanServ
09:34 You're now known as TheWatcher
10:37 You're now known as TheWatcher[afk]
10:46
<@AnnoDomini>
When accessing an array which is a member of a struct, I would just go "someStruct->someArray[][] = x"?
10:46
<@AnnoDomini>
If the pointer to the struct was passed to the function doing this.
10:51
<@AnnoDomini>
And if I want to get the pointer to a member of the struct that I have the pointer to?
10:51
<@AnnoDomini>
"someStruct->&whatever"?
11:09 * AnnoDomini hmms. It compiles, but doesn't move the snake. Input is handled correctly, though.
11:09
<@AnnoDomini>
It seems to draw the thing right, too, since resetting randomly regenerates the apple.
11:15
<@AnnoDomini>
Hmm. MoveSnake() isn't being called. :(
11:25 * AnnoDomini facepalms. Of course it wasn't being called if the condition was if (dead).
11:29
<@AnnoDomini>
It works now. :D
11:42
<@AnnoDomini>
Seems the only point addressed by McM, besides going OO, is to divide the project into multiple files.
11:42
<@AnnoDomini>
But I don't know the first thing about that.
13:13 Serah [~Z@87.72.35.ns-26506] has quit [Quit: Be right back, got some smiting and righteous justice to attend to.]
14:00 GeekSoldier [~Rob@Nightstar-8573.midstate.ip.cablemo.net] has quit [Quit: Going to the in-laws' for xmas. NEED VODKA!]
15:40 Syloqs_AFH [~Syloq@Admin.Nightstar.Net] has joined #code
15:40 Syloqs-AFH [~Syloq@Admin.Nightstar.Net] has quit [Ping Timeout]
15:42 Syloqs_AFH is now known as Syloqs-AFH
16:38 Vornotron [~vorn@Admin.Nightstar.Net] has joined #code
16:38 Vornicus-Latens [~vorn@Admin.Nightstar.Net] has quit [Ping Timeout]
20:12 * AnnoDomini scratches head. What should go in a separate file and what should not?
20:13 You're now known as TheWatcher
20:13
<@ToxicFrog>
A typical division is one file == one logical type.
20:14
<@ToxicFrog>
Eg, for snake, you might have one file for the snake, one for the apples, one for general game behaviour, and one for main.
20:14
<@ToxicFrog>
Also, as to how you do it - crash course on C build system incoming.
20:14
<@ToxicFrog>
Building a C program consists of three stages: preprocess, compile, and link.
20:15 * AnnoDomini sits back.
20:15
<@ToxicFrog>
Preprocessing handles stuff like #include and #define. It spits out a modified and hard to read source file.
20:15
<@ToxicFrog>
Compiling handles the actual translation of C code into machine code (object code). It generates a .o file, an object file.
20:16
<@ToxicFrog>
Finally, linking combines .o files - and/or libraries - into a single program binary or library package, by resolving references in each .o to symbols carried by another or by a library.
20:16
<@ToxicFrog>
If you just go "gcc -o foo foo.c bar.c", it will do all of those steps automatically.
20:17
<@ToxicFrog>
(this also works for g++)
20:17
<@ToxicFrog>
Basically, you just pass it all of the source files you want.
20:18
<@ToxicFrog>
Most build systems go for a two stage approach, for improved efficiency when rebuilding; adding the -c option will stop after compiling, emitting a .o file, and you can then use those later (gcc -o foo foo.o bar.o) to link them.
20:18
<@ToxicFrog>
(the efficiency comes from the fact that if, say, bar.c changes, but not foo.c, you only need to redo bar.c -> bar.o and then link, rather than recompiling everything. See also: make, prime mover, rank, s-construct)
20:19
<@ToxicFrog>
(s/rank/rake)
20:19
<@ToxicFrog>
That's the build end of things.
20:19
<@ToxicFrog>
As for the coding end of things, same principle as using libraries - you need to make sure each source file knows about all the symbols it uses.
20:20
<@ToxicFrog>
So, typically, you'll write a header for each one, containing declarations as appropriate.
20:20
<@AnnoDomini>
So I need to, say, include SDL everywhere something uses a function from SDL?
20:20
<@ToxicFrog>
Yes - each file that uses SDL needs to #include it.
20:20
<@ToxicFrog>
But also, files that use each other need to know about it.
20:21
<@ToxicFrog>
Say that main.c uses a bunch of features from foo.c: typdef struct Foo, a function Foo * make_foo(int n), and a global variable nrof_foos.
20:21
<@ToxicFrog>
You would have main.c #include "foo.h"
20:21
<@ToxicFrog>
And write a foo.h containing something like:
20:21
<@ToxicFrog>
typedef struct Foo { ... } Foo;
20:21
<@ToxicFrog>
Foo * make_foo(int n);
20:21
<@ToxicFrog>
extern int nrof_foos;
20:22
<@ToxicFrog>
Just the declarations, no actual code or initializers (and variables declared extern)
20:23 * AnnoDomini tries to do that, then.
20:23
<@ToxicFrog>
Basically, the breakdown is:
20:24
<@ToxicFrog>
Header file: declarations, but not definitions, for all publically usable symbols from the corresponding C file.
20:24
<@ToxicFrog>
Source file: definitions for all this stuff, plus private symbols used only within this file.
20:25
<@ToxicFrog>
Both: other #includes as needed (if it exports a function that takes an SDL_Surface*, for example, they both need to #include <SDL.h>)
20:25
<@ToxicFrog>
(the source will generally include its own header, too)
20:25
<@AnnoDomini>
Where would constants go (both the #defined ones and the global ones)?
20:27
<@ToxicFrog>
#defines: in the header if they're public, in the source if they're private.
20:27
<@ToxicFrog>
Consts I think you can do the same with.
20:28
<@ToxicFrog>
You might need to put them in the source regardless and have the header say "extern const whatever foo", though
20:28
<@ToxicFrog>
To avoid multidefinition errors.
20:28
<@AnnoDomini>
This is complicated.
20:29
<@ToxicFrog>
You get used to it eventually.
20:29
<@ToxicFrog>
That said: welcome to C.
20:29
<@ToxicFrog>
Not having to fuck about with headers is one of the things I like about, well, every other programming language I use.
20:39
<@AnnoDomini>
Where does a struct go?
21:08
<@ToxicFrog>
typdefs go in the headers.
21:08
<@ToxicFrog>
Instances go in the source.
21:26
<@AnnoDomini>
http://pastie.org/346753 <- I got something like this. I don't understand how to do constants, however.
23:09 You're now known as TheWatcher[T-2]
23:17 You're now known as TheWatcher[zZzZ]
23:29 AnnoDomini [~farkoff@Nightstar-29097.neoplus.adsl.tpnet.pl] has quit [Quit: Black, the colour of despair.]
--- Log closed Fri Dec 26 00:00:49 2008
code logs -> 2008 -> Thu, 25 Dec 2008< code.20081224.log - code.20081226.log >
 search of the:   for: