The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
If I'm analysing a time based data stream I may wish to record how many milliseconds worth of a data I am processing per second. This information would be crucial for scaling the services doing the processing.
MILLISEC_PER_SEC is actually a conversion factor between some underlying time measurement and seconds - the name suggests it is milliseconds, but it might not be, and it might change. Some old computer hardware only kept time in power line frequency of 50 or 60 hz, and some future hardware (or OS) might keep time intrinsically in nanoseconds. Having a symbolic constant in this conversion, instead of a magic number 1000, makes it perfectly clear what the semantics of the conversion are, which is a good thing.
I disagree - I have done such things often.
If you are writing software for an embedded system, it will often happen that the basic time tick is close to but not exactly a millisecond: for instance, with a 1MHz clock and a clock divider of 1024 you get 1.024 msec. You can still think of this as a millisecond, which is close enough for some purposes. But if you want to scale to a longer time period, you get errors. For instance, there are about 977 of your "milliseconds" in a second. So defining MILLISEC_PER_SEC as 977 is quite reasonable. Then 60 "seconds" is only off by .027 seconds. If you used the nominal 1000 "msec" per "sec", you'd be off by 1.44 seconds.
It may never be actually needed, but it's better than having a lurking special value, repeated throughout the code, of 1000. It communicates something about wherever it's being used -- probably to convert a seconds value to / from milliseconds.
If you have measurement-illeterate members on your team, it's rather needed indeed. Sure, to everyone with even a bit education in engineering, "milli" is clearly E-3. But to everyone else, not so much.
Heck, I've seen people stumbling over "1,2 k€" which is still rather clear to me.
I've done quite a bit of threading work, generally related to WinForms and Progress Bars and simpler challenges like that in the past. Now with Async / Await, I've done a bit too (under UWP) but this chapter is great because it starts with the more historical "manual" threading and builds through the modern ways to solve concurrency challenges.
Really great, in-depth writing.
No, but your book: Programming Windows 10 Via UWP, arrived late yesterday. I plan to start reading it today. First impression: I like the large size of the pages, making it easier to read for an old guy who is heavily dependent on reading glasses.
your book: Programming Windows 10 Via UWP, arrived late yesterday.
That's very cool. Thanks so much for trying my book out. I hope you find it useful.
Cornelius Henning wrote:
I like the large size of the pages,
Glad you like that too. I am now (over 40...by 10 years). I had 20/20 vision up until I was 42 or so and since then it's been reading glasses so I find it nice when things are a little more clear too.
One of the big things I was shooting for on that was that the screen shots would still look good.
I hope they do.
I think the threading chapter is very similar, if not the same in both anyways.
This chapter is just so good. I really like the way it builds up the story of threading -- how it has worked in past, using lambdas, handling exceptions, etc. Each little bit step by step. Very cool.
does the newer versions of NutShell also contain the previous versions content in them, as if i remember i had read few chapters of c# 5.0 in a nutshell 2 years back and it was indeed a good read for me but wasn't able to finish the whole book.
also contain the previous versions content in them
Basically it does, because the authors are really good at explaining what has changed along the way which is also why the book is so good.
For example in the threading chapter they talk about C# pre-lambda calls and how passing argument to a new thread is different back then. really great stuff.
A minor point (correction) but async/await is not threading and threading is not async/await
Agreed. It is a concurrency / asynchronous thing not really threading.
I now try to always say concurrency but I often fall back on old words.
This is also why I'm reading this chapter because the authors cover all of this.