AMDG Niels Dekker - address until 2010-10-10 wrote:

Steven Watanabe wrote:

...

It's better to use non-members for operator+, operator-, etc.

In the case of a template class like SafeInt<T>, do you think the binary operator+, operator-, etc., should be friend functions, defined inside the class declaration, or template functions?

I don't think that non-template friends should be defined inline in a class template because they are always supposed to be instantiated regardless of whether they are used or not (unlike ordinary members). For templated operator+, etc, I don't really care.

Note that I've just posted a slightly related ticket on David LeBlanc's SafeInt: "Potential performance gain from non-member operator+" http://safeint.codeplex.com/WorkItem/View.aspx?WorkItemId=7910

BTW, I do think it would be great to have such a library in Boost.

Kind regards, Niels

In Christ, Steven Watanabe

AMDG Niels Dekker - address until 2010-10-10 wrote:

Steven Watanabe wrote:

...

I don't think that non-template friends should be defined inline in a class template because they are always supposed to be instantiated regardless of whether they are used or not (unlike ordinary members).

Thanks, Steven. Do I understand correctly that when you look at the following example, you find the definition of operator+ preferable to operator- ?

////////////////////////////////////////////////////////// template <typename> class safe_int;

template <typename T> safe_int<T> operator+(safe_int<T>, safe_int<T>);

template <typename T> class safe_int { public: friend safe_int operator+ <>(safe_int, safe_int);

inline friend safe_int operator-(safe_int, safe_int) { throw "operator- not yet implemented."; } };

template <typename T> safe_int<T> operator+(safe_int<T>, safe_int<T>) { throw "operator+ not yet implemented."; } //////////////////////////////////////////////////////////

I still hesitate, because the non-template inline friend, operator-, appears to support implicit conversions more intuitively... I think.

Sorry. I reacted automatically, because of the problems that I've had with inline friends. In this case, I think it's not a problem to define them inline. The cases that cause problems are like: template<class Iterator> struct reverse_iterator { friend reverse_iterator operator+(typename Iterator::difference_type n, reverse_iterator iter) { return(reverse_iterator(iter.base() - n)); // oops... early error if Iterator is not a RandomAccessIterator } }; For safe_int, you could only run into problem by both a) supporting user-defined type. I don't see the point of this. b) only requiring the underlying type to support division (e.g.) if the user tries to divide two safe_ints.

Isn't support of such conversions (in a symmetrical way) the main reason to declare such operators as non-members, rather than as member functions?

Maybe. For me it's more important that the operators are defined consistently and there is no way to overload an operator as a member with the first argument being of a different type. In any case, it's okay to support implicit conversions for both arguments or neither, as far as I am concerned. It's the matter of supporting implicit conversions only for the second argument that makes the member operator really unattractive. In Christ, Steven Watanabe

Jean-Francois Bastien wrote:

[pedanticism] Don't both your examples rely on pre-standard C++ friend declarations and definitions injecting the function name in the innermost enclosing namespace? I might be reading this worng, but 7.3.1.2 [namespace.memdef] paragraph 3 states: "The name of the friend is not found by unqualified lookup (3.4.1) or by qualified lookup (3.4.3) until a matching declaration is provided in that namespace scope". So you'd still need to declare in the namespace. From what I understand the examples shouldn't work.

Correct me if I'm wrong :)

Well... I do appreciate your pedanticism, but I think you're wrong. All the compilers I tried accept the function calls to the inline friend function, operator-(safe_int,safe_int), including MSVC 2008 SP1, Comeau (www.comeaucomputing.com/tryitout), and g++ 4.1.2, run at http://codepad.org/dB9IbQJ7 You might want to have a look at [temp.inject] ("Friend names declared within a class template"). Quoting the latest C++0x Working Draft, www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf, 14.7.5/2 (slightly reformatted): "As with non-template classes, the names of namespace-scope friend functions of a class template specialization are not visible during an ordinary lookup unless explicitly declared at namespace scope (11.4). Such names may be found under the rules for associated classes (3.4.2). [ Example: template<typename T> struct number { number(int); friend number gcd(number x, number y) { return 0; }; }; void g() { number<double> a(3), b(4); a = gcd(a,b); // finds gcd because number<double> is an // associated class, making gcd visible // in its namespace (global scope) b = gcd(3,4); // ill-formed; gcd is not visible } —end example ] Kind regards, Niels

Jean-Francois Bastien wrote:

Niels,

...

Correct me if I'm wrong :)

Well... I do appreciate your pedanticism, but I think you're wrong. All the compilers I tried accept the function calls to the inline friend function, operator-(safe_int,safe_int), including MSVC 2008 SP1, Comeau (www.comeaucomputing.com/tryitout), and g++ 4.1.2, run at http://codepad.org/dB9IbQJ7

You might want to have a look at [temp.inject] ("Friend names declared within a class template"). Quoting the latest C++0x Working Draft, www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf, 14.7.5/2 (slightly reformatted):

"As with non-template classes, the names of namespace-scope friend functions of a class template specialization are not visible during an ordinary lookup unless explicitly declared at namespace scope (11.4). Such names may be found under the rules for associated classes (3.4.2). [ Example:

template<typename T> struct number { number(int); friend number gcd(number x, number y) { return 0; }; };

void g() { number<double> a(3), b(4); a = gcd(a,b); // finds gcd because number<double> is an // associated class, making gcd visible // in its namespace (global scope) b = gcd(3,4); // ill-formed; gcd is not visible } -end example ]

I might very well be wrong, that part of the standard has always been a bit shady to me and had a ring of "pre-standard stuff". That being said compilers aren't the best way to verify standard compliance ;)

I believe that the friend becomes visible once the template is instantiated for a specific type. Therefore there is a gcd for number<double> visible in the example above, but not for any other types. Bo Persson

Niels Dekker - address until 2010-10-10 wrote:

...

4. x86 has hardware support for checking for integer overflows. It means that the OS may provide some means to check if an overflow has occurred. Using hardware may be way faster then doing the checks in the software.

Interesting! How would you use hardware to check int overflow?

If you are programming in x86 assembler you can use OF flag in FLAGS register that is set when an integer operation overflows. But you need to check it after each operation. There is a special INTO instruction that triggers an overflow interrupt handler if the OF flag is set. It means that you just have to put INTO after all of instructions that you want to check for overflow and provide proper handler. POSIX defines a signal that is delivered to a process upon invalid integer operation, SIGPFE: http://en.wikipedia.org/wiki/SIGFPE. On Windows there is a structures exception with code STATUS_INTEGER_OVERFLOW. There seems to be a sample of how to use it here: http://msdn.microsoft.com/en-us/library/7sw7cha4.aspx, but it is not complete.

Hi Omer,

the library should be platform independent

I've noticed that you make implicit assumptions in the code like: - the number of bits in a byte is 8, - signed integer types use 2's complement representation. These assumptions are not true for all platforms, making your code not fully portable and not standards-compliant. I realise that implementing the library without such assumptions may be much more difficult, but if you decide to make them, it is necessary to: - describe them precisely in the documentation, - add corresponding static asserts in the code to prevent people from using it on unsupported platforms. Apart from this, you should adhere to Boost coding conventions (see http://www.boost.org/development/requirements.html for details). That said, I think such a library would be a very useful addition to Boost, so I hope all the problems will be solved and the code will be submitted for a review. ;-) Best regards, Robert