How to Write a Large Number in C++ Source Code with Spaces to Make It More Readable

Is there a way to write a large number in C++ source code with spaces to make it more readable?

Try digit separator:

int i = 1'000'000'000;

This feature is introduced since C++14. It uses single quote (') as digit separator.

---

Also see:

• Why was the space character not chosen for C++14 digit separators?
• Generalizing Overloading for C++2000 (April's joke by the father of C++ himself)

Representing big numbers in source code for readability?

Here's a macro that would do it, tested on both MSVC and GCC. No reliance on Boost...

#define NUM(...) NUM_(__VA_ARGS__, , , , , , , , , , )
#define NUM_(...) NUM_MSVCHACK((__VA_ARGS__))
#define NUM_MSVCHACK(numlist_) NUM__ numlist_
#define NUM__(a1_, a2_, a3_, a4_, a5_, a6_, a7_, a8_, ...) a1_##a2_##a3_##a4_##a5_##a6_##a7_##a8_

Use it like:

int y = NUM(1,2,3,4,5,6,7,8);
int x = NUM(100,460,694);

Produces:

int y = 12345678;
int x = 100460694;

Making large constants in C source more readable?

One possibility is to write it like that:

#define F_CPU (16 * 1000 * 1000)

alternatively

#define MHz (1000*1000)
#define F_CPU (16 * MHz)

Edit: The MHz(x) others suggested might be nicer

Delimiter tens and units in c++ literals

Since C++14 you can use single quotes (') for integer literal to improve the readability, e.g.

int i = 1'200'200;

Optional single quotes(') may be inserted between the digits as a
separator. They are ignored by the compiler.

Reading string from input with space character?

Use:

fgets (name, 100, stdin);

100 is the max length of the buffer. You should adjust it as per your need.

Use:

scanf ("%[^\n]%*c", name);

The [] is the scanset character. [^\n] tells that while the input is not a newline ('\n') take input. Then with the %*c it reads the newline character from the input buffer (which is not read), and the * indicates that this read in input is discarded (assignment suppression), as you do not need it, and this newline in the buffer does not create any problem for next inputs that you might take.

Read here about the scanset and the assignment suppression operators.

Note you can also use gets but ....

Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.

Read input numbers separated by spaces

By default, cin reads from the input discarding any spaces. So, all you have to do is to use a do while loop to read the input more than one time:

do {
   cout<<"Enter a number, or numbers separated by a space, between 1 and 1000."<<endl;
   cin >> num;

   // reset your variables

   // your function stuff (calculations)
}
while (true); // or some condition

Is scientific notation safe for integer constants in C?

In theory, no. Neither language specifies how floating point values are represented, or which values can be represented exactly. (UPDATE: apparently, C11 does recommend a representation. C++, and older C dialects, don't).

In practice, yes, for quite a large range of values. Any implementation you're remotely likely to encounter will use a 64-bit IEEE representation for double. This can represent any integer value up to 2⁵³ (approximately 9x10¹⁵) exactly. It can certainly represent anything representable by a 32-bit integer type.

Why was the space character not chosen for C++14 digit separators?

There is a previous paper, n3499, which tell us that although Bjarne himself suggested spaces as separators:

While this approach is consistent with one common typeographic style, it suffers from some compatibility problems.

• It does not match the syntax for a pp-number, and would minimally require extending that syntax.
• More importantly, there would be some syntactic ambiguity when a hexadecimal digit in the range [a-f] follows a space. The preprocessor would not know whether to perform symbol substitution starting after the space.
• It would likely make editing tools that grab "words" less reliable.

I guess the following example is the main problem noted:

const int x = 0x123 a;

though in my opinion this rationale is fairly weak. I still can't think of a real-world example to break it.

The "editing tools" rationale is even worse, since 1'234 breaks basically every syntax highlighter known to mankind (e.g. that used by Markdown in the above question itself!) and makes updated versions of said highlighters much harder to implement.

Still, for better or worse, this is the rationale that led to the adoption of apostrophes instead.

---

Related Topics