2 suggested new features for C++

Discussion in 'C++' started by W Karas, Jul 10, 2008.

  1. W Karas

    W Karas Guest

    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 ... ;
     
    W Karas, Jul 10, 2008
    #1
    1. Advertising

  2. W Karas

    Joe Greer Guest

    W Karas <> wrote in news:3cb466d6-76bf-4c92-ba01-
    :

    > 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
     
    Joe Greer, Jul 10, 2008
    #2
    1. Advertising

  3. W Karas

    W Karas Guest

    On Jul 10, 1:21 pm, Victor Bazarov <> wrote:
    > 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, Jul 10, 2008
    #3
  4. W Karas

    W Karas Guest

    On Jul 10, 1:45 pm, Joe Greer <> wrote:
    > W Karas <> wrote in news:3cb466d6-76bf-4c92-ba01-
    > :
    >
    > > 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, Jul 10, 2008
    #4
  5. W Karas

    W Karas Guest

    On Jul 10, 1:08 pm, W Karas <> wrote:
    > 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, Jul 10, 2008
    #5
  6. W Karas

    W Karas Guest

    On Jul 10, 3:28 pm, W Karas <> wrote:
    > On Jul 10, 1:08 pm, W Karas <> wrote:
    >
    >
    >
    > > 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, Jul 10, 2008
    #6
  7. W Karas

    W Karas Guest

    Does de facto solution nix std change? (was: 2 suggested new featuresfor C++)

    On Jul 10, 5:24 pm, W Karas <> wrote:
    > On Jul 10, 3:28 pm, W Karas <> wrote:
    >
    >
    >
    > > On Jul 10, 1:08 pm, W Karas <> wrote:

    >
    > > > 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?
     
    W Karas, Jul 10, 2008
    #7
  8. Juha Nieminen, Jul 11, 2008
    #8
  9. W Karas

    James Kanze Guest

    On Jul 11, 4:21 pm, 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


    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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 11, 2008
    #9
  10. 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...
     
    Juha Nieminen, Jul 12, 2008
    #10
  11. James Kanze wrote:
    > On Jul 11, 4:21 pm, 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

    >
    > 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.
     
    Gennaro Prota, Jul 14, 2008
    #11
  12. 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.
     
    Juha Nieminen, Jul 14, 2008
    #12
  13. W Karas

    Lionel B Guest

    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
     
    Lionel B, Jul 15, 2008
    #13
  14. 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, Jul 15, 2008
    #14
  15. 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.)
     
    Juha Nieminen, Jul 15, 2008
    #15
  16. 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.
     
    Gennaro Prota, Jul 15, 2008
    #16
  17. 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).
     
    Juha Nieminen, Jul 18, 2008
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jay

    Suggested Books

    Jay, Jul 22, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    352
    Steve C. Orr, MCSD
    Jul 22, 2003
  2. Calvin
    Replies:
    0
    Views:
    325
    Calvin
    Aug 27, 2003
  3. Replies:
    0
    Views:
    277
  4. Jonathan Mcdougall
    Replies:
    2
    Views:
    499
    Kaz Kylheku
    Nov 3, 2005
  5. BillJosephson
    Replies:
    148
    Views:
    2,665
    peter koch
    Jan 27, 2007
Loading...

Share This Page