Hi Everybody,

referring to the current TR1 draft
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf) and
in particular to clause 8.16.3 [tr.c99.cmath.tmpl]. I see that it's
being proposed to replace C99 classification and comparison macros
(signbit, fpclassify, etc.) with templates. It took me a minute to
understand why this is the best approach. However I have a question
about the statement "behave the same as C99 macros with corresponding
names defined in C99 subclause 7.12.3 Classification macros and C99
subclause 7.12.14 Comparison macros."

C99 macros are subject to the blanket requirement "the argument shall be
an expression of real floating type". The use of "shall" implies that it
is undefined behaviour to apply those macros to any other type. So,
given the current proposed wording of TR1, that would also be the case
in C++/TR1. However, templates allow a better control so we can do
better than that. It's obvious that a conformant implementation will
provide specializations for all real floating types, but for other types
we have several options:

1) leave the generic templates undefined (so using non-float types will
produce a link-time error)

2) implement the generic templates in a way that produces a compile time
error (for example by forcing a failed static assert)

3) implement the generic templates in a generic way, at least for those
where it may make sense, for example by implementing isgreater in terms
of operator>.

Orthogonally to those approaches above, it would be easy to provide
specializations for non-float arithmetic types. In fact all templates
except fpclassify() have an obvious implementation for integer types.

The question is: does it make sense to specify in the standard the
behaviour for non-floating point types?

If I were to answer, my answer would be yes and I would specify approach
n.2 with no exceptions for non-float arithmetic types. In standardese,
something like:

"The implementation shall provide specializations of all said templates
for each floating point type. The implementation shall not provide
additional specializations. A definition of the generic template shall
be provided in a way that an instantiation would be ill-formed."

The rationale is that it would help programmers spot unintended usages
of those templates.

Any other opinion?

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alberto Ganesh Barbati wrote:
>
> If I were to answer, my answer would be yes and I would specify approach
> n.2 with no exceptions for non-float arithmetic types.                  ]
>

Suggested standardese aside (leave drafting to us professionals <g>),
the standard doesn't distinguish between compile-time errors and
link-time errors, so there would be some new language needed just to
talk about them, not to mention the philosophical change that would also
be needed.

But more important: what errors does this prevent, and how important are
they? How do they arise? Do C programmers, for example, routinely apply
fp_classify to integral types?

Remember, every addition the standard requires wording and discussion.
Is this important enough to warrant the time needed to get it right?

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote in message
news:hVClf.73694$65.2123782@twister1.libero.it...

> referring to the current TR1 draft
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf) and
> in particular to clause 8.16.3 [tr.c99.cmath.tmpl]. I see that it's
> being proposed to replace C99 classification and comparison macros
> (signbit, fpclassify, etc.) with templates. It took me a minute to
> understand why this is the best approach. However I have a question
> about the statement "behave the same as C99 macros with corresponding
> names defined in C99 subclause 7.12.3 Classification macros and C99
> subclause 7.12.14 Comparison macros."
>
> C99 macros are subject to the blanket requirement "the argument shall be
> an expression of real floating type". The use of "shall" implies that it
> is undefined behaviour to apply those macros to any other type. So,
> given the current proposed wording of TR1, that would also be the case
> in C++/TR1. However, templates allow a better control so we can do
> better than that. It's obvious that a conformant implementation will
> provide specializations for all real floating types, but for other types
> we have several options:
>
> 1) leave the generic templates undefined (so using non-float types will
> produce a link-time error)
>
> 2) implement the generic templates in a way that produces a compile time
> error (for example by forcing a failed static assert)
>
> 3) implement the generic templates in a generic way, at least for those
> where it may make sense, for example by implementing isgreater in terms
> of operator>.
>
> Orthogonally to those approaches above, it would be easy to provide
> specializations for non-float arithmetic types. In fact all templates
> except fpclassify() have an obvious implementation for integer types.
>
> The question is: does it make sense to specify in the standard the
> behaviour for non-floating point types?
>
> If I were to answer, my answer would be yes and I would specify approach
> n.2 with no exceptions for non-float arithmetic types. In standardese,
> something like:
>
> "The implementation shall provide specializations of all said templates
> for each floating point type. The implementation shall not provide
> additional specializations. A definition of the generic template shall
> be provided in a way that an instantiation would be ill-formed."
>
> The rationale is that it would help programmers spot unintended usages
> of those templates.
>
> Any other opinion?

