Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[floatfield.manip]/8 has not stood the test of time #4258

Closed
zygoloid opened this issue Sep 30, 2020 · 4 comments · Fixed by #4446
Closed

[floatfield.manip]/8 has not stood the test of time #4258

zygoloid opened this issue Sep 30, 2020 · 4 comments · Fixed by #4446
Assignees

Comments

@zygoloid
Copy link
Member

This note is explaining why hexfloat uses a weird combination of flag values, but it's phrased as if justifying a change to the status quo, not as a historical description. It's not clear that this note is useful, but if we want to retain it, we should rephrase.

@tkoeppe
Copy link
Contributor

tkoeppe commented Oct 1, 2020

It seems that having a well-constructed, durable note here would be friendly, since this is indeed an odd design, so some form of "sic!" marker would be nice.

@zygoloid
Copy link
Member Author

zygoloid commented Oct 1, 2020

[Note 1: If you find this surprising, you were paying attention. Good job! --end note]

@jensmaurer
Copy link
Member

I don't understand the rationale offered here. "floatfield" could never be "hex" in C++2003. Maybe in some implementations, the numeric value of hex conflicted with scientific or fixed?

@Eelis
Copy link
Contributor

Eelis commented Oct 24, 2020

Well, to make

str.setf(ios_­base​::hex, ios_­base​::​floatfield);

do anything, ios_base::hex must have bits in common with ios_base::floatfield. But ios_base::basefield is defined as dec|oct|hex, so the result would be that floatfield and basefield would overlap, which seems bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants