2 suggested new features for C++

[W Karas]

1)

Support the idiom:

p - static_cast<C::*M>(p)

C is a class.
M is a data member of C (not a type).
The value of p must implicitly convert to the type of M.
If the value of p (after conversion) is the address of
the member M of some instance of C, the result
of the "expression" has type C * and is the address of
the instance of C. Otherwise, the result is undefined.

This idiom could be supported directly, or by
allowing C::*M as a new sort of pointer, that
would only have default and copy constructors,
assignment. Otherwise only usable in this
weird new overload of -.

2)

Allow

class X.Y ... ;

to indicate that class Y can only be used as the
type of data members of class X. If Y is member
of class X, X can be omitted:

class .Y ... ;

[Victor Bazarov]

W Karas wrote:

1)

[..]

2)

[..]

Can you perhaps explain what problems those solve (that can't be solved
now by any other means)? Thanks!

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Joe Greer]

W Karas <wk****@yahoo.comwrote in news:3cb466d6-76bf-4c92-ba01-
3e**********@z72g2000hsb.googlegroups.com:

1)

Support the idiom:

Ummm, how can this be an idiom if it's new?

>
p - static_cast<C::*M>(p)

C is a class.
M is a data member of C (not a type).
The value of p must implicitly convert to the type of M.
If the value of p (after conversion) is the address of
the member M of some instance of C, the result
of the "expression" has type C * and is the address of
the instance of C. Otherwise, the result is undefined.

This idiom could be supported directly, or by
allowing C::*M as a new sort of pointer, that
would only have default and copy constructors,
assignment. Otherwise only usable in this
weird new overload of -.

What problem does this address?

>
2)

Allow

class X.Y ... ;

to indicate that class Y can only be used as the
type of data members of class X. If Y is member
of class X, X can be omitted:

class .Y ... ;

How is this different than:

class X
{
class Y
{
};

Y y;
};

Class Y can only be used by data members of class X.

joe

[W Karas]

On Jul 10, 1:21 pm, Victor Bazarov <[e-mail]:

W Karas wrote:

1)

[..]

2)

[..]

Can you perhaps explain what problems those solve (that can't be solved
now by any other means)? Thanks!

1)

The rational is the same as for having the
capability to get the address of a derived
class instance from the address of the
base class instance within the derived
class instance.

2)

Suppose you have in a class where one
member is an array and another
this is an intrusive linked list
container for elements of the array.
Suppose that the linked list uses
array indexes as links instead of
pointers. The implementation of
the class for the container would
be dependent on the instance being
in the class with the array. This
language feature would allow this
requirement to be express and enforced
by the compiler.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[W Karas]

On Jul 10, 1:45 pm, Joe Greer <[e-mail]:

W Karas <[e-mail] in news:3cb466d6-76bf-4c92-ba01-
[e-mail]:

1)

Support the idiom:

Ummm, how can this be an idiom if it's new?

p - static_cast<C::*M>(p)

C is a class.
M is a data member of C (not a type).
The value of p must implicitly convert to the type of M.
If the value of p (after conversion) is the address of
the member M of some instance of C, the result
of the "expression" has type C * and is the address of
the instance of C. Otherwise, the result is undefined.

This idiom could be supported directly, or by
allowing C::*M as a new sort of pointer, that
would only have default and copy constructors,
assignment. Otherwise only usable in this
weird new overload of -.

What problem does this address?

2)

Allow

class X.Y ... ;

to indicate that class Y can only be used as the
type of data members of class X. If Y is member
of class X, X can be omitted:

class .Y ... ;

How is this different than:

class X
{
class Y
{
};

Y y;

};

Class Y can only be used by data members of class X.

(I need to amend my original proposal to say that
Y can only be used for non-static data members of X.)

In your example, this would also be possible:

void X::foo(void) { Y y; ... }

