Hello,
I like the idea of GEM5_ONCE, but as it would become part of the API users
could definitely use in unforeseen ways (e.g., debugging). I am not saying this
is a bad thing, but it is something to consider.
Regards,Daniel
___
gem5-dev mailing list
Yeah, that's not a bad option either. Between the two, I suggested
GEM5_ONCE so that the _once version wouldn't be as inconsistent with the
normal version of warn, and even though the GEM5_ONCE macro probably
wouldn't be useful outside of warn, it's a pretty generic mechanism and
could be. For inst
Wouldn't we get the same net result by just renaming warn_once() to
GEM5_WARN_ONCE()? Seems simpler 😊.
Steve
On Mon, Jul 26, 2021 at 11:03 PM Gabe Black wrote:
> Or I should say without un-namespaced macros (GEM5_ prefixed), since
> GEM5_ONCE itself would be a macro.
>
> Gabe
>
> On Mon, Jul 2
Or I should say without un-namespaced macros (GEM5_ prefixed), since
GEM5_ONCE itself would be a macro.
Gabe
On Mon, Jul 26, 2021 at 11:01 PM Gabe Black wrote:
> No, not that I'm aware of. It would just be to make it feasible to
> implement the warn_once functionality without using macros. With
No, not that I'm aware of. It would just be to make it feasible to
implement the warn_once functionality without using macros. With c++20, I
can more or less get it to work with some minor template syntax,
warn("xyz"), but that relies on the source location (file, line,
column which may be iffy) to
Hi Gabe,
Is there a use case for GEM5_ONCE() other than warn_once()?
Thanks,
Steve
On Mon, Jul 26, 2021 at 6:06 PM Gabe Black via gem5-dev
wrote:
> Hi folks. I'm continuing to research how to turn warn, panic, etc, into
> regular functions instead of macros, and one particularly sticky probl
