u/wandering_platypator

Hey!

By overriding the operator new in the promise_type in coroutines you can apparently use your own allocator - there is a pigweed blog on this somewhere. However, if you wanted to use coroutines in embedded with async runtime kinda like embassy in rust instead of an RTOS I want to understand how you “tame” the heap allocation to make it more deterministic.

I am not super familiar with this area….apparently there is no way to get the coroutines size at compile time. In embedded you might wanna make your own pool allocator. For this and not to waste memory it would be good to know the size of the coroutines frames exactly if they are allocator allocated.

So do you introduce a build script for your projects that compiles and records the sizes of the coroutines when they call new with a logger compiled in? Without guessing is this literally the professional way to get some level of certainty? It feels kinda crude :(

There was an open std pdf on getting some decent compile time failure if they exceed a size but as far as I can tell it was never implemented (maybe I am being dumb?) P1365r0.pdf

Hello! Not the most experienced Cpp programmer.

What I think I understand:

I have watched a load of talks on start_lifetime_as. I understand it is a way to prevent undefined behaviour, I understand that it does nothing at runtime, I understand it signals to the compiler that a lifetime (in the abstract machine Cpp is specified against) has begun in the given storage. I understand that if you type pun by, say, receiving from a (say) “FreeRTOS queue” (copying bytes between threads ) or over a network into a properly aligned byte buffer to place a trivially copyable type T’s byte representation in there and T is implicit lifetime type then you can use start_lifetime_as to indicate to the compiler that a lifetime was begun there. My understanding is that this prevents UB and presumably the possibility of weird behaviour.

What I do not understand:

All the talks I have seen and docs I have read focus entirely on this being undefined if you do not start_lifetime_as when type punning in the situation described above. They point out it is UB and then show ways around it…but…I cannot find a single example of what a compiler might wrongly optimize if you do not do this anywhere? Apparently most compilers support this unofficial “idiom” but can someone to whom Compiler optimisations are less of a black box explain to me incorrect assumptions a compiler might ACTUALLY make if I tried to type pun as above without start_lifetime_as? Like, what might ACTUALLY be optimized wrongfully?

Thanks, have been tearing hair out over this!