#2 and #1 are related. The idea is that member functions
of Y should know it's safe to get the address of X
from the "this" pointer (to Y).

>
joe

[W Karas]

On Jul 10, 1:08 pm, W Karas <[e-mail]:

1)

Support the idiom:

p - static_cast<C::*M>(p)

C is a class.
M is a data member of C (not a type).
The value of p must implicitly convert to the type of M.
If the value of p (after conversion) is the address of
the member M of some instance of C, the result
of the "expression" has type C * and is the address of
the instance of C. Otherwise, the result is undefined.

This idiom could be supported directly, or by
allowing C::*M as a new sort of pointer, that
would only have default and copy constructors,
assignment. Otherwise only usable in this
weird new overload of -.

Actually a better idiom would be:

static_cast<C::*M>(p) - &(C::M)

yields the address (with type C *) of
the containing instance of C.

[W Karas]

On Jul 10, 3:28 pm, W Karas <[e-mail]:

On Jul 10, 1:08 pm, W Karas <[e-mail]:

1)

Support the idiom:

p - static_cast<C::*M>(p)

C is a class.
M is a data member of C (not a type).
The value of p must implicitly convert to the type of M.
If the value of p (after conversion) is the address of
the member M of some instance of C, the result
of the "expression" has type C * and is the address of
the instance of C. Otherwise, the result is undefined.

This idiom could be supported directly, or by
allowing C::*M as a new sort of pointer, that
would only have default and copy constructors,
assignment. Otherwise only usable in this
weird new overload of -.

Actually a better idiom would be:

static_cast<C::*M>(p) - &(C::M)

yields the address (with type C *) of
the containing instance of C.

Another possibillity would be to simply
add a new overload of - :

C *containing_C = p - &(C::M);

Or, to appropriately scare the code
maintainer, the overloaded
- here could return a instance of the
appropriate instantiation of:

namespace std
{
template<class C>
struct CONTAINING {
C *containing; };
}

changing the above to

C* containing_C =
(p - &(C::M)).containing;

[W Karas]

On Jul 10, 5:24 pm, W Karas <[e-mail]:

On Jul 10, 3:28 pm, W Karas <[e-mail]:

On Jul 10, 1:08 pm, W Karas <[e-mail]:

1)

Support the idiom:

p - static_cast<C::*M>(p)

C is a class.
M is a data member of C (not a type).
The value of p must implicitly convert to the type of M.
If the value of p (after conversion) is the address of
the member M of some instance of C, the result
of the "expression" has type C * and is the address of
the instance of C. Otherwise, the result is undefined.

This idiom could be supported directly, or by
allowing C::*M as a new sort of pointer, that
would only have default and copy constructors,
assignment. Otherwise only usable in this
weird new overload of -.

Actually a better idiom would be:

static_cast<C::*M>(p) - &(C::M)

yields the address (with type C *) of
the containing instance of C.

Another possibillity would be to simply
add a new overload of - :

C *containing_C = p - &(C::M);

Or, to appropriately scare the code
maintainer, the overloaded
- here could return a instance of the
appropriate instantiation of:

namespace std
{
template<class C>
struct CONTAINING {
C *containing; };

}

changing the above to

C* containing_C =
(p - &(C::M)).containing;

There is, of course, a solution to this problem
using reinterpret_cast<char *. The de facto
portability of this solution is very high, even
though the Standard does not guarantee the
portability of it. Is the fact that this de
facto solution exists a significant reason
why the language has not been changed to
address the issue?

[Juha Nieminen]

I apologize for shamelessly put this here, but it seemed to be a
proper place... :)

I have compiled my own C++ wishlist, if anyone is interested:

http://warp.povusers.org/cpluspluswishlist.html

[James Kanze]

On Jul 11, 4:21 pm, Juha Nieminen <[e-mail]:

I apologize for shamelessly put this here, but it seemed to be a
proper place... :)

I have compiled my own C++ wishlist, if anyone is interested:

