Pete Becker wrote:
> Thorsten Ottosen wrote:
>
>>
>> Ditto for auto/decltype which pretty much makes result_of obsolete.
>>
>
> Not at all obsolete, if you care about existing code.
>

What exisint code? It has never been in namespace std, only in tr1.

-Thorsten

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

David Abrahams wrote:
> Pete Becker <petebecker@acm.org> writes:
>
>
>>Thorsten Ottosen wrote:
>>
>>
>>>Ditto for auto/decltype which pretty much makes result_of obsolete.
>>>
>>
>>Not at all obsolete, if you care about existing code.
>
>
> s/obsolete/trivial to implement/
>

Not really, unless I'm missing something. Note that Thorsten's reference
to "auto/decltype" is a bit misleading: the proposed enhancements to
auto were adopted, but there is no decltype. With auto the compiler will
infer the type of a declared variable from its initializer. That's
several steps away from determining the return type of a function type.

--

Pete Becker
Roundhouse Consulting, Ltd.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

David Abrahams wrote:
> Pete Becker <petebecker@acm.org> writes:
>
>
>>Thorsten Ottosen wrote:
>>
>>
>>>Ditto for auto/decltype which pretty much makes result_of obsolete.
>>>
>>
>>Not at all obsolete, if you care about existing code.
>
>
> s/obsolete/trivial to implement/
>

Ignore the reply I just made, talking about "auto/decltype." I was
narrowly focused on what was approved in Berlin, not on the blue sky
talk about possible futures.

--

Pete Becker
Roundhouse Consulting, Ltd.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

At the ACCU conference in April, I thought I heard that all of TR1 except the
mathematical special functions had been voted into the C++0x working paper, but
in the May DDJ (which I realize contains material written weeks or months ago),
Pete Becker writes that "some of what's in TR1 will become part of Standard C++
in the next revision, but much of it will not."

Can somebody in the know please clarify what the relationship is likely to be
between functionality specified in TR1 and functionality specified as part of
the C++0x library?  I'd expected that C++0x might tweak TR1 functionality, but
Pete's comment above suggests that he foresees more that just tweaking.

Thanks,

Scott

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:

> At the ACCU conference in April, I thought I heard that all of TR1
> except the mathematical special functions had been voted into the C++0x
> working paper, but in the May DDJ (which I realize contains material
> written weeks or months ago), Pete Becker writes that "some of what's in
> TR1 will become part of Standard C++ in the next revision, but much of
> it will not."

That was my reading of the mood at the time. All of TR1 except the
mathematical special functions were voted into the C++0x working draft
at the Berlin meeting last month.

--

Pete Becker
Roundhouse Consulting, Ltd.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Scott Meyers" <usenet@aristeia.com> wrote in message
news:125d3upc4tdva3e@corp.supernews.com...

> At the ACCU conference in April, I thought I heard that all of TR1 except
> the mathematical special functions had been voted into the C++0x working
> paper, but in the May DDJ (which I realize contains material written weeks
> or months ago), Pete Becker writes that "some of what's in TR1 will become
> part of Standard C++ in the next revision, but much of it will not."
>
> Can somebody in the know please clarify what the relationship is likely to
> be between functionality specified in TR1 and functionality specified as
> part of the C++0x library?  I'd expected that C++0x might tweak TR1
> functionality, but Pete's comment above suggests that he foresees more
> that just tweaking.

The C++ committee did indeed vote to all all of TR1 except special math to
the draft C++ Standard. That was more than many of us expected, as heralded
by Pete's earlier writing. Now that it's in C++0x, the TR1 material will
doubtless evolve, particularly as it interacts with other significant
additions planned for C++0x.

HTH,

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.comeaucomputing.com/csc/faq.html                      ]

Out of curiosity, why were the mathematical special functions not voted
in?  Was there just not enough time to review or vote or are there some
technical problems?

Many thanks,

Kevin Hall

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <125d3upc4tdva3e@corp.supernews.com>,
 usenet@aristeia.com (Scott Meyers) wrote:

> At the ACCU conference in April, I thought I heard that all of TR1 except the
> mathematical special functions had been voted into the C++0x working paper,
> but
> in the May DDJ (which I realize contains material written weeks or months
> ago),
> Pete Becker writes that "some of what's in TR1 will become part of Standard
> C++
> in the next revision, but much of it will not."
>
> Can somebody in the know please clarify what the relationship is likely to be
> between functionality specified in TR1 and functionality specified as part of
> the C++0x library?  I'd expected that C++0x might tweak TR1 functionality,
> but
> Pete's comment above suggests that he foresees more that just tweaking.

On April 7, 2006, the C++ committee voted everything in TR1 into the
C++0X working draft except the chapter on special math functions.  In
the C++0X working draft, these items will be in namespace std instead of
namespace std::tr1.

The committee is expecting that there will continue to be some tweaks to
these components:  they are not now set in stone in the C++0X working
draft.  Indeed some changes are known to be coming in the random number
library, and I personally have some minor modifications to propose in
the type traits library.

Should language changes be accepted into C++0X which obsolete or
significantly modify these libraries, they will be changed in response
(e.g. rvalue reference, lambda functions, and variadic templates could
have significant impact).

Howard
Library Working Group Chair

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

usenet@aristeia.com (Scott Meyers) wrote:
>At the ACCU conference in April, I thought I heard that all of TR1 except the
>mathematical special functions had been voted into the C++0x working paper, but

Yes. For more about what happened at the meeting, see the minutes:

  Minutes of J16 Meeting No. 42/WG21 Meeting No. 37, April 3-7, 2006
  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1993.html

