How to share SFML games 'correctly' (DLLs issue)?

[Groogy]

But your missing the point... Compiled code doesn't take up much space. What does take up much space are graphics, scripts, and everything else which is not compiled code. Focus on that first.

If you look at the AAA games they all release their games providing their own DLL files in their own folders.

Make this your mantra: "Make it work, then make it right, then make it fast"
What I'm trying to tell you. First focus on finishing the project before worrying anything about optimization. Then do it right, make the project integrate nicely with the environment, like an installer. Then make it fast, which is both optimizing size wise and performance wise.

Though optimizing size on PC's is just wasted work. Especially on Windows as Windows isn't capable of managing several different versions of a DLL file at the same time like Linux can. If you want to keep your mental sanity on Windows then I REALLY REALLY recommend that you just keep the DLL files in the same folder as the executable. Or else you'll probably just destroy the system stability.

[Svenstaro]

Also note that if you static link completely you will lose exceptions in C++.

[Silvah]

Also note that if you static link completely you will lose exceptions in C++.

Oh, really? What compiler are you talking about?

[Svenstaro]

Talking about gcc. See here: http://www.trilithium.com/johan/2005/06/static-libstdc/ and here: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

I don't think it is possible to link the very c++ stdlib statically on any other compiler.

[Groogy]

Also note that if you static link completely you will lose exceptions in C++.

Well you should avoid using exceptions any way in C++.

[Tenry]

If you want to keep your mental sanity on Windows then I REALLY REALLY recommend that you just keep the DLL files in the same folder as the executable. Or else you'll probably just destroy the system stability.

Okay, I will heed your advice.

[Silvah]

Talking about gcc. See here: http://www.trilithium.com/johan/2005/06/static-libstdc/

Ahem, this says it certainly is possible to use C++ exceptions with static linking, as long as there's only one copy of libgcc. So, if you link everything statically, you will be safe.

I don't think it is possible to link the very c++ stdlib statically on any other compiler.

It is possible to do that on Microsoft's compiler too, for instance.

[bastien]

Though optimizing size on PC's is just wasted work. Especially on Windows as Windows isn't capable of managing several different versions of a DLL file at the same time like Linux can. If you want to keep your mental sanity on Windows then I REALLY REALLY recommend that you just keep the DLL files in the same folder as the executable. Or else you'll probably just destroy the system stability.

With .NET there's a new scheme for system-wide libs which is supposed to solve the problems, and if I remember correctly Microsoft's C and C++ runtimes are distributed in this way. (It's stored in a weird directory name, like Winsxs or something).
I have no experience with that, but supposedly Windows is able to manage multiple versions of system-wide libraries now.

Well you should avoid using exceptions any way in C++.

Huh, why?

[Groogy]

Well you should avoid using exceptions any way in C++.

Huh, why?

If you want the application to crash because something went wrong then assertions is much faster to implement and easier to use. Also you can get them ignored when compiled to release code much easier so they aren't even added to the source for compilation.

If you want to use exceptions actively in your code at runtime then you.... Well I don't even want to know what you was thinking. throwing an exception is like giving up control of the code flow in your application. The exceptions jumps up the stacks until it finds a try, catch statement. What if you for instance allocated anything on the heap memory in one of those functions? Also if we use the exception functionality often it might reduce performance, not sure, never tested just what I've heard.

Haven't you wondered why SFML doesn't implement any exceptions?

I myself actually use exceptions But do as I say and not as I do is a very common phrase ^^

[bastien]

If you want the application to crash because something went wrong then assertions is much faster to implement and easier to use. Also you can get them ignored when compiled to release code much easier so they aren't even added to the source for compilation.

Well exceptions are not about making the app crash when an error occurs, it's about handling errors or throwing them back to the caller.

What if you for instance allocated anything on the heap memory in one of those functions?

It gets deallocated if you use RAII. I'm not saying it's easy, I personally avoid C++ as I find it overly complicated for most uses. But you can say the same with, say, templates, “it's complicated so I don't want to use them, I'm used to void pointers”, or polymorphism, or operator overloading, ...

Also if we use the exception functionality often it might reduce performance, not sure, never tested just what I've heard.

It's supposed to be possible to avoid exceptions overhead when your code path doesn't raise any exception, but I couldn't find much information when I researched it. Now a quick search shows this: http://stackoverflow.com/questions/43253/measuring-exception-handling-overhead-in-c

Anyway, performance reduction must be measured and you should make a choice based on your specific needs. Many programs spend most of their time waiting for I/O, computing long algorithms or whatever. It often just doesn't make sense to choose a technology just because it might make your application a few microseconds faster.

Strictly speaking polymorphism is slow as well, but it doesn't mean you shouldn't use it. The lack of templates in C also causes some code to be slower than in C++, it doesn't mean all C programs are slower and C should be avoided.

Haven't you wondered why SFML doesn't implement any exceptions?

Laurent answered that. He said that exceptions make writing bindings more difficult, and maybe something else I forgot (I can't find the post). Anyway, even if Laurent hates exceptions, it doesn't mean they shouldn't be used.

[Laurent]

I don't hate exceptions, I don't use them because:
- I don't need them for this project (I prefer to design SFML directly without exceptional cases)
- It would make bindings so much harder to write

Exceptions are very good if you use proper C++. It makes it possible to handle an error at the point where it can be handled, without polluting your calls and function prototypes with error codes and tons of checks.

Regarding exceptions vs. no-exceptions performances, one thing that people often forget is to compare similar situations. A code without exceptions, but which does the same thing will probably be slower because of the returned error codes the tons of checks (that are executed even when nothing goes wrong). With the addition of bloated code.

But anyway, you can find millions of discussions about exceptions in C++ with Google, we'd better not start a new one here

[Nexus]

Also if we use the exception functionality often it might reduce performance, not sure, never tested just what I've heard.

Exceptions are designed for exceptional cases. That means you're not dealing with them all the time. When it comes to these errors, the execution speed rarely has priority. Additionally, the point mentioned by Laurent applies.

Strictly speaking polymorphism is slow as well, but it doesn't mean you shouldn't use it.

You can't generalize that. When one instead writes an if-else-cascade, a switch statement or uses function pointers, it's likely to be even slower than a virtual function call.

The problem is, a lot of people hear things like "exceptions are slow", "virtual functions are slow" and so on, but they only hear one side of the truth and never question it. It's a pity people begin to avoid language features because of such misbeliefs.