Richard Smith wrote:

> Perhaps the solution is not to introduce some new C#-like property
> syntax, but instead to have a way of saying that a member should take
> up no space.  The bit-field syntax already provides a way of doing this
> (though only integral or enum types are currently allowed, and zero has
> a special meaning).  It would only take a very minor language change to
> make the following legal
>
>   struct C {
>     struct {
>       operator int() const { return 42; }
>     } m : 0;
>   };
>

I think there's an issue that affects any solution that relies on
"property objects" -- basically, the inability to overload the "."
operator means that we can't construct a type that behaves like a
reference...so we can't create a property type T1 that behaves like a
T2&.  We can, however, create a function which (when called) behaves
like a T2& (because it returns a T2&).  That's one of the reasons for
wanting to implement "properties" as function calls rather than as
objects (even zero sized ones).

Now, I did think about the idea of zero-sized reference members, but
that led to other snarls.  For instance, getting "const correct"
behavior from reference members requires special rules, while ordinary
member function overloading gives us the "right" behavior for free.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Yechezkel Mett wrote:

> Have a look at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf

Thanks! That's just the sort of thing I was looking for.

How was this received by the committee?  Is it under active
consideration?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> Yechezkel Mett wrote:
>
>> Have a look at
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf
>
> Thanks! That's just the sort of thing I was looking for.
>
> How was this received by the committee?  Is it under active
> consideration?
>
"State of C++ Evolution (after Berlin 2006 Meeting)"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2011.htm
puts it in
"Still under consideration in evolution, but no clear progress to WP status"

which I understand to mean it still has a chance, but it's not actively
being worked on.

Yechezkel Mett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Yechezkel Mett wrote:
> johnchx2@yahoo.com wrote:
> > Yechezkel Mett wrote:
> >
> >> Have a look at
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf
> >
> > Thanks! That's just the sort of thing I was looking for.
> >
> > How was this received by the committee?  Is it under active
> > consideration?
> >
> "State of C++ Evolution (after Berlin 2006 Meeting)"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2011.htm
> puts it in
> "Still under consideration in evolution, but no clear progress to WP status"
>
> which I understand to mean it still has a chance, but it's not actively
> being worked on.
>
> Yechezkel Mett

There seems to be at least one ambiguity not addressed in the paper
(unless I missed it).

struct x
{
  operator int(){ return 1; }
  int operator()(){ return 2; }
};

x& foo() implicit { static x x_; return x_; }

int i = foo(); // foo().x::operator() or foo().x::operator int() ?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

wade@stoner.com wrote:

> There seems to be at least one ambiguity not addressed in the paper
> (unless I missed it).
>
> struct x
> {
>   operator int(){ return 1; }
>   int operator()(){ return 2; }
> };
>
> x& foo() implicit { static x x_; return x_; }
>
> int i = foo(); // foo().x::operator() or foo().x::operator int() ?
>


It may not be stated explicitly, but from the definition, which say
that it "...is implicitly called whenever it is mentioned in an
expression context," I'd say that the meaning of the above would have
to be "call foo and apply operator() to the result."  (Which means that
a function declared implicit *cannot* be called with the ordinary
function call syntax.)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In the last few months, I've noticed a number of postings with feature
proposals and/or work-arounds to simulate features, including:

  (a) using anonymous unions to simulate zero-size member
      references and introduce "properties" into the language

  (b) using unions or new language features to allow "named
      access" to array elements

What they have in common is a desire to bind a name to an arbitrary
object (including a member, a base class, and/or an array element),
without space overhead.  Currently, we can accomplish this by using
functions which return references, which is nice enough, but which
requires the the function-call syntax at the point of use -- which some
find unwieldy and inconvenient.

I'm wondering whether it would be feasible -- without doing too much
harm to the grammar -- to make the "()" operator optional when calling
a function without arguments.  (This would obviously be a "future"
proposal, for C++1x.)

