viewer.git/indra/test/llevents_tut.cpp, branch 26.1.1

#5078 Replace boost::assign usage with modern c++ brace initialization

2025-12-01T10:48:07Z

Signed-off-by: Rye

Clean up boost includes and remove compiler warning pragma for unreachable code in PCH (#2361)

2024-08-20T15:41:48Z

#824 Process source files in bulk: replace tabs with spaces, convert CRLF to LF, and trim trailing whitespaces as needed

2024-04-29T04:56:09Z

replace boost library to standard

2024-01-08T21:29:21Z

DRTVWR-476: Kill LLEventQueue, per-frame LLEventPump::flush() calls.

2020-03-25T22:58:16Z

No one uses LLEventQueue to defer posted events until the next mainloop tick -- and with LLCoros moving to Boost.Fiber, cross-coroutine event posting works that way anyway, making LLEventQueue pretty unnecessary. The static RegisterFlush instance in llevents.cpp was used to call LLEventPumps::flush() once per mainloop tick, which in turn called flush() on every registered LLEventPump. But the only reason for that mechanism was to support LLEventQueue. In fact, when LLEventMailDrop overrode its flush() method for something quite different, it was startling to find that the new flush() override was being called once per frame -- which caused at least one fairly mysterious bug. Remove RegisterFlush. Both LLEventPumps::flush() and LLEventPump::flush() remain for now, though intended usage is unclear. Eliminating LLEventQueue means we must at least repurpose LLEventPumps::mQueueNames, a map intended to make LLEventPumps::obtain() instantiate an LLEventQueue rather than the default LLEventPump. Replace it with mFactories, a map from desired instance name to a callable returning LLEventPump*. New map initialization syntax plus lambda support allows us to populate that map at compile time with little lambdas returning the correct subclass instance. Similarly, LLLeapListener::newpump() used to check the ["type"] entry in the LLSD request specifically for "LLEventQueue". Introduce another such map in llleaplistener.cpp for potential future extensibility. Eliminate the LLEventQueue-specific test.

DRTVWR-476: Remove special case for listen(boost::bind(weak_ptr)).

2020-03-25T22:52:11Z

LLEventDetail::visit_and_connect() promised special treatment for the specific case when an LLEventPump::listen() listener was composed of (possibly nested) boost::bind() objects storing boost::weak_ptr values -- specifically boost::bind() rather than std::bind or lambdas, specifically boost::weak_ptr rather than std::weak_ptr. Outside of self-tests, it does not appear that anyone actually uses that support. There is good reason not to: it's a silent side effect of a complicated compile-time inspection that could be silently derailed by use of std::bind() or a lambda or a std::weak_ptr. Can you be sure you've engaged that promise? How? A more robust guarantee can be achieved by storing an LLTempBoundConnection in the transient object itself. When the object is destroyed, the listener is disconnected. Normal C++ rules around object destruction guarantee it. This idiom is widely used. There are a couple good reasons to remove the visit_and_connect() machinery: * boost::bind() and boost::weak_ptr do not constitute the wave of the future. Preferring those constructs to lambdas and std::weak_ptr penalizes new code, whether by silently failing or by discouraging use of modern idioms. * The visit_and_connect() machinery was always complicated, and apparently never very robust. Most of its promised features have been commented out over the years. Making the code base simpler, clearer and more maintainable is always a useful effect. LLEventDetail::visit_and_connect() was also used by the four LLNotificationChannelBase::connectMumble() methods. Streamline those as well. Of course, remove related test code.

DRTVWR-476: Remove llwrap(), LLListenerWrapper[Base] and support.

2020-03-25T22:52:11Z

The only usage of any of this was in test code.

DRTVWR-493: Introduce test catch_what(), catch_llerrs() functions.

2019-08-11T00:33:59Z

Use them in place of awkward try/catch test boilerplate.

remove execute permission from many files that should not have it

2015-11-10T14:48:56Z

Fix Xcode 6 compile errors relating to tut::ensure_equals() overloads.

2014-10-23T15:44:42Z

lltut.h declares a number of ensure_equals() overloads for various data types, notably the types supported by LLSD. We expect these to be called by tut code. But the tut code in question is in a template in tut.hpp -- which was #included BEFORE the overloads were declared. Previous C++ compilers have evidently made multiple passes, collecting the relevant overloads before attempting to compile the template bodies. clang does not, complaining that the overloads must be declared before the tut.hpp template code that references them. Reordering parts of lltut.h seems to address that problem. For similar reasons, test programs that use StringVec.h and its operator<<() must #include StringVec.h before lltut.h. Add ensure_equals(const std::string&, const LLSD::Binary&, const LLSD::Binary&) overload. The sloppy mix of (const char*, ...) and (const std::string&, ...) overloads bothers me, since for many of those ... types we seem to have to duplicate them.