This is a dependency problem like any other, the fact that it's a library rather than an application makes no effective difference, you just don't have an application entry point.

It's not uncommon for libraries to have dependencies on other libraries, especially those that somehow wrap others.  My OpenAL interface for Ada for requires OpenAL, Freetype requires zlib, etc...

Your best bet is to simply list the dependencies.  Static linking is a bad solution, I believe, for a few reasons.  One, your binary is going to be huge, or at least bigger than necessary.  For libraries this is kind of a big deal.  Two, as someone already mentioned, if the user is also using SDL, you may run into nasty version differences, including link failures due to name clashes.

Developers should know enough to understand library dependencies and how to deal with them, and if they don't, you can write a FAQ or something.  Documentation is the best solution.

Programmer is probably less ambiguous.  My previous job was doing programming at a non-profit medical research firm, and they kept talking about "coders."  It turns out that in their particular research area people did something called "coding" which was completely unrelated to computers or programming.  Took me a few months to figure that out.

I've always thought about it this way:  games aren't supposed to be concerned with realism.  Realism is the domain of a totally different kind of program, and they're called simulators.

The line is blurred sometimes, but the truth is that reality isn't very fun.  I get especially annoyed when I hear people wanting realistic war games, and I want to explain to them that a realistic war game would be one the most boring things you ever played, you'd spend most of your time walking guard duty and cleaning your gun.

I know this doesn't have much to do with physics, and is more of a philosophical rant, but as a closing argument, if realistic physics were fun, wouldn't we be having fun all the time just walking down the street?

Interesting.  I wonder if different architectures are better at it.  I would never make such an optimization, because I don't like to assume x86.

There's also lrint and friends, which should do this kind of stuff portably (it was also mentioned in the second link, I think). As far as I know it's a C99 thing, so I'm not sure how well-supported it is, and whether it always gives the same speedup. Worth a try I guess.

Even if you don't want to limit yourself to x86, you could still use the preprocessor to disable these optimizations in the unlikely case that you're not on x86.

For me it's not unlikely, it's 100% certain, as I build Mac OS X universal binaries for PowerPC and x86.

Semi-on-topic-ish remark: the standard C float-to-int cast is indeed a shockingly slow beast, which has historical reasons related to the C standard. It's very useful to know that there are ways to do this conversion about 10 times faster:

http://www.stereopsis.com/FPU.html#convert
http://mega-nerd.com/FPcast/

If you ever need to convert floats to ints in anything remotely performance sensitive, do yourself the favor and use one of those. I've seen dramatic increases in frames per seconds for certain pieces of code just by making use of these things.

Interesting.  I wonder if different architectures are better at it.  I would never make such an optimization, because I don't like to assume x86.

For any built-in data type, the "default constructor" form gives you the default value.  So given a template like so:

Code:

template <typename Type>
void Funk()
{
    Type val = Type(); // Initialize to default value.
}

This. Perfect answer. Tried it, works great! Didn't know it works with buildin ones, too. And I finally understood whats behind the int(...) cast - it's like creating a new object out of the original value, except that it's casted.

It isn't a cast, it's the creation of a temporary via a constructor.

Code:

int(4.0); // Temporary int from value 4.0.
(int)4.0; // C-style cast of the value 4.0.

For the built-in types, there is no difference between the two that I'm aware of, but for user-defined types they can have very different behavior (conversion operators come into play) and it's important to know the difference.

When initializing something with 0, it just means that type's default value.

Not for user-defined types.  Type() works for both user-defined and built-in types, 0 does not.

[constexpr]

Using enums is a handy way to invoke specific constructors, good for things like matrices which have additive and multiplicative identities. Plus you might want to leave the default constructor for simple value types empty for performance reasons.

Code:

enum ZeroTag { ZERO };
enum OneTag { ONE };

template <typename T> class Matrix
{
    Matrix( ZeroTag ) /* init NxN zeroes */ {}
    Matrix( OneTag ) /* init NxN identity */ {}
};

Matrix zero(ZERO);
Matrix one(ONE);