I think you're reading too much into the (possibly too brief)
wording. The intent was merely to replace magic macros, never
appreciated in C++, with templates specialzed for the three
floating-point types.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
> Alberto Ganesh Barbati wrote:
>> If I were to answer, my answer would be yes and I would specify approach
>> n.2 with no exceptions for non-float arithmetic types.                  ]
>
> Suggested standardese aside (leave drafting to us professionals <g>),
> the standard doesn't distinguish between compile-time errors and
> link-time errors, so there would be some new language needed just to
> talk about them, not to mention the philosophical change that would also
> be needed.

In fact, in my proposed wording I used the standard expression
"ill-formed" without any reference to when the error is to be detected
and/or diagnosed. I may not be a professional in standard writing, but
I'm not a newbie in C++. I'm sorry that my reference to solution #2 may
have raised in you the idea that I would make it a difference between
compile-time and link-time checking, but it wasn't my intention to do
so. My standardese conveyed the right intention. Are you saying that it
was so poorly written that you did not even read it?

> But more important: what errors does this prevent, and how important are
> they? How do they arise? Do C programmers, for example, routinely apply
> fp_classify to integral types?

It's conceivable that C++ programmers might inadventently use those
templates with the wrong type in heavy templated code. As C programmers
cannot write templates, they are less affected by this issue, so the
comparison is irrelevant.

> Remember, every addition the standard requires wording and discussion.
> Is this important enough to warrant the time needed to get it right?

Of course, I know that every addition needs to be discussed. We are
discussing it right now, aren't we? The problem is that I am not aware
about how much important a feature needs to be in order to be considered
"important enough". I made this proposal just because the original
paragraph sounded like it was missing something and it seemed quite
simple to me about how to complete it.

Just my opinion,

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
.
> But more important: what errors does this prevent, and how important are
> they? How do they arise? Do C programmers, for example, routinely apply
> fp_classify to integral types?

No, of course not, since they don't have the option of writing
templates, which is the context where you'd be most likely to use such
a feature. The real question is, if this feature were added to the C++
standard, how useful would it be in templated code that was intended to
be instantiated with both floating point and integral types.
Personally, I don't think it would be very useful. Maybe Alberto can
provide an example of code which makes use of such a feature, to show
us how useful it would be?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alberto Ganesh Barbati wrote:
>
> It's conceivable that C++ programmers might inadventently use those
> templates with the wrong type in heavy templated code. As C programmers
> cannot write templates, they are less affected by this issue, so the
> comparison is irrelevant.
>

It's conceivable that C programmers might inadvertently use those macros
with the wrong type in heavy macro-ized code, so the comparison is quite
relevant. But I gather the answer to my original question is that you
don't know of any evidence that this is a problem in C.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:

> Pete Becker wrote:
> .
>
>>But more important: what errors does this prevent, and how important are
>>they? How do they arise? Do C programmers, for example, routinely apply
>>fp_classify to integral types?
>
>
> No, of course not, since they don't have the option of writing
> templates, which is the context where you'd be most likely to use such
> a feature.

Sigh. fp_classify is part of C. It's a macro, yes, but C programmers use
macros. If there are significant problems in C that's evidence that we
need to be concerned.

> The real question is, if this feature were added to the C++
> standard, how useful would it be in templated code that was intended to
> be instantiated with both floating point and integral types.
> Personally, I don't think it would be very useful. Maybe Alberto can
> provide an example of code which makes use of such a feature, to show
> us how useful it would be?
>

