cplusplus / lewg Goto Github PK

I'm leaning toward a bugzilla on isocpp.org, but a copy of the LWG's issues software will work if that doesn't.

Until then, I'm recording issues here so we don't lose them.

Recorded from c++std-lib-ext-655, from Herb Sutter:

Hans Boehm:

Which, like the status quo, leaves us with no efficient way to express the
mathematical version of X mod 2**n (which doesn't yield negative values),
in spite of the fact that the hardware can easily do it in one instruction?

Richard Smith:

Excuse my ignorance, but what's wrong with "unsigned(X) & (1u << n)" (for
n <= sizeof(int) * CHAR_BIT)?

Jens Maurer:

Indeed, 4.7p2 says "(unsigned)X" does the right thing even for negative X.

Assuming this is correct, the above six lines seems like ample motivation for a std::mod2 function... Standardization is (among other things) for common operations that (a) will be duplicated by many programmers, and/or (b) are so subtle that programmers won't readily get them right. If someone named Hans Boehm is both stating it's frequently needed and is asking how to implement it, I presume that's enough evidence for both criteria and we should add std::mod2 with the above semantics?

Initial proposed resolution:

In [??.??], add the following new subclause:

[??.??] Modulo 2 operations [??.??]

int mod2(int val, int n);
unsigned mod2(unsigned val, int n);
long mod2(long val, int n);
unsigned long mod2(unsigned long val, int n);
long long mod2(long long val, int n);
unsigned long long mod2(unsigned long long val, int n);

1 Requires: n <= sizeof(val) * CHAR_BIT.
2 Returns: UTYPE(X) & ((UTYPE(1) << n) - 1), where for each function UTYPE is the unsigned type of the same size as val.

We should support code snippets like this:

for (const auto& entry : m.equal_range(key)) {
}

The design guideline recommend to use C++03 syntax over C++11 features.

Where C++ 2003 syntax can be used, that is preferred over C++ 2011 features.

It is not clear to me what that mean exactly, and it seems to be there are benefits to use the latest published standard in the specification whenever beneficial and relevant. Which I think we do, so that guideline may no longer apply?

Other things that seems need changing:

• Use SFINAE to constrain templates:

It's implementation defined how templates are constrained, and concepts should probably be otherwise preferred?

• Operators come in groups: (==, !=), (<, >, <=, >=)

Maybe we should prefer <=> whenever applicable

• Don't use code to specify behavior.

I think we do, sometimes

• For templates, make it clear what the concepts are.

Should we not prefer exposition-only concepts where applicable?

• Use clause [structure.specifications] to determine what specification clauses to use.

Might be interesting to mention P1369

• Do not use requires clauses or define new language-level concepts until the introduction (section 6) and fundamental concepts (section 7) from the Ranges TS have merged into the IS.

Time to revisit that ?

Although this Bugzilla uses a separate login, it should state that use of issues.isocpp.org is subject to the isocpp.org terms of use: https://isocpp.org/home/terms-of-use .