[DiscordArchive] at that point the functions you call should just hand you the resources and it'd be the same as AddS
[DiscordArchive] at that point the functions you call should just hand you the resources and it'd be the same as AddS
Archived author: <o> • Posted: 2022-09-11T18:09:53.672000+00:00
Original source
and the variable that leaktests uses must use a variable _in that tu_, not just any tu
Archived author: <o> • Posted: 2022-09-11T18:10:47.181000+00:00
Original source
but, unless i read or remembered this wrong, they can still be deferred until you actually call that function
Archived author: <o> • Posted: 2022-09-11T18:13:10.872000+00:00
Original source
if i understood your description right, you have your hashmap in some hashmap.cpp and then have a bunch of functions in various TU's loading it with side effects, but don't actually reference variables in its own TU, it's just those variables that register themselves to your map
Archived author: Sovak • Posted: 2022-09-11T18:18:36.928000+00:00
Original source
Ye, but by calling the LeakTests function I should basically initialize the whole TU
Archived author: Sovak • Posted: 2022-09-11T18:19:20.399000+00:00
Original source
The only issue is whether the linker will be forced to link in all the global variables, but I think it should be, cause it must be able to see the side-effect within each TU. But I need a LeakTests function for each TU
Archived author: <o> • Posted: 2022-09-11T18:20:15.503000+00:00
Original source
>Ye, but by calling the LeakTests function I should basically initialize the whole TU
that's not how i read the specs, you must actually odr use something in the tu to initialize it, not just call a function
Archived author: <o> • Posted: 2022-09-11T18:20:27.439000+00:00
Original source
but i guess you could just have some stupid dummy variable and odr use it as part of the macro