Maybe.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
> kuyper@wizard.net wrote:
>
> > Pete Becker wrote:
> > .
> >
> >>But more important: what errors does this prevent, and how important are
> >>they? How do they arise? Do C programmers, for example, routinely apply
> >>fp_classify to integral types?
> >
> >
> > No, of course not, since they don't have the option of writing
> > templates, which is the context where you'd be most likely to use such
> > a feature.
>
> Sigh. fp_classify is part of C.

And this discussion is on comp.std.c++, and is about how fp_classify
should be brought into C++.

> ... It's a macro, yes, but C programmers use
> macros. If there are significant problems in C that's evidence that we
> need to be concerned.

I agree. Do you know of any such problems? The original poster said
nothing to suggest that there were any.

Problems of the kind that might be more easily detected if this
suggestion were approved are far more likely in templated C++ code than
in macroized C code. Therefore, the existence of such problems in C
would be a strong motivation for this change. However, even if such
problems are rare in C code, they might be very common in C++ code.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:

> Pete Becker wrote:
>
>>kuyper@wizard.net wrote:
>>
>>
>>>Pete Becker wrote:
>>>.
>>>
>>>
>>>>But more important: what errors does this prevent, and how important are
>>>>they? How do they arise? Do C programmers, for example, routinely apply
>>>>fp_classify to integral types?
>>>
>>>
>>>No, of course not, since they don't have the option of writing
>>>templates, which is the context where you'd be most likely to use such
>>>a feature.
>>
>>Sigh. fp_classify is part of C.
>
>
> And this discussion is on comp.std.c++, and is about how fp_classify
> should be brought into C++.
>

Once again: if there have been problems with fp_classify in C that would
be an indication that we need to look more carefully at the templates in
C++.

>
>>... It's a macro, yes, but C programmers use
>>macros. If there are significant problems in C that's evidence that we
>>need to be concerned.
>
>
> I agree. Do you know of any such problems?

No. If I did I'd have mentioned it.

> The original poster said
> nothing to suggest that there were any.

Nope. It's not clear to me what motivated that suggestion, which is why
I asked.

>
> Problems of the kind that might be more easily detected if this
> suggestion were approved are far more likely in templated C++ code than
> in macroized C code. Therefore, the existence of such problems in C
> would be a strong motivation for this change. However, even if such
> problems are rare in C code, they might be very common in C++ code.
>

Yes, that's what I said. I'm not at all clear on what it is in what I
said that you think you're disagreeing with.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
> kuyper@wizard.net wrote:
> > Pete Becker wrote:
> >>kuyper@wizard.net wrote:
> >>>Pete Becker wrote:
.
> > Problems of the kind that might be more easily detected if this
> > suggestion were approved are far more likely in templated C++ code than
> > in macroized C code. Therefore, the existence of such problems in C
> > would be a strong motivation for this change. However, even if such
> > problems are rare in C code, they might be very common in C++ code.
> >
>
> Yes, that's what I said. ...

I didn't understand, from what you had written, that you were even
considering the possibility that this suggestion was motivated by
template problems, much less that you recognised it as the main
motivation. I got the impression that you didn't, and apparantly still
don't, understand the motivation for this suggestion.

> ... I'm not at all clear on what it is in what I
> said that you think you're disagreeing with.

