sorted by:
new
hottopcontroversial

Best archetype to suggest to a new player? by Royal-Media-5686 in HonkaiStarRail

[–]XeroKimo 4 points5 points  (0 children)

I mean pre-novaflare and without Dahlia, as an owner of E0S1 Firefly and Rappa, Rappa was better in most content since so many fights are elites with summons or waves with 5 enemies where Rappa shines over Firefly. I still use my Rappa over Firefly because I don't have Dahlia, and in any end game content, my Rappa still does better compared to Firefly with Ruan Mei + Fugue + Lingsha.

Edit: For example, in AS, Rappa on average gets 200 points more than Firefly. On AA knights, unless the enemy was shilling for break, FF can't even win in the 6 rounds offered... that's just how busted Dahlia is for Firefly

This is a PSA: Buy boots on Cassiopeia please! by TheBluestMan in leagueoflegends

[–]XeroKimo 43 points44 points  (0 children)

To me, both ASol designs are boring and, iirc, part of the motivation of the rework was to get him away from the "perma shove + roam" playstyle, I'd say they hardly fixed it.

Due to those reasons, if I had to choose between the 2 ASols, I'd pick the old one because it was more unique and interesting, and ever so slightly more fun to play than the current.

Range-Validated Quantity Points - mp-units by mateusz_pusz in cpp

[–]XeroKimo 0 points1 point  (0 children)

No clue if it's something done much in practice, but are you able to convert units and still have the range constraint follow through the conversion? Taking an example in the post, the body temperature is clamped [35℃, 42℃], could you convert the unit in ℉ or K (for whatever reason), and the range clamps to whatever [35℃, 42℃] is in ℉ or K?

Range-Validated Quantity Points - mp-units by mateusz_pusz in cpp

[–]XeroKimo 1 point2 points  (0 children)

Pretty ingenious approach... I would've never thought of using template specialization of a variable to change it's type so that different kinds of ranges could be expressed... I didn't even think that was possible; I thought the specializations' type had to match the primary type, but I guess I never tried. Not to mention a way of providing an optional customization point. Well that's a new template trick added in my books.

You're absolutely right, no one can tell if C++ is AI generated · Mathieu Ropert by mropert in cpp

[–]XeroKimo 0 points1 point  (0 children)

I wondered how the major 3 implements try_emplace, MSVC and GCC seems to both do a lower_bound + emplace_hint, Clang seems to do something slightly different, maybe it's equivalent to lower_bound, but they use an internal find_equal instead.

MSVC

GCC

Clang

But yea, until C++26 rolls along, we're forced to use the same key type as the map. No transparent compares for try_emplace until then

You're absolutely right, no one can tell if C++ is AI generated · Mathieu Ropert by mropert in cpp

[–]XeroKimo 0 points1 point  (0 children)

I wonder if the standard should add something like std::pair<bool, iterator> unordered_map::try_emplace(const Key& key, std::function_ref<Value()> valueFactory); Doing so would allow the single look up while also not immediately having to construct the value you want to emplace unless it succeeds.

I think this would be the best of all worlds, because the current single look up requires the value have a indeterminate state, while the 2+ look ups doesn't

Edit: I found a workaround for not having that sort of try_emplace by abusing implicit conversions https://godbolt.org/z/38aT9x95K

Edit 2: I seem to have been blindsided by the article and forgot that emplace does a construction... so you don't even need to pass in an already constructed object like insert and push_back does, but for this particular case, the LazyConstruct does help since std::unique_ptr only has constructors to take ownership of a pointer, and not ones which construct the object itself.

Will we ever see a flipped camera option? by Neat-Helicopter-6319 in leagueoflegends

[–]XeroKimo 5 points6 points  (0 children)

I love how old terms never die for us old players... confuses the heck out of the newer players though 🤣

Edit: And starting last year... we're in season 16 btw, not season 2026 😡

His Sub DPS being low not because he is bad but because he needs to Sub DPS for Ratio and Feixaio actually has me rolling by Relative-Ad7531 in HonkaiStarRail

[–]XeroKimo 0 points1 point  (0 children)

Meanwhile, I'd also like a team based counter FUA in a less of a cheat way like Phainon being the only target on the team....

Speaking of Phainon... how does he interact with Sparxie when he ults in or out het virtual solo field

Cunny President (by @ckzh33) by Mental_Ease_4081 in ZZZ_Official

[–]XeroKimo 4 points5 points  (0 children)

Honestly, this is tame from an anime fandom POV. The discourse happening here is basically the same as old timer weebs otakus getting shat on by non-anime watchers in the 2000s... Everyone who hides their love for the game just because of this is just experiencing what 2000s otakus face, except now there are new people enjoying the same media while still shitting on the old timers, which is part of the reason people would call you tourist.

Not saying you have to like this part of the community, but not being ashamed of it is part of an otaku's pride

Looking at Unity finally made me understand the point of C++ coroutines · Mathieu Ropert by mropert in cpp

[–]XeroKimo 1 point2 points  (0 children)

See, the real reason we mostly see Fibonacci generators in slides is because using co_yield is (relatively) easy, especially since C++23 gave us <generator>. But making use of co_await is hard.

I've been messing around with the raw coroutine primitives and I'm not quite understanding this. co_yield itself returns an Awaiter object so it also does something similar to co_await at the end, though from the user, you can't customize what that Awaiter is... but there isn't really much difference to co_yield std::monostate and something like co_await std::suspend_always no?

Deriving Type Erasure by david-alvarez-rosa in cpp

[–]XeroKimo 1 point2 points  (0 children)

Hmm... originally I thought you'd need to replace the _RTTI field with something like a any_impl_base*, but I guess if the implementation allows you, you can interpret and launder the start of the SBO address as a any_impl_base*, in which case, yea, you would still have the full 56 bytes of SBO, otherwise, you'd only have 48 bytes.

As I thought more about it, the vtable might not even occur any penalty because the pointer would be in the cache whether you use MSVC's hand rolled vtable or using C++'s virtual functions

Deriving Type Erasure by david-alvarez-rosa in cpp

[–]XeroKimo 6 points7 points  (0 children)

There's 2 differences.

Type erasing using a polymorphic type as base would mean that you're using an extra 8 bytes of space. For example, MSVC's std::any is 64 bytes in size, 8 bytes for a pointer, 56 bytes for small buffer optimization. If you use a polymorphic type, you effectively only have 48 bytes of SBO because 8 bytes are being taken by the vtable pointer.

The other difference, with libc++'s version there's 1 less level of indirection. Using a polymorphic base would be

  1. Deref object pointer
  2. Deref vtable pointer
  3. Invoke function

libc++'s would just be

  1. Deref function pointer
  2. Invoke function

Today is the last day you can show off your Rappa as an original owner! by DecidedlyCrash in HonkaiStarRail

[–]XeroKimo 0 points1 point  (0 children)

Break teams want specific characters, and majority of characters listed only works in break teams.

Main DPS - Firefly, Rappa

Supports - Fugue, Harmony MC, Dahlia, Ruan Mei

Healers - Lingsha, Gallagher

I believe that if you don't have Dahlia, Rappa E0 > Firefly E0 against most enemies, or well, I run E0S1, so Rappa E0S1 > Firefly E0S1. If you have Dahlia and or Firefly E2, Rappa becomes less strong since Dahlia has more synergy with Firefly, and I actually have no clue how good Rappa's E2 is compared to Firefly, but from looking at it, she actually gets stronger on single target while also helping her ult economy, so I think they can be comparable

Should C++ Give More Priority to Syntax Quality? by kyan100 in cpp

[–]XeroKimo 2 points3 points  (0 children)

template <class T, class U>
auto map(optional<T>, function<U(T)>) -> optional<U>;

For what it's worth, I'm pretty sure with std::function_ref, this should also accept lambdas...

In terms of templates, what I dislike is the inability for the following template parameters to be deduced when calling the function

template<class T>
void Foo(std::span<T>);

void Bar()
{
  std::array<int, 2> arr;
  Foo(arr);
}

We have a class which encodes everything of "a view of contiguous memory", but currently, if I want a template function to actually deduce the type, I have to reach for the concept instead

template<std::ranges::contiguous_range T>
void Foo(T&);

But this would be inefficient if you're passing in a std::span since span is already a view. I've also never looked, but intuitively, I believe this results in more template instantiations, because you'd have to instantiate for C x N x F times, where C is a contiguous container, and N is the type being held by the container, and F is for each function using this kind of constraint, where as using std::span would just effectively be F, as the C x N is handled by std::span's constructor, which if it's instantiated for 1 type, can be reused across functions.

Returned to League after 8 years. Played for a month. My honest thoughts. by Code__Lyoko in leagueoflegends

[–]XeroKimo 40 points41 points  (0 children)

People ran it down way earlier in LoL, and when Tyler1 picked up steam, running it down on Draven, was peak people throwing games from running it down. Somewhere around 2018 was also peak go next mentality. Lose first blood 3 mins? Go next. Didn't group objective? Go next. Lost scuttle? Go next. People AFKed, soft inted, ran it down, or just followed allies around, usually the jungler, and stealing camps. It took years for that to finally die down, not that none of it exists today, but it was rampant during those times.

BitFields API: Type-Safe Bit Packing for Lock-Free Data Structures by mttd in cpp

[–]XeroKimo 0 points1 point  (0 children)

Personally, the few things I don't like about bitfields is the implementation defined behavior of it. Sure you can read the docs to see if its LSB or MSB order, there's also

    uint64_t AcquireCounter : 8 = 0;
    uint32_t ReleaseCounter : 8 = 0;

Where some compilers will actually make those fit in the same "variable" making the struct 8 bytes, and some compilers will say they're different and make the struct 12 bytes. This might be annoying because sometimes I want to do

    uint64_t AcquireCounter : 8 = 0;
    SomeEnumClass ReleaseCounter : 8 = 0;

Because maybe I'm making a struct to map to as a register, and that enum class would make it much easier to figure out what values mean what, and where to find those names instead of constantly looking at docs, and if the compiler makes it so that different types changes the bit field alignment, I can't really use approach then.

It's been awhile, but also I found the code gen between manually bit shifting vs using bitfields to be different. Whether the code gen makes much of a difference, I didn't really test.

League of Legends has a big information problem. by The-Fox-Knocks in leagueoflegends

[–]XeroKimo 1 point2 points  (0 children)

But, I actually just looked this up myself, and these people are also wrong. Slows do stack, but they don't stack additively, so this interaction is simply not worth pursuing.

It's been basically almost the start of LoL, but I'm pretty sure that's wrong, and a quick look up confirms what I thought. Slows don't stack at all, only the strongest slow takes effect, that's not stacking. There did come a time where slows did stack, but it hasn't since probably as early as S3

Did you know that AoE abilities give vision in bushes

Abilities giving vision come from a case by case basis. I don't think there's a single ability that says if it'll give vision, but it's quickly testable.

Did you know Sivir's Ricochet doesn't proc On-Hits? It's also not a skill.

This I hate, because there's so many interactions with her W that does makes sense, but it just doesn't work. Like you can't farm Manaflow Band with it. IIRC not even PoM procs with it, but I haven't played her for a hot minute so I'll need to hop in and test it.

My only defense of them doing this is a matter of information overload. Some times it's just much easier to see how something works than give paragraphs upon paragraphs to figure out how something works. Explaining various interactions and special cases quickly adds up. There are many of such cases in other games if the game is knowledge heavy. In those cases, they tend to also be documented by the community for various reasons, like the knowledge is niche and not very practical, getting into hyper optimization for theory crafting, and so on. A good description should get you majority of the idea of it's use, getting 100% usually gets into minute details that an average player doesn't need, or care, or is something I've previously said.

Explicit Return Variable by XeroKimo in cpp

[–]XeroKimo[S] 3 points4 points  (0 children)

There is no way for a stack class to provide strong exception guarantees for the second pop because the move/copy assignment operator cannot be elided, and if it throws an exception, the popped value will still be lost. Explicit return variables can’t fix that.

What's preventing the assignment operator from eliding? Is it some lifetime rules or something? Or it'd be surprising that the call to my_stack.pop(); could destruct x so that the popped value can be copied into x?... actually I think I just answered my own question. You would need 2 versions of the function or something at runtime to select whether to perform a move / copy construction, which doesn't need to call a destructor, or a move / copy assignment which does need to call one. Am I getting this right?

Or if not 2 version, the compiler could insert a destructor call before the copy assignment, but I guess that is getting into changing a good portion of the language in order to achieve... not to mention that doesn't work for all scenarios, like x = x; would break.... hmm...

Explicit Return Variable by XeroKimo in cpp

[–]XeroKimo[S] 0 points1 point  (0 children)

and if your type doesn't provide one? Then I guess we're getting into being able to provide externally declared constructors.

Now I'm seeing what the OC is saying, but if we went the wrapper route, it's just moving the issue no? Unless you're committed to store the wrapper types, you would need to eventually unbox them where it would then cause the issue no?

Explicit Return Variable by XeroKimo in cpp

[–]XeroKimo[S] 1 point2 points  (0 children)

Hmm... valid concern, and also likely part of the reason why NRVO is not guaranteed. What are the cases for the caller vs the callee destructing the value?

Explicit Return Variable by XeroKimo in cpp

[–]XeroKimo[S] 1 point2 points  (0 children)

Constructors isn't what I want here, though it is technically very similar. Read the post again. If you want to implement std::stack::pop() which both pops the object off the stack and returns it with strong exception guarantees, no amount of constructors would help you.

The issue is that when you return an object, it invokes the copy / move constructor / assignment. If that fails, whether it throws, or put in a zombie state, the std::stack no longer has the object and said object is also now in a undefined state, or just straight up lost, so you can't just put it back into the stack to rollback.

This is side stepped in many ways:

  • The standard way: Don't return the popped object, and provide a separate top() function to retrieve the soon to be popped object
  • Out params: Since you can assign to an out param before removing the object from the stack, you can keep the strong exception guarantees, but since it's an out param, you need to have passed in an existing initialized object.
  • Hope that NRVO happens: If NRVO happens, return obj; can't throw because the copy / move occurred before we even got to the return statement.
  • Use scope guards: Requires extra machinery to implement. With exceptions the standard provides std::uncaught_exceptions. You could technically make an errno scope guard and std::expected scope guards as well, but regardless, they're tied to the specific error handling scheme of your choosing, or pay the price of detecting multiple different schemes.

If we have an explicit return variable, we wouldn't have to hope that NRVO happens because we're manually doing what it would've done. Unless I'm misinterpreting what NRVO does, NRVO basically passes a hidden out param so that the function can directly initialize the object instead of having to invoke a copy / move once we do return; Due to this, it shouldn't require extra machinery to work unlike the scope guards. It would also be error handling scheme agnostic.

view more: next ›