>Let's hear your ideas.


1. typedef for return type of container insert to avoid the
std::pair<mymap_t::iterator, bool> x = mymap.insert(...)

2. find member function which works for any argument where operator<
defined.
struct mystruct {
  string key;
  int member1;
  ...
  friend bool operator<(const mystruct& l, const mystruct& r) { return
l.key < r.key; }
  friend bool operator<(const mystruct& l, const string& r) { return
l.key < r; }
  friend bool operator<(const string& l, const mystruct& r) { return l
< r.key; }
};
std::set<mystruct> myset;

myset.find("abc");

instead of

mystruct x;
x.key = "abc"
myset.find(x);

3. time_punct facet
Store locale specific time and date formats in a facet instead of using
strftime to format %x, %c etc.
Makes it possible to change date delimiter without rewriting the entire
time_put & time_get facets. Also makes it at least theoreticly possible
to parse local date/time strings.

4. Remove currency symbol from money_punct facet.
Currency (if any) should be part of the streamed value not fixed in the
locale.

5. Add a separator character to iosbase (defaults to EOF which means
ctype::isspace)

cout >> setseparator(',') >> 1 >> separator >> "several words";
cin >> setseparator(',') >> myint >> separator >> mystring;

(This would also make it easier to add container streaming)

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

wpcmame@hotmail.com wrote:
> >Let's hear your ideas.
>
>
> 1. typedef for return type of container insert to avoid the
> std::pair<mymap_t::iterator, bool> x = mymap.insert(...)

auto is going to make that easy:

auto x = mymap.insert(...);

> 2. find member function which works for any argument where operator<
> defined.
> struct mystruct {
>   string key;
>   int member1;
>   ...
>   friend bool operator<(const mystruct& l, const mystruct& r) { return
> l.key < r.key; }
>   friend bool operator<(const mystruct& l, const string& r) { return
> l.key < r; }
>   friend bool operator<(const string& l, const mystruct& r) { return l
> < r.key; }
> };
> std::set<mystruct> myset;
>
> myset.find("abc");
>
> instead of
>
> mystruct x;
> x.key = "abc"
> myset.find(x);

incidently I did put this on my list :-)


br

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

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20050830121148.3192A@brangdon.m...
> hinnant@metrowerks.com (Howard Hinnant) wrote (abridged):
>> > I agree the "void" syntax is tricky. Last time I raised this, someone
>> > suggested using a question mark:
>> >
>> >     int i = ?;  // leave i uninitialized?
>>
>> Or we could change the language so that it is very convenient, and even
>> more useful to delay local variable declaration until you can
>> initialize it at the same time ... oops, we already did that.
>
> Not for member variables. They have to be declared in the class and
> initialised in each constructor.
>
>
>> Maybe compilers could detect reads from uninitialized variables and
>> issue warnings.  This could even be augmented with lint-like tools ...
>> oops, we did that too.
>
> I don't know of a compiler which warns about uninitialised member
> variables. The fact that some warn about local variables shows that the
> problem is real, and the fact that they don't all warn about all
> situations shows the current solution is only partial.
>
>
>> Instead today we have people complaining that vector<double> is
>> > unusable in their context:
>>
>> vector<double> v(1000000);  // zero'd, too expensive
>>
>> It would have been far better to let the above be uninitialized
>> doubles, and let the following be zero'd
>>
>> vector<double> v(1000000, 0);  // explicitly zero'd
>
> I disagree. We need both initialised and uninitialised variables, so the
> question is what the default should be. It sounds like you want the
> default to be fast and dangerous. Code like:
>
>     vector<double> v( 10 );
>     v.push_back( 0.0 );
>
> would be undefined behaviour because it copies uninitialised doubles. In
> my view this would be too dangerous. Skipping the initialisation step is a
> performance optimisation. Doing so by default is premature optimisation.
>
>
>> Don't get me wrong, I'm a big fan of safety.  But when the safety comes
>> at an O(N) (or worse) performance cost, I'll do without thank you very
>> much.
>
> That is why we are discussing a syntax for uninitialised variables.
>
>
>> So here we are today with a hybrid zero/no-op scalar default construct
>> system.  Where to go from here?  Please let's not make it any worse
>> than it already is.
>
> Although the performance issues are greatest for vector, I think a uniform
> syntax which also handled local variables and class member variables would
> be better than treating vector as a special case. The "void" suggestion is
> a bit confusing, we don't want another keyword, hence "?".
>
> As to the mechanics, I suspect it should be represented by a special type,
> with nominal conversions to every other type. And I don't think that type
> is void.

