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.c omwrote in news:3cb466d6-76bf-4c92-ba01-
3e**********@z7 2g2000hsb.googl egroups.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 <v.Abaza...@com Acast.netwrote:

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 <jgr...@doublet ake.comwrote:

W Karas <wka...@yahoo.c omwrote in news:3cb466d6-76bf-4c92-ba01-
3e6f4392b...@z7 2g2000hsb.googl egroups.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.

(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 <wka...@yahoo.c omwrote:

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 <wka...@yahoo.c omwrote:

On Jul 10, 1:08 pm, W Karas <wka...@yahoo.c omwrote:

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)).contai ning;

[W Karas]

On Jul 10, 5:24 pm, W Karas <wka...@yahoo.c omwrote:

On Jul 10, 3:28 pm, W Karas <wka...@yahoo.c omwrote:

On Jul 10, 1:08 pm, W Karas <wka...@yahoo.c omwrote:

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)).contai ning;

There is, of course, a solution to this problem
using reinterpret_cas t<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 <nos...@thanks. invalidwrote:

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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]