http://warp.povusers.org/cpluspluswishlist.html

Well, my first wish would be that compilers would actually
implement the features we've got (e.g. like export).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Juha Nieminen]

James Kanze wrote:

Well, my first wish would be that compilers would actually
implement the features we've got (e.g. like export).

Not to talk about the features of the upcoming standard. I'm really
drooling over rvalue references...

[Paavo Helde]

W Karas <wk****@yahoo.comkirjutas:

On Jul 10, 1:21 pm, Victor Bazarov <[e-mail]:

>W Karas wrote:

1)

[..]

2)

[..]

Can you perhaps explain what problems those solve (that can't be solved
now by any other means)? Thanks!

1)

The rational is the same as for having the
capability to get the address of a derived
class instance from the address of the
base class instance within the derived
class instance.

This can be done now by making the classes polymorphic and using the
dynamic_cast<operator.

If this approach for inherited classes is OK, you can easily use the same
mechanism for a data member - just put this data member into a separate
class and (multiple) derive from that. The drawbacks are possible
performance loss (possibly not important in most cases) and the fact that
the inheritance cannot be private, thus making the implementation details
visible outside of the class. If I wanted to make a standards change
proposal I would instead vote for refining dynamic_cast<rules so that it
would work for such private inheritance in certain contexts (like inside
member functions of the classes involved (the one privatly inheriting and
the one inherited from)). But of course it's too late now to change
anything here.

Regards
Paavo

[Gennaro Prota]

James Kanze wrote:

On Jul 11, 4:21 pm, Juha Nieminen <[e-mail]:

> I apologize for shamelessly put this here, but it seemed to be a
proper place... :)

> I have compiled my own C++ wishlist, if anyone is interested:

>http://warp.povusers.org/cpluspluswishlist.html

Well, my first wish would be that compilers would actually
implement the features we've got (e.g. like export).

I think I gave up hoping for export in compilers not based on the EDG
front-end when H. Sutter presented his paper "Why We Can't Afford Export"

<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf>

about five years ago. The minutes of the following meeting

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1459.html>

show that pretty much nobody in the committee took it into much
consideration (see the straw poll results) but it seemed to generate
quite an outcry in the world outside. It was IMHO a "Why we
--Microsoft-- don't want to tackle export" which turned into "Why
top-most experts like Herb Sutter say that if I think I'm capable to
implement export than I haven't understood it" for every other
implementor.

And, alas, note that *even* most of the EDG-based compilers come with
export disabled.

--
Gennaro Prota | <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

[Juha Nieminen]

Gennaro Prota wrote:

I think I gave up hoping for export in compilers not based on the EDG
front-end when H. Sutter presented his paper "Why We Can't Afford Export"

If I'm not completely mistaken, the latest gcc does support export
templates.

[Lionel B]

On Mon, 14 Jul 2008 19:12:41 +0000, Juha Nieminen wrote:

Gennaro Prota wrote:

>I think I gave up hoping for export in compilers not based on the EDG
front-end when H. Sutter presented his paper "Why We Can't Afford
Export"

If I'm not completely mistaken, the latest gcc does support export
templates.

