Talk:cpp/language/floating literal

Hexadecimal floating literals in C++

I have tested floating point literals in C++ (MinGW) without the use of scanf or something, it worked perfectly.

Yes, C-style fp literals are one of the non-standard language extensions provided by gcc. --Cubbi 17:41, 21 July 2013 (PDT)

Maybe that can be added to c/language/floating_literal, the entire page is missing there though. --Bazzy 02:25, 22 July 2013 (PDT)

That would be the best outcome. P12 04:37, 22 July 2013 (PDT)

syntax

The literals can be seen as four different parts:

integral dot decimal exponent suffix

The valid combinations are:

int	dot	dec	exp
X	X	X	X
	X	X	X
	X	X
X			X
X	X		X
X	X
X	X	X

where X means "present in literal"
The suffix is always optional

Splitting in regex:

[0-9]+ \. [0-9]* exponent?

int	dot	dec	exp
X	X	X	X
X	X		X
X	X
X	X	X

[0-9]* \. [0-9]+ exponent?

int	dot	dec	exp
X	X	X	X
	X	X	X
	X	X
X	X	X

[0-9]+ exponent

int	dot	dec	exp
X			X

RegEx may not be an optimal representation of this

Bazzy 15:02, 5 March 2012 (PST)

As for the representation, what do you think about something similar to this? -P12 01:38, 6 March 2012 (PST)

Can it be used to express efficiently the fact that every part of a floating point is optional but only some combinations are allowed?

Another option may be the BNF like in the ISO docs. It's quite clean but makes harder to get how the accepted literals look like

Maybe it would be clearer with both a formal notation and a textual description.

-- Bazzy 09:02, 6 March 2012 (PST)

Given the fact, that the decimal floating point expression at that page already describes 6 out of 7 cases (except that decimal point isn't optional), I think it's sufficiently efficient. For the last case (|X| | |X|), we could add a separate description. By the way, does strtof support this textual floating-point representation? -P12 10:34, 6 March 2012 (PST)

the int+exp can be obtained with: nonempty digit sequence without decimal-point but with the exponent

Would the following work?

• nonempty sequence of decimal digits optionally containing a decimal point character (defines significand)
• (optional) e or E followed with optional minus or plus sign and nonempty sequence of decimal digits (defines exponent)
• (optional) a suffix type specifier as a l, f, L or F

-- Bazzy 11:27, 6 March 2012 (PST)

Yes, I was thinking exactly about that. The point character is not optional though. I'll update the page with this. -P12 13:58, 6 March 2012 (PST)

The point is optional. The ISO C document on strtof says as follows:

a nonempty sequence of decimal digits optionally containing a decimal-point character, then an optional exponent part as defined in 6.4.4.2;

And it's the fact that it's optional to allow the syntax like 1e4

I'll update here with the textual description

-- Bazzy 14:06, 6 March 2012 (PST)

According to your first table the dot is mandatory in all cases except the fourth. We could add a separate description for the fourth entry. -P12 14:18, 6 March 2012 (PST)

I find the current presentation difficult to parse: For example: Given 42f, is this a valid floating-point literal? On a quick glance this page seems to suggest that it is, when in fact it is not (42.f would be correct). I also think it is unfortunate that the main syntax description claims that exponent and/or suffix are optional when there are cases where this is not the case (for example (1)). Only after carefully reading it, does one understand that this is not the case. Unfortunately it seems difficult to come up with a better form of presentation though.

80.153.181.229 00:54, 18 May 2018 (PDT)

In case anyone else is confused -- some things in this page are definitely still wrong. For example, variant (4) implies that 0x1e5 is a hex float, when in fact it is just an unsigned hex integer.

81.141.95.199 09:39, 16 April 2021 (PDT)

No it doesn't, hexadecimal exponent token is p, not e. Also 0x1e5 is usually a signed hex int --Ybab321 (talk) 09:56, 16 April 2021 (PDT)

Ah yes, my mistake — I see the note underneath where the 'exponent' token is defined. However I would still contend that the way it is presented is misleading. I have shown this page to a few people and they all interpreted it the same way as I did.

81.141.95.199 11:31, 16 April 2021 (PDT)

Well we can't be allowing that :) --Ybab321 (talk) 14:37, 16 April 2021 (PDT)