| Age | Commit message (Collapse) | Author |
|---|
|
owning_ptr<T> adapts std::unique_ptr<T> to be a better drop-in replacement for
a legacy class that formerly stored plain T* data members, and explicitly
destroyed them using domain-specific destructor functions.
Directly substituting std::unique_ptr into JPEG2KEncode and JPEG2KDecode was
cumbersome because every such pointer declaration required a redundant
template parameter describing the deleter function passed into its
constructor. Moreover, it required lots of little syntax tweaks: changing
every assignment to a reset() call, changing every reference to a get() call.
Using owning_ptr<T> allows us to leave the code more or less as it was before,
save that assignment and destruction automatically handle the previous
referenced T instance.
|
|
|
|
|
|
|
|
|
|
Instead of using strdup() and free() to store comment_text in JPEG2KEncode,
store a std::string. Similarly, instead of manually managing pointers to
encoder, decoder, image, stream and codestream_info in JPEG2KDecode and
JPEG2KEncode, use std::unique_ptr for each, specifying their respective
deleter functions.
|
|
This allows removing #include "llerror.h" from llpointer.h.
Also remove #include "llmutex.h" as a heavy way to get
<boost/functional/hash.hpp>.
That requires adding #include "llmutex.h" to llimage.h, llnotifications.h,
llwatchdog.cpp and llvolumemgr.cpp, which were inheriting it from llpointer.h.
|
|
|
|
|
|
Now the lerp() in global namespace is std::lerp(), but it remains true that
for some calls to std::lerp(), MSVC issues fatal argument conversion warnings.
In those places, call flerp() (our historic lerp()) instead.
|
|
|
|
|
|
For reasons that remain unclear, MSVC likes our lerp() function better than
its own std::lerp() function: publishing the latter into the global namespace,
instead of defining our own, produces fatal argument conversion warnings.
"math.h" publishes all of <cmath> into the global namespace, which causes a
GCC conflict between std::lerp() and our lerp() function. Including <cmath>
instead leaves std::lerp() in the std namespace, eliminating the conflict.
|
|
`LLKeyData::operator==(const LLKeyData&)` and `operator!=(const LLKeyData&)`
were not themselves `const` methods. In C++20, that can produce a fatal
warning that if the compare operands were reversed, you'd get different
results. Making them both `const` should fix it.
While touching the method definitions, make `operator==()` more intuitive, and
make `operator!=()` simply negate `operator==()` instead of restating it in
reverse.
|
|
Hoist `std::lerp()` into the global namespace instead.
|
|
GCC on Linux complains that "math.h", which hoists all the standard library
math functions into the global namespace for classic C compatibility, creates
a conflict between `std::lerp()` and the `lerp()` function in llmath.h.
(Perhaps we should just replace our `lerp()` definition with `using std::lerp;`)
Anyway, bringing in <cmath> rather than "math.h" leaves standard library math
functions in the `std` namespace, avoiding the conflict.
|
|
|
|
Fix various issues with snapshot upload fee calculation
|
|
In C++20, `std::filesystem::u8path()` (that accepts a UTF-8 encoded
`std::string` and returns a `std::filesystem::path`) is deprecated. Instead,
to engage UTF-8 coding conversions, we're supposed to pass the `path`
constructor a `std::u8string`, i.e. a `std::basic_string<char8_t>`. Since
`char8_t` is a type distinct from both `char` and `unsigned char`, we must Do
Something to pass a UTF-8 encoded `std::string` into `std::filesystem::path`.
To avoid copying characters from a `std::string` into a temporary
`std::u8string` and from there into the `std::filesystem::path`, make a
`boost::transform_iterator` that accepts a `std::string_view::iterator` and
adapts it to dereference `char8_t` characters. Make `fsyspath(std::string_view)`
engage the base-class constructor accepting (iterator, iterator), adapting
`string_view::begin()` and `end()` to deliver `char8_t` characters.
Use the same tactic for `fsyspath::operator=(std::string_view)`, explicitly
calling `std::filesystem::path::assign()` with the adapted iterators.
To resolve ambiguities, provide both constructors and assignment operators
accepting `(const std::string&)` and `(const char*)`, explicitly converting
each to `std::string_view`.
At the same time, `std::filesystem::path::u8string()` now returns
`std::u8string` rather than `std::string`. Since `std::filesystem::path`
delivers only that `std::u8string` rather than iterators into its internal
representation, we can't avoid capturing it and copying to the returned
`std::string`.
Remove explicit `.u8string()` calls from a few existing `fsyspath` instances,
now that `fsyspath` supports implicit conversion to `std::string`.
|
|
"Current Window" to determine correct image size and upload cost
|
|
on previously selected snapshot type and not necessarily snapshot to inventory
|
|
image size and display upload cost to user
|
|
|
|
history with Ctrl-PgUp/PgDown (#2680)
|
|
|
|
|
|
|
|
|
|
Generalize LLPointer's comparison operators to allow comparable LLPointer types.
|
|
Given templated constructors and assignment operators, it's tempting to remove
specific constructors and assignment operators with the same LLPointer<Type>
parameters. That turns out to be a mistake. Add comments to warn future
maintainers.
|
|
This affords strong exception safety. Also, eliminating the conditional may
improve speed.
|
|
|
|
Add Lua scripts to viewer source tree
|
|
|
|
Instead of restating the whole class, requiring changes to be made in parallel
(which has already failed), just make a template alias.
|
|
That is, both `LLPointer::operator==()` and `operator!=()` and the free function
`operator==()` and `operator!=()` now accept pointer types other than the type
of the subject `LLPointer`, letting the compiler apply implicit pointer
conversions or diagnose an error.
|
|
|
|
Add Lua scripting to develop, behind feature flag
|
|
Performance improvements and cleanup in llviewerdisplay.cpp
|
|
|
|
|
|
|
|
Merge develop into release/luau-scripting
|
|
tonemapping (#2659)
Co-authored-by: Rye Cogtail <rye@lindenlab.com>
|
|
|
|
|
|
|
|
|
|
Maintenance B merges into develop
|
|
develop → Maint B sync
|
