Anyone know if the committee has committed itself to adding
DateTime/TimeSpan types and XML classes to the 0x library? If the goal
is to make additions that EVERYONE will use... surely these would score
higher than many of other fine additions that are already planned.

Also, just my $.02, it'll be easier for most of us to remember, require
less typing, and save us time searching the list of #includes in source
files to see if the one we want is already there (somewhere), if... the
handy new unordered_x classes would live in the same headers we already
know, e.g. <set> and <map>. I thought it a poor choice when I saw the
plan to have 4 new long header names.

Thanks for listening

---
[ 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                       ]

"scottz" <scottz1@hotmail.com> writes:

> Anyone know if the committee has committed itself to adding
> DateTime/TimeSpan types and XML classes to the 0x library? If the goal
> is to make additions that EVERYONE will use... surely these would score
> higher than many of other fine additions that are already planned.

No.  Nobody has brought us a proposal for either of these.

> Also, just my $.02, it'll be easier for most of us to remember, require
> less typing, and save us time searching the list of #includes in source
> files to see if the one we want is already there (somewhere), if... the
> handy new unordered_x classes would live in the same headers we already
> know, e.g. <set> and <map>. I thought it a poor choice when I saw the
> plan to have 4 new long header names.

It's a trade-off.  Some people don't want to pay the compilation-time
costs of processing definitions they're not using.

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:
> "scottz" <scottz1@hotmail.com> writes:
>
>
>>Anyone know if the committee has committed itself to adding
>>DateTime/TimeSpan types and XML classes to the 0x library? If the goal
>>is to make additions that EVERYONE will use... surely these would score
>>higher than many of other fine additions that are already planned.
>
>
> No.  Nobody has brought us a proposal for either of these.

Yesterday night I found Jeff Garlands's date-time proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1900.pdf

I keep my fingers crossed for Jeff!

Greetings,

Daniel

---
[ 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                       ]

David Abrahams wrote:
> "scottz" <scottz1@hotmail.com> writes:
>
>>Anyone know if the committee has committed itself to adding
>>DateTime/TimeSpan types and XML classes to the 0x library? If the goal
>>is to make additions that EVERYONE will use... surely these would score
>>higher than many of other fine additions that are already planned.
>
> No.  Nobody has brought us a proposal for either of these.
>

Although there's no formal proposal, for DateTime/TimeSpan we have
boost.date_time which may deserve one ;-)

For XML, the committe has been explicitly mentioned it in the TR2 call
for proposals:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html, so
definetely there is interest in it. About this issue, I believe that the
W3C did an enormous job with the DOM specifications... C++ programmers
may not like DOM (personally I found it to have a vague java-ish
flavour) but it's here to stay and gets the job done. In fact there are
already plenty of implementations. So the question is: do we really need
something different?

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                       ]

In article <uslumjz15.fsf@boost-consulting.com>,
 dave@boost-consulting.com (David Abrahams) wrote:

> "scottz" <scottz1@hotmail.com> writes:
>
> > Anyone know if the committee has committed itself to adding
> > DateTime/TimeSpan types and XML classes to the 0x library? If the goal
> > is to make additions that EVERYONE will use... surely these would score
> > higher than many of other fine additions that are already planned.
>
> No.  Nobody has brought us a proposal for either of these.

Well there is:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1900.pdf

It was briefly reviewed in Mont Tremblant and received positive feedback.

-Howard

---
[ 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                       ]

howard.hinnant@gmail.com (Howard Hinnant) writes:

> In article <uslumjz15.fsf@boost-consulting.com>,
>  dave@boost-consulting.com (David Abrahams) wrote:
>
>> "scottz" <scottz1@hotmail.com> writes:
>>
>> > Anyone know if the committee has committed itself to adding
>> > DateTime/TimeSpan types and XML classes to the 0x library? If the goal
>> > is to make additions that EVERYONE will use... surely these would score
>> > higher than many of other fine additions that are already planned.
>>
>> No.  Nobody has brought us a proposal for either of these.
>
> Well there is:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1900.pdf
>
> It was briefly reviewed in Mont Tremblant and received positive feedback.

Sorry, my Google search missed that one.

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

Yes, I realize it's a tradeoff the committee will weigh. I assume
compiler vendors on the committee are naturally interested in
compilation speed. But I think that while including some extra
declarations I may not need costs a few milliseconds when compiling,
the alternative costs in human-time are greater when programmers must
learn them, explain them, search lists of #includes for their
existence, and key the extra lines. Would anyone disagree that the
total global seconds spent discussing those new headers (including this
thread) will be orders of magnitude greater than the total global
compile time of putting them in the map/set headers?

Note that when 2 or more of these headers are needed in a given source
file, compilation time would be reduced by consolidation. Though I
don't have any statisics that say what percent of source files will use
2 or more of set/map/unordered_x.

Thanks

> > Also, just my $.02, it'll be easier for most of us to remember, require
> > less typing, and save us time searching the list of #includes in source
> > files to see if the one we want is already there (somewhere), if... the
> > handy new unordered_x classes would live in the same headers we already
> > know, e.g. <set> and <map>. I thought it a poor choice when I saw the
> > plan to have 4 new long header names.
>
> It's a trade-off.  Some people don't want to pay the compilation-time
> costs of processing definitions they're not using.
>
> --
> 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.jamesd.demon.co.uk/csc/faq.html                       ]

"scottz" <scottz1@hotmail.com> writes:

> Yes, I realize it's a tradeoff the committee will weigh. I assume
> compiler vendors on the committee are naturally interested in
> compilation speed. But I think that while including some extra
> declarations I may not need costs a few milliseconds when compiling,
> the alternative costs in human-time are greater when programmers must
> learn them, explain them, search lists of #includes for their
> existence, and key the extra lines.

At Boost we are beginning to find that the best organization is one
header per name; nobody ever has trouble remembering what header
contains boost::mpl::apply.  It's in <boost/mpl/apply.hpp>.

> Would anyone disagree that the total global seconds spent discussing
> those new headers (including this thread) will be orders of
> magnitude greater than the total global compile time of putting them
> in the map/set headers?

Not if I get out of the discussion immediately ;-)

Ciao,

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

scottz wrote:
> Yes, I realize it's a tradeoff the committee will weigh. I assume
> compiler vendors on the committee are naturally interested in
> compilation speed. But I think that while including some extra
> declarations I may not need costs a few milliseconds when compiling,
> the alternative costs in human-time are greater when programmers must
> learn them, explain them, search lists of #includes for their
> existence, and key the extra lines. Would anyone disagree that the
> total global seconds spent discussing those new headers (including this
> thread) will be orders of magnitude greater than the total global
> compile time of putting them in the map/set headers?
>

Compiling with no optimisation the following program:

--
#ifdef UNORDERED
#include <tr1/unordered_map>
#endif
#include <map>

int main(void) {}
--

(I ran these a few times first to get over the initial slowdown and get
things into cache)

time g++ prog.cc
real    0m0.488s
user    0m0.245s
sys     0m0.113s

time g++ prog.cc -DUNORDERED
real    0m5.049s
user    0m3.143s
sys     0m0.604s

I think if you imposed that on everyone, it would be quite serious!

If I use pre-compiled headers, the differences do get much smaller

With unordered_map
real    0m0.338s
user    0m0.079s
sys     0m0.149s

Without unordered_map
real    0m0.199s
user    0m0.053s
sys     0m0.078s

So, this suggests once everyone is using precompiled headers, things
should get much better

(For those who don't know, using pre-compiled headers on a recent g++ is
very easy. Just type "g++ header.h", and a new file called header.h.pch
will appear, and be automatically picked up when you include the header.
As you can see, speed improvements can be impressive.)

Chris

---
[ 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                       ]

OK, you convinced me. Thanks for the helpful replies.

---
[ 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                       ]