Messages

1

Feature requests / Re: Conversion of all SFML classes from using private to protected

« on: December 06, 2015, 06:06:27 am »

Inheriting your "pausable clock" (i.e. stopwatch") from an sf::Clock means that you are saying that your stopwatch is a "clock that only keeps track of time passed with an ability to restart", since that is what an sf::Clock is.

Except my 'stopwatch' isn't called 'stopwatch' (which is where your assumptions are going horribly wrong), but 'AdvancedClock' with stopwatch-esque capabilities. Chances are I will expand upon that - with the clock arithmetic noted above. Is clock arithmetic a stopwatch only functionality? I'm guessing the answer is 'no'.

Nexus mentioned this already:

You make a common mistake: you violate the Liskov Substitution Principle by assuming that stopwatches are clocks and have every property of their base class. Currently, a class invariant of sf::Clock is to be always running and to count the time since the last reset() call.

LSP falls foul of the Circle-Ellipse problem. But what you've got to consider is that each person implements design of a particular feature differently. This isn't an argument of having a stopwatch in SFML... it's the ability to inherit from clock - regardless of what purpose it might be for. Stopwatch is just a 'tip of the tongue' example.

I don't see why it's so important to inherit from sf::Clock rather than to just use sf::Clock.

This isn't just about sf::Clock. It is but one example.

For me, if a class calls a duplicate function of another class (the stopwatch example you've given calls 'getElapsedTime' - which is a duplicate function of sf::Clock), I feel that's a signpost saying 'this class needs to be a subclass', especially if it shares variables and merely 'adds additional functions'.

If I pass my AdvancedClock (to you, a type of stopwatch) to a function, the function can still treat it as though a clock - because it still has those types of variables and functions in-place: getElapsedTime, restart etc.

If I put a clock internal to my AdvancedClock, I cannot use the same functions that could call a clock - despite there being plenty of overlap in accessibility and function usage!

It's quite possible to argue either way. I'm not asking you to accept nor use inheritance in your clock classes, nor anyone else: I'm asking for the ability for myself and others to be able to use inheritance in general.

[It'd allow people to readily expand upon SFML as well - even offering third party libraries that explicitly expand SFML classes. And even that's not your thing, you'd be making my life a lot easier, and probably many others as well.]

The ones that were changed from private to protected.
As soon as the function becomes protected it becomes callable by user code which means SFML can no longer freely change the implementation since that might break user code that calls it and depends on details of the previous implementation.

Ah, there, a valid response to the actual topic.

This is an invalid rebuttal, however, because SFML has often changed things that go on to break user's code - for example, shifting the naming convention from UpperCase style to lowerUpperCase style, the removal of rand etc. I think generally, as a rule, when one uses a codebase under development, they have to expect code breaking changes.

Changing how getSampleRate() works is no different if it was a private, public or protected function. Indeed, any changes to the original function would apply less in the case of a subclass - which often overloads the original function.

I think not wanting to change something because it might break code isn't legitimate here, because one could use that to argue for a stagnant SFML with no changes. I wouldn't mind if they changed something fundamentally - because with protected access, chances are I could easily add in a work around.

I've now got three classes out of SFML with dopplegangers due to the inability to inherit: Clock, HTTP and SoundBuffer.

2

Feature requests / Re: Conversion of all SFML classes from using private to protected

« on: December 05, 2015, 08:56:18 pm »

To put it bluntly: just because subclassing is avoidable, doesn't mean it should be avoided.

The fact a lot of SFML classes internally are subclasses of other SFML classes, implies even when it comes to development and expansion of SFML that subclassing is required. But why is it then restricted from use by other developers if it's use is a requirement intrinsically?

3

Feature requests / Re: Conversion of all SFML classes from using private to protected

« on: December 05, 2015, 08:40:50 pm »

On the contrary, after this private -> protected modification we are always bothered with those additional functions, which would now be part of the API but were previously implementation details, when we have to fix a bug or add a new feature.

What additional functions would you be bothered by? I don't understand the problem you guys are referring to - you make it sound like switching to protected means that you are obliged to somehow add in external third party functions... which isn't my argument. If anything, protected would allow you to say to more posters 'you can do that yourself by subclassing XYZ' - a basis to refuse third party functions.

I'd personally just like to be able to modify SFML classes rather than work on re-writes. Perhaps an alternative idea - could SFML offer a 'private to protected' version that's separate from the main build, but would install essentially the same way?

I've never seen SFML using protected before, and I think you should at least try it. I think it'd solve a lot of the basic complaints.

Have you looked at line 83? 

I have now, but that wasn't what was originally linked to above. My argument isn't reliant on my knowledge of third party libraries.

There's a big difference between the is-a and the has-a relationship. You should read a bit on that and especially about the LSP as Nexus said. 

Which would all be fascinating if this thread was actually about sf::Clock and stopwatches (which is a subjective design choice, if anything), when it was only an example of where subclassing could apply.

I notice for example no-one has broached subclassing SoundBuffer. Is that because it's easier to attack the stopwatch example using appeals to subjective priniciples? Does the clock example apply in the case of append operations for SoundBuffer? (I'm guessing the answer is no).

[You *could* avoid subclassing... but that doesn't incur the same overheads as image or sound manipulation operations where having direct access to the data is preferable to stepping around it because of some priniciple some guy wrote. Myself? I'd consider a stopwatch a subclass of a clock because it intentionally inherits the clock's characteristics - in the same way a std::string inherits a basic string on functionality.]

4

Feature requests / Re: Conversion of all SFML classes from using private to protected

« on: December 05, 2015, 05:38:14 am »

I don't think you actually looked at Thor's Stopwatch. It internally uses an sf::Clock.

That's not evident from the HPP supplied. Perhaps in the CPP it is, but that's not been provided.

You are suggesting that a stopwatch is a clock, which is incorrect.

Then how does it keep tabs on the transition on time if there is no clock intrinsic?

The Stopwatch is a red herring besides: this is about using protected to allow extensibility of pre-existing classes. The fact you cite the stopwatch in the other library as making use of an sf::Clock internal, not only suggests it indeed does rely on a clock to that effect (refuting it's 'not a clock' argument), but a stopwatch should really be a subclass of clock.

Whether your agree or not is just grounds to allow customisation of classes as people see fit. The fact this won't ever be approved is why SFML requires the ability to customise SFML classes to some degree to use limited use cases. At the moment, sf::Clock is entirely redundant in my library because if I'm duplicating a majority of the functions of sf::Clock to formulate a pause/unpause feature, I might as well add the rest.

[As it stands, it makes no calls to sf::Clock.]

5

Feature requests / Re: Conversion of all SFML classes from using private to protected

« on: December 05, 2015, 02:36:05 am »

Yes, and this exactly the purpose of encapsulation. protected is almost public, because it exposes implementation details, and by doing so, tremenously limits the implementation.

How does allowing expansion of it's implement 'limit' the implemention?

War is peace and all that.

This is the typical Java way of thinking, where classes are the core language element and deeply nested class hierarchies are the standard. Not so in C++ -- here, you have many possibilities of extending functionality, and inheritance is usually not the best option.

Inheritence *is* the best option, that's why it exists! That's why protected exists! This isn't a simple hate on Java style idea - given that platform is about 'pointerless' systems, but the fact C++ is an expansion on C with the idea of classes with intended inheritence. Indeed, the very class SoundStream uses this very assumption to allow people to write their own variants on it!

It's indeed a great example, because it can be perfectly extended without inheritance, see thor::StopWatch.

By rewriting an entirely arbitrary class that makes use of system clock calls... which makes sf::Clock now redundant to me. sf::Clock has all the components to become a pauseable clock, but it requires I have access to it's stored time variable from a sub-class perspective.

The fact it's been implemented by so many people suggests it should have been added ages ago, but rather than fighting SFML's paradigm, it's easier if I just say 'hey, can I just independently modify the clock?'.

You make a common mistake: you violate the Liskov Substitution Principle by assuming that stopwatches are clocks and have every property of their base class. Currently, a class invariant of sf::Clock is to be always running and to count the time since the last reset() call. Depending on the semantics you provide, reset() would need to be virtual, or you have a broken base class. The destructor would also have to be virtual, for people who destroy stopwatches polymorphically. This would add useless overhead that most people never use, but all people have to bear.

The sf::Clock is an example of why allowing access via protected would be a good idea (indeed, because it would require a subclass, IE Stopwatch would inherit from Clock). Because most people require a pause/unpause function, it follows the principle of least surprise that it should be added. But alas, my argument is not adding pause to clock: it's moving clock's variables etc to protected so I can derive a subclass with pause from it.

And this is typical: C++ classes must be explicitly designed as base classes, inheritance can't be an afterthought.

This isn't a refutement to the position given though. If anything, as a library, extensibility should be a prime consideration. Consider string basic under STD which is used for the groundwork of char and wchar classes, or the map/list/deque (which are all template types but extensible in their form).

I can widely agree with Hiura and therocode. If you find a certain component in SFML lacking, you should report this to us, and not just patch your way around it. This way, other users can benefit from improvements as well.

What might be lacking from SFML for me, might not warrant a wide enough use case scenario to justify SFML including it, which simply forces me to either write an entire (duplicate) class from scratch, or rewire the library, and neither are practical considerations.

But I'll humour, here's my list (I suspect you'll agree they won't be ending up in SFML any time soon, hence my request for extensibility so I can add my own changes):

1) Pause/Unpause for clock (I'm not the only one).
2) Clock arithmetic (being able to add or subtract clock time from one clock to another with a return clock class as the end result: specific case stuff. You'll definitely say no to this).
3) Ability to specify request types on HTTP (at the very least, GET types).
4) Base64 decoding support on HTTP (standard format for encoding files, messages).
5) Bulk draw support for Window.
6) The ability to 'append' sounds in sf::Buffer.
7) The ability to 'insert' sounds in sf::Buffer (EG silence).
The ability to overwrite/insert sounds in sf::Buffer.
9) GetChannel/GetSplitChannel functionality (so it's possible to isolate left from right cleanly).
[All of the sf::Buffer case scenarios are prime for subclassing]


I'm sure there are others but those are off the top of my end. It's a real bugbear for me to not be able to subclass pre-existing classes in SFML because it means I essentially have to create an external duplicate that then occasionally interfaces with the arbitrary SFML class I can't subclass, which is messy, bad design and inefficient - but I'm forced to do that because inheritance is a thing not being utilised.

There is a reason why protected exists, it's not 'just' a public, and that's misleading at best. The whole point of protected is to grant subclasses access whilst denying conventional outside usage. The fact virtualisation of functions exists implies C++ is all about the inheritance, especially given it's OO code.

6

Feature requests / Re: Conversion of all SFML classes from using private to protected

« on: December 05, 2015, 02:10:27 am »

A very simple solution, which comes at no cost to SFML and greatly increases it's functionality, is for SFML classes to change their private contents and functions, to protected

Actually, there is one major hidden cost with this approach: everything that is accessible from outside SFML implementation code is de facto part of the *public* application interface. Hence, `protected` is somewhat equivalent to `public` meaning that we cannot change them without potentially breaking users' code. From a maintenance point of view, the modification you're proposing has huge drawbacks.

Now, I'm not saying that no function should be protected instead of private but this should be discussed on a case-basis.

Certainly. But I believe that if you're willing to expand a pre-existing class, it implies you have some understanding of how it works, a more 'advanced: proceed at your own discretion' kind of thing. A lot of users request features or functions that are limited case use, but can't be added without a big rewrite of either library or their own class. Having protected allows them to extend their own limited use case to that class without having to bug Laurent to add it in.

A prime example is the HTTP class: it doesn't do POST requests. When I first approached this I was having issues until I realised it always transmitted GET - which required I modify the class itself fundamentally. After much stress re-writing the SFML library and recompiling, I found that if I simply wrote my own HTTP class from scratch, I'd not have compatibility issues. But then it undermines the point of having SFML with HTTP (and my HTTP class isn't without bugs).

Another example is an extensive number of individual draw requests (something I haven't encountered yet), which, if it was possible to extend the Window class, it'd be possible to attach on a sort of push style bulk drawing system, so it'd go:

Push(Sprite);
Push(Image);
Push(Sprite);
//...etc
DrawPush(); //Implicitly clears push list
DrawPush(false); //Explicitly doesn't clear push list

I know no-one would necessarily agree with that, but if extensibility was there, no-one would have to. I think the idea of shifting to protected would help everyone: SFML can say 'you can extend that', and I can build on top of some good classes.

7

Feature requests / Conversion of all SFML classes from using private to protected

« on: December 04, 2015, 07:16:29 am »

In regularly using SFML, I often encounter a class where I want to expand it's basic functionality (a term for this is extensibility), but I'm unable to do so as it's contents and functions are declared private, which means only members of that class and friend classes can access it.

A prime example would be adding pause functionality to the sf::Clock.

Often, the individual is faced with a choice: either write their own class from scratch to address what is usually only a few additional functional add-ons, or port the SFML source code, make modifications at the low-level and then compile a new library, which then often makes any code reliant on it incompatible with the active version of SFML (and thus requires all future additions of SFML be modified in the same way, a time consuming process!).


A very simple solution, which comes at no cost to SFML and greatly increases it's functionality, is for SFML classes to change their private contents and functions, to protected, which allows a subclass to inherit and access both the functions and the contents, which would allow people to readily extend SFML whilst solving problems such as allowing people to add pause functionality.

It might be argued that private is there as a form of protection, however, given the user is forced into  implementing their own (dodgy!) design (either their own standalone class or modifying the library), it's safer if they're allowed to simply expand a pre-existing stable class.


For example, right now (ignoring the Pause example for sf::Clock) I'd love to implement my own append and get split channel style function for sf::Buffer, but it's looking like I will have to copy out sf::Buffer's contents, modify it, and then put it back in, which is pretty messy and would look neater as an expanded sub-class of sf::Buffer, but without direct access to it's internalised vector, will require I declare duplicate space (a big overhead on large sound files) to do things like append operations - noting that std::vector directly supports appending (where I can simply 'attach on' a sound file without duplicating sf:Buffer's contents).

I know the idea of shifting it from private to protected will get stick from those in-favour of the status quo, but my classes in my library use protected de facto to allow extensibility *unless* I can justify the usage of private (IE a function call must only be called in specific states that only the class itself knows).

8

General / Re: Static Link Errors

« on: November 24, 2013, 03:51:15 pm »

Well, after all this madness about compiler changes, writing a load of code, installing stuff that would make the problem worse, there's a hacky solution that actually works:

Code: [Select]

int _Unwind_Resume;
int __gxx_personality_v0;

Append that to the top of the .cpp file allows it to compile because, basically, those two are merely undeclared variables that the system is searching for. THE ONLY TWO VARIABLES, EVER.

I am sure this is breaking something major on the most fundamental levels. but I have ONLY THREE DAYS to get this project done, and you don't throw me what amount to basically two undeclared variables and expect me to run around the houses to solve it.

GOGI
 

9

General / Re: Static Link Errors

« on: November 23, 2013, 11:06:35 pm »

Static libraries are basically the same code as dynamic, the only difference is the linking is not postponed until loading. It wont solve an incompatibility.
A 64 bit OS can easily use 32 bit binaries, but if you use 32 bit dll files you need to compile your program in a compatible way, that means as 32bit with a compiler with a compatible ABI. The easiest way to do that is recompile both SFML and your program using the same compiler.
Then if its running on one computer, if you copy the exe and all dll files over to another and make sure it uses these dll files (put them into the same directory or double check the dll files are the only SFML dll files in path), it should work there too.

What exactly am I looking to recompile SFML into and what files am I looking to copy where?

The 'Flynn Edition' (FE) version of SFML is compiled 'off-site' (stand alone directory) and the relevant DLLs are simply tacked in with the main program which conventionally is dynamically linked. This is obviously not the case with static linking because it's obviously trying to pull the code from somewhere. What files am I looking to transfer from the FE compile to the compiler's directory?

10

General / Re: Static Link Errors

« on: November 23, 2013, 06:35:12 pm »

made sure compiler defaulted to the 4.4.0 version, still getting errors:

Code: [Select]

c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x135): undefined reference to `_Unwind_Resume'

Why does it still use the MinGW directory for 4.4.1? If you have this a path for the libs in your settings, you might want to change it, since it potentially can confuse the compiler even further when it has the same lib dir twice.

That's where the SFML libraries are stored.

We've only changed the compiler, not the SFML libraries we're using. I don't see how duplicating the SFML files to the other compiler helps?

Also, it can't get confused: the two compilers reside in two completely different directories.

64-bit problem?

Okay, story in full:
I constructed an SFML program that works fine on my machine (32-bit, Vista), and works fine on another laptop (32-bit, Vista) showing the DOS-esque screen debug data and graphics window, but on a 64-bit (Vista) machine, shows only a static black DOS (it doesn't print any starting messages either, and doesn't report any errors or missing libraries).

If, however, I compile an .exe that DOESN'T use SFML and send it, the program runs fine and displays the message. If I use any kind of SFML code, it doesn't play ball (debug and normal libraries are both available, and it works on the other 32-bit laptop fine, note).

I know that 1.6 has 32 bit DLLs and no 64-bit ones. So my idea is to include the library as statically linked into the main program so it doesn't rely on the external 32-bit libraries and see if that works. Except that is quite obviously easier said than done.

11

General / Re: Static Link Errors

« on: November 23, 2013, 06:34:07 pm »

How can you run your own branch while using the official binaries?
If you use your own branch then you need to recompile anyways, so the discussion around what compiler to use is essentially useless since you can use which ever you currently have.

The network DLLs were all that I replaced (as that was the only part I was having problems with). But the rest are de facto downloads. But the problem seems to oddly crop up when sfml-audio is turned to -s: but I can't omit it as sound is a fundamental part of the program. I can omit networking (but it'd be nice if I could showcase networking as well).

The network DLLs were compiled with the same compiler, but aren't the problem.

I don't get why Dynamic Link Libraries and their compile process would have anything to do with statically linked libraries, which I assume just compile the code at run time and merge it with the source code?

I think you still haven't understood what MinGW is. It's first a way to use GCC for Windows, so if one talks about MinGW one mostly always talks about a Windows compiler, and second it's a cross-compiler on Linux, thus if someone actually is talking about something on Linux, then they are still trying to build for Windows.

But if you're talking windows compiler, doesn't "cross-compiler on Linux" nullify your point it's "for windows"?

If you had spent more than two seconds looking at the file list, you'd have noticed that there's only one compiler you're essentially have interest in, namely "c++". If you spent even a bit more, you might have seen the "full" package.

Rather than present a direct link to the singular and apparently only obvious file, you decided to present an entire list including unnecessary file references and then berate me when I get confused?

S stands for simple, y'know, not snarky.

12

SFML game jam / Re: Questions regarding game jam

« on: November 23, 2013, 06:07:33 pm »

To be honest, I seriously doubt anyone is going to have time to put multiplayer action into their jam games.

Well, if people have their own codebase to work from, anything is possible. My own library includes things ranging from compression functions, router reset and IP rotation, automatic imageshack URL uploads (under registered accounts) to (now non-functional) SMTP email, to pulling image links from the GOES satellite weather website, earthquake data from USGS, efficient text parsing systems, 'conversation' text generator (that works by script), basic musical instrumental script system (that can play multiple instruments in parallel).

In-fact, part of the codebase is used to post to a forum to demonstrate how false information can be broadly propagated by automated systems (which combines the automatic image uploading, etc). I've had to reconstruct some fundamental classes (being able to access, read and remove header fields from a HTTP request is highly important in uploads, SFML has it set to private and therefore inaccessible to even subclasses). I suspect people's ingenuity is unlimited. I mean, imagine a forum based computer game?


I'm planning to offer up the compression algorithm to SFML (no licence, public domain) at some point after I clean up and finish testing the recursive functions. It's not a fantastic algorithm (don't expect it to be on par with gzip), and it's written using C programming style (so it would probably need to be encased such to be C++ in classes or namespaces), but...

...It'd have no licensing terms (public domain, no need for credit or anything or additional license bulk), works with pre-existing std::string, configurable settings (so if it's taking too long, you can simplify the pattern search, and if it's not compressed enough, you can increase the complexity). Settings don't affect the receiving end (so you can decompress a heavy level search compression just as you would a light search, no need to communicate settings). It can handle machine code and text code alike, so you can feed in file data raw and it'll spit out the compressed version (however, it's optimised towards text-based data: the more randomised the data stream, less returns you get, and if there are no returns to be had, it doesn't compress the data stream).

13

Audio / Re: Question on how audio is stored in SoundBuffer

« on: November 23, 2013, 06:04:16 pm »

You use the compiler, yet you don't know how it works internally. You use SFML, although you don't know the libraries behind it and the interaction with the hardware. This concept is abstraction: Using things as a black box without caring about the implementation details. It's the same with FFT, you won't need to compute the integral or sum yourself. But you have to understand the different signal representations, in order to know what input and output mean.

Ah, to the contrary! In the end we're forced to learn about the things we're using one way or another. I'm aware of how compilers convert between C's high-level language into assembly code, and how different architecture has different machine commands and how one program won't work on another, because ignorance in coding is surely not bliss (not that knowledge thereforth brings much happiness: just better preparation).

Big endian, little endian. Subjects I'd gladly prefer to not have to deal with or remain ignorant of, but they form fundamental to the innerworkings of a machine. And likewise, if there's a problem with the FFT, how does one propose I diagnose it?

Copy-paste programming very rarely works. Lots of little cogs have to be internally shifted before things run together smoothly. If I feed in my noise, I have to know what to do with the output.

Frequency spectrum, straight forward to understand, yes!

But this mathematical function encoded into those funny symbols akin to another language: Chinese room problem. I don't understand them. I'd have to learn what each symbol means, even though I don't know their names or where to start. Ever tried to find the name of a song to which you don't know the lyrics or band name to? It's like that.

As soon as your signal contains the slightest bit of noise, min/max (and thus mid-point) become effectively useless. These metrics only take into account extreme values, which is not a very good representation of the signal.

Not true! Tis only supposed to be an average (you can't work out the 'pitch' of two competing noises, as it's a harmony and you're recording input wrong). Background noise should register less than the peak (noted by the max, which denotes most dominant noise source), and by approximating a fuzzy-logic area for the peak, you know when you've cross the main crest between a given frequency before searching for the mid-point.

Maybe it's slightly inaccurate. But if I wanted accurate, I'd not be a cheapskate and go out and buy the real thing. Or maybe I would become a music maestro and learn pitch-perfect hearing. But I'm musically and therefore pitch oblivious. I just want a tool that takes my voice, extrapolates what pitch it thinks I'm singing so then I can find the right note and manually script the music to each note, maybe in series, to form a song.

I won't discuss with you about that, since success at using libraries depends a lot on personal experience and motivation. What I can say however is that FFT is a very often used functionality (not only in scientific field, but by virtually all media-related applications, especially music players), so you can be optimistic that there are well-tested and optimized implementations out there. But you seem to have made your choice already without even looking at a single library, that's a pity

Well, you'd think graphics, which is used in every piece of software, would have a straight-forward library for it. But alas, here we are at SFML, what is in effect an Indie development project, because other libraries fail to meet the tasks: licensing (main reason I use SFML is Laurent's permittance for commericialisation, although if I ever get lucky he can expect recompense for his efforts), implementation, or simply obtuse coding language.

But it doesn't. DirectX and it's copyright infringement rage-quit. OpenGL and the license-stranglehold minefield some libraries use or bad implementations.

FFT is no different. I'm lucky in that I was shown SFML and, later, Code::Blocks (the latter of which includes things like posix threads and cross-platform directory headers installed along with the IDE, both extremely useful).

Licensing and installing libraries installs dread and fear in a way it shouldn't (I've wondered why for years why people accept status quo of difficulty adding in libraries and haven't written programs that 'auto-configure' IDEs, compilers etc and the like to get them to work). Such that losing the entire setup IDE is the main fear and not so much the codebase itself.

I was hoping to make a Code::Blocks only OS of Linux on a LiveCD that could be duplicated (with stuff like SFML etc added) so that if the IDE was ever lost, I could just run another copy of it. That way I could boot the IDE, and thus all libraries, from any machine, anywhere, ever.

(Custom LiveCDs however require tons of space just to modify, and a lot of time. Sigh.)

Why couldn't adding libraries be as simple as 'sudo apt-get SFML' or something for an IDE?

14

General / Re: Static Link Errors

« on: November 23, 2013, 05:00:10 pm »

No dice, installed the TDM-GCC version supplied and added the DW2 parts, made sure compiler defaulted to the 4.4.0 version, still getting errors:

Code: [Select]


-------------- Build: Release in SelfBuilding ---------------

mingw32-g++.exe  -o "bin\Release\CV Project.exe" obj\Release\main.o  obj\Release\resources.res  -static-libgcc -static-libstdc++ -lsfml-audio-s -lsfml-network-s -lsfml-graphics-s -lsfml-window-s -lsfml-system-s -s  -lpthread -lcomdlg32 -lGdi32
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x135): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x1ad): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x21d): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x35a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x4a6): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0x6f2): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0x76a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0x998): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0xbc4): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0xcba): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0xdb2): more undefined references to `_Unwind_Resume' follow
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x2ee): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x35a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x3ce): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x43a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x49e): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x19e): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x2ad): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x3aa): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x414): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x47c): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x4ee): more undefined references to `_Unwind_Resume' follow
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x3aa): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x476): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x569): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x675): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x781): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0xc61): more undefined references to `_Unwind_Resume' follow
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(AudioResource.o):AudioResource.cpp:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(AudioDevice.o):AudioDevice.cpp:(.text+0x40a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(AudioDevice.o):AudioDevice.cpp:(.text+0x461): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(AudioDevice.o):AudioDevice.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileOgg.o):SoundFileOgg.cpp:(.text+0x136): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileOgg.o):SoundFileOgg.cpp:(.text+0x17a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileOgg.o):SoundFileOgg.cpp:(.text+0x1c6): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileOgg.o):SoundFileOgg.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.text+0x2c2): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.text+0x306): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.text+0x352): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.text+0x859): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Listener.o):Listener.cpp:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-graphics-s.a(Sprite.o):Sprite.cpp:(.text+0x941): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-graphics-s.a(Sprite.o):Sprite.cpp:(.text+0x9fd): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-graphics-s.a(Sprite.o):Sprite.cpp:(.text$_ZN2sf6SpriteD0Ev[sf::Sprite::~Sprite()]+0x15d): undefined reference to `_Unwind_Resume'
Process terminated with status 1 (0 minutes, 1 seconds)
50 errors, 0 warnings

So I'm stuck, unless someone can figure a way for me to solve the 64-bit problem by another means?

15

General / Re: Static Link Errors

« on: November 23, 2013, 04:42:27 pm »

Now I think, if I remember correctly, they only provided SJLJ at that stage to avoid the issue of crashes on DW2 exceptions thrown from a callback through a dll back to your program.

Edit: I guess I found something for you to try: http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.905.0/ or http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Old%20Releases/TDM-GCC%204.4%20series/Previous%20Releases/4.4.0-tdm-1%20%28r2%29%20DW2/

Thank you, I'll give these a try.