------- Comment #5 from piotr dot wyderski at gmail dot com 2009-12-21 14:27
-------
(In reply to comment #4)
> Certainly *is* a problem if we hope to debug the issue decently fast...
>
I meant "the cause of the problem is in its size", i.e.
there must be a critical mass of templates to trigger
the issue. There probably is no problem in std::unique_ptr
on its own; to me it seems to be a "random victim" of
something strange happening under the hood. As I said,
I am not able to shrink it down in a reasonable way.
For example, this simplified testcase compiles flawlessly:
#include <memory>
struct release_deleter {
template <class T> void operator()(T* p) {
static_assert(std::is_pod<T>::value ||
std::is_same<T, void>::value,
"T must be a POD type or void");
}
};
template <typename T> class dynamic_dispatch;
template <
typename TC,
typename TR,
typename TD,
typename... TA
> class dynamic_dispatch<TR (TC::*)(TD&, TA...)> {
class entry {};
typedef std::unique_ptr<entry[], release_deleter> entry_ptr;
public:
template <typename UC, typename UD> void attach_handler(TR
(UC::*m)(UD&, TA...));
};
template <
typename TC,
typename TR,
typename TD,
typename... TA
> template <
typename UC,
typename UD
> void dynamic_dispatch<TR (TC::*)(TD&, TA...)>::attach_handler(TR
(UC::*m)(UD&, TA...)) {
};
class C {
public:
void M(int&);
};
dynamic_dispatch<void (C::*)(int&)> dd;
int main() {
dd.attach_handler(&C::M);
}
But the problem is definitely related to template
processing. If you comment out the folowing line
(at the very bottom of the attached file, in the
constructor):
attach_handler(static_cast<void (file_reader::*)(read_request<0>&)>
(&file_reader::execute_command));
it compiles OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