Has anyone attempted to craft language to implement such a change,
and/or hashed out the major problems and road-blocks?  Alternatively,
is this something that's already been looked into and graded "no-way,
no-how?"

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> In the last few months, I've noticed a number of postings with feature
> proposals and/or work-arounds to simulate features, including:
>
>  (a) using anonymous unions to simulate zero-size member
>      references and introduce "properties" into the language
>
>  (b) using unions or new language features to allow "named
>      access" to array elements
>
> What they have in common is a desire to bind a name to an arbitrary
> object (including a member, a base class, and/or an array element),
> without space overhead.  Currently, we can accomplish this by using
> functions which return references, which is nice enough, but which
> requires the the function-call syntax at the point of use -- which
> some find unwieldy and inconvenient.
>
> I'm wondering whether it would be feasible -- without doing too much
> harm to the grammar -- to make the "()" operator optional when calling
> a function without arguments.  (This would obviously be a "future"
> proposal, for C++1x.)
>
> Has anyone attempted to craft language to implement such a change,
> and/or hashed out the major problems and road-blocks?  Alternatively,
> is this something that's already been looked into and graded "no-way,
> no-how?"

What does the expression with '&' followed by a name of such function
yield?  Is that the address of the object returned by the function or
is it a pointer to that function?

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
>
> I'm wondering whether it would be feasible -- without doing too much
> harm to the grammar -- to make the "()" operator optional when calling
> a function without arguments.  (This would obviously be a "future"
> proposal, for C++1x.)

A function name without () is already a valid expression of the function
type, which is often converted to a pointer to the function. With your
suggestion, the meaning of a function name in an expression becomes
ambiguous; do you have any idea how to resolve the ambiguity?

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

John posted:

> Has anyone attempted to craft language to implement such a change,
> and/or hashed out the major problems and road-blocks?


Here would be another example of where things would go wrong:

int Func(double)
{
    return 5;
}

void DoStuff(int (*)(double)) {}
void DoStuff(int) {}

int main()
{
    DoStuff(Func);

    /* This should call the function
       pointer overload. */
}



--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Seungbeom Kim wrote:

> A function name without () is already a valid expression of the function
> type, which is often converted to a pointer to the function.

Good point.  I've mainly been thinking in terms of non-static member
functions called via the member selection (.) operator, though it would
be nifty to encompass non-member function calls too.  But, as you point
out, non-member functions have slightly different semantics -- you can
use their names to form references-to-functions and
pointers-to-functions.

So any change would have to be limited to non-static member functions.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Victor Bazarov" wrote:

> What does the expression with '&' followed by a name of such function
> yield?  Is that the address of the object returned by the function or
> is it a pointer to that function?

I think that can be avoided by limiting the scope of the change to
non-static member functions.  Which is a pity, but I don't think there
is a good answer to your question regarding non-member functions.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

John posted:

> Currently, we can accomplish this by using
> functions which return references, which is nice enough, but which
> requires the the function-call syntax at the point of use -- which some
> find unwieldy and inconvenient.


Have you considered the likes of the following?

class MyClass {
public:

    class MemberProcessor {
    public:

        operator int() const
        {
            /* Put the function in here */

            return 5;
        }
    };


    MemberProcessor member;
};


int main()
{
    MyClass obj;

    int i = obj.member;

    /* No need for function call syntax. */
}

--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:

> Have you considered the likes of the following?
>
> class MyClass {
> public:
>
>     class MemberProcessor {
>     public:
>
>         operator int() const
>         {
>             /* Put the function in here */
>
>             return 5;
>         }
>     };
>
>
>     MemberProcessor member;
> };
>
>
> int main()
> {
>     MyClass obj;
>
>     int i = obj.member;
>
>     /* No need for function call syntax. */
> }
>

Yes, and some some variations on the theme.  The main drawback is the
space overhead ("member" adds to the size of the containing class).
Arguably not a big deal if you're just talking about adding one or two
such members, but possibly enough to make the technique unuseable if
you're talking about adding many such "properties."

