Not available on GLES2, similar to BufferAttachment but with the added
constraint that WebGL1 doesn't support invalidating attachments at all.
Not adding this for DefaultFramebuffer since that takes different target
values, and GL_DEPTH_STENCIL is not one of them.
This makes it possible to conveniently do things like
Containers::StridedArrayView1D<Float> array = …;
Vector4 vector{NoInit};
Utility::copy(array, vector); // or the other way around
which is especially useful together with the new JSON classes. In some
cases this means the function is no longer constexpr, but those weren't
constexpr because it was useful for anything, they were only because it
was possible. So this breakage shouldn't do any harm I think.
Certain Clang-based IDEs (CLion) "emulate" a compiler by inheriting all
its defines, which means one gets __clang__ defined but also __GNUC__
set to 11 or whatever, breaking all these assumptions.
While branching on a compiler is rather common, checking a particular
compiler version should be needed only rarely. Thus minimize use of such
macros to make them easier to grep for.
Yay, I can abuse/reuse the features I had to add to flextGL because of
GOOGLE!!!, and with only one additional patch to support local xml
files I can very conveniently include whatever entrypoints I need.
I realized those are too annoying when writing a glTF exporter which
contains a lot of switches over enums. And as further shown by the diff,
those were only inflicting additional pain in *all* switch statements,
nothing else, no other added value. And everywhere else the helpers are
the designated way to deal with those, so there's no point in having an
explicit enum value denoting start of a "custom range".
It wasn't even any convenient to have it in the enum, as the extra
effort needed for casting actually made it *exactly* the same length as
if I'd just use a separately-defined constant.
Like, it's a *debug printer*, why an inline call would matter in there.
Or maybe it's that the debug printer was done way earlier than the
helpers? ... and then copied, without a brain attached to my head, from
MeshData to the new SceneData?
Until now, these were only transitively tested in concrete plugin
implementations, meaning that if the base implementation would have an
error (such as accessing a null optional), it would only get discovered
when building a plugin, worst case a plugin in a completely different
repo.
Here the benefit is especially clear -- as Containers::Pair is trivially
copyable with trivial types, all growable arrays can make use of
std::realloc() while with the STL variant a silly constructor, copy
constructor, destructor had to be used.
Additionally, we no longer need to take explicit care of libc++ and MSVC
STL where returning a std::pair<bool, Containers::String> as
return {{}, Containers::String{..., <deleter>}};
would caused an unnecessary copy instead of a move, losing the custom
deleter in the process. Yay!
There's a <Corrade/Containers/PairStl.h> include for backwards
compatibility purposes, but obviously it would only work for the return
type of validate*() and cases where an initializer list was passed to a
list-of-pairs-taking functions, and not a concretely typed ArrayView.
Those functions were though mostly the linker API which isn't
implemented by any plugin yet, so it shouldn't be *that* breaking to
users. Neverteless, I'm trying to do this breaking change rather sooner
than later to prevent pain further down the road when the Vulkan APIs
and SPIR-V pipeline gets widely used.
Consistently with changes done to Utility::Path, this enforces proper
error handling on user side. Originally I didn't want to do this and
instead wanted to have a special Array instance devoted for an error
state, but that still would allow the error state be errorneously
treated as a successful but empty array.
It's more useful if the Error class is directly referenced than saying
just "error output" -- so people can grab it, redirect it, etc. Also
drop the useless "does what it is expected to do on success" sentences
that add no value whatsoever.
Pablo Escobar