Ticket #141 (new fixme)
variant unit test
| Reported by: | ichthyo | Owned by: | ichthyo |
|---|---|---|---|
| Priority: | lesser | Milestone: | 0integration |
| Component: | lumieraProc | Keywords: | QA |
| Cc: | Blocked By: | #738 | |
| Blocking: | #283 |
Description
Note to @self: this got sidelined almost a year ago...
...which just again shows you should never defer writing tests just to "get ahead"
Change History
comment:3 Changed 14 months ago by ichthyo
really should do that....
I recall that at the time when devising AccessCasted, I had almost a complete unit test fixture in tool/try.cpp. Just I was too lazy to spend an additional hour or so to rewrite that into a real unit test. Damn it!
the Variant type itself could also use some revamp and straightening; especially as we have now all those opaque holder types; there is potential to share more code. I am still a bit doubtful regarding Variaint, but the assessment of benenfits has remained basically the same (special visitation scheme, no dependency on the boost metaprogramming library, which tends to bloat the debug compiled code, deliberately no thread safety and thus simpler and shorter code paths)

when doing this, we should also cover the similar cases of lib::OpaqueHolder, which are actually based on the same code from access-casted.hpp, which would need to be covered by the unit test in discussion here. (I.e. put a value into OpaqueHolder, and then re-access it as a parent-type or through an automatic conversion). While we don't need this to get ahead right now, it seems rather likely to expect some hidden bugs in this code...