What I'm disagreeing with is your emphasis on the possibility that
problems in C were a significant motivation for this suggestion. It
seemed pretty clear to me that this change was motivated almost
entirely by possibilities that could come up with macroized code, but
are far more likely to come up in templated code. As a result, it's
really almost irrelevant whether any problems that could come up in C
code would be solved by this suggestion. The problems that could come
up in C++ code are overwhelmingly more important. The utility of this
suggestion will stand or fall based almost entirely upon whether it's a
good solution to problems in template code; the problems that could
come up in macro code aren't likely to tip the decision in either
direction.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:
> Pete Becker wrote:
>
>>kuyper@wizard.net wrote:
>>
>>>Pete Becker wrote:
>>>
>>>>kuyper@wizard.net wrote:
>>>>
>>>>>Pete Becker wrote:
>
> .
>
>>>Problems of the kind that might be more easily detected if this
>>>suggestion were approved are far more likely in templated C++ code than
>>>in macroized C code. Therefore, the existence of such problems in C
>>>would be a strong motivation for this change. However, even if such
>>>problems are rare in C code, they might be very common in C++ code.
>>>
>>
>>Yes, that's what I said. ...
>
>
> I didn't understand, from what you had written, that you were even
> considering the possibility that this suggestion was motivated by
> template problems, much less that you recognised it as the main
> motivation. I got the impression that you didn't, and apparantly still
> don't, understand the motivation for this suggestion.
>
>
>>... I'm not at all clear on what it is in what I
>>said that you think you're disagreeing with.
>
>
> What I'm disagreeing with is your emphasis on the possibility that
> problems in C were a significant motivation for this suggestion. It
> seemed pretty clear to me that this change was motivated almost
> entirely by possibilities that could come up with macroized code, but
> are far more likely to come up in templated code. As a result, it's
> really almost irrelevant whether any problems that could come up in C
> code would be solved by this suggestion. The problems that could come
> up in C++ code are overwhelmingly more important. The utility of this
> suggestion will stand or fall based almost entirely upon whether it's a
> good solution to problems in template code; the problems that could
> come up in macro code aren't likely to tip the decision in either
> direction.
>

I asked what the justification was, and in particular, asked about the
only area where there might be real-world experience with fp_classify,
namely, in C. Apparently "no, I don't know of any problems" is too
simple an answer, since the two responses to my question have been
rather defensive assertions that real-world experience with something
similar is irrelevant.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
.
> I asked what the justification was, and in particular, asked about the
> only area where there might be real-world experience with fp_classify,
> namely, in C. Apparently "no, I don't know of any problems" is too
> simple an answer, since the two responses to my question have been
> rather defensive assertions that real-world experience with something
> similar is irrelevant.

In general, real world experience with something similar is very
relevant. However, in this case there's no real world experience with
anything sufficiently similar to be helpful. This suggestion was
intended to anticipate and avoid problems that, if real, won't happen
in significant numbers until after a templated fp_classify is added to
C++.

The best approach would be to add an fp_classify template, as proposed,
as an extension to an existing compiler, in order to gain some real
world experience to help decide whether this refinement of the concept
would be helpful. Let me emphasize that I remain agnostic on that
issue.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<kuyper@wizard.net> wrote in message
news:1134352463.419372.202630@g43g2000cwa.googlegroups.com...

> Pete Becker wrote:
> .
>> I asked what the justification was, and in particular, asked about the
>> only area where there might be real-world experience with fp_classify,
>> namely, in C. Apparently "no, I don't know of any problems" is too
>> simple an answer, since the two responses to my question have been
>> rather defensive assertions that real-world experience with something
>> similar is irrelevant.
>
> In general, real world experience with something similar is very
> relevant. However, in this case there's no real world experience with
> anything sufficiently similar to be helpful. This suggestion was
> intended to anticipate and avoid problems that, if real, won't happen
> in significant numbers until after a templated fp_classify is added to
> C++.
>
> The best approach would be to add an fp_classify template, as proposed,
> as an extension to an existing compiler, in order to gain some real
> world experience to help decide whether this refinement of the concept
> would be helpful. Let me emphasize that I remain agnostic on that
> issue.

Done. We've been shipping a combined C/C++ library with fp_classify
as a template in C++ for three years now. It has been accepted as
part of C++ Library TR1, which has been approved as a non-normative
addition to the C++ Standard. So far, nobody has complained that
fp_classify doesn't work right with integer types. (I think it may
be the "fp" in the name that tips them off.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]