BTW, the easiest way to find WG21 minutes for a given meeting/year is to
Google for "wg21 2006 minutes". In general, the easiest way to find any
WG21 doc is to Google for "wg21 <doc number>". That's what I always do,
because it's quicker than navigating my own hard drive even though I know
where the doc is. The minutes are usually available online about 2-3 weeks
after the meeting.

>in the May DDJ (which I realize contains material written weeks or months ago),
>Pete Becker writes that "some of what's in TR1 will become part of Standard C++
>in the next revision, but much of it will not."

Right, though I think Pete did a good job setting expectations in advance
when no one can confidently predict what the committee will decide to do
on a given day. :-) (BTW, Pete, very nice article!)

FWIW, if I wanted to justify Pete's "much," I could see one justification
for calling the special math functions "much" of TR1: Although the math
special functions only count for about a dozen pages of TR1, they account
for "much" of the effort required to implement TR1. (I don't think that
they require as much as the rest of TR1 put together, but Pete and
Dinkumware in general could answer that since they did the work.) Those
functions are tricky and subtle, in part because they require an extremely
high bar for precision and accuracy, and any requirement with
"floating-point" and "precision and accuracy" in the same mouthful is
bound to cause many sleepless nights...

>Can somebody in the know please clarify what the relationship is likely to be
>between functionality specified in TR1 and functionality specified as part of
>the C++0x library?  I'd expected that C++0x might tweak TR1 functionality, but
>Pete's comment above suggests that he foresees more that just tweaking.

On April 7 this year, everything in TR1 except special maths got voted
into the working draft for C++0x.But yes, do expect minor tweaks to the
TR1 and other stuff that got voted in. I'm still rooting for function<>
equality comparison, myself...

BTW, other work voted into the draft includes the following, with links to
papers for those who are interested in following along at home:


Right angle brackets: Fixed so as to<work<sensibly>> without annoying
required whitespace. The fix is the same that C++/CLI specified. The paper
is:

  N1757 , "Right Angle Brackets (Revision 2)".
  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1757.html


Auto type deduction: This permits you to write declarations like

  auto x = 3.1415926535;
  auto i = container.begin();

where the type is deduced from the initializer, so x has type double, and
i has type map<string,EmployeeList>::const_iterator or whatever the right
type happens to be, without having to spell it out. The paper is:

  N1984, "Deducing the type of variable from its initializer expression
(revision 4)".
  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1984.pdf


Delegating constructors: A combined WG21 / C++/CLI proposal, though it was
cut from the first edition of C++/CLI; if C++/CLI does add this it will
follow this that WG21 has adopted (plus any future tweaks). The paper is:

  N1986 , "Delegating Constructors (revision 3)".
  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1986.pdf


Extern template:

  N1987 , "Adding 'extern template' (version 2)".
  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1987.htm


Enjoy,

Herb

---
Herb Sutter (www.gotw.ca)      (www.pluralsight.com/blogs/hsutter)

Convener, ISO WG21 (C++ standards committee)     (www.gotw.ca/iso)
Architect, Developer Division, Microsoft   (www.gotw.ca/microsoft)

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

<kevin.hall@motioneng.com> wrote in message
news:1146581224.786325.145300@j73g2000cwa.googlegroups.com...

> Out of curiosity, why were the mathematical special functions not voted
> in?  Was there just not enough time to review or vote or are there some
> technical problems?

Some of the opinions expressed in the discussion prior to the vote:

-- they're too hard to implement

-- there's really only one vendor (Dinkumware)

-- there's no open-source version available

-- they serve too narrow a constituency

(Forgive me if I've been too glib in characterizing some of these
positions, or if I've left any out.)

There's truth in all of these opinions, but it's worth observing that
they also all apply to the long double versions of tgamma, lgamma,
erf, and erfc -- which *were* voted in along with the rest of the C99
additions to the Standard C library. The main difference is that
the C99 stuff has been around an extra decade, and does have several
adequate double implementations.

Chris Walker and I at Dinkumware have invested an extraordinary
amount of time the past few years implementing all the C99 and
special math functions, in all the IEEE precisions from 24 bits to
113. The result is a very high quality set of functions, and tests
to go with them. But more importantly, we've learned a lot about
how to characterize the regions where it just plain doesn't make
sense to approximate certain functions numerically. Our next step
is to concoct good standards language to capture what we now can
demonstrate in pretty graphs. Once we do that, I believe that
the barrier to other implementers will go down quite a bit. We'll
also have better guidance for programmers in using *all* math
functions, including the old standbys. And it may just be easier
to justify the inclusion of the special math functions in C++0x.

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.comeaucomputing.com/csc/faq.html                      ]

Howard Hinnant wrote:

> Should language changes be accepted into C++0X which obsolete or
> significantly modify these libraries, they will be changed in response
> (e.g. rvalue reference, lambda functions, and variadic templates could
> have significant impact).

Ditto for auto/decltype which pretty much makes result_of obsolete.

-Thorsten

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

P.J. Plauger wrote:
>
> Some of the opinions expressed in the discussion prior to the vote:
>
> -- they're too hard to implement
>
> -- there's really only one vendor (Dinkumware)
>
> -- there's no open-source version available
>
> -- they serve too narrow a constituency
>

  -- too hard to test

--

Pete Becker
Roundhouse Consulting, Ltd.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Thorsten Ottosen wrote:

>
> Ditto for auto/decltype which pretty much makes result_of obsolete.
>

Not at all obsolete, if you care about existing code.

--

Pete Becker
Roundhouse Consulting, Ltd.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Pete Becker <petebecker@acm.org> writes:

> Thorsten Ottosen wrote:
>
>> Ditto for auto/decltype which pretty much makes result_of obsolete.
>>
>
> Not at all obsolete, if you care about existing code.

s/obsolete/trivial to implement/

;-)

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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.comeaucomputing.com/csc/faq.html                      ]