The nice thing about a zero-overhead option is that it scales so well.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> In the last few months, I've noticed a number of postings with feature
> proposals and/or work-arounds to simulate features, including:
>
>   (a) using anonymous unions to simulate zero-size member
>       references and introduce "properties" into the language
>
>   (b) using unions or new language features to allow "named
>       access" to array elements
>
> What they have in common is a desire to bind a name to an arbitrary
> object (including a member, a base class, and/or an array element),
> without space overhead.  Currently, we can accomplish this by using
> functions which return references, which is nice enough, but which
> requires the the function-call syntax at the point of use -- which some
> find unwieldy and inconvenient.
>
> I'm wondering whether it would be feasible -- without doing too much
> harm to the grammar -- to make the "()" operator optional when calling
> a function without arguments.  (This would obviously be a "future"
> proposal, for C++1x.)
>
> Has anyone attempted to craft language to implement such a change,
> and/or hashed out the major problems and road-blocks?  Alternatively,
> is this something that's already been looked into and graded "no-way,
> no-how?"
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Csharp ahs the concept of get and set inside a parameter. It would be
like this....

public type Variable
{

  get {
       return var2[count];
  }
  set {
       if (value == 0)
        var3 = value;
      else
        var4 = value;
 }
}

//accessing it...
object.Variable = 4;
type t = object.Variable;


You can omit a get or a set or add conditional statements or whatever.
The idea is that this is only for accessing properties. Cleaner syntax
that get and set. can do exception handling etc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> I'm wondering whether it would be feasible -- without doing too much
> harm to the grammar -- to make the "()" operator optional when calling
> a function without arguments.  (This would obviously be a "future"
> proposal, for C++1x.)
Have a look at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf

Yechezkel Mett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Goalie_Ca wrote:
> public type Variable
> {
>
>   get {
>        return var2[count];
>   }
>   set {
>        if (value == 0)
>         var3 = value;
>       else
>         var4 = value;
>  }
> }

The C++/CLI way is a bit more C++-ish:

class Foo
{
   int bar;

public:
   property int Bar
   {
      int get()
      {
         return bar;
      }

      void set(int newBar)
      {
         bar = newBar;
      }
   }
};

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> Frederick Gotham wrote:
>
> > Have you considered the likes of the following?
> >
> > class MyClass {
> > public:
> >     class MemberProcessor {
> >     public:
> >         operator int() const {
> >             return 5;
> >         }
> >     };
> >
> >     MemberProcessor member;
> > };
> >
> > int main() {
> >     MyClass obj;
> >     int i = obj.member;
> > }
>
> Yes, and some some variations on the theme.  The main drawback is the
> space overhead ("member" adds to the size of the containing class).

Perhaps the solution is not to introduce some new C#-like property
syntax, but instead to have a way of saying that a member should take
up no space.  The bit-field syntax already provides a way of doing this
(though only integral or enum types are currently allowed, and zero has
a special meaning).  It would only take a very minor language change to
make the following legal

  struct C {
    struct {
      operator int() const { return 42; }
    } m : 0;
  };

Indeed, if you omit the ": 0", it already is legal, and, excepting the
fact that it takes up space, does the right thing; all the ": 0"
specifier would do is (i) tell the compiler that it is allowed to not
allocate space for the object; and (ii) per 9.6/3, prevent the address
of the member from being taken (though perhaps an overloaded operator&
could be allowed).

So far as I can see, all that would be required to make this legal
would be to change the second sentence of 9.6/3 to allow empty classes
and the last sentence of 9.6/2 to allow a size of zero to be specified
for empty classes.  And I find it hard to believe that this would cause
implementation difficulties for compiler vendors.

Of course, some syntactic sugar like C#'s property syntax might make
this more palatable.

--
Richard Smith

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]