...the usual return for something that is invalid is 0.I don't think this is correct. Zero is a very common valid input. In fact, main() itself returns zero when it executes successfully ;D
I do think the assert would be a good idea, with the separate debug and release libraries allowing scope for that sort of thing.Why not? The whole point of assert is to have debug checks that are optimized away in release mode ;)
Asserts are for the developers of the library, not the users.Assertions are regularly used to check preconditions, both internal or external. The STL is the best example: they do those checks for the users, not for themselves.
They were never meant to replace proper bounds checking code.How would such code look? Other error-checking mechanisms such as exceptions and error codes are associated with a runtime cost. You don't want to have an overhead every time you access an index, because as you say, this is not Java. Assertions are the ideal compromise between safety in debug and speed in release mode.
By using a debugger, out-of-bounds errors such as this can be resolved in a matter of seconds, even with a complete stack trace.This is simply not true. Out-of-bound errors cause undefined behavior, there's no guarantee that debuggers detect them. For example, it's very well possible that there's other data after the end of the array, and by accessing an index beyond the array, you just write to that data.
No, it uses python. Just checked on the website and it uses c, c++ and python, with the backbone being written in c and c++ and most of the functions written in python, holding your mouse over functions shows that they are all called by python functions.Yes, it uses Python. For extensions and the game engine. The Python info in tooltips are for extension writers as some kind of documentation, so you know what to call in Python to reach the same functionality. The code behind those calls is implemented in C though.
Ignoring the fact that this is off topic, I was part of the first ever project (that we could find out about), where we made the school trophy by scanning people in and (me) doing the modelling in blender. It crashed every computer we put it on, including an alienware aurora, that has an i7 and 16gb of ram. It was also taking about a minute per vertex move or quadrilateral creation.No, it uses python. Just checked on the website and it uses c, c++ and python, with the backbone being written in c and c++ and most of the functions written in python, holding your mouse over functions shows that they are all called by python functions.Yes, it uses Python. For extensions and the game engine. The Python info in tooltips are for extension writers as some kind of documentation, so you know what to call in Python to reach the same functionality. The code behind those calls is implemented in C though.
Blender is everything, but not slow. :)
Ignoring the fact that this is off topic, I was part of the first ever project (that we could find out about), where we made the school trophy by scanning people in and (me) doing the modelling in blender. It crashed every computer we put it on, including an alienware aurora, that has an i7 and 16gb of ram. It was also taking about a minute per vertex move or quadrilateral creation.
What I don't exactly understand is Hiura's argument: the assertions are an implementation detail, an additional safety check -- they're neither something that must be documented nor something the user can rely on. They merely catch some common mistakes in the usage.My point was more about defensive programming strategy in itself: since they are not documented the user cannot rely on them (and it would be a poor decision to rely on them if they were documented -- okay, debatable opinion but not essential here) and thus has no reasons to believe there are any assertions. Hence, he doesn't have any actual benefits in using debug binaries for SFML in the (debug) configuration for his application. (*) Therefore we don't catch more common mistakes.
I myself use assertions all over my code and find them great, and yet I would never consider adding them as part of the public API of any library I write.But why? Why are you using them yourself (out of reasons, I suppose, which bring advantages?), but not in SFML? That's something I really don't get. I mean, assertions *do a thing*, it's not like saying "I like chocolate ice cream, you like vanilla.".
Now I ask again: Would assertions benefit those who don't bother posting on the forum when they don't have a problem with SFML?Assertions only help when you *have* a problem.
If assertions aren't targeted at them, and more experienced users don't make the kind of mistakes that are caught by assertions that often, then who are they targeted at?They are targeted at everyone. Assertions increase code safety, so if things go wrong, anyone can benefit from it. Beginners and experts make mistakes.
Also, if we went ahead and added an assertion here, we would have to add them everywhere else as well to stay consistent.Sure thing. It would be part of a consistent error reporting strategy.
I'm just estimating at this point, but this is at least a few hundred lines of new code, maybe even up to or over 1000. This adds to the total maintenance cost of the library, considering that the assertions would have to be adjusted, possibly at multiple remote locations of the library any time we decide to change any pre-/post-conditions. Is this extra maintenance cost worth that little peace of mind that assertions might give us?Yep. :) For me code safety is very high up on my list of important requirements for code in general. Even if it costs effort, I'm happy to have it. It has already saved my life multiple times, which made me value it a lot more.
Like I said, there are tools that are more effective at catching programmer errors than manually maintained asserts.Yes, they are good at detecting programming errors, but they fail miserably for logic errors. Like I said before, those are the errors that are really tough to debug. If one single assert() triggers due to malicious user input, then this already paid off.
Having a tool that goes hand in hand with the toolchain you are using is much more powerful than anything a library writer could ever add to the library, that is of course if people use those tools in the first place.I think it ADDS to safety, not replaces it. You can use the tools on top.
Lastly, we mustn't forget that like everybody has already stated, assertions only have an effect in debug configurations.This is indeed a problem I can see as well. The best we could do is spending a tutorial or something that explains this.
Also, think of the people who make use of the SFML packages on Linux systems, they won't benefit from the assertions at all since the packages rarely if ever come with a debugging configuration.At least Debian-based systems all provide *-dbg packages. But in general it's an issue, yes.
All I am asking for at this point is tangible proof that the change we are going to make is actually going to be effective (and more effective than its alternatives) by benefiting more than 1% of the typical SFML user base. Everything posted up to now has failed to meet that requirement, talking around the actual point. Provide proof and I will happily concede.I'm not sure what kind of proof you are looking for. I don't think I have to prove that assertions increase code safety. And increased code safety benefits everyone. I tend to declare this as a fact. The problem of using a debug build is a big one, and the effort of adding all assertions initially is huge. But other than that, I'm not sure what I should prove.