Date: Thu, 22 Jan 2026 22:56:01 +0000
On Thu, Jan 22, 2026 at 3:48 PM Frederick Virchanza Gotham wrote:
>
> For some reason, the C++ Standard necessitates that a class have a
> non-trivial destructor in order to be trivially copyable but I'm not
> on board with that, so I'm removing that requirement.
I've been searching for a few hours and I can't find one example of a
class that has a default copy constructor and a non-trivial
destructor. Not even one. ChatGPT gave me a few examples along the
lines of:
struct Owning {
int* p;
Owning() : p(new int(1)) {}
~Owning() { delete p; }
Owning(Owning const&) = default;
};
struct F {
std::FILE* f;
~F() { if (f) std::fclose(f); }
};
but of course there is a bug in both of the above classes. The bug is
that the copy-constructor doesn't copy the resource (or increment a
reference counter for the resource).
Perhaps if we were doing debugging, we could have a default
copy-constructor and then do some debug printing in the destructor,
but this debug printing in the destructor should have no influence on
whether or not the class is deemed to be trivially copyable.
I do not see the logic in why the committee decided that a trivially
copyable type must have a trivial destructor, and so unless someone
can convince me of otherwise, my new trait
"is_trivially_copyable_in_reality" will disregard destructors
altogether.
>
> For some reason, the C++ Standard necessitates that a class have a
> non-trivial destructor in order to be trivially copyable but I'm not
> on board with that, so I'm removing that requirement.
I've been searching for a few hours and I can't find one example of a
class that has a default copy constructor and a non-trivial
destructor. Not even one. ChatGPT gave me a few examples along the
lines of:
struct Owning {
int* p;
Owning() : p(new int(1)) {}
~Owning() { delete p; }
Owning(Owning const&) = default;
};
struct F {
std::FILE* f;
~F() { if (f) std::fclose(f); }
};
but of course there is a bug in both of the above classes. The bug is
that the copy-constructor doesn't copy the resource (or increment a
reference counter for the resource).
Perhaps if we were doing debugging, we could have a default
copy-constructor and then do some debug printing in the destructor,
but this debug printing in the destructor should have no influence on
whether or not the class is deemed to be trivially copyable.
I do not see the logic in why the committee decided that a trivially
copyable type must have a trivial destructor, and so unless someone
can convince me of otherwise, my new trait
"is_trivially_copyable_in_reality" will disregard destructors
altogether.
Received on 2026-01-22 22:55:07
