Re: . as an alternative to m_

Discussion in 'C++' started by Pascal J. Bourguignon, Aug 6, 2008.

  1. "Chris Becke" <> writes:

    > I know this isn't the place for suggestions, but I just need to vent. Why
    > dont c++ compilers let us use . as way of saying "this->", and hence an
    > alternative for m_
    >
    > struct foo {
    > int a;
    > void bar(int a){
    > .a = a;
    > }
    > };


    Ok, we cannot #define . but we could write:

    #define member this->

    struct foo {
    int a;
    void bar(int a){
    member a = a;
    }
    };

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Aug 6, 2008
    #1
    1. Advertising

  2. Pascal J. Bourguignon

    James Kanze Guest

    On Aug 6, 11:17 am, (Pascal J. Bourguignon)
    wrote:
    > "Chris Becke" <> writes:
    > > I know this isn't the place for suggestions, but I just need to vent. Why
    > > dont c++ compilers let us use . as way of saying "this->", and hence an
    > > alternative for m_


    > > struct foo {
    > > int a;
    > > void bar(int a){
    > > .a = a;
    > > }
    > > };


    > Ok, we cannot #define . but we could write:


    > #define member this->


    > struct foo {
    > int a;
    > void bar(int a){
    > member a = a;
    > }
    > };


    Now that should drive a reader really nuts, asking himself what
    the type member is.

    Since you're interested in obfucation: C++ allows Unicode
    characters in variable names, so you can use something like AMO
    (that's U+0041,U+004D,U+004F) for the member, and AMO (that's
    U+0386,U+029C,U+039F) for argument. That way, both look right.

    --
    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, Aug 6, 2008
    #2
    1. Advertising

  3. Pascal J. Bourguignon

    Bo Persson Guest

    Victor Bazarov wrote:
    > James Kanze wrote:
    >> On Aug 6, 11:17 am, (Pascal J. Bourguignon)
    >> wrote:
    >>> "Chris Becke" <> writes:
    >>>> I know this isn't the place for suggestions, but I just need to
    >>>> vent. Why dont c++ compilers let us use . as way of saying
    >>>> "this->", and hence an alternative for m_

    >>
    >>>> struct foo {
    >>>> int a;
    >>>> void bar(int a){
    >>>> .a = a;
    >>>> }
    >>>> };

    >>
    >>> Ok, we cannot #define . but we could write:

    >>
    >>> #define member this->

    >>
    >>> struct foo {
    >>> int a;
    >>> void bar(int a){
    >>> member a = a;
    >>> }
    >>> };

    >>
    >> Now that should drive a reader really nuts, asking himself what
    >> the type member is.

    >
    > Isn't the whole point of standard and user-defined conversions that
    > I shouldn't care what type 'a' (the member) is?
    >
    > V


    I think James says that the syntax is already taken. What is the
    difference between these:

    member a = a;
    int a = a:
    mytype a = a;


    Not to mention the fact that "member" is just as long as "this->".
    :)


    Bo Persson
    Bo Persson, Aug 6, 2008
    #3
  4. "Bo Persson" <> writes:

    > Victor Bazarov wrote:
    >> James Kanze wrote:
    >>> On Aug 6, 11:17 am, (Pascal J. Bourguignon)
    >>> wrote:
    >>>> "Chris Becke" <> writes:
    >>>>> I know this isn't the place for suggestions, but I just need to
    >>>>> vent. Why dont c++ compilers let us use . as way of saying
    >>>>> "this->", and hence an alternative for m_
    >>>
    >>>>> struct foo {
    >>>>> int a;
    >>>>> void bar(int a){
    >>>>> .a = a;
    >>>>> }
    >>>>> };
    >>>
    >>>> Ok, we cannot #define . but we could write:
    >>>
    >>>> #define member this->
    >>>
    >>>> struct foo {
    >>>> int a;
    >>>> void bar(int a){
    >>>> member a = a;
    >>>> }
    >>>> };
    >>>
    >>> Now that should drive a reader really nuts, asking himself what
    >>> the type member is.

    >>
    >> Isn't the whole point of standard and user-defined conversions that
    >> I shouldn't care what type 'a' (the member) is?
    >>
    >> V

    >
    > I think James says that the syntax is already taken. What is the
    > difference between these:
    >
    > member a = a;
    > int a = a:
    > mytype a = a;


    Well some more advanced languages use the same form for different
    notions and this doesn't pose any problem in practice.

    C++ers can differentiate between a(b) and a(b) too, so I don't
    think this new member keyword would be confused with a type.

    class C{
    protected: int a;
    public: C(int b): a(b) {}};
    void a(int b) { typedef unsigned long a;
    std::cout<< a(b) ;}
    void f(int b){ a(b) ;}


    > Not to mention the fact that "member" is just as long as "this->".
    > :)


    Yes, but so much more explicit than .a :)

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Aug 7, 2008
    #4
  5. Pascal J. Bourguignon

    kwikius Guest

    Pascal J. Bourguignon wrote:

    > C++ers can differentiate between a(b) and a(b) too, so I don't
    > think this new member keyword would be confused with a type.


    Yes but AFAICS Bjarne Stroutrup clearly sees that as not that helpful
    and we know that it causes confusion and ambiguities in the grammar,
    hence the uniform initialiser syntax:

    T a{b} ; initialisation

    T a(b); should be function decl only

    IMO that would be preferable and if I ever get a C++0x compiler I'd
    certainly prefer the curly init.

    regards
    Andy Little
    kwikius, Aug 7, 2008
    #5
  6. kwikius <> writes:

    > Pascal J. Bourguignon wrote:
    >
    >> C++ers can differentiate between a(b) and a(b) too, so I don't
    >> think this new member keyword would be confused with a type.

    >
    > Yes but AFAICS Bjarne Stroutrup clearly sees that as not that helpful
    > and we know that it causes confusion and ambiguities in the grammar,
    > hence the uniform initialiser syntax:
    >
    > T a{b} ; initialisation
    >
    > T a(b); should be function decl only
    >
    > IMO that would be preferable and if I ever get a C++0x compiler I'd
    > certainly prefer the curly init.


    Indeed. I don't advocate syntactic ambiguity either. In fact I'd
    prefer a solution more explicit and more homogeneous.


    For example, like:

    (defvar a T b)
    (defvar a (function (b) T)) ; since the type of the function a would be (function (b) T)

    (defvar p double 3.141592d0)
    (defvar s (function (double) double) sin)

    (s p) ; calls (sin 3.141592d0)

    ;-)

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Aug 7, 2008
    #6
  7. Pascal J. Bourguignon

    kwikius Guest

    Chris Becke wrote:
    > "kwikius" <> wrote in message news:489adc5f$...
    >> Pascal J. Bourguignon wrote:
    >>
    >>> C++ers can differentiate between a(b) and a(b) too, so I don't
    >>> think this new member keyword would be confused with a type.

    >> Yes but AFAICS Bjarne Stroutrup clearly sees that as not that helpful
    >> and we know that it causes confusion and ambiguities in the grammar,
    >> hence the uniform initialiser syntax:
    >>
    >> T a{b} ; initialisation
    >>
    >> T a(b); should be function decl only
    >>
    >> IMO that would be preferable and if I ever get a C++0x compiler I'd
    >> certainly prefer the curly init.

    >
    > Hey. Does that mean we'll eventually get to call functions with []'s? I mean, arrays are functions too.
    >

    we already do :

    map["key"] = val;

    regards
    And Little
    kwikius, Aug 12, 2008
    #7
    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. Metin Yerlikaya

    an alternative method to do divided clocks

    Metin Yerlikaya, Feb 15, 2005, in forum: VHDL
    Replies:
    4
    Views:
    636
    John_H
    Feb 15, 2005
  2. Carl Ogawa
    Replies:
    1
    Views:
    465
  3. Bootstrap Bill

    Alternative to Regular Expressions?

    Bootstrap Bill, May 8, 2004, in forum: Perl
    Replies:
    5
    Views:
    1,186
  4. Xanathos
    Replies:
    0
    Views:
    459
    Xanathos
    Feb 2, 2005
  5. Donato Pace
    Replies:
    3
    Views:
    562
    Andy Peters
    Jan 27, 2006
Loading...

Share This Page