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 ... ;

[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.c omkirjutas:

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.

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

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<ru les 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 <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).

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::Funct ion(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::Funct ion(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).