4

I was reading a code of a middleware that is written in c and in the code they wrote the following: 

usleep(6*1000*1000);

So my question is:

Is there a reason behind writing it like this? why not just write 6000000? Doing this multiplication has any effect on the performance of the program?

Cœur
  • 32,421
  • 21
  • 173
  • 232
Loay Ashmawy
  • 637
  • 1
  • 7
  • 24
  • 3
    Or why not just write `sleep(6);`, which also conveys '6 seconds' without any readability issues. – Jonathan Leffler Mar 17 '17 at 15:18
  • @JonathanLeffler good question ! I will add it – Loay Ashmawy Mar 17 '17 at 15:19
  • 4
    Can you immediately tell the difference between `6000000` and `60000000` and `600000`? When reading lots of code, its sometimes hard to see exactly how many zeros are present. – abelenky Mar 17 '17 at 15:21
  • 1
    A better and safer trick than nonsense like this: `(int)(6.0*10e6)` – Lundin Mar 17 '17 at 15:31
  • Or to not use magic numbers in the first place, but a textual constant instead. `#define NUMBER 6##000##000` – Lundin Mar 17 '17 at 15:32
  • 1
    FYI: C++14 allows single quotes as punctuation in numbers, so in C++14, you could write `usleep(6'000'000)`. In case you're wondering, there's no particular requirement about consistency; the quotes must be surrounded by digits, but that's about all. It complicates parsing of C++ by simple-minded scanners: `usleep(6000'000)` is legitimate, but could easily look like the start of a character constant adjacent to a number, and it would throw naïve parsers into a tizzy. (I know; I've got naïve parsers that got thrown into a tizzy. Also play with `r"==('raw string literals"""sometime)=="`.) – Jonathan Leffler Mar 17 '17 at 15:32
  • 2
    @Lundin: Your `(int)(6.1*10e6)` suggestion is fatally flawed on the grounds that you use 6.1 where 6 was required, and because the sleep is 10 times as long as desired. Both those indicate that it is anything but better and safer. —— Lundin managed to correct his comments before the time limit was up (but not the off by an order of magnitude: `6.0*1E6` or `6.0*1.0E6` would be OK).; – Jonathan Leffler Mar 17 '17 at 15:34
  • @JonathanLeffler GCC happily compiled it under strict mode, `-std=c11 -pedantic-errors`. – Lundin Mar 17 '17 at 15:35
  • And yeah look at that, I read the expression as 6100000 and not 6000000. Another reason not to write such obfuscated nonsense. Typos fixed in comments. – Lundin Mar 17 '17 at 15:36
  • @JonathanLeffler Perhaps C11 6.4 constraints: "Each preprocessing token that is converted to a token shall have the lexical form of a keyword, an identifier, a constant, a string literal, or a punctuator." In this case an integer constant. – Lundin Mar 17 '17 at 15:39
  • 3
    A problem with `6*1000*1000` vs. `6000000` is type. Consider `6*1000*1000*1000` (`int` math) vs. `6000000000` vs. `6LL*1000*1000*1000` (`long long` math) – chux - Reinstate Monica Mar 17 '17 at 15:42

3 Answers3

8

usleep() expects the supplied argument to be in "microseconds".

This is a visual transformation of the microsecond to seconds, no impact on code expected as any half-decent compiler will compute that at compile time.

Sourav Ghosh
  • 127,934
  • 16
  • 167
  • 234
7

It just makes the source easier to read. With the multiplication, the number is obviously 6 million.

As it evaluates to a constant, the compiler will evaluate the constant at compile-time and there will be no difference in the compiled code.

Graham Borland
  • 57,578
  • 20
  • 131
  • 176
  • 1
    With multiplication, the product may overflow, depending on `int` range and numbers used. (Hopefully a warning will arise) A constant without multiplication does not have that problem. – chux - Reinstate Monica Mar 17 '17 at 15:47
5

Most likely, this was done for readability.

Looking at 6000000 in the code, you might not immediately see how many zeros there are. The visual distinction between this value and 60000000 or 600000 is not great. By splitting it up, it makes it easier to see.

Any decent compiler should compute 6*1000*1000 at compile time, so there should be no performance impact.

dbush
  • 162,826
  • 18
  • 167
  • 209