Fast and Small C++ - When Efficiency Matters - Andreas Fertig - CppCon 2024

[@spacechild2]

That implementation of fbstring is genius!

[@Roibarkan]

56:06 Note that the libc++ implementation (slide 16, around 27:51) doesn’t have UB because the accessed field is in the initial-common-prefix of both union members- which is well defined in the standard. In the libstdc++ implementation (slide 14) the ‘unprotected’ access is actually to the address of a member which might not be the active member - and I am not sure if that’s a problem.

[@xavierthomas1980]

I think accessing the start of a union that is common to all members of the union is OK, and is not UB even when accessing the union member that is not the active one (and even for bit fields). However fbstring is definitely UB. It just happens that this UB is the expected behavior on most compilers, on most architectures with most of the combinations of compiler options. But this is not guaranteed by the standard. Edit: And when I say "I think", it means "I read the part of the standard relative to this, a long time ago, and this is what I understood".

[@Roibarkan]

32:44 Nicholas Ormrods talk: kzbin.info/www/bejne/oYG1aZtqYtaNms0

[@Roibarkan]

1:01:36 I think the commenter missed the point that mBuf (in slide 14) is a char-array that gets decayed, so the comparison “mPtr != mBuf” doesn’t access the contents of mBuf/mCapacity union. Thus, I believe there’s no value that can be placed in mCapacity that could confuse the code (assuming access to the address of an inactive union member is fine)

[@benhetland576]

Never thought of such a thing as a union member being _active_ or _inactive_ at all. I know writing to one member and reading back via another is not formally well-defined, or even UB, although in practice I've never experienced an implementation that doesn't just overlay the bytes of each member in the order each would have been stored individually (incl internal padding of structs). That makes it very predictable and useful for things like interpreting the contents of binary message blocks differently depending on context (eg. a preceding "message type" code). Which part is active/inactive is just the user's perspective (the source code being compiled), and I'm not aware of any way the compiler keeps track of that. I _believe_ it is well-defined that the (starting) address of each union member is one and the same, effectively making the _alignas_ for the whole union the same as its member with strictest requirement.

[@Roibarkan]

@@benhetland576 well, the rules for C++ do refer to active/inactive union members. I assume one reason for this has to do with classes that can have constructors and destructors, and with the "strict aliasing rules" in C++. More about ways union inactive member access in this talk by Nina Ranns kzbin.info/www/bejne/ppXShqGsidyhqJY

[@benhetland576]

Did anyone understand the question at the end? If he was referring to the libstdc++ implementation at 20:00, then I think he must be mistaken/confused. It doesn't matter what the _content_ of the union (aka mCapacity aka mBuf) is at all, only where it is located, which is somewhere inside the struct string object. *is_long()* is only checking to see if mPtr does not point to the start of mBuf (aka &mCapacity aka &mBuf[0]), which it cannot do if was allocated from _new._ Is it I or the questioner that is most confused now?

[@Roibarkan]

@@benhetland576 I think you are correct. Still I'm not sure about whether it's UB or not - but I agree with you the comparison is done with the address of the mBuf/mCapacity variable, and not the content

[@SniPat0101]

He is talking about clang and FB implementation. E.g. in fbstring, 35:00, function get_mode_byte() always accesses field from “packed.small”, even if we are using large string implementation.

[@grogan2]

All that microoptimisation makes sence just because the strings in C++ are enormously large (32 byte msvc/gcc vs 24 bytes clang). But real world string (aka string_view) fits into 16 byte structure (8 byte address and 8 byte size).

[@peterprokop]

Nice!

[@troyfrei2962]

Please try to program in Delphi. It really easier to get the job done faster. The refactoring code is very easy to do. If you use the Delphi, it is easier to read and refactoring code for reading.

[@WndSks]

Excellent topic

[@dexterman6361]

Really interesting stuff. Thank you! 49:44: I don't understand this part. Since the list is declared const, it cannot change at runtime. So even when recursing, the members of that list can never change right, since they're not initialized at runtime either? Why can't they all be optimized into the same memory? Is it just the standard that forcing this behavior even for const stuff, even though logically it can all be the same memory? Also I cannot understand why the C++ committee just doesn't break the ABI once and for all. constexpr all the things, const all the things. And SO many other improvements (await instead of co_await!) we can make to the language. I love using C++ especially with featureset around 26 but c'mon, but all this baggage seems so wasteful.

[@СергейФёдоров-щ8ш]

I would do it like clang of course, but "string size" of 64 bits is not always reasonable (here you can save more bits)

[@TheSlazzo]

and when I have a union { float x, y, z; float r, g, b; } suddenly I'm the bad guy

[@a.n.t.i.p.o.p]

have no idea why do you need to mix it like that, but in that case imo, std::variant would be a better choice in any aspect (if you have c++17 ofc).

[@antagonista8122]

​​​​​@@a.n.t.i.p.o.pstd::variant has nothing to do with anonymous union trick/hack some linear algebra libraries use to provide alternate representation/naming e.g. Vec3 fields accessible through r, g, b or x, y, z fields or 3-element array

[@artemmartus4253]

We’ve got Cpp people still inventing ‘string’ instead of doing the actual work in 2024 Q4

[@benhetland576]

Reinventing std::string is just such a fun and satisfying thing to do!

[@TanzinulIslam]

Not inventing, it's rather optimizing. It's an iterative process of discovery and development.

[@thev01d12]

Actual work? You prolly do web dev

[@Salehalanazi-7]

Agreed cpp is dead. And all the low level people are deadweight on departments

[@Dziaji]

@@Salehalanazi-7 tell me you don't know what you are talking about without saying you don't know what you are talking about.