Leo Izen: > > On 8/30/22 15:37, Nicolas George wrote: >> Leo Izen (12022-08-30): >>> Is there a reason this is AVWriter wr = foo() and not AVWriter *wr = >>> foo()? >>> Most other APIs return pointers to structs, rather than structs >>> themselves >>> (see: av_packet_alloc). Using a pointer would prevent us from having >>> sizeof(AVWriter) as part of the ABI, as was done with AVPacket. >> >> Yes: to return a pointer, you need somewhere to store the structure. One >> of the point of AVWriter is that you can store it on the stack to avoid >> dynamic allocations when the string is short enough. >> >> Note that AVWriter is exactly two pointers. It will always be two >> pointers, and all the objects that I intend to introduce later will >> always be two pointers: one const pointer for the methods, one pointer >> for the object itself. >> >> This design is essential to the features I promised for AVWriter and for >> later. >> > > I don't see how you are planning on avoiding dynamic allocations by > stack-allocating AVWriter when AVWriter itself only contains two pointers. > > I also don't see how this design is essential to the features you > promised in a way that can't be done by just not making sizeof(AVWriter) > part of the ABI and returning pointers to a struct. >
He is not only stack-allocating AVWriter, he also intends to stack-allocate the actual writers like AVDynbufWriter, AVBufWriter (AVWriter is just a wrapper around the underlying writers). This means that no allocations need to be performed for AVBufWriter at all (and due to the inherent small-string optimization of an AVBPrint, it can also be avoided for AVDynbufWriter in lots of cases). If you return pointers to an AVWriter struct, you need to allocate this struct somewhere, which means that your init/av_dynbuf_writer_wrap has an allocation that can fail and therefore needs to be checked; and the struct needs to be freed lateron. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
