The pre Santa Cruz mailing and the core issues list rev 66 and library
issues list rev 67 is now available from the committee web site at
http://www.open-std.org/jtc1/sc22/wg21

Best regards
keld Simonsen

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 1 oct, 18:56, Keld J   rn Simonsen <k...@dkuug.dk> wrote:
> The pre Santa Cruz mailing and the core issues list rev 66 and library
> issues list rev 67 is now available from the committee web site athttp://www.open-std.org/jtc1/sc22/wg21
>
> Best regards
> keld Simonsen
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@netlab.cs.rpi.edu]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]

Why doesn't tuple includes the member function size(), like the
containers (except forward_list) ?



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 1 oct, 18:56, Keld J   rn Simonsen <k...@dkuug.dk> wrote:
> The pre Santa Cruz mailing and the core issues list rev 66 and library
> issues list rev 67 is now available from the committee web site athttp://www.open-std.org/jtc1/sc22/wg21
>
> Best regards
> keld Simonsen
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@netlab.cs.rpi.edu]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]

I've been reading some of the things in the draft. I have some doubts:

1.- When you put a virtual function in a class. I read some time ago
that this
should implicitly generate a virtual destructor. Looking at the draft
I couldn't find anything
that mentions this. I think this should be corrected, since it is
confusing and error-prone.

2.- There is a new trait: is_explicitly_convertible. I think that
is_convertible should be renamed
to is_implicitly_convertible for name consistency.

And another thing. I think the default thing for overloading
general functions, such as std::begin and end should be:

template <class T>
[] begin(T && t) -> decltype(t.begin()) { return t.begin(); }

This way you can overload everything as a member function. For
iterators, I would suggest to do the
same than for allocators in the traits class. So instead of calling
operator++ in generic code, it should
be called:

iterator_traits<iter>::operator++(iter)

and so on. Doing this kind (this description for iterators is not
accurate, but you know what I mean if
yout take into account categories and so on) of adaptation you
could adapt your own iterators that don't have operator++ but, for
example, nextElem().

This way you can adapt any class that is an iterator but has different
names for the functions.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Oct 4, 8:17 am, german diago <germandi...@gmail.com> wrote:
> template <class T>
> [] begin(T && t) -> decltype(t.begin()) { return t.begin(); }

Just to make sure, the reason you are using an Rvalue-reference and
not a normal reference is that a normal reference wouldn't work on
temporaries, and that a const reference wouldn't allow mutating
iterators?

If so, would having the 2 declaraions below also work?

template <class T>
[] begin(T & t) -> decltype(t.begin()) { return t.begin(); }
template <class T>
[] begin(const T & t) -> decltype(t.begin()) { return t.begin(); }


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 4 Okt., 08:17, german diago <germandi...@gmail.com> wrote:
[..]
> Why doesn't tuple includes the member function size(), like the
> containers (except forward_list) ?

The size of tuple's is a pure compile-time thing. You can use
std::tuple_size applied on the tuple type to realize the same
thing. If the type is not at your hand, just use decltype on the
expression that represents your tuple, e.g.

std::tuple_size<decltype(t)>::value;

assuming that t is your tuple object.

HTH & Greetings from Bremen,

Daniel Kr   gler



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 4 Okt., 08:17, german diago <germandi...@gmail.com> wrote:

[..]

> I've been reading some of the things in the draft. I have some doubts:
>
> 1.- When you put a virtual function in a class. I read some time ago
> that this
> should implicitly generate a virtual destructor. Looking at the draft
> I couldn't find anything
> that mentions this. I think this should be corrected, since it is
> confusing and error-prone.

I tend to disagree. In fact adding a virtual function signals that
you want to take advantage of runtime polymorphism for this
function, adding a virtual destructor means that you want runtime
polymorphism for delete. In principle both are separate issues,
because I can take advantage of runtime polymorphism of a
function without any usage of the free store:

#include <iostream>

