Our new Indie Games subforum is now open for business in G&T. Go and check it out, you might land a code for a free game. If you're developing an indie game and want to post about it, follow these directions. If you don't, he'll break your legs! Hahaha! Seriously though.

Our rules have been updated and given their own forum. Go and look at them! They are nice, and there may be new ones that you didn't know about! Hooray for rules! Hooray for The System! Hooray for Conforming!

Summary: Django is what PHP contributors wish for in their darkest dreams. Django provides intensely incredible functionality to generate small to medium data driven web applications in minutes. A pretty decent ORM provides a healthy layer of abstraction from database development and allows people who are most comfortable with a traditional scripting environment (read: me) to compete with that 14 year old from Slovenia who got a MySQL book for their birthday. I'm trying to close my first official Django development freelance contract this week.

Python is what it is. A simple, slick programming language with a light syntax and flexible rules that I think is a great language for new programmers. Python does everything including exploring Mars.

Summary: Obj-C is a thin veneer over ANSI-C enabling OOP and other neat features. Cocoa is the framework upon which all depends when it comes to Mac development, much like Win32 for Windows. My feelings on Cocoa are mixed, the learning curve is steep. I am currently enjoying the tiny bit of abstraction it provides for OpenGL. I am developing an iPhone application for the retail chain I work in-house for, and I just got taken on as a contractor for an iPhone game developer.

Summary: This got me a job, all my jobs really. Flash has evolved in the last decade from an annoying trend to an underground success in the world of RIA's thanks to Flex. ATG, the worlds leading eCommerce engine, just redid their entire commerce administration tool in Flex and I hear great things about it. Traditional Flash (what I do) is in steady decline as non-proprietary web technologies evolve and become mainstream, but with a high dollar creative team, nothing can compare for raw presentation value.

