|
I blame the Brits for that one.
cheers
Chris Maunder
|
|
|
|
|
You'd better blame the french, and the long scale was the original.
|
|
|
|
|
It depends on what it is used for. It could be set to other values to speed up or slow down the time counting without changing other modules.
If you develop PLC virtualizations, emulators or firmware that value may be fundamental instead of useless.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
In such a situation, the constant is badly mis-named.
Calling it a constant, if you intend to vary it, is a small detail.
Setting MILLISECONDS_PER_SEC to 2000? Seriously?
Which time-dependent operations would that affect - those where milliseconds are used, those where other milliseconds are used? Or all? Would it double or half the speed?
A properly named semi-constant value would be something like SLOWDOWN_FACTOR or VIRTUAL_TIME_TO_REAL_TIME.
And while I am at it: I really hate this C style CONSTANTS_IN_ALL_UPPER_CASE rule - much because I have seen too many cases where functional extensions requiring the symbol defintion to be changed to a a variable to adapt to other situations - but the old UC name was used in so many source files and documentation that it cost too much to change it, and the old UC name was retained for the variable.
(I also had my first serious programming training in Pascal, and when switching to C, I really missed the option to replace a semi-const/variable definition with a (parameterless) function call - parentheses were not required in Pascal, but in C you have to go through every use and add () to every use of the symbol.)
|
|
|
|
|
Member 7989122 wrote: I really hate this C style CONSTANTS_IN_ALL_UPPER_CASE
I really love it as it makes very clear what I'm looking at 
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
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.
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
