This is why I prefer C++.
It's people like you what cause unrest.
Oh, it's especially fun to read these in the text client in reverse order.
""const considered harmful" considered harmful" considered harmful. (Don't make me bring Godwin in here.)
STFU and code.
Did that... created an executable that waits on your Windows domain controller to change its network settings before changing the workstation network settings (and renaming the hostname), because things go wrong if you don't do this sort of thing in the right order when you're 'randomizing' your network settings.
This job has me do some pretty strange things.
*grumble* Fucking multithreaded programming. Easier said than done...
Everyone says, "Why? It's easy!"
No. It isn't.
It is always a deception waiting to bite you in the ass someday while your customer breaths down your neck for a solution.
I try very hard to avoid multithreaded programming, or to recast the programming in asynchronous terms instead, so while the logic might feel dysjunct, at least most of the problems associated with true multithreading are mitigated.
That wasn't an option here, we're required to do some resource pooling stuff that isn't available off the shelf.
I get it... sometimes, you're forced into it. And it's never easy.
Much easier to think about things in terms of asynchronous message passing than locking resources.
The locking resources approach is heinous, and mostly what I'm talking about when I say that multi-tasking is hard.
In C++, the asio library makes handling this stuff much, much easier, as it provides a very nice environment for what you've described.
"event-driven asynchronous" sounds suspiciously like a state machine.
Please tell me you aren't praising state machines.
Dec 5 2001 5:26pm from LoanShark
o how i love thee
better than spaghetti
who the hell needs localization anyway?
screw this, i'm getting into real-estate
2018-04-06 14:44 from kc5tja @uncnsrd
The thing is, if your code is built for event-driven asynchronous
architecture, it's already **mostly** multi-threading ready. The only
thing you need to worry about then is shared resource locking, which
can be made easier by wrapping shared resources in a server process (in
the Erlang sense of the term "process", not Unix-style process!). The
I feel like that just moves the problem somewhere else. Dealing with shared state always has complexities. For example, one of the problems I was dealing with was not so much locking-related, as it was a mistaken idea that we could delete something from the shared state, a little too early...
Thanks IG, I wouldn't want to quote myself ;-p
so yeah, I'm not really a fan of event-driven unless the application naturally fits it (like answering UI input events or responding to HTTP queries). I know some people like to turn every program into one big event loop, and although I respect their mad skillz, I find it makes the program unreadable.