I think you may be mistaken... where did you see that? My 4.3.1 (current
stable) doesn't and the documentation under "Current development"
(http://gcc.gnu.org/onlinedocs/) still says "GCC implements the majority
of C++98 (export is a notable exception)...".

--
Lionel B

[Juha Nieminen]

Lionel B wrote:

I think you may be mistaken... where did you see that? My 4.3.1 (current
stable) doesn't and the documentation under "Current development"
(http://gcc.gnu.org/onlinedocs/) still says "GCC implements the majority
of C++98 (export is a notable exception)...".

http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

Maybe I got confused with "extern template" (which I really don't know
what it means, if it's something different than an export template).

[Juha Nieminen]

Gennaro Prota wrote:

I think I gave up hoping for export in compilers not based on the EDG
front-end when H. Sutter presented his paper "Why We Can't Afford Export"

<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf>

IMO that paper is a bit misleading in one point: It seems to make it
sound like the only (and imaginary) advantage of export templates is
that you can reorganize your code better (that is, you don't have to put
everything in header files), and that's about it. The section 2.4 is
even titled "provides little or no value".

Unless I have understood export templates incorrectly (and please
correct me if I'm wrong, I really want to get this straight), export
templates allow for better modularity (which is one of the most, if not
the single most important feature of object-oriented programming).

Without export templates (which is the current situation with
basically all compilers) it's impossible to have templated classes and
functions which have private code inside their own compilation unit
(that is, inside a nameless namespace). In other words, non-export
templates can *not* use their own private nameless namespaces because
they don't have their own private compilation unit.

Unless I'm completely mistaken (please correct me if I am), export
templates can use data and code inside a nameless namespace inside the
compilation unit where those templates are implemented. This allows for
greater modularity and data hiding. The larger the amount of data and
code inside this nameless namespace, the more important it would be for
it to be inside that namespace. (For example trying to put hundreds or
even thousands of lines of non-templated code, or unrelated templates,
inside the private section of a template class as static data and static
functions can quickly make the header file a huge mess. With template
functions you can't even do that at all.)

[Gennaro Prota]

Juha Nieminen wrote:

Gennaro Prota wrote:

>I think I gave up hoping for export in compilers not based on the EDG
front-end when H. Sutter presented his paper "Why We Can't Afford Export"

<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf>

IMO that paper is a bit misleading in one point: It seems to make it
sound like the only (and imaginary) advantage of export templates is
that you can reorganize your code better (that is, you don't have to put
everything in header files), and that's about it. The section 2.4 is
even titled "provides little or no value".

A comment that I'd actually apply to the paper :-) Frankly it is
probably the worst of all H. Sutter's writings, from a technical point
of view.

Unless I have understood export templates incorrectly (and please
correct me if I'm wrong, I really want to get this straight), export
templates allow for better modularity (which is one of the most, if not
the single most important feature of object-oriented programming).

Without export templates (which is the current situation with
basically all compilers) it's impossible to have templated classes and
functions which have private code inside their own compilation unit
(that is, inside a nameless namespace). In other words, non-export
templates can *not* use their own private nameless namespaces because
they don't have their own private compilation unit.

[further elaboration snipped...]

I believe you got it very right. I'm not saying that the world can't
leave without export but certainly the paper presents an unbalanced
view of the matter. Frankly, even the 4.5 person-years... is it such a
show-stopper for a compiler vendor? At EDG, of course, they were just
three at the time, so the issue was a tad different for them :-)

--
Gennaro Prota | <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

[Allen]

Juha Nieminen wrote:

I apologize for shamelessly put this here, but it seemed to be a
proper place... :)

I have compiled my own C++ wishlist, if anyone is interested:

http://warp.povusers.org/cpluspluswishlist.html

One feature I'd love to see is support for keyword arguments when
calling a function. When a function looks like:

void MyObject::Function(int x, int y, int z = 0 int z2 = 5 int z3 = 10)

it would be nice to be able to do something like:

a.Function(x, y, z3 <-- 20)

to specify a value for z3 without changing/specifying defaults for z and z2.

Brian Vanderburg II

[Juha Nieminen]

Allen wrote:

One feature I'd love to see is support for keyword arguments when
calling a function. When a function looks like:

void MyObject::Function(int x, int y, int z = 0 int z2 = 5 int z3 = 10)

it would be nice to be able to do something like:

a.Function(x, y, z3 <-- 20)

to specify a value for z3 without changing/specifying defaults for z and
z2.

Some programmers argue that default function parameter values are
actually bad design, at least if there are many of them. Personally I
can't decide one way or the other (but I do find them handy in many cases).