The same is done for `Vector` (and thus `Packed*Array`).
`begin` and `end` can now take any value and will be clamped to
`[-size(), size()]`. Negative values are a shorthand for indexing the array
from the last element upward.
`end` is given a default `INT_MAX` value (which will be clamped to `size()`)
so that the `end` parameter can be omitted to go from `begin` to the max size
of the array.
This makes `slice` works similarly to numpy's and JavaScript's.
Each file in Godot has had multiple contributors who co-authored it over the
years, and the information of who was the original person to create that file
is not very relevant, especially when used so inconsistently.
`git blame` is a much better way to know who initially authored or later
modified a given chunk of code, and most IDEs now have good integration to
show this information.
We prefer to prevent using chained assignment (`T a = b = c = T();`) as this
can lead to confusing code and subtle bugs.
According to https://en.wikipedia.org/wiki/Assignment_operator_(C%2B%2B), C++
allows any arbitrary return type, so this is standard compliant.
This could be re-assessed if/when we have an actual need for a behavior more
akin to that of the C++ STL, for now this PR simply changes a handful of
cases which were inconsistent with the rest of the codebase (`void` return
type was already the most common case prior to this commit).
Some platforms (*cough* web *cough*) have hard limits on the number of
threads that can be spawned.
Currently, ThreadPoolWork (mostly used in rendering/physics servers)
will spawn as many threads as CPUs available causing exception on
machines with high CPU count.
This commit adds a new overridable method to OS that returns the default
thread pool size (still the CPU count by default), and overrides it for
the JavaScript platform so it always allocate only one thread.
We can likely improve the whole ThreadPoolWork in the future to always
allocate X amount of threads, and assign jobs to them on the fly, but
that will require some more architectural changes.
`#pragma once` was used in a few files, yet we settled on using
traditional include guards instead.
The PooledList template comment was also moved to allow editors
such as Visual Studio Code to display the comment when hovering
PooledList.
`app.h` was renamed to `app_uwp.h` to be less generic for the
include guard.
On latest (11.1 as of this commit) GCC, the following warning is
continuously issued during build:
warning: placement new constructing an object of type
'SafeNumeric<unsigned int>' and size '4' in a region of type
'uint32_t*' {aka 'unsigned int*'} and size '0' [-Wplacement-new=]
This happens because on 98ceb60eb4 the new operator override used
was dropped and replaced with standard placement new. GCC sees the
subtraction from the pointer and complains as it thinks that the
SafeNumeric is placed outside an allocation, not knowing that the
address requested is already inside one.
After suggestions, the false positive is silenced, with no other
changes.
The constructor was expecting a mutable pointer, while the passed pointer was immutable ( returns a const pointer), so the compilation was failing when iterating a constant .
It uses the (`const T &&... p_args`) forward reference, to avoid copying the
memory in case it's an rvalue, or pass a reference in case it's an lvalue.
This is an example:
```c++
PagedAllocator<btShapeBox> box_allocator;
btShapeBox* box = box_allocator.alloc( btVector3(1.0, 1.0, 1.0) );
```
With this commit the macro `memnew_placement` uses the standard memory
placement syntax: `new (mem) TheClass()`, and removes the outdated and
not used syntax:
```
_ALWAYS_INLINE_ void *operator new(size_t p_size, void *p_pointer, size_t check, const char *p_description) {
```
Thanks to this change, the function `memnew_placement` call is compatible with
any class, and can also initialize classes with non-empty constructor:
```
// This is valid, like before.
memnew_placement(mem, Variant);
// This works too:
memnew_placement(mem, Variant(123));
```
Found via `codespell -q 3 -S ./thirdparty,*.po,./DONORS.md -L ackward,ang,ans,ba,beng,cas,childs,childrens,dof,doubleclick,fave,findn,hist,inout,leapyear,lod,nd,numer,ois,ony,paket,seeked,sinc,switchs,te,uint`
The `Math_INF` and `Math_NAN` defines were just aliases for those
constants, so we might as well use them directly.
Some portions of the code were already using `INFINITY` directly.
This PR implements range iterators in the base containers (Vector, Map, List, Pair Set).
Given several of these data structures will be replaced by more efficient versions, having a common iterator API will make this simpler.
Iterating can be done as follows (examples):
```C++
//Vector<String>
for(const String& I: vector) {
}
//List<String>
for(const String& I: list) {
}
//Map<String,int>
for(const KeyValue<String,int>&I : map) {
print_line("key: "+I.key+" value: "+itos(I.value));
}
//if intending to write the elements, reference can be used
//Map<String,int>
for(KeyValue<String,int>& I: map) {
I.value = 25;
//this will fail because key is always const
//I.key = "hello"
}
```
The containers are (for now) not STL compatible, since this would mean changing how they work internally (STL uses a special head/tail allocation for end(), while Godot Map/Set/List do not).
The idea is to change the Godot versions to be more compatible with STL, but this will happen after conversion to new iterators have taken place.
Vector handles this silently by returning -1, and we should do the same here.
Otherwise we get errors when calling `find()` on e.g. a LocalVector of size 0,
while `find()` is expected to always work (if the parameters are invalid then
it doesn't find anything, so -1).
Fixup to #49925.
