On Tuesday, 8 January 2019 at 10:23:30 UTC, Russel Winder wrote:
Actually that is not a worry since the TransmitterData instance
is only needed to call the scan function which creates a
ChannelsData instance that holds no references to the
TransmitterData instance.
It turns out that whilst the code used to run, and now doesn't,
all the things
we have been talking of are nothing to do with the core
problem. It turns out
that the function call to initialise the File_Ptr object is
returning a valid
object with invalid data. Thus the unknown change is likely in
the libdvbv5
library either due to the C API doing different things or the
adapter created
using DStep doing the wrong thing.
Ahh. Good that you've found that, I can't help you much more with
that then.
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.
I deleted them, added a test or three (should have done this
ages ago) and the tests pass. So teh generated methods do the
needful. Thanks for that "heads up".
No problems, less code is good code.
Very true. For now I have forbidden copying, which is wrong for
this sort of thing. If D had the equivalent of C++
std::shared_ptr or Rust std::rc::Rc or std::rc::Arc, that would
be the way forward But I guess having explicit reference
counting is not too hard.
I believe Andrei and Razvan are working on that, part of that
being the Copy Constructor DIP. Hopefully it will arrive soon.
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 am a person who always makes Java variables final, and loves
that Rust variables are immutable by default!
Indeed, less to think about is always nice.
Good luck figuring out why your data is dud.
Nic
