On Saturday, 5 January 2019 at 12:14:15 UTC, Russel Winder wrote:
Indeed. I should do that to see if I can reproduce the problem
to submit a proper bug report.
File_Ptr is wrapping a dvb_file * from libdvbv5 to try and make
things a bit for D and to ensure RAII. libdvbv5 is a C API with
classic C approach to handling objects and data structures.
My DStep/with manual binding is at
https://github.com/russel/libdvbv5_d and the application using
it (which is causing the problems) is at
https://github.com/russel/DVBTune
Your problem possibly (probably?) stems from
auto channelsData = TransmitterData(args[1]).scan(frontendId);
The temporary TransmitterData(args[1]) is, well, temporary and
its destructor runs after that expression is done. As the
returned object from scan references data from the temporary, you
have a stale pointer.
I have a feeling that I am really not doing things in a D
idiomatic way.
Some driveby style comments then:
bool opEquals()(const FrontendId other) const {
if (this is other) return true;
if (other is null) return false;
return this.adapter_number == other.adapter_number &&
this.frontend_number == other.frontend_number;
}
The compiler generated default opEquals will do basically the
same thing. Ditto for the other types. You usually want to take a
const ref for opEquals since there is no point copying it.
if (other is null)
I'm surprised the compiler doesn't warn or error on that as the
only way that could make sense would be if it had an alias this
to a pointer type.
You should consider reference counting your pointer wrapper
types, FrontendParameters_Ptr/File_Ptr/ScanHandler_Ptr
You seem to like const, good! You don't need to take `const int`s
as parameters, you're getting a copy anyway. You have a bunch of
redundant casts as well.
I'll have another looks tomorrow when I'm a bit more awake.