C++11 (I think that's the official name now) is adding the ability to create instance of objects that are treated as compile-time constants, that is all of their data is known and can be optimized at compile time, in assignment for example.  I don't remember the syntax (it has something to do with the new keyword constexpr) but I would think it would render some of those techniques obsolete.

The above solution is best, but I'd bet even initializing both with "0" would optimize to similar code.

That doesn't work for types that don't accept 0 as an initializer (most user-defined types, I reckon).

For any built-in data type, the "default constructor" form gives you the default value.  So given a template like so:

Code:

template <typename Type>
void Funk()
{
    Type val = Type(); // Initialize to default value.
}

This will solve your default value problem.

As for the other problem, try using the C++ header <cmath> instead of the C header <math.h>.  I think <cmath> has some additional overloads, but I may be wrong.

I got my Ada/Objective-C project migrated from Xcode to a makefile, this is very happy.

For all those who claimed that an IDE could do everything the command line could, try setting up a combined Ada/Objective-C project in Xcode.  Let me know how you did it, if you pull it off.

Why would one want to use Ada? 

Because it's the most interesting and well-designed programming language I've ever seen.

I got my Ada/Objective-C project migrated from Xcode to a makefile, this is very happy.

For all those who claimed that an IDE could do everything the command line could, try setting up a combined Ada/Objective-C project in Xcode.  Let me know how you did it, if you pull it off.

I think I've solved my localization woes.  That's happy.

What did you decide on in the end?

Well, on Linux I pull the current locale and load a glade file and strings file for that locale, en_US.glade and en_US.strings, for example.

On OS X it's as easy as making a .lproj for each language to contain the UI, and putting a Localizable.strings file in each one, this allows you to use NSLocalizedString to retrieve the strings.

On Windows I put language IDs on all my resources, including a string table.  I'm not sure if this approach actually works yet, but it seems to be moving in the right direction.

I think I've solved my localization woes.  That's happy.

But the fact is, it's nice to have tools like code autocomplete and call/caller information on hand at the press of a button (and yes, obviously other things too).

For me, autocomplete is one of the biggest annoyances of IDEs, and other programs too.  When it comes to things like this, I have one very simple (and to me, obvious) rule.  Whatever I have physically typed must take absolute precedence over anything you want to recommend.  I have never seen an autocomplete system that follows this simple rule.  From Xcode, to Visual Studio, to Borland C++ and every other IDE I've tried, the damn thing keeps trying to stick crap in there that I don't want.  I have no clue how anybody tolerates autocomplete.  It's the first thing I turn off when I have to use an IDE.

That exact problem bit me in the ass just two days ago.  They're not different enough to justify having multiple source files, so I have several #ifndef __WIN32__ ... #else ... #endif blocks scattered through my network code.  Annoys the hell out of me.

One of the first things I do with a body of code using sockets in any significant way is to quickly wrap them up in a lightweight abstraction/API of some sort. This generally removes the need for a whole bunch of switching ifdefs throughout the whole body of the code, and is *especially* useful if the code is to be cross-platform- it is simply stunning as to the number of tiny differences between platforms when it comes to socket APIs. Without such a thing, in a project of decent size you can be left with a series of increasingly complex and poorly-understood nested preprocessor defines, all through the code. If you pull it to one place, you can make global changes to the whole system on discovering a problem quickly, and can properly document all the weird socket hacks you need to do for different systems in the one place. Oh, and when it comes to socket APIs, the Windows one is in a horrifying league of its own.

Anyway, such a thing would bring the complexity from your app into just one file, and avoid polluting the rest of the app with a series of switches to cope. It's not advice I'd give to someone just starting out, as it's better to get your hands dirty initially, but once you've got a (bitter) taste it's something I'd highly recommend.

This code is in my abstracted API.

Guys, I know I'm going to start a flame war and/or make this situation even worse, but every time someone says, "I don't like IDEs because of x and y" all I hear is "I think my programmer cred is more important than getting my work done."

I'm more productive without an IDE, hands down.  It has nothing to do with macho skill contests, I simply work better that way.  I've been programming professionally for five years, and I've consistently noticed that the best programmers on my teams never seem to use them.  I know that correlation is not causation, but there might be a connection there.

I mean, command line is fine for small projects, but I really enjoy having a quality debugger and extras like a callers' graph and what-have-you. SVN integration with the IDE makes source control 99% automated...

I'd be willing to bet that the developers of large projects like the Linux kernel and GCC are command line developers.  I'm on the Microsoft Office team, and I know for a fact that many of the developers work from the command line.  The command line is just fine for large projects as well as small ones.

The debugger you get in an IDE is just a pretty interface over a command line debugger.  It's the same "quality debugger" either way.

Personally, I don't think IDEs should have anything to do with source control.  Source control is to development as libraries are to writing books.

Edit: and obviously, everything you can do with an IDE, you can pretty much do from the command line, but the converse is also true. The difference is that with the IDE you have it all in one place and it's faster to set up and work.

Everything is all in one place from the command line too.

So, all you vim lovers out there, how do you cope without:
- Stepping though source in a debugger
- One key compile with error highlighting

Those aren't even IDE level features, but I consider them indispensable.

I run the debugger from the command line.  GDB prints the lines as you step through them, and you can get a larger listing on demand.

vim can be attached to a compiler and can do error highlighting and such, but I've never seen the need.  I just type 'make' in my build console, look at the line number in the error message and go there.

Good programmers on linux don't use IDE's. Period.

vim and a makefile, wouldn't work any other way.

Like not having a "poll()".  For real, Microsoft?  You reckon that "select()" is good enough, do you?   

That exact problem bit me in the ass just two days ago.  They're not different enough to justify having multiple source files, so I have several #ifndef __WIN32__ ... #else ... #endif blocks scattered through my network code.  Annoys the hell out of me.