*Post by Vincent Reverdy*(&j - &i)*std::numeric_limits<unsigned int>::digits + (pos_j - pos-i)

âSince i and j are not part of the same array, the above is actually

undefined behaviour.

*Post by Vincent Reverdy*âWhat is, conceptually and mathematically, a bit? (a pure digit with no

mathematical meaning, a pure bool, a one-digit long unsigned integer => it

will put strong constraints on the design (including arithmetic operators

and implicit conversions))

A bit is a bool. Now, you can argue about what a bool is (conceptually,

mathematically) and you might get a different answer than what C++ has

decided a bool is. â But the closest thing we have to a bit is a bool, so

you should align with that, and not step past it to arithmetic types.

I don't want to argue about what C++ has decided a bool is. I am perfectly

requires a bit to be a bool, but maybe I am wrong.

proposal), and bool have compound assignment operators. That is already

quite strong differences.

arithmetic operators.

are (and I discuss five of them in the proposal).

â> Plus, I have an additional question: what would be the most suited part

of the committee to discuss this proposal? Library evolution, Ranges (SG9)

or Low Latency (SG14)? Or a mix of all of them?

LEWG.

IMO,

Tony

Sent from my BlackBerry portable Babbage Device

Original Message

*From: *Vincent Reverdy

*Sent: *Thursday, January 21, 2016 11:13 AM

*To: *ISO C++ Standard - Future Proposals

*Subject: *Re: [std-proposals] Bit utilities proposal, last revision

before submission

*Post by Vincent Reverdy**Post by Vincent Reverdy*Thanks for the comments!

The approach you describe (no arithmetic operations), is the one I was

using in the previous versions.

*Post by Vincent Reverdy*I prefered to opt for the most exhaustive approach, because it is

easier to remove arithmetic operators later than to introduce them.

*Post by Vincent Reverdy*1) no arithmetic behaviour at all (and consequently no implicit

conversion to bool, but only an explicit one)

*Post by Vincent Reverdy*2) an exhaustive arithmetic behaviour (like the one I present in this

version)

I can't follow "exhaustive"; I didn't see free functions such as + - * /.

Most operators are obtained through an implicit conversion to bool (which

is then likely to be promoted to int, but that's ok because if a bit is

mathematically defined as a one-bit long unsigned integer, then, this

behaviour is consistent with what would be expected if a bit was a

fundamental type). With the current std::bitset::reference, you can write

x = x + 3, but you cannot write x += 3. For me, this is a significant

conceptual problem.

*Post by Vincent Reverdy**Post by Vincent Reverdy*Having an overloaded ~, no compound assignment but binary arithmetic

operators through an implicit conversion seems very error-prone to me.

No implicit conversions out of a bit_* class, please.

This design choice is directly related to the question of arithmetic

behaviour, because implicit conversions provide most operators without

having to write all the possible combinations of binary operators with

integer types. Maybe there is another "simple" way to provide all the

binary arithmetic operators that I don't have considered, and in that case

it would make the two questions separate (which would be good). But if the

two question are linked, then I would like the question of the arithmetic

behaviour to be discussed with this proposal, because I think it is

important. It boils down to the fundamental question of "what is a bit?".

In this version of the proposal, I have considered that a bit is

mathematically a one-digit long unsigned integer. I discuss the other

options that came to my mind in the "What is the arithmetic definition of a

bit?" subsection. In my view, the first question to anwer is "what is,

mathematically speaking, a bit?". This question have strong design

consequences, including, implicit conversions (at least as long as the two

questions are linked).

*Post by Vincent Reverdy**Post by Vincent Reverdy*For non-members, I will list the idea in the last part of the document.

But maybe set and reset are far too common names to be dedicated to bit

manipulation? (and there is also the problem of the conflicting name).

*Post by Vincent Reverdy*And if we make the bool conversion operator explicit, for me, it means

that we consider that a bit and a boolean are two different concepts, and

in that case, I find it far more elegant to have a dedicated bit_value

class. But that is just my opinion.

Frankly, and I understand this is a large item, I'd like to see more

use-cases for this. That is, specific problems that are addressed

by these classes. I'm particularly interested in specific use-cases

(as in: problems to be solved, not conceived snippets of code) for

the arithmetic operations. Note that "bool" does NOT have the

arithmetic properties you ascribe to bit_value here.

You mean, more use-cases for bit utilities, in general, or more use cases

for bit_value? If we are speaking of bit_value, for me, the simple fact

that a reference and a value of an object would have a different arithmetic

behaviour, is both error-prone and conceptually very strange And this would

be the case if we consider that the value type associated with a

bit_reference is a bool. That is one of the reason behind bit_value. The

arithmetic behaviour I provide for bit_value and bit_reference, here, is

the arithmetic behaviour of a hypothetical one-digit long integer (in the

sense of unsigned char, unsigned short int, unsigned int, unsigned long

int, unsigned long long int), which is NOT a bool.

*Post by Vincent Reverdy**Post by Vincent Reverdy*For the comparison and difference operators, I explain it in the

"additional remark" subsection of the "design decisions part" (as far as I

remember).

No, I'm not talking about const vs. non-const. I'm talking about

unsigned int i = 0;

unsinged int j = 0;

bit_pointer(i, 0) - bit_pointer(j, 1) // what's the result?

The result should be the distance, in iterable bits, between the pointed

bits (as an extension of a classical difference of pointers).

(&j - &i)*std::numeric_limits<unsigned int>::digits + (pos_j - pos-i)

*Post by Vincent Reverdy*(I don't think we want the argument of bit_pointer to ever be

NULL, so using a reference instead of a pointer parameter seems

the better approach.)

Thanks,

Jens

Note: keep in mind that, this is a first draft with a "suggestion of

design" only.

Actually, the main questions I would really like to be answered after a

- Do we want a bit_iterator in the standard library to be able to write

algorithms on bits (if the answer by the community, and especially the low

latency application domains, is yes, then the other classes are a

consequence of that)?

- How to define the position of a bit (it put constaints on the template

parameter type, and on the way we iterate on bits)?

- What is, conceptually and mathematically, a bit? (a pure digit with no

mathematical meaning, a pure bool, a one-digit long unsigned integer => it

will put strong constraints on the design (including arithmetic operators

and implicit conversions))

Given the answers to these "fundamental" questions, the whole document

will be updated to propose something that fit these requirements.

@Tomasz

Thanks for the very interesting suggestion. I did not think of that.

=================

Plus, I have an additional question: what would be the most suited part of

the committee to discuss this proposal? Library evolution, Ranges (SG9) or

Low Latency (SG14)? Or a mix of all of them?

--

---

You received this message because you are subscribed to the Google Groups

"ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an

Visit this group at

https://groups.google.com/a/isocpp.org/group/std-proposals/.