struct IP { virtual void operator()() = 0; };
struct P : IP { virtual void operator()() { std::cout << "Hi, I'm
P"; } };

void action(IP& p) { p(); }

int main() {
 P p;
 action(p);
}

For production code this kind of example is probably
irrelevant, but on the other hand I consider this "problem"
as a tool problem: A reasonable IDE should allow you
to generate class definitions on the fly that have such
a virtual destructor added.

> 2.- There is a new trait: is_explicitly_convertible. I think that
> is_convertible should be renamed
> to is_implicitly_convertible for name consistency.

I agree that this probably cleaner from a linguistic point of
view. But I also tend to say that is_convertible will typically
have more use-cases than is_explicitly_convertible, so the
name should be more simple.
But the dust has not yet settled, maybe more people have
the same view as you and so I keep your opinion in mind ;-)

> And another thing. I think the default thing for overloading
> general functions, such as std::begin and end should be:
>
> template <class T>
> [] begin(T && t) -> decltype(t.begin()) { return t.begin(); }
>
> This way you can overload everything as a member function.

As tohava replied there exists an overload set that is near
to this. I'm not yet convinced that it is very reasonable to
actively support mutable r-value references. Can you present
a non-artificial example which the current proposal does
not properly cover and would therefore require mutable
rvalue support?

> For iterators, I would suggest to do the same than for allocators
> in the traits class. So instead of calling operator++ in generic
> code, it should be called:
>
> iterator_traits<iter>::operator++(iter)
>
> and so on. Doing this kind (this description for iterators is not
> accurate, but you know what I mean if
> yout take into account categories and so on) of adaptation you
> could adapt your own iterators that don't have operator++ but, for
> example, nextElem().
>
> This way you can adapt any class that is an iterator but has
> different names for the functions.

Basically I sympathize with the idea. But I fear that defining
the complete specification of this so late in the process
is impossible. But if you have a more detailed plan, I strongly
encourage you to send a corresponding proposal to the
standard committee.

Greetings from Bremen,

Daniel Kr   gler




--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> Basically I sympathize with the idea. But I fear that defining
> the complete specification of this so late in the process
> is impossible. But if you have a more detailed plan, I strongly
> encourage you to send a corresponding proposal to the
> standard committee.

Ok, I'm posting now an initial implementation, with an example of
an iterator adapted.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Oct 4, 1:06 pm, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> Basically I sympathize with the idea. But I fear that defining
> the complete specification of this so late in the process
> is impossible. But if you have a more detailed plan, I strongly
> encourage you to send a corresponding proposal to the
> standard committee.
>
> Greetings from Bremen,
>
> Daniel Kr   gler

I don't think it's worth the effort with concepts forthcoming (albeit
delayed). Concepts address the very problem of needing traits classes
for everything, and do so in a far far more elegant manner. I'd much
prefer the committee just work on getting concepts out the door than
to waste their time trying to improve the usability of a feature they
intend to replace.

Sean Hunt


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 1 Oct, 20:56, Keld J   rn Simonsen <k...@dkuug.dk> wrote:
> The pre Santa Cruz mailing and the core issues list rev 66 and library
> issues list rev 67 is now available from the committee web site athttp://www.open-std.org/jtc1/sc22/wg21

Could anybody explain why local classes still can't have template
members? When local classes couldn't be used as template parameters
there was no usable case for one's template members. But in C++0x I
see at least two cases for such members:

1. Localize template parameter-dependent code inside template
function. Now global (and local) namespaces "polluted" with classes
(and functions) which are only specializes some functionality for
certain types or types combinations (look into the 'algorithm'
standard header, for example).
2. Make polymorphic function wrappers very simple. For example:

class Foo
{
public:
  typedef boost::variant<int, std::string, double> var_type;

  void Process(var_type const& v)
  {
     struct Processor : boost::static_visitor<>
     {
        Foo* m_Object;
        Processor(Foo* obj) : m_Object(obj) {;}
        template<typename T> void operator()(T val) const {m_Object-
>Process(val);}
     } p(this);

     boost::apply_visitor(p, v);
  }
private:

  void Process(int a);
  void Process(std::string const& a);
  void Process(double a);
};

Is is sufficient reasons to allow template members in local classes or
there is some significant reasons to disallow this extension which are
hidden from me?

----------------
Best regards,
Flex Ferrum.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]