Not trying to be mean but why submit something like this to HN? This snippet just launches a thread per every timer using standard library and sleeps. There is no way to really stop anything or knowing if timers are active etc.
Sure, it's syntactically valid C++ (probably) but that's about it.
I feel like there is a more constructive way to outline in which ways this solution might need to be improved to be suitable for various real-world use-cases, without focusing on whether this submission qualifies as HN content.
It has the same syntax as JavaScript, but unfortunately C++ is quite a different language. As C++ has neither compiler check for lifetimes nor garbage collection, this would be very easy to misuse in practice.
The Timer requires anything captured by the lambda to still be alive by the time the function is called. This may be obvious in C++, but it's still dangerous.
Even trying to use this as a set-and-forget-timer without any captures to work around this gotcha (like the example just printing stuff) won't work as the Timer object itself also needs to stay alive until the function is called. Do it further down the stack and the Timer is long destroyed when its function is supposed to run.
Exactly. And the eventloop that is available to a C++ application will differ completely depending on framework/platform. The only thing common to all platforms is that a thread is most likely to be the wrong way to do this.
Seems like a very useful short snippet for creating threads without having to learn a new threading API coming from a JS background.
It seems to me like it would be more useful however to implement these functions using a queue and run loop so that we don't have to worry about hard-to-trace race conditions, etc.
> so that we don't have to worry about hard-to-trace race conditions, etc
Seems to me that something like 50% of clientside Javascript coding is "worrying about hard-to-trace race conditions", so maybe that's a feature, not a bug.
I'm sorry but I'm not sure how a single threaded program can have race conditions? Surely the very definition of a race condition excludes the possibility? Or are our definitions different?
The event loop stops being deterministic if you start triggering events based on a clock. Or if you have calls blocking on external resources with unpredictable timing.
Say, you have a code like this:
asynchronously doA();
blockReadingFile();
doB();
Whether doA() is finished or not when doB() executes depends on internals of doA() and on how long blockReadingFile() takes.
In general async executions really are big sources of race conditions in single threaded program. JS avoids this problem by blocking/queuing tasks until the current task is done but this is not the case in most lower-level environments.
1. Reentrancy. Flow of tasks can be interrupted by hardware interrupts and OS signals. In that case race conditions can happen by interrupt handlers. Bare metal embedded system programmers often have big headaches because of this.
2. JS implementations and JS API design can have race condition bugs. So JS API designers have to consider it. One of example is because of the order of queuing tasks/handlers. [1]
asynchronicity and parallelism (threads) are two entirely different concepts. Most GUI systems except BeOS's are asynchronous on a single thread. When you code in node you just have one big hidden while loop that does
> asynchronicity and parallelism (threads) are two entirely different concepts
They are. However, in the browser resources (such as scripts) will be loaded using multiple threads. Javascript will be executed on one thread at a time, but this execution will switch to another context at the appropriate breakpoints.
Javascript in the browser is a multithreaded cooperatively multitasking system.
> However, in the browser resources (such as scripts) will be loaded using multiple threads.
Are you sure about this ? I could not find anywhere something saying that the main JS execution would switch threads - and even if it did, it would not impact the observable behaviour of your JS code anyways. Everything I could find on google says "JS is single-threaded" (except for web workers of course).
Read what I said again. Javascript is a language that will be executed using several threads when run in the browser environment.
However, that isn't the point. The point is that multiple Javascript scripts will be executing concurrently (via cooperative multitasking) and manipulating the same DOM elements.
This is absolutely a source of race conditions and a huge, HUGE pain in the ass for programmers who think Javascript is a 'single-threaded language'.
It seems author is making a point that modern C++ programming is degrading towards the same illness JS packages are: we're now going to be using libraries which are literally 60 lines of code in order to accomplish something that could be done by the standard library.
The problem is that it's not that good information but for some reason seems to make it to the front page quite easily. Being critical of a project is a good thing, this isn't it.
Sure, it's syntactically valid C++ (probably) but that's about it.