Summary: C and its descendants (C++/Java/C#/etc.) are the most popular programming languages in the world. (As co-inventor Dennis Ritchie supposedly said, "C is quirky, flawed, and an enormous success.") The web browser you're using, the OS, most of your applications, most embedded software, the software on your router, the software on your ISP's router, the software on your game console, etc., were all written in C (well, or in C++).

For my job, I write in straight C. No libraries, no frameworks, no C++, no nothin'. C is a programming language for Real Men (tm), which means that there's no memory management and you're free to crash your program in various horrific ways. The trade-off for this is speed and size, attributes which give C its staying power - though proper C is losing favor as an application development language to C++, C#, and the like, it's found a second life in embedded applications and other small devices. I also think there's a certain elegance to the syntax - it's a language from an era when you didn't have a lot of memory, so statements are terse and lack the cruft of some more modern languages (*cough*C++*cough*). And best of all, no right minded C programmer would use LongVariableNamesLikeThis.

There's no shortage of manuals and documentation for the various incarnations of C, but the best reference is still from the source: The C Programming Language, by Kernighan and Ritchie. This book is so ubiquitous and standard that it's known simply as K&R in the field.

Summary: Pygame is an extensive wrapper of the cross-platform SDL frameworks, specifically geared toward game development. Pygame takes care of loading assets, playing back sounds and music, drawing to the screen, handling keyboard and USB gamepad input, and can even capture live images from webcams on most platforms.

Pygame is also aware of PyOpenGL, the OpenGL binding for Python, and will gladly create a window complete with OpenGL context. Add 3 lines of code and suddenly you can make OpenGL drawing calls. No fuss.

Anyone with some knowledge of Python can create a working, playable 2D game demo in under a week. With minimal effort, this game will run on Windows, Mac OS X, or Linux, even the 3D bits, with no problems.

PHP is probably the most ubiquitous server-side language around right now, although its been besieged by others on all sides. It's a simple, but bloated language, which suffers from a convoluted past and a stubborn refusal by the devs to trim the fat.

A lot of its popularity stems from how easy it is for newcomers to get results. This low barrier to entry, and PHP's ability to change from script blocks to blocks of HTML on the fly, means that there's a ton of shitty PHP code floating around out there.

Language: JavaScript
Framework: jQuery (looking for one a bit more complex to play with)
Purpose: Web Development

JavaScript is the most widely used programming language on the planet, and one of the most misunderstood. It doesn't behave like other languages, and this difference leads to confusion and frustration. It runs on the client (web browser), and can be turned off. Despite this, it's the driving force behind most of the interactive web apps out there today. Ever use Google Maps or GMail? Yeah, that's JavaScript.

When people talk about JavaScript development today, they tend to mean AJAX, which stands for Asynchronous JavaScript and XML. Essentially, this is a programming technique that allows portions of a web page to show new data without a complete page refresh. Again, look at Google's stuff for examples in action.

Language: C#
Framework: .NET 3.5
Purpose: Web Development (although it can be used for other purposes - see: XBOX 360 Indie Games)

C# is a managed OOP programming language. The managed part means that you don't need to worry about memory management (although you can still dabble with pointers and dynamic memory if you want). I like the language a lot, as it stresses readability (at least, more than PHP). When code is written correctly, its very easy to read, and seems almost self-evident. Beyond that, it just works.

bah calling all macros evil is very heavy handed. But that might be because I work with C++ code that uses macros every day for at least:

ObjectFactory

Object Reference Counting

Object Set/Get Macros

And everyone of those cases could be handled by a template function/class in a much more type-safe, compiler friendly way. Just sayin'.

Obviously if you work with an existing code base full of macros, then that's life...but if you are writing new code and doing it...for shame.

The code base was initial written in the early 90's by programmers that had little experience with meta-programming.

To be fair, I don't think a lot of that sort of stuff went into C++ before 1994.

Templates were part of the original C++ standard (86), but compilers didn't fully support them until the early 2000's. Templates have been updated with a lot of things with the C++98 and 03 standards (of the most note would be partial template specialization).

Pre-2000 it was really hard to use templates though, because as I said, compiler support was shit across platforms.

Define cyclic dependencies in C...do you mean in terms of header files? If so, you should avoid it. If it were C++, I would say pre-define...but uhh...not sure what to do about it in raw C...split the common parts in to another header?

Define cyclic dependencies in C...do you mean in terms of header files? If so, you should avoid it. If it were C++, I would say pre-define...but uhh...not sure what to do about it in raw C...split the common parts in to another header?

Don't use just place #define guards around the header in C to stop the cycle?

Define cyclic dependencies in C...do you mean in terms of header files? If so, you should avoid it. If it were C++, I would say pre-define...but uhh...not sure what to do about it in raw C...split the common parts in to another header?

Don't use just place #define guards around the header in C to stop the cycle?

Yah, but I think he just means the practice of including two headers inside of each other, regardless of guard placement or not (and I wish more compilers support MS's #pragma once would save a ton of guard code).

Define cyclic dependencies in C...do you mean in terms of header files? If so, you should avoid it. If it were C++, I would say pre-define...but uhh...not sure what to do about it in raw C...split the common parts in to another header?

Don't use just place #define guards around the header in C to stop the cycle?

Yah, but I think he just means the practice of including two headers inside of each other, regardless of guard placement or not (and I wish more compilers support MS's #pragma once would save a ton of guard code).

Now I am confused. The guards in each header should stop it from being included more than once since it has been defined already. This than allows any circular nonsense that you want.

Define cyclic dependencies in C...do you mean in terms of header files? If so, you should avoid it. If it were C++, I would say pre-define...but uhh...not sure what to do about it in raw C...split the common parts in to another header?

Don't use just place #define guards around the header in C to stop the cycle?

Yah, but I think he just means the practice of including two headers inside of each other, regardless of guard placement or not (and I wish more compilers support MS's #pragma once would save a ton of guard code).

Now I am confused. The guards in each header should stop it from being included more than once since it has been defined already. This than allows any circular nonsense that you want.

Yah, it does, but the question is: Is the practice of requiring two headers to include each other a good idea, not really can it be done. Would the smarter approach be to split the common parts out somehow. I really don't have an answer, especially since I do C++ and use pre-deceleration which completely defeats the problem.

and for whatever reason I need to include them in each other.... this happens a lot in Objective-C I am finding when you have parent/child relationships and need a two-way bridge between the objects... I mean, technically you can not properly cast objects and just call the methods blindly, but this can cause compiler warnings, and I hate compiler warnings.

and for whatever reason I need to include them in each other.... this happens a lot in Objective-C I am finding when you have parent/child relationships and need a two-way bridge between the objects... I mean, technically you can not properly cast objects and just call the methods blindly, but this can cause compiler warnings, and I hate compiler warnings.

Granted it's not good design, but, why not just include them in the same file?

and for whatever reason I need to include them in each other.... this happens a lot in Objective-C I am finding when you have parent/child relationships and need a two-way bridge between the objects... I mean, technically you can not properly cast objects and just call the methods blindly, but this can cause compiler warnings, and I hate compiler warnings.

I dunno about Objective-C, but in C++ there are some limitations to pre-decleration. Mostly where the header itself contains code that actually tries to use or instantiate the pre-declared class. You will get compiler errors about incomplete types.

It's easy to work around though, unless you have a template class that needs to be fully header implemented. Then in the case of a circular dependency, you are probably stuck with a cyclic include.

Speaking of template implementation...I am sort of miffed that a) more compilers never supported 'export', and b) that C++0x is removing it and not forcing compilers to support it. Being able to actually define your template functions/classes separate from their deceleration is a good thing.

Speaking of template implementation...I am sort of miffed that a) more compilers never supported 'export', and b) that C++0x is removing it and not forcing compilers to support it. Being able to actually define your template functions/classes separate from their deceleration is a good thing.

Speaking of template implementation...I am sort of miffed that a) more compilers never supported 'export', and b) that C++0x is removing it and not forcing compilers to support it. Being able to actually define your template functions/classes separate from their deceleration is a good thing.

I dunno about Objective-C, but in C++ there are some limitations to pre-decleration. Mostly where the header itself contains code that actually tries to use or instantiate the pre-declared class. You will get compiler errors about incomplete types.

That, and if you're using a non-pointer of a pre-declared type in your definition of a structured type, you'll get that error too.

I dunno about Objective-C, but in C++ there are some limitations to pre-decleration. Mostly where the header itself contains code that actually tries to use or instantiate the pre-declared class. You will get compiler errors about incomplete types.

That, and if you're using a non-pointer of a pre-declared type in your definition of a class or struct, you'll get that error too.

Right, because that's considered instantiation to the compiler.

This:

MyClass _someVar;

in your class actually causes the compiler to instantiate that object, and allocate storage for it. Which, as you said, will cause the incomplete type error.

Speaking of template implementation...I am sort of miffed that a) more compilers never supported 'export', and b) that C++0x is removing it and not forcing compilers to support it. Being able to actually define your template functions/classes separate from their deceleration is a good thing.

Yeah, in the last thread I was lamenting that while we went over why including your source definitions using #include was oh god dammit just support export already.

Speaking of template implementation...I am sort of miffed that a) more compilers never supported 'export', and b) that C++0x is removing it and not forcing compilers to support it. Being able to actually define your template functions/classes separate from their deceleration is a good thing.

Yeah, in the last thread I was lamenting that while we went over why including your source definitions using #include was oh god dammit just support export already.

Yah, well, it will never happen now. C++0x removes the feature, but keeps the 'export' keyword reserved.

Speaking of template implementation...I am sort of miffed that a) more compilers never supported 'export', and b) that C++0x is removing it and not forcing compilers to support it. Being able to actually define your template functions/classes separate from their deceleration is a good thing.

Yeah, in the last thread I was lamenting that while we went over why including your source definitions using #include was oh god dammit just support export already.

Yah, well, it will never happen now. C++0x removes the feature, but keeps the 'export' keyword reserved.

Speaking of template implementation...I am sort of miffed that a) more compilers never supported 'export', and b) that C++0x is removing it and not forcing compilers to support it. Being able to actually define your template functions/classes separate from their deceleration is a good thing.

Yeah, in the last thread I was lamenting that while we went over why including your source definitions using #include was oh god dammit just support export already.

Yah, well, it will never happen now. C++0x removes the feature, but keeps the 'export' keyword reserved.

Those bastards!

Yah...

But hey, in exchange we get lambdas and type inference, which I am a-okay with. I use the shit out of both of those features in my C++ work now.

I dunno about Objective-C, but in C++ there are some limitations to pre-decleration. Mostly where the header itself contains code that actually tries to use or instantiate the pre-declared class. You will get compiler errors about incomplete types.

That, and if you're using a non-pointer of a pre-declared type in your definition of a class or struct, you'll get that error too.

Right, because that's considered instantiation to the compiler.

This:

MyClass _someVar;

in your class actually causes the compiler to instantiate that object, and allocate storage for it. Which, as you said, will cause the incomplete type error.

Now, obviously they hadn't actually created a page in their VS project for that particular topic. So are they just using some sort of URL rewriting method?

I've been playing around with ASP.Net again, and if I were building something like that, only way I could think of creating a topic display page that could display any given topic would be to use the query string like: