UmbralRaptor changed the topic of #kspacademia to: https://gist.github.com/pdn4kd/164b9b85435d87afbec0c3a7e69d3e6d | Dogs are cats. Spiders are cat interferometers. | Космизм сегодня! | Document well, for tomorrow you may get mauled by a ネコバス. | <UmbralRaptor> egg|nomz|egg: generally if your eyes are dewing over, that's not the weather. | <ferram4> I shall beat my problems to death with an engineer. | We can haz pdf
egg|laptop|egg has quit [Remote host closed the connection]
<catalograptop>
WeylandsWings: compiling data from a few catalogs for more simulations
e_14159_ has joined #kspacademia
e_14159 has quit [Ping timeout: 378 seconds]
<egg|cell|egg>
Are you going to compile a new catalog
<galois>
egg|upstairs|egg meant to say: (nobody does that thankfully, all implementations treat it as a byte)
<egg|upstairs|egg>
whitequark: I think unions can type pun in C but not in C++, but to my knowledge nobody exploits that in C++ yet
<egg|upstairs|egg>
whitequark: note of course that, because memcpy is the mechanism to say "this is aliased" rather than "I want to copy stuff", it almost always gets compiled away
<whitequark>
I can't copy
<egg|upstairs|egg>
much like inline doesn't mean inline, memcpy doesn't mean copy
<egg|upstairs|egg>
:-p
<whitequark>
the converted pointer ends up passed via FFI
<whitequark>
whcih is the whole point of converting it
<galois>
[WIKIPEDIA] Forces françaises de l'intérieur | "Les Forces françaises de l'intérieur (FFI) sont le résultat de la fusion, au 1er février 1944, des principaux groupements militaires de la Résistance intérieure française qui s'étaient constitués dans la France occupée : l'Armée secrète (AS, gaulliste, regroupant Combat, Libération-Sud, Franc-Tireur…"
<egg|upstairs|egg>
so you are interchanging the pointer across languages?
<whitequark>
yeah, from c++ to c, or anything that speaks c abi
<whitequark>
that's why it's standard-layout
<egg|upstairs|egg>
yeah at that point I think you are reaching outside what the C++ standard talks about anyway
<whitequark>
but the code that exports a c api is in c++
<egg|upstairs|egg>
hm
<whitequark>
so i'm doing the conversion there
<egg|upstairs|egg>
I'm mildly confused tbh, why do you need two layout-equivalent types in the C++ side then
<whitequark>
well, one of them comes from the c++ header (which has constructors and can't be parsed by a c compiler), and another comes from the c header (which can)
<egg|upstairs|egg>
hm
<egg|upstairs|egg>
and why do you need them to not be copied?
<egg|upstairs|egg>
(i.e., what is the intended lifecycle of the objects around all those calls)
<whitequark>
because the function that does the conversion returns a pointer with the same lifetime as the pointer it takes
<egg|upstairs|egg>
I don't really understand the broader context; what happens to the C object from the boundaries of the C ABI here
<whitequark>
the API looks more or less like this:
<whitequark>
void do_something(struct c_layout_container *container) { /* do something with container->things[..].a */ }
<whitequark>
the C code will call get_thing(), manipulate thing->a, then call do_something()
<whitequark>
which will presumably do something else with thing->a.
<egg|upstairs|egg>
OK so then the vector has to be a vector of the actual C layout things, not their C++ alias
<whitequark>
yeah and i don't want that.
<whitequark>
because i want the c_layout_thing to have a constructor, which can't be a part of the c header
<egg|upstairs|egg>
hmm
<egg|upstairs|egg>
you could do horrible ifdef things to remove the constructor if you are looking at the header in C
<whitequark>
i have a completely separate header for c
<whitequark>
for a few reasons, one of them being that c enums can't have storage type specified
<whitequark>
so on the c++ side i have a `enum x : uint32_t` and on the c side i have a `uint32_t` and then a separate `enum x` for the values
raptop has joined #kspacademia
egg|cell|egg has quit [Ping timeout: 378 seconds]
<whitequark>
i guess i could... inehrit from the c thing
<egg|upstairs|egg>
yeah that could work I think?
<egg|upstairs|egg>
The other option is definitely UB; some UBs are worse than other, but I think this is a UB that actually gets used by most compilers (I am having trouble godbolting my way to an example but that mostly says that I suck at this rather than that reinterpret_cast is being treated specially by the compiler)
egg|upstairs|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #kspacademia
egg|upstairs|egg has joined #kspacademia
<whitequark>
mhm
egg|upstairs|egg has quit [Read error: Connection reset by peer]
<raptop>
"Description of some particular keywords" why would the readme file with your data table not include descriptions of all keywords used?
<kmath>
<cvtsi2sd> @whitequark Besides, the Rules already allow to use these two types interchangeably in an union as they share a "co… https://t.co/MsCONr4OmC
<egg|upstairs|egg>
(though in practice C++ implementations tend to not use the UBness of union punning if I remember Regehr’s post correctly)
<egg|upstairs|egg>
cppreference says "Note that many C++ compilers relax this rule, as a non-standard language extension, to allow wrong-type access through the inactive member of a union (such access is not undefined in C)."