dlib::matrix : expression template temporary objects : use std::shared_ptr ?

[pfeatherstone]

It's my understanding that the expression template engine stores temporary objects as normal value types. That means you can't store a sub-expression using auto keyword since you would get dangling references to destroyed objects.

How about we store temporary objects with std::shared_ptr ?
This means you would be able to store expressions using auto. Now I realise this may be bad practice bad I would like to do something like this:

template <class T>
auto mat (const circular_buffer<T>& m)
{
    return join_cols(mat(m.data.data() + offset, m.data.size() - m.offset),
                     mat(m.data.data(),          m.offset));
}

Currently this is illegal but using shared_ptr under the hood would be fine.
This makes writing custom expression templates more composable in my opinion because you can refactor recurring expressions into sub-expressions without having to write it out manually every time you use it or having to write a custom matrix_op object.

[pfeatherstone]

Side note, this refers to the whole discussion about optimizing dot products on circular buffers. If there were a specialisation of dot() on joined columns, then doing what's suggested above would get optimized in that way.

[davisking]

That would require every operation do a dynamic allocation though, which would slow them down a ton.

[davisking]

Oh yeah, you can totally write a function for that. Just do like http://dlib.net/matrix_expressions_ex.cpp.html notes and it will be optimal. I thought you were asking about a way to do it with less template magic. Don't know how to get less template magic 🤷 It's not that much template magic though.

[pfeatherstone]

Yeah, ideally i don't want to write matrix_op stuff. I just want to write:

template <class T>
auto mat (const circular_buffer<T>& m)
{
    return join_cols(mat(m.data.data() + offset, m.data.size() - m.offset),
                     mat(m.data.data(),          m.offset));
}

If this were possible, a whole bunch of other stuff would get simpler and compose better in my opinion. Right now, I would have to write my own custom fused join_cols + mat operation.

[pfeatherstone]

This is why I suggested using shared_ptr<> to store and track "references" to temporary objects. That way writing the above would work because the returned expression would still have shared_ptrs to the temp objects and only get deallocated when they needed to. I wonder if the compiler can "see through" all the shared_ptr stuff and optimize it away too...

[pfeatherstone]

Tried on compiler explorer. Even with an up-to-date compiler and latest standard, it can't optimize away std::shared_ptr. That's crazy. It can optimize away std::unique_ptr but that's no good to us.

[davisking]

Right, that would be nice. I don't see a way to do it though that doesn't result in much slower runtime code 🤷