ipv6 address must be specifid surrounded by [], like [ipv6_address]:port,
since otherwise impossible to disambiguate colons separating ipv6 quads
from the colon delimiting port
This is no longer needed with the compilers we support. It is needed on VS 2013, but
we dropped that. Don't know when GCC or Clang stopped needed it (if they ever did).
I'm guessing the "function that returns a value cannot be bound in a function type
that returns void" behavior wasn't an intentional design. Additionally, I don't believe
point 1 raised in the accompanying comment has ever been true... if so, pretty sure
we wouldn't have been able to build at all.
Also removed unnecessary global.hpp include from functional.hpp.
(cherry-picked from commit 17fc9d71db)
This changes:
utf8::char_t -> char
utf8::string -> std::string
utf16::char_t -> char16_t
utf16::string -> std::u16string
ucs4::char_t -> char32_t
ucs4::string -> std::u32string
utf16::string and ucs4::string are now proper strings instead of vectors of characters too.
In order to get this change to compile at all, I needed to add a ucs4_convert_impl::convert_impl
specialization for wchar_t alongside the new char16_t specialization; both point to the same
conversion implementation type.
This commit doesn't do any additional cleanup. I'm sure if we looked, we could get rid of a
lot of the custom conversion code and probably a bunch of stuff that might have had to do with
supporting utf16::string and ucs4::string being vectors instead of basic_string specializations.
Either way, I don't know the code (or encoding handling in general) to make a call as to what's
needed or not. I'll let someone else do that.
(cherry-picked from commit 1deacd89f6)
This completely removes the wrappers for aliases included in c++14. It also enables
use of the value alias wrappers, since we now have variable templates.
(cherry-picked from commit c1fcba17b7)
Partial revert of commit ecbb15e1c6.
Replacing bounded_add() with std::clamp() in these contexts disables
time-of-day bonuses, since ToD bonuses (the base value in these functions)
are almost always outside the range set in terrain properties.
* Dropped bounded_add for clamp. There's a slight behavior change with this, namely that
base is no longer returned if it falls outside the bounds. However, for both usecases of
bounded_add, that behavior doesn't make sense. The wiki clearly states min/max_light=
define the bounds for light=.
* Replaced gcd with Boost's gcd function. We already use the latter in the Preferences
dialog, so this is more consistent.
* Simplified the implementation of in_ranges.
__builtin_expect is something that should only be used if you're very sure it will result in
an optimization (see http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html).
This code was added back in 2008. It seems it was part of an effort to get the preprocessor
functioning faster. It looks like mordante played some role in the decision of where to use
the LIKELY and UNLIKELY macros, so it's possible it had some use at the time (he's a rather
experienced programmer).
However, it's better to let the compiler automatically optimize code itself. I haven't done
any profiling on the preprocessor speed with or without __builtin_expect, but it doesn't seem
worth keeping this around and having to test every so often whether it's still useful or has
become a performance hit instead.
It's also worth noting that I myself noticed what seems a perceptible performance improvement
in the game (again, not backed by profiling) when I switched from TDM GCC to MSVC 2017. IIRC,
I'm using at least quick LTO for my builds. Apples and oranges, yes, but it also proves there
are likely various compiler options (such as LTO) which could improve performance on their own,
and better, than trying to point the program down branch paths ourselves.
This throws out the custom smart_list class in favor of a plain std::list. It also greatly simplifies
a few things. First, event handlers no longer remove themselves from the main list in event_handlers.
Now they just flag themselves as disabled (which means they will never execute once marked) and cleaned
up later in a newly added cleanup stage. This means a handler no longer needs to keep its index in the
active handler vector.
This removal of reliance on indices also means I could add the aforementioned cleanup stage. With the
smart_list code, event handlers were never actually removed from the active vector, nor any weak_ptrs
pointing to them removed either. This wasn't exactly a problem, since the handlers were stored via
shared_ptrs which would then simply be null after one deleted itself. Still, it's cleaner to drop any
invalid ones (and unlockable weak_ptrs) from any relevant containers. I've opted to do this in
manager::execute_on_events. Seems a good enough place as any.
The net result of this is the code is much cleaner. We're able to get rid of a bunch of unnecessary
feelers into various classes. This also makes the manager::iteration dereference code a lot easier
to understand. There certainly could be further refactoring, but I think this is a good start.
1) We now use a single function to set slider min/max value, this fixes#1641
(sliders having a temporary invalid (min > max) state between set_min() and
set_max() calls)
2) I split the sliders_base class from the scrollbar_base class to not
accidently break the rather complicated scrollbar_base class while
refactoring sliders.
3) We don't use floats in the slider code to make sure no rounding errors happen.
4) This fixes#1539 by removing slider::in_orthoginal (which made it impossible
to pull a slider to its maximum/minimum) and intead clamping the mouse
position in range.
5) This fixes#1656 and #1767 by refactoriung code (that bug happend mainly
because the old code used variables that contained the position in 'steps'
as pixel position and vice versa)
6) Sliders now 'snap' to the correct values just like the gui1 sliders did.
7) Slider positions are now poperly rounded to its neariest values
instead of just beeing 'floored'
First, VS2015 doesn't appear to support importing alias templates directly,
so let's make an alias template ourselves and import every alias we need.
That approach doesn't work with VS2013, apparently due to lack of support
for expression SFINAE. Thus, we now use our custom alias templates on
VS2013.
Also, I moved type_trait_aliases.hpp to the wesnothlib project where it
belongs.
Note that because of requiring expression SFINAE on VS2015, building
Wesnoth on VS2015 now requires that Update 1 or above is installed.
[ci skip]
I ran the command used in 9b7b1751fd, excluding results in lua/ and spirit_po/.
Also, once again, for some reason actions/vision.hpp gets registered as massively changed
(similar to f11fa0652a) despite nothing really having changed at all.
* Apparently, even VS 2013 includes the general type alias templates. Allow their use there.
* Removed broken C++11 value alias templates (values aren't even allowed this fashion).
* VS 2015 Update 2 apparently both introduced support for variable templates and added them for type traits. Updated accordingly.
* Blocked off the entire variable template section until we bump out min compiler version, since there's no way to implement
them without variable templates.
Turns out 'inline constexpr' is a C++17 feature. Fallback to 'static constexpr' with C++14,
except with VS < 2017, where variable templates are not supported.
