Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 16 Oct 1999
Offline Last Active Today, 08:56 AM

Posts I've Made

In Topic: D language code question

31 July 2015 - 07:48 PM

You can think of a delegate as something like this:

struct Delegate {
    void* context;
    void* funcPtr;

So when you return a delegate, you're returning an instance of a type similar to this struct. The context is what allows the delegate to access any variables that were in scope at the point the delegate was created. It's what distinguishes a delegate from a function pointer, which has no context.

In Topic: D language enum question

19 July 2015 - 10:58 PM

This form is called a manifest constant. It's identical to an anonymous enum with one member, e.g. the following are equivalent:

enum { foo = 10 }
enum foo = 10;

An enum in D can be any type, including arrays, classes, and structs. You have to be careful with array enums like logTypes, though. Anywhere you use it, it's just like using an array literal, meaning you're allocating on the GC heap. See the D documentation on enums and this newsgroup post.

In Topic: Why do you need the .h .cpp AND .lib files?

16 June 2015 - 04:43 AM

I think this is one of those cases where analogies just aren't the best way to answer. Better to get your hands dirty. Please bear with me through the parts you are already familiar with.

Create three C files like so:

// fun1.c

#include <stdio.h>
void fun1(void) {
    puts("Running fun1.");
// fun2.c
#include <stdio.h>
void fun2(void) {
    puts("Running fun2.");
// main.c
extern void fun1(void);
extern void fun2(void);
int main(int argc, char **argv) {

You could put the prototypes of fun1 and fun2 in a header file and include it in main.c. Were you to do so, the C preprocessor would just replace the #include directive with the content of the header file anyway. The preprocessor is just an elaborate text substitution machine. Headers allow you to reuse the same declarations across multiple files without typing them over and over and over. Anyway, no need for one here.

Given a GCC compiler (I'm using the tdm64 distribution of MinGW on Windows), you can compile all three files into an executable with the following command line:

gcc main.c fun1.c fun2.c -odemo

Doing so results in an executable, but no intermediate files. The compiler has taken all three source files, translated them to the final output format, and passed everything directly to the linker to create the executable. This approach requires all of the source files. We can split it up, though, like this.

gcc -c fun1.c
gcc -c fun2.c
gcc main.c fun1.o fun2.o -odemo

The -c flag tells the compiler to compile the source file and store the output in an intermediate file (called an object file with a .o extension in this case), so the first two lines produce the files fun1.o and fun2.o. The third line creates the executable using the object files instead of the source files. Now, you can distribute fun1.o and fun2.o to other people (in which case you would want to create a header with the function prototypes) and they never need to see your original source.

Distributing two object files isn't a big deal, but if you've got several of them, then it can be a bit of an annoyance for the users of your project to have to pass all those object files to the compiler. So you can bundle them up into a library (or archive) to make it simpler. Given that you've already created fun1.o and fun2.o, you can then do this.

ar rcs libfuns.a fun1.o fun2.o

With this, ar (the GNU archiver, or librarian) takes the two object files and packs them together in a library file, much as you would add files to a zip archive (except they aren't compressed in this case). When you have dozens of object files, it's much more convenient to pack them into a library like this. Then the user can do the following.

gcc main.c libfuns.a -odemo.exe

Or, more commonly (given that a library is usually not in the same directory as the source)

gcc main.c -L. -lfuns -odemo.exe

-L tells the linker to search a specific directory, in this case the current directory (specified via the '.') for any libraries. The -l (lowercase L) in this case says to link with libfuns.a.

So, to directly answer your question, you don't need the YAML source to build your project, you only need the library and the YAML headers. However, to get the YAML library, you first have to compile the YAML source if it isn't available for download somewhere. Then you can link the library with your project. Alternatively, you could add the YAML source directly into your build system and compile it together, but then you have to worry about how to configure the source, which compiler options to use and so on. It's typically a much better choice to use the build system that ships with any library project to compile the library separately from your project, then link with the resulting binary. That way, you let the library maintainers worry about how best to configure the compiler output for the library and you can focus on configuring the output of your own project.

In Topic: Best Java Book For Complete Beginners

04 January 2015 - 05:13 AM

I've heard very good things about Herbert Schildt's "Java, A Beginner's Guide." The 5th edition covers Java 7, which is a good place to start. Your friend can move on up to Java 8's new functional features after getting comfortable with 7. Besides, it's going to be a while before 8 becomes a major part of the Java ecosystem. And you can tell your friend that Java is perfectly fine for games :-)

In Topic: Problem with a getter function

01 January 2015 - 10:30 PM

The foo in your main function is *not* the same instance as the foo in your Moo instance. They are two different objects. Change your main method to this to see what I mean:

#include <iostream>

#include "Moo.h"

using std::cout;
using std::endl;

int main()


    bool running = true;

    Foo foo;







    return 0;



You will need to call moo.foo.Update() to do what you want, either by adding an update method to Moo that calls it internally or some other means.