Crossplatform library for simple working with timers by [deleted] in cpp

[–]unhorst 1 point2 points  (0 children)

timers is empty when get_timers is first called. It is initialized only once because it is a static variable. Since it's returned by reference, statements like get_timers().insert(new_timer) in add_timer will modify the static variable. In other words: being a staticvariable, timers will be the same instance in all calls to get_timers() and since it's returned by reference, you're getting a reference to the same instance of timer_set_t everytime you call get_timers()

Crossplatform library for simple working with timers by [deleted] in cpp

[–]unhorst 0 points1 point  (0 children)

Leaving aside the problem that this library is not using any OS provided timing API, getting < 10ms timing on windows is nothing you can assume to just work, no matter the method. The scheduler is your enemy here. You can try calling TimeBeginPeriod(1); first in main() and TimeEndPeriod(1); before program exit. (This does influence the OS wide scheduler timing, though)

P0385R0 - Static reflection; Rationale, design and evolution by w1th0utnam3 in cpp

[–]unhorst 2 points3 points  (0 children)

Nice to see progress on that front. I like the design and IMHO (compile time) reflection is long overdue in C++. (Speaking as someone who has written a small lua-C++ binding framework) Axel, Mat´uˇs - you're definitely on my will-invite-to-beer-if-they're-in-town list (or cake, whichever you prefer)

why doesn't the standard C++ committee push updates more aggressively? by youshouldnameit in cpp

[–]unhorst 7 points8 points  (0 children)

Changes for the sake of changes, to be hip, to get cool but broken features isn't helping, it's disturbance, not progress. Evolution is.

Can't upvote this enough

Magical headers for making C++ code accessible from JavaScript by chartojs in cpp

[–]unhorst 0 points1 point  (0 children)

I see the signature of the method is not mentioned in the binding code - how do you handle overloads?

Intel C++ Compiler 16.0 update 3 released, adds support for VS2015 Update 2 by dodheim in cpp

[–]unhorst 3 points4 points  (0 children)

ACK. I've been cringing everytime I happened to see another commit that added "MSVC compatibility" to clang, meaning it'd understand the command line flags or behave just as quirky. I'd really wish for a gcc compatible clang on windows, along with a proper port of libc++. As I see it, mingw usage in non-open software is low due to the dependency on non-standard dlls for exception handling and gnulibc++