Yes.

void can be thought of as a special type which has only one distinguished
value - call this value (). In type theory and functional programming the
analogue of void is usually called 1. For every type T, there is a unique
mapping from T into 1 - which just returns (). Dually there is a type 0 such
that for every type T there is a unique mapping from 0 into T. 0 is a
special type which does not have any values - hence the unique mappings from
0 into T are all empty. Undefined expressions have type 0. ? is an undefined
expression (as it does not have a value) and 0 is the type-theoretic
analogue of the type of ?.

Sam


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

Hi Michiel,

I don't think we want to open that can of worms.

Take your example:

int i = void(); // leave i uninitialized

We already have a way to leave i uninitialized:

int i; // leave i uninitialized

We cannot deprecate that, and take this example:

void foo();
int i = foo(); // leave i uninitialized?

Should that be a compile error? Why? Why not?

Cheers,
Anders Dalvander

msalters wrote:
>
> Why no spell it void()? That looks like an expression.
>

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

google@dalvander.com (Anders Dalvander) wrote (abridged):
> We already have a way to leave i uninitialized:
>
> int i; // leave i uninitialized
>
> We cannot deprecate that

Why not? If the above is changed in C++0x to default-initialise i, how
could any conforming C++99 program tell the difference?


> void foo();
> int i = foo(); // leave i uninitialized?

I agree the "void" syntax is tricky. Last time I raised this, someone
suggested using a question mark:

    int i = ?;  // leave i uninitialized?

-- Dave Harris, Nottingham, UK.

---
[ 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 <memo.20050827135702.2736A@brangdon.m>,
 brangdon@cix.co.uk (Dave Harris) wrote:

> google@dalvander.com (Anders Dalvander) wrote (abridged):
> > We already have a way to leave i uninitialized:
> >
> > int i; // leave i uninitialized
> >
> > We cannot deprecate that
>
> Why not? If the above is changed in C++0x to default-initialise i, how
> could any conforming C++99 program tell the difference?
>
>
> > void foo();
> > int i = foo(); // leave i uninitialized?
>
> I agree the "void" syntax is tricky. Last time I raised this, someone
> suggested using a question mark:
>
>     int i = ?;  // leave i uninitialized?

Or we could change the language so that it is very convenient, and even
more useful to delay local variable declaration until you can initialize
it at the same time ... oops, we already did that.

Maybe compilers could detect reads from uninitialized variables and
issue warnings.  This could even be augmented with lint-like tools ...
oops, we did that too.

Today's C++ is very much more complicated because of the fight over what
it means to default construct a scalar.  Sometimes it is zeroed and
sometimes it is not.  It makes scalars and user-defined types behave
differently.  I understand the motivations that led to today's C++.  But
hindsight is 20/20 and if we had a clean slate I'd do it differently
today.

Imho it would have been much simpler if C++'98 had just said:  the
default constructor for a scalar is a no-op.  There's not a single
context where such behavior can't be overridden with an easy and
intuitive syntax.

The motivating use case for today's behavior is std::map<scalar,
value>::operator[] where you really want a zero-initialized scalar
instead of default constructed scalar when an insert happens.  Using
what we know today, that could have easily been solved with a brief and
efficient utility:

#include <type_traits>

namespace detail
{

template <class T>
inline
T
zero_or_default_ctor(std::tr1::true_type)
{
    return T(0);
}

template <class T>
inline
T
zero_or_default_ctor(std::tr1::false_type)
{
    return T();
}

}  // detail

template <class T>
inline
T
zero_or_default_ctor()
{
    return detail::zero_or_default_ctor<T>(std::tr1::is_scalar<T>());
}

int i = zero_or_default_ctor<int>();   // zero'd
A   a = zero_or_default_ctor<A>();     // default constructed

Instead today we have people complaining that vector<double> is unusable
in their context:

vector<double> v(1000000);  // zero'd, too expensive

It would have been far better to let the above be uninitialized doubles,
and let the following be zero'd

vector<double> v(1000000, 0);  // explicitly zero'd

Instead there's no way today to get an uninitialized vector of scalar
and the proposals to do so are more complicated because of the decisions
reasonably made a decade ago when we had less experience:

struct no_initialize
{
    template <class T>
    void (T*, size_t) {}
};

vector<double> v(1000000, initialize());  // uninitialized

Don't get me wrong, I'm a big fan of safety.  But when the safety comes
at an O(N) (or worse) performance cost, I'll do without thank you very
much.  I know a Hummer is safer to drive than a Civic.  But I'm not
willing to pay the costs associated with all that extra steel just to
get to the grocery store and back.

So here we are today with a hybrid zero/no-op scalar default construct
system.  Where to go from here?  Please let's not make it any worse than
it already is.

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

Maybe we could define an std::uninitialized_vector class, which could
only be instantiated for POD classes, and with a reducde functionality
over std::vector, and it woudl do the trick in a nice way

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

Anders Dalvander schreef:

> Hi Michiel,
>
> I don't think we want to open that can of worms.
>
> Take your example:
>
> int i = void(); // leave i uninitialized
.
> void foo();
> int i = foo(); // leave i uninitialized?
>
> Should that be a compile error? Why? Why not?

Compile error. There's no conversion from void to int. Note
that void() does not create an object of type void. It is
implemented using compiler magic. You can't return it, or
use it in any other context.

Regards,
Michiel Salters

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

"msalters" <Michiel.Salters@logicacmg.com> wrote in message
news:1125301570.758893.206080@f14g2000cwb.googlegroups.com...
>
> Anders Dalvander schreef:
>
>> Hi Michiel,
>>
>> I don't think we want to open that can of worms.
>>
>> Take your example:
>>
>> int i = void(); // leave i uninitialized
> .
>> void foo();
>> int i = foo(); // leave i uninitialized?
>>
>> Should that be a compile error? Why? Why not?
>
> Compile error. There's no conversion from void to int. Note
> that void() does not create an object of type void. It is
> implemented using compiler magic. You can't return it, or
> use it in any other context.
>

   Then, in the code that started this discussion,
    vector<int> vec(10000, void());
how is the above constructor declared?

Joe Gottman

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

hinnant@metrowerks.com (Howard Hinnant) wrote (abridged):
> > I agree the "void" syntax is tricky. Last time I raised this, someone
> > suggested using a question mark:
> >
> >     int i = ?;  // leave i uninitialized?
>
> Or we could change the language so that it is very convenient, and even
> more useful to delay local variable declaration until you can
> initialize it at the same time ... oops, we already did that.

Not for member variables. They have to be declared in the class and
initialised in each constructor.


> Maybe compilers could detect reads from uninitialized variables and
> issue warnings.  This could even be augmented with lint-like tools ...
> oops, we did that too.

I don't know of a compiler which warns about uninitialised member
variables. The fact that some warn about local variables shows that the
problem is real, and the fact that they don't all warn about all
situations shows the current solution is only partial.


> Instead today we have people complaining that vector<double> is
> > unusable in their context:
>
> vector<double> v(1000000);  // zero'd, too expensive
>
> It would have been far better to let the above be uninitialized
> doubles, and let the following be zero'd
>
> vector<double> v(1000000, 0);  // explicitly zero'd

I disagree. We need both initialised and uninitialised variables, so the
question is what the default should be. It sounds like you want the
default to be fast and dangerous. Code like:

     vector<double> v( 10 );
     v.push_back( 0.0 );

would be undefined behaviour because it copies uninitialised doubles. In
my view this would be too dangerous. Skipping the initialisation step is a
performance optimisation. Doing so by default is premature optimisation.


> Don't get me wrong, I'm a big fan of safety.  But when the safety comes
> at an O(N) (or worse) performance cost, I'll do without thank you very
> much.

That is why we are discussing a syntax for uninitialised variables.


> So here we are today with a hybrid zero/no-op scalar default construct
> system.  Where to go from here?  Please let's not make it any worse
> than it already is.

Although the performance issues are greatest for vector, I think a uniform
syntax which also handled local variables and class member variables would
be better than treating vector as a special case. The "void" suggestion is
a bit confusing, we don't want another keyword, hence "?".

As to the mechanics, I suspect it should be represented by a special type,
with nominal conversions to every other type. And I don't think that type
is void.

-- Dave Harris, Nottingham, UK.

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

brangdon@cix.co.uk (Dave Harris) writes:

[...]

| > Maybe compilers could detect reads from uninitialized variables and
| > issue warnings.  This could even be augmented with lint-like tools ...
| > oops, we did that too.
|
| I don't know of a compiler which warns about uninitialised member
| variables.

GCC-4.x does.

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

Bit invasive, but I've sometimes wished we could use negative numbers
to denote container element's position relative to end().  E.g.
my_string[-1] for the last character.  Imagine it'd be a major pain to
implement and test such a change through the interfaces, and cause a
deal of bloat.  Plus there's the backward compatibility bit: the signed
type could be required to be bigger than any value of size_type,
although it's tempting to make them the same size and risk breaking
code.  Depending on differences between signed and unsigned is dodgy
though - could cause problems for classes with implicit conversion to
both, but such code probably deserves problems, and there are the usual
problems with implicit conversion between signed and unsigned in many
contexts that could bite end-users even if the STL was itself ok.
Cheers, Tony

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

Gabriel Dos Reis wrote:
<snip>
> GCC-4.x does.
<snip>

Interesting. Mine (4.0.1) doesn't. Please share the
respective command line flags that make it do so.

Marc

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

marc@klaralvdalens-datakonsult.se (Marc Mutz) writes:

| Gabriel Dos Reis wrote:
| > brangdon@cix.co.uk (Dave Harris) writes:
| >
| > [...]
| >
| > | > Maybe compilers could detect reads from uninitialized variables and
| > | > issue warnings.  This could even be augmented with lint-like tools ...
| > | > oops, we did that too.
| > |
| > | I don't know of a compiler which warns about uninitialised member
| > | variables.
| >
| > GCC-4.x does.
|
| Interesting. Mine (4.0.1) doesn't. Please share the
| respective command line flags that make it do so.

"-Wuninitialized -O2".

   % cat mm.C && g++ -Wuninitialized -O2 -c mm.C
   struct A {
      int i;
   };

   void f(A);

   int main()
   {
      A a;
      f(a);
   }
   mm.C: In function 'int main()':
   mm.C:10: warning: 'a$i' is used uninitialized in this function

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

Tony Delroy wrote:

> Bit invasive, but I've sometimes wished we could use negative numbers
> to denote container element's position relative to end().  E.g.
> my_string[-1] for the last character.  Imagine it'd be a major pain to
> implement and test such a change through the interfaces, and cause a
> deal of bloat.  Plus there's the backward compatibility bit: the
> signed type could be required to be bigger than any value of
> size_type, although it's tempting to make them the same size and risk
> breaking
> code. <snip>

A major complication of this proposal is that it makes the subscripting
behaviour of containers and plain arrays subtly different.
If p is a pointer into (the middle of) an array object, then the
expression 'p[-1]' is entirely valid and yields the value of the
element before p.

This subtle difference will also make it harder to use the feature in
generic code, because you may not know if you are operating on an STL
container or on a plain array.

> Cheers, Tony

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

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

<garthdickie@gmail.com> wrote in message
news:1124248853.468519.15200@o13g2000cwo.googlegroups.com...
> Jim King posted a suggestion a few years ago for std::set set-theoretic
> operators:
>
>
http://groups.google.com/group/comp.std.c++/tree/browse_frm/thread/34ce925366074bd5/e9bbf1c4c3c32a35?rnum=1&hl=en&q=james+e+king&_done=%2Fgroup%2Fcomp.std.c%2B%2B%2Fbrowse_frm%2Fthread%2F34ce925366074bd5%2Fe9bbf1c4c3c32a35%3Fq%3Djames+e+king%26rnum%3D2%26hl%3Den%26#doc_e9bbf1c4c3c32a35

nice little post

> I have been using his implementation for more than three years, and it
> certainly makes it a lot easier to deal with sets.

yes, that would be the main argument.

performane wise I have also considered that it should be possible tp
"splice" two sets (or maps for that sake), and these operators
do all that.

His implmentation of uset is far from optimal. I imagine that
member operations that move elements from one set to another
can move the nodes themselves and thus completely avoid
allocations.

> The operators are union ( operator | ), intersection ( operator & ),
> symmetric difference ( operator ^ ), and set difference ( operator - ),
> as well as the in-place versions |=, &=, ^=, and -=.

it all seems fairly simple to specify.

I'll seriously consider it.

Thanks

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

""Thorsten Ottosen"" <nesotto@cs.aau.dk> wrote in message
news:4303a7ce$0$18645$14726298@news.sunsite.dk...
>
> <garthdickie@gmail.com> wrote in message
> news:1124248853.468519.15200@o13g2000cwo.googlegroups.com...
>> Jim King posted a suggestion a few years ago for std::set set-theoretic
>> operators:
> http://groups.google.com/group/comp.std.c++/tree/browse_frm/thread/34ce925366074bd5/e9bbf1c4c3c32a35?rnum=1&hl=en&q=james+e+king&_done=%2Fgroup%2Fcomp.std.c%2B%2B%2Fbrowse_frm%2Fthread%2F34ce925366074bd5%2Fe9bbf1c4c3c32a35%3Fq%3Djames+e+king%26rnum%3D2%26hl%3Den%26#doc_e9bbf1c4c3c32a35
>
> nice little post
>
>> I have been using his implementation for more than three years, and it
>> certainly makes it a lot easier to deal with sets.
>
> yes, that would be the main argument.
>
> performane wise I have also considered that it should be possible tp
> "splice" two sets (or maps for that sake), and these operators
> do all that.
>
> His implmentation of uset is far from optimal. I imagine that
> member operations that move elements from one set to another
> can move the nodes themselves and thus completely avoid
> allocations.
>
>> The operators are union ( operator | ), intersection ( operator & ),
>> symmetric difference ( operator ^ ), and set difference ( operator - ),
>> as well as the in-place versions |=, &=, ^=, and -=.
>
> it all seems fairly simple to specify.
>
> I'll seriously consider it.

This one gets my vote as well. I've had several projects that would have
benefited from the availability of such functionality.

Jeff Flinn




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

""Jeff Flinn"" <NONONE@nowhere.com> wrote in message
news:de1up3$q7g$1@bluegill.adi.com...
>
> ""Thorsten Ottosen"" <nesotto@cs.aau.dk> wrote in message
> news:4303a7ce$0$18645$14726298@news.sunsite.dk...
>>
>> <garthdickie@gmail.com> wrote in message
>> news:1124248853.468519.15200@o13g2000cwo.googlegroups.com...
>>> Jim King posted a suggestion a few years ago for std::set set-theoretic
>>> operators:
>> http://groups.google.com/group/comp.std.c++/tree/browse_frm/thread/34ce925366074bd5/e9bbf1c4c3c32a35?rnum=1&hl=en&q=james+e+king&_done=%2Fgroup%2Fcomp.std.c%2B%2B%2Fbrowse_frm%2Fthread%2F34ce925366074bd5%2Fe9bbf1c4c3c32a35%3Fq%3Djames+e+king%26rnum%3D2%26hl%3Den%26#doc_e9bbf1c4c3c32a35
>>
>> nice little post
>>
>>> I have been using his implementation for more than three years, and it
>>> certainly makes it a lot easier to deal with sets.
>>
>> yes, that would be the main argument.
>>
>> performane wise I have also considered that it should be possible tp
>> "splice" two sets (or maps for that sake), and these operators
>> do all that.
>>
>> His implmentation of uset is far from optimal. I imagine that
>> member operations that move elements from one set to another
>> can move the nodes themselves and thus completely avoid
>> allocations.
>>
>>> The operators are union ( operator | ), intersection ( operator & ),
>>> symmetric difference ( operator ^ ), and set difference ( operator - ),
>>> as well as the in-place versions |=, &=, ^=, and -=.
>>
>> it all seems fairly simple to specify.
>>
>> I'll seriously consider it.
>
> This one gets my vote as well. I've had several projects that would have
> benefited from the availability of such functionality.
>

   Note also that std::set_union, set_intersection, etc. don't work with
hashed containers because they require sorted ranges.  If we add these for
associative sets we might as well do the same for hashed sets.

Joe Gottman

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

I think standard library could be extended so that the following
program could be legal:

#include <main>

void main(std::vector<std::string> const & args)
{
    (...)
}

<main> would be a system header that be something like:

#include <vector>
#include <string>

void main(std::vector<std::string> const & args);

int main(int  argc, char * argv[])
{
    std::vector<std::string> args(argc);
    for (int index=0;index<argc;++index) args[i]=argv[i];

}

That should give an "STLed" way of writing the main function of a
programa, and would link it to the concrete library implementation
being used.

Just to forget c strings.

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

"Zara" <yozara@terra.es> wrote in message
news:1124802816.743943.15170@g49g2000cwa.googlegroups.com...
> I think standard library could be extended so that the following
> program could be legal:
>
> #include <main>
>
> void main(std::vector<std::string> const & args)
> {
>     (...)
> }

> That should give an "STLed" way of writing the main function of a
> programa, and would link it to the concrete library implementation
> being used.
>
> Just to forget c strings.

well, the above is nice, but usually not enough when you really need
parse options.

http://www.boost.org/doc/html/program_options.html

shows how much that is actually needed.

br

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

I've just thought of another possible cute feature.  I've occasionally seen
posts on this board complaining about the fact that the code
    vector<double> vec(1000);
zero-initializes the vector.  If the vector is to be used as an
output-buffer for instance, this may cost more time than the user would
like.  What if we made it possible to say something like
    vector<double> vec(1000, no_init);
to create a vector<double> of size 1000 without zero-initializing it?
no_init would be a special value, like ignore in the sequence
    int x, z;
    tie(x, ignore, z) =  tuple<int, int, int>(1,2,3); // now x = 1 and z =
3.

Of course, this constructor would have to require that the vector's
value_type be a POD, but it could be very useful for people who need to
squeeze the last ounce of speed out of their programs.  Also, if we do add
this constructor, we would also want to be able to say
    vec.resize(2000, no_init);
as well, with this version of resize() also requiring that the vector's
value_type be a POD.

It might also be possible to add this functionality for deque and list, but
I don't see this as nearly as useful.

Joe Gottman

---
[ 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 <009Pe.46776$ll3.540047@twister.southeast.rr.com>,
 jgottman@carolina.rr.com ("Joe Gottman") wrote:

> I've just thought of another possible cute feature.  I've occasionally seen
> posts on this board complaining about the fact that the code
>     vector<double> vec(1000);
> zero-initializes the vector.  If the vector is to be used as an
> output-buffer for instance, this may cost more time than the user would
> like.  What if we made it possible to say something like
>     vector<double> vec(1000, no_init);
> to create a vector<double> of size 1000 without zero-initializing it?
> no_init would be a special value, like ignore in the sequence
>     int x, z;
>     tie(x, ignore, z) =  tuple<int, int, int>(1,2,3); // now x = 1 and z =
> 3.
>
> Of course, this constructor would have to require that the vector's
> value_type be a POD, but it could be very useful for people who need to
> squeeze the last ounce of speed out of their programs.  Also, if we do add
> this constructor, we would also want to be able to say
>     vec.resize(2000, no_init);
> as well, with this version of resize() also requiring that the vector's
> value_type be a POD.
>
> It might also be possible to add this functionality for deque and list, but
> I don't see this as nearly as useful.

You'll get more milage out of:

template <class T, class A>
class vector {
..
    template <class F> vector(size_type n, F f);
..
};

used like:

struct no_init
{
        template <class T>
          void operator()(T*, size_t) {}
};

std::vector<double> vec(1000, no_init());

This has the added advantage of being able to initialize your vector
with legacy C code:

extern "C" int interpol(const double *x, const double *fx, int n,
                                      const double *z, double *pz, int m);


inline
vector<double>
interpolate(const vector<double>& x,
            const vector<double>& fx,
            const vector<double>& z)
{
  assert(x.size() == fx.size());
  return vector<double>
   (
     z.size(),
     bind
     (
       interpol,
       x.data(), fx.data(), x.size(),
       z.data(), _1, _2
     )
   );
}

In the example above, the returned vector is sized and then initialized
by calling the legacy C interpol function.  bind is used to adapt the
interface of the legacy C function into the f(T*, size) functor that
vector is looking for.

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

"Joe Gottman" schreef:

> I've just thought of another possible cute feature.  I've occasionally seen
> posts on this board complaining about the fact that the code
>     vector<double> vec(1000);
> zero-initializes the vector.  If the vector is to be used as an
> output-buffer for instance, this may cost more time than the user would
> like.  What if we made it possible to say something like
>     vector<double> vec(1000, no_init);
> to create a vector<double> of size 1000 without zero-initializing it?

Why no spell it void()? That looks like an expression.

vector<double> vec(1000, void() );

Of course, we could generalize that:

int i = void(); // leave i uninitialized

The reason you'd do that is to make int i; equal to int i = int();
This doesn't break existing programs (they'd have to assume i could
be anything, 0 included) but makes it easier for new programmers.
The void() syntax would again be a performance optimalization.

HTH,
Michiel Salters

---
[ 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" <hinnant@metrowerks.com> wrote in message
news:hinnant-5C213E.09463625082005@syrcnyrdrs-01-ge0.nyroc.rr.com...
> In article <009Pe.46776$ll3.540047@twister.southeast.rr.com>,
> jgottman@carolina.rr.com ("Joe Gottman") wrote:
>
>> I've just thought of another possible cute feature.  I've occasionally
>> seen
>> posts on this board complaining about the fact that the code
>>     vector<double> vec(1000);
>> zero-initializes the vector.  If the vector is to be used as an
>> output-buffer for instance, this may cost more time than the user would
>> like.  What if we made it possible to say something like
>>     vector<double> vec(1000, no_init);
>> to create a vector<double> of size 1000 without zero-initializing it?
>> no_init would be a special value, like ignore in the sequence
>>     int x, z;
>>     tie(x, ignore, z) =  tuple<int, int, int>(1,2,3); // now x = 1 and z
>> =
>> 3.
>>
>> Of course, this constructor would have to require that the vector's
>> value_type be a POD, but it could be very useful for people who need to
>> squeeze the last ounce of speed out of their programs.  Also, if we do
>> add
>> this constructor, we would also want to be able to say
>>     vec.resize(2000, no_init);
>> as well, with this version of resize() also requiring that the vector's
>> value_type be a POD.
>>
>> It might also be possible to add this functionality for deque and list,
>> but
>> I don't see this as nearly as useful.
>
> You'll get more milage out of:
>
> template <class T, class A>
> class vector {
> ..
>    template <class F> vector(size_type n, F f);
> ..
> };
>
> used like:
>
> struct no_init
> {
>  template <class T>
>    void operator()(T*, size_t) {}
> };
>
> std::vector<double> vec(1000, no_init());
>
> This has the added advantage of being able to initialize your vector
> with legacy C code:
>
> extern "C" int interpol(const double *x, const double *fx, int n,
>             const double *z, double *pz, int m);
>
>
> inline
> vector<double>
> interpolate(const vector<double>& x,
>            const vector<double>& fx,
>            const vector<double>& z)
> {
>  assert(x.size() == fx.size());
>  return vector<double>
>   (
>     z.size(),
>     bind
>     (
>       interpol,
>       x.data(), fx.data(), x.size(),
>       z.data(), _1, _2
>     )
>   );
> }
>
> In the example above, the returned vector is sized and then initialized
> by calling the legacy C interpol function.  bind is used to adapt the
> interface of the legacy C function into the f(T*, size) functor that
> vector is looking for.

   How would this interact with the current vector::vector(size_t, const
value_type &, const Allocator &) constructor? Currently, if I write
     vector<double> vec(1000, 42);
the compiler will correctly call that constructor, converting 42 from an int
to a double.  Would your proposed template constructor get called in this
case?  Unless one of the concepts proposals is accepted I'm afraid that it
would.  My original proposal is a non-template constructor, and
decltype(no_init) would not be convertible to or from any other type, so it
would probably be much safer.

Joe Gottman

---
[ 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 <E9uPe.55128$ll3.629270@twister.southeast.rr.com>,
 jgottman@carolina.rr.com ("Joe Gottman") wrote:

> > template <class T, class A>
> > class vector {
> > ..
> >    template <class F> vector(size_type n, F f);
> > ..
> > };

>    How would this interact with the current vector::vector(size_t, const
> value_type &, const Allocator &) constructor? Currently, if I write
>      vector<double> vec(1000, 42);
> the compiler will correctly call that constructor, converting 42 from an int
> to a double.  Would your proposed template constructor get called in this
> case?  Unless one of the concepts proposals is accepted I'm afraid that it
> would.  My original proposal is a non-template constructor, and
> decltype(no_init) would not be convertible to or from any other type, so it
> would probably be much safer.

It would need a "do the right thing" clause analogous to 23.1.1p9-p11.
What we have going for us now that we didn't in '98 is enable_if and
powerful static introspection capabilities for implementation details.

There would be 3 constructors competing in this area for attention
(instead of the two today):

vector(size_type n, const value_type& value);
template <class InputIterator>
   vector(InputIterator first, InputIterator last);
template <class F> vector(size_type n, F f);

And for consistency the constructor I've proposed should probably have a
defaulted allocator_type parameter (as the others do).

The current WP allows for much stricter concept checking on
InputIterator than did C++03 (see N1804 and lwg 438).

I recommend that a requirement of F be that it not be convertible to
value_type.

This is all quite implementable in C++03 (I've prototyped it), quite
safe, and quite pleasant to work with.  Unfortunately I have not had
time to write it up. ;-(

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

Jim King posted a suggestion a few years ago for std::set set-theoretic
operators:

http://groups.google.com/group/comp.std.c++/tree/browse_frm/thread/34ce925366074bd5/e9bbf1c4c3c32a35?rnum=1&hl=en&q=james+e+king&_done=%2Fgroup%2Fcomp.std.c%2B%2B%2Fbrowse_frm%2Fthread%2F34ce925366074bd5%2Fe9bbf1c4c3c32a35%3Fq%3Djames+e+king%26rnum%3D2%26hl%3Den%26#doc_e9bbf1c4c3c32a35

I have been using his implementation for more than three years, and it
certainly makes it a lot easier to deal with sets.

The operators are union ( operator | ), intersection ( operator & ),
symmetric difference ( operator ^ ), and set difference ( operator - ),
as well as the in-place versions |=, &=, ^=, and -=.

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