|
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.
I'm for the constant - for easy-to-grok code.
|
|
|
|
|
Yes; but otherwise "1000" becomes a "magic number".
Perhaps a little anal, but if one's intention is to be consistent...
Some (scientific) apps treat seconds as a "double"; how else does one convert from milliseconds?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Sure it is. Imagine a clock that is gradually slowing down. Its rate of slowing down could be described in milliseconds per second.
|
|
|
|
|
Documentation wise it isn't totally ridiculous.
So something like the following is more obvious than with the real value.
timeToProcess = runTime/MILLISEC_PER_SEC
To be fair, myself I would probably have coded the above like the following
timeToProcessSeconds = runTimeMillis/MILLISEC_PER_SEC
But lots of times others do not. And I would rather see the hint.
|
|
|
|
|
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'm reading the Threading Chapter of C# 7.0 in a Nutshell: The Definitive Reference: Joseph Albahari, Ben Albahari: 9781491987650: Amazon.com: Books[^].
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.
Have any of you read this chapter?
|
|
|
|
|
Quote: Have any of you read this chapter?
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.
Get me coffee and no one gets hurt!
|
|
|
|
|
Cornelius Henning wrote: 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.
Thanks again!
|
|
|
|
|
where i can find the book on UWP ?
|
|
|
|
|
|
No, we only have C# 6.0 in a Nutshell, but I agree that this is one of the most useful books around.
|
|
|
|
|
RickZeeland wrote: No, we only have C# 6.0 in a Nutshell,
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.
Great writing.
|
|
|
|
|
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.
|
|
|
|
|
Ehsan Sajjad wrote: 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. You can think of async/await as being Task based rather than Thread based.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: 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.
Thanks
|
|
|
|
|
Quote: async/await is not threading and threading is not async/await.
It took me a while to understand this fact!
Get me coffee and no one gets hurt!
|
|
|
|
|
but then how the method executes asynchronously while the main thread still continues doing it's work , the async method which is being called in executed in what thread then ?
|
|
|
|
|
With async/await, as also for Tasks, you have to think in terms of SynchronizationContexts instead of threads. There's an excellent overview of this concept here[^].
This space for rent
|
|
|
|
|
|
Thanks, i will give a read.
|
|
|
|
|
Does it talk about how to create an Asynchronous method using tasks?
Most information I've found about async/await is about the caller, "You mark a method as async and then use await to call asynchronous methods". I haven't been able to find a lot on how one would actually go about writing an asynchronous method to be called by await.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
