new keywords for (C++)++

[Gernot Frisch]

When someone thinks about a new version of C++, how about including
these:

-----------------------
typeof:
class A
{
public:
void foo();
} a;

typefo(a) b;
b.foo();

-----------------------
typeofbase:

class A
{
public:
foo();
};

class B : public A
{
foo() {typeofbase::foo();} // calls: A::foo();
};

 

[Bob Hairgrove]

When someone thinks about a new version of C++, how about including
these:

[snip]

comp.std.c++ is the place to ask this question.

 

[Pete Becker]

When someone thinks about a new version of C++, how about including
these:

As Bob Hairgrove said, clc++ is the place for this. But a suggestion:
instead of proposing keywords, talk about what problem you're trying to
solve. Syntax comes later.

 

[Howard]

When someone thinks about a new version of C++, how about including these:

-----------------------
typeof:
class A
{
public:
void foo();
} a;

typefo(a) b;
b.foo();

-----------------------
typeofbase:

class A
{
public:
foo();
};

class B : public A
{
foo() {typeofbase::foo();} // calls: A::foo();
};

Why would you need that? Can't you just look and see the type you want? It
looks like all you're saving is some effort on your part to know what you're
doing. It's not like you suddenly want a new type for b because you're
changing the type of a, or that your base class simply changes at some
point. Such changes would generally involve how you use the objects, not
just their type. Do you have a real-world problem that this solves?

-Howard

 

[Arkadiy]

Why would you need that? Can't you just look and see the type you want? It
looks like all you're saving is some effort on your part to know what you're
doing. It's not like you suddenly want a new type for b because you're
changing the type of a, or that your base class simply changes at some
point. Such changes would generally involve how you use the objects, not
just their type. Do you have a real-world problem that this solves?

Here are a couple of examples where typeof/decltype/auto would be
useful:

1)

#include <boost/lambda/lambda.hpp>
using namespace boost::lambda;

auto var = 15 < _1 && _1 < 20;

(the type is too complicated to specify by hand)

2)

template<class T, class U>
typeof(T() + U()) add(T t, U u)
{
return t + u;
}

(it's impossible to specify the type by hand)

A library-based implementation of typeof has been recently accepted
into Boost and will most likely become available as a part of Boost
starting version 1.34. See
http://boost-sandbox.sourceforge.net/vault/, typeof.zip for the current
version.

Regards,
Arkadiy

 

[Victor Bazarov]

Howard wrote:

Why would you need that? [...]

Here are a couple of examples where typeof/decltype/auto would be
useful: [...]

To put your discussion to end, there is a proposal to introduce the
keyword 'decltype' and reuse 'auto' for those purposes. See N1607:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf

I am surprised that you kept posting about those, the proposal has been
around for quite a while. Perhaps you should just go to the Standard
Committee site (http://www.open-std.org/jtc1/sc22/wg21/) and peruse it
for some time before arguing again...

V

 

[Arkadiy]

Why would you need that? Can't you just look and see the type you want? It
looks like all you're saving is some effort on your part to know what you're
doing. It's not like you suddenly want a new type for b because you're
changing the type of a, or that your base class simply changes at some
point. Such changes would generally involve how you use the objects, not
just their type. Do you have a real-world problem that this solves?

Here are a couple of examples where typeof/decltype/auto would be
useful:

1)

#include <boost/lambda/lambda.hpp>
using namespace boost::lambda;

auto var = 15 < _1 && _1 < 20;

(the type is too complicated to specify by hand)

2)

template<class T, class U>
typeof(T() + U()) add(T t, U u)
{
return t + u;
}

(it's impossible to specify the type by hand)

A library-based implementation of typeof has been recently accepted
into Boost and will most likely become available as a part of Boost
starting version 1.34. See
http://boost-sandbox.sourceforge.net/vault/, typeof.zip for the current
version.

Regards,
Arkadiy

 

[Arkadiy]

Well, if you like you can wait until this proposal is accepted, and
then until the compiler vendors implement it...

Or you can have something that works right now (see the Boost sandbox
file vault).

Regards,
Arkadiy

 

[Victor Bazarov]

Well, if you like you can wait until this proposal is accepted, and
then until the compiler vendors implement it...

Or you can have something that works right now (see the Boost sandbox
file vault).

I am not sure I understand. Works right now how? You're proposing new
keywords to be added to the language, no? Without actually adding them
(and that's the job for compiler implementors) how is "something" going
to satisfy your need for new keywords?

V

 

[Pete Becker]

I am not sure I understand. Works right now how? You're proposing new
keywords to be added to the language, no? Without actually adding them
(and that's the job for compiler implementors) how is "something" going
to satisfy your need for new keywords?

And, of course, this raises the complementary question: if there's
something that works right now, why is a new keyword needed?

 

[Arkadiy]

I am not proposing new keywords added -- other people are, and I do
agree with them.

However, the process of implementing language changes is quite lengthy.
OTOH, the feature is so useful that one can benefit even from the
limited solution a library can implement.

In our case the limitation is that one has to "tell" the library about
user-defined types/templates by "registering" them, something like:

BOOST_TYPEOF_REGISTER_TYPE(foo)
BOOST_TYPEOF_REGISTER_TEMPLATE(bar, 2) // 2 template parameters

After this is done any combination of registered types/templates can be
handled, in case of my earlier lambda example:

BOOST_AUTO(x, 15 < _1 && _1 < 20); /* equivalent to: auto x = 15 < _1
&& _1 < 20; */

Regards,
Arkadiy

 

[Arkadiy]

Because a library-based solution has limitations that can't be avoided.

Regards,
Arkadiy