could ptr->() and ptr->[] be implemented in C++0X?

[Steven T. Hatton]

I find writing things such as (*ptr)(arg), and (*ptr)[i], to be at least
awkward. I've often thought the following would be useful as an
alternative form of ptr->operator(arg), ptr->operator[i]:

ptr->(arg)
ptr->[i]

Some people may find such an expression unintelligible. If it could be made
to work, I believe it would be quickly learned, and probably used by a good
number of programmers. Does anybody know of a purely technical reason that
functionality couldn't be implemented if it were added to the standard?
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Ferdi Smit]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:Ps********************@speakeasy.net...

I find writing things such as (*ptr)(arg), and (*ptr)[i], to be at least
awkward. I've often thought the following would be useful as an
alternative form of ptr->operator(arg), ptr->operator[i]:

ptr->(arg)
ptr->[i]

Some people may find such an expression unintelligible. If it could be
made
to work, I believe it would be quickly learned, and probably used by a
good
number of programmers. Does anybody know of a purely technical reason
that
functionality couldn't be implemented if it were added to the standard?

The part following the -> should be an identifier according to the grammar
rules. So by allowing this syntax, the grammar rules would have to be
rewritten. I think that's a cost higher than people are willing to pay for
some exceptionally ugly syntactic sugar :)
--
Regards,

Ferdi Smit
smit xs4all nl

[Steven T. Hatton]

Ferdi Smit wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:Ps********************@speakeasy.net...

I find writing things such as (*ptr)(arg), and (*ptr)[i], to be at least
awkward. I've often thought the following would be useful as an
alternative form of ptr->operator(arg), ptr->operator[i]:

ptr->(arg)
ptr->[i]

Some people may find such an expression unintelligible. If it could be
made
to work, I believe it would be quickly learned, and probably used by a
good
number of programmers. Does anybody know of a purely technical reason
that
functionality couldn't be implemented if it were added to the standard?

The part following the -> should be an identifier according to the grammar
rules. So by allowing this syntax, the grammar rules would have to be
rewritten. I think that's a cost higher than people are willing to pay for
some exceptionally ugly syntactic sugar :)

I don't believe the grammar would be impacted very significantly. And my
own opinion is that ptr->[i] is more readable than (*ptr)[i], and I find it
much easier to type as well. (*ptr)(arg) is even worse than (*ptr)[i].
The alternative are to create a reference to *ptr, and use pref(arg) and
pref[i]. That is reasonable if you will be using the reference a lot.
I've even done T& _self(*this). Another alternative is ptr->operator(arg)
and ptr->operator[i] which seems longwinded and redundant.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Victor Bazarov]

Steven T. Hatton wrote:

[...] Another alternative is ptr->operator(arg)
You mean

ptr->operator()(arg)
and ptr->operator[i] which seems longwinded and redundant.

...and

ptr->operator[](i)

Are you proposing to change those existing forms in favor of new ones or
simply add new ones to complement the already existing ones?

My question is this: what, except changing

(*ptr)(arg)

to

ptr->(arg)

does your suggestion provide? If nothing, you should consider spending
your time on something of substance.

V

[Steven T. Hatton]

Victor Bazarov wrote:

Steven T. Hatton wrote:

[...] Another alternative is ptr->operator(arg)

You mean

ptr->operator()(arg)

and ptr->operator[i] which seems longwinded and redundant.

..and

ptr->operator[](i)

Are you proposing to change those existing forms in favor of new ones or
simply add new ones to complement the already existing ones?

My question is this: what, except changing

(*ptr)(arg)

to

ptr->(arg)

does your suggestion provide? If nothing, you should consider spending
your time on something of substance.

V

Perhaps the answer is to go to using smart references rather than smart
pointers. The problem with references is that, unless you name your
parameters well, it is less evident that a function call has the potential
of changing its parameters.

This is the kind of situation where I believe that syntax would be
advantageous.

return *_p0_sptr + math::vec3f((*_mapping1To3_sptr)((*_mapping1To1_sp tr
(p)));

I find this clearer:

return *_p0_sptr + math::vec3f(_mapping1To3_sptr->(_mapping1To1_sptr->(p)));
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Julián Albo]

Steven T. Hatton wrote:

return *_p0_sptr + math::vec3f((*_mapping1To3_sptr)((*_mapping1To1_sp tr
(p)));

I find this clearer:

return *_p0_sptr +
math::vec3f(_mapping1To3_sptr->(_mapping1To1_sptr->(p)));

That remembers me some discussion in the Perl 6 development summaries. Some
people ask what of two or three possible syntax for some operator is
clearer, and both of them looks like noise to me.

--
Salu2

[Steven T. Hatton]

Julián Albo wrote:

Steven T. Hatton wrote:

return *_p0_sptr + math::vec3f((*_mapping1To3_sptr)((*_mapping1To1_sp tr
(p)));

I find this clearer:

return *_p0_sptr +
math::vec3f(_mapping1To3_sptr->(_mapping1To1_sptr->(p)));

That remembers me some discussion in the Perl 6 development summaries.
Some people ask what of two or three possible syntax for some operator is
clearer, and both of them looks like noise to me.

*p + v((*m)((*n(p))); // this looks - and reads - like Lisp

*p + v(m->(n->(p))); // I can understand this far more easily.

I believe this proposal may suggest a means of accomplishing what I want in
a fairly clean way, but through a different modification to the language.
I don't really perceive a huge downside to it, but it would seem the idea
does not have a history of favorable consideration.

http://www.open-std.org/jtc1/sc22/wg...2004/n1671.pdf
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Victor Bazarov]

Steven T. Hatton wrote:

[...]
Perhaps the answer is to go to using smart references rather than smart
pointers. The problem with references is that, unless you name your
parameters well, it is less evident that a function call has the potential
of changing its parameters.
So, we're talking about _mapping1To3_sptr variable that you use in the
example below, right? According to what you write, it has to be a pointer
and shouldn't be a reference because the function where the expression
just the one below appears, has to change it as well as use it to call the
operator() for its referred object, yes?

Well, I for one find it confusing. The argument is either uses or it's
changed. If it's used, it should be passed by ref (often, to const), and
if it's changed, it is passed by address, but then it's not used in most
cases...
This is the kind of situation where I believe that syntax would be
advantageous.

return *_p0_sptr + math::vec3f((*_mapping1To3_sptr)((*_mapping1To1_sp tr
(p)));

I find this clearer:

return *_p0_sptr + math::vec3f(_mapping1To3_sptr->(_mapping1To1_sptr->(p)));

It's clearer _in_this_case_. But it seems that what you're asking is
essentially a fix for a problem you invented yourself. Separate changing
of the variables and using them, and you won't have this problem at all.

V

[Stephen Howe]

>I find writing things such as (*ptr)(arg), and (*ptr)[i], to be at least

awkward. I've often thought the following would be useful as an
alternative form of ptr->operator(arg), ptr->operator[i]:

ptr->(arg)
ptr->[i]

Some people may find such an expression unintelligible.

It is not unintelligible.
However a generation of C and C++ programmers all know that "->" is used to
dereference a pointer to a struct/union/class
Now with this addition, we all have to remember that "->" is now used to
mean something else as well.

This bifurcated use of "->" is large.
For such minor syntactic sugar above, I don't consider the price paid worth
it.

You might want to read Stroustrup's "Design and Evolution of C++" and see
why an exponential operator, so far, has never made it into the language.

Stephen Howe

[Steven T. Hatton]

Victor Bazarov wrote:

Steven T. Hatton wrote:

[...]
Perhaps the answer is to go to using smart references rather than smart
pointers. The problem with references is that, unless you name your
parameters well, it is less evident that a function call has the
potential of changing its parameters.
So, we're talking about _mapping1To3_sptr variable that you use in the
example below, right? According to what you write, it has to be a pointer
and shouldn't be a reference because the function where the expression
just the one below appears, has to change it as well as use it to call the
operator() for its referred object, yes?

The _identifier notation is my convention for indicating a class member.
The _mappingXToY members are (interfaces to) function objects, subject to
change in in different ways depending on many factors. It the code I
presented, they are not modified. The could just as well be references.
That is, as long as I can share them. These same function objects may be
referenced by many classes at the same time. I used boost::shared_ptr
because it has the best advertising.
Well, I for one find it confusing. The argument is either uses or it's
changed. If it's used, it should be passed by ref (often, to const), and
if it's changed, it is passed by address, but then it's not used in most
cases...

This is the kind of situation where I believe that syntax would be
advantageous.

return *_p0_sptr + math::vec3f((*_mapping1To3_sptr)((*_mapping1To1_sp tr
(p)));

I find this clearer:

return *_p0_sptr +
math::vec3f(_mapping1To3_sptr->(_mapping1To1_sptr->(p)));

It's clearer _in_this_case_. But it seems that what you're asking is
essentially a fix for a problem you invented yourself. Separate changing
of the variables and using them, and you won't have this problem at all.

V

I can only take that so far. x(t) = k(x(t)')*x(f(t))''

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Steven T. Hatton]

"Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote:

I find writing things such as (*ptr)(arg), and (*ptr)[i], to be at least
awkward. I've often thought the following would be useful as an
alternative form of ptr->operator(arg), ptr->operator[i]:

ptr->(arg)
ptr->[i]

Some people may find such an expression unintelligible.

It is not unintelligible.
However a generation of C and C++ programmers all know that "->" is used
to dereference a pointer to a struct/union/class
Now with this addition, we all have to remember that "->" is now used to
mean something else as well.

This bifurcated use of "->" is large.
For such minor syntactic sugar above, I don't consider the price paid
worth it.

You might want to read Stroustrup's "Design and Evolution of C++" and see
why an exponential operator, so far, has never made it into the language.

Stephen Howe

It seems almost blatantly obvious what ptr->() should mean. It means

struct T{
float operator()(float p);
};
T* ptr(new T());
T& temp(*ptr);
ptr(p);

So basically, it means dereferencing the pointer and calling a member
function on the object pointed to.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Steven T. Hatton]

Steven T. Hatton wrote:

"Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote:

I find writing things such as (*ptr)(arg), and (*ptr)[i], to be at least
awkward. I've often thought the following would be useful as an
alternative form of ptr->operator(arg), ptr->operator[i]:

ptr->(arg)
ptr->[i]

Some people may find such an expression unintelligible.
It is not unintelligible.
However a generation of C and C++ programmers all know that "->" is used
to dereference a pointer to a struct/union/class
Now with this addition, we all have to remember that "->" is now used to
mean something else as well.

This bifurcated use of "->" is large.
For such minor syntactic sugar above, I don't consider the price paid
worth it.

You might want to read Stroustrup's "Design and Evolution of C++" and see
why an exponential operator, so far, has never made it into the language.

Stephen Howe

It seems almost blatantly obvious what ptr->() should mean. It means

struct T{
float operator()(float p);
};
T* ptr(new T());
T& temp(*ptr);
ptr(p);

Make that temp(p); So basically, it means dereferencing the pointer and calling a member
function on the object pointed to.

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Michael Smolensky]

Steven T. Hatton wrote:

I find writing things such as (*ptr)(arg), and (*ptr)[i], to be at least
awkward. I've often thought the following would be useful as an
alternative form of ptr->operator(arg), ptr->operator[i]:

ptr->(arg)
ptr->[i]

Some people may find such an expression unintelligible. If it could be made
to work, I believe it would be quickly learned, and probably used by a good
number of programmers. Does anybody know of a purely technical reason that
functionality couldn't be implemented if it were added to the standard?
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

Take a look at Stroustrup's Design and Evolution of C++, Section
2.8.1, where he discussed that idea. He wrote, "Unfortunately, I
fumbled the idea and did not ever deliver a complete implementation
[...]. My eventual rationale for leaving things as they were was [that
the old syntax] is not a significant problem for C programmers [...].
I'm not sure if I did the right thing, though." As you can see
there is no technical reason.

The book was published in 1994. I'm wondering what he thinks 11 years
later...

I, as a C++ user, would like to have this syntax implemented. I'm not
sure if implementers are exited about making more changes in syntax.

[Greg]

Ferdi Smit wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:Ps********************@speakeasy.net...

I find writing things such as (*ptr)(arg), and (*ptr)[i], to be at least
awkward. I've often thought the following would be useful as an
alternative form of ptr->operator(arg), ptr->operator[i]:

ptr->(arg)
ptr->[i]

Some people may find such an expression unintelligible. If it could be
made
to work, I believe it would be quickly learned, and probably used by a
good
number of programmers. Does anybody know of a purely technical reason
that
functionality couldn't be implemented if it were added to the standard?

The part following the -> should be an identifier according to the grammar
rules. So by allowing this syntax, the grammar rules would have to be
rewritten. I think that's a cost higher than people are willing to pay for
some exceptionally ugly syntactic sugar :)

C++ already has a ->* operator, so adding ->[] and ->() operators to
the lanaguage would obviously not violate any exisitng C++ grammar
rules. Though such a change may do little to reduce the obviously
prevalent misconception that the -> and ->* operators are one and the
same. They are not.

[Steven T. Hatton]

Greg wrote:

C++ already has a ->* operator, so adding ->[] and ->() operators to
the lanaguage would obviously not violate any exisitng C++ grammar
rules. Though such a change may do little to reduce the obviously
prevalent misconception that the -> and ->* operators are one and the
same. They are not.
The only thing I fully understand about ->* is that it is /not/ the same as
->. ->* is a "pointer to member" operator. It is described in §15.5 of
TC++PL(SE) which is probably the most obscure section in the entire book.
Stroustrup made the mistake of assuming his reader understood well the
notion of pointer to function from C. His comments in the ARM suggest if
it weren't for C compatability this may be a far more elegant feature in
C++.

Coincidentally, I just found a reply from Victor to one of my posts which I
had missed. Victor's response indirectly shows a use of this language
feature. (I have not tested his suggestion)
Victor Bazarov May 31, 9:41 am show options
Newsgroups: comp.lang.c++
From: Victor Bazarov <[e-mail]> - Find messages by this author Date: Tue, 31 May 2005 09:41:40 -0400
Local: Tues,May 31 2005 9:41 am
Subject: Re: STL:invoking a member of an object not in the container
Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse
Steven T. Hatton wrote:

I have a std::vector<Vec3*> _vertices and an object BoundingBox _bbox. _bbox has a member function called void expandBy(Vec3& v); I want to call
_bbox.expandBy on every member of _vertices. I know I can loop through and do that. I also know I can create a function object and pass it. The
latter can be pretty slick, if I will be doing it a lot. It seems more
trouble than it's worth to do it for only one function in one class.
AFAIK, there is no way to use things such as mem_fun to do that. They
apply to the objects in the container being iterated over by the STL
algorithm.

Is there a way to accomplish what I want with the STL algorithms? Boost?

Actually, using 'bind1st' and 'mem_fun' should be enough, no need for
Boost. I can never remember the right order of things, takes me a couple
of tries to get it right, but the direction is something like

BoundingBox _bbox;
for_each(_vertices.begin(), _vertices.end(),
bind1st(mem_fun(&BoundingBox::expandBy), &_bbox));

V

Thanks Victor.

The use of ->* to implement std::mem_fun is described in TC++PL(SE)
§18.4.4.2. I will admit that I did not give that chapter careful study
when I read it. I was still struggling with the fundamental concepts of
C++ and believed I would be better served by gaining some hands-on
experience before I concentrated on an indepth understanding of the
material therein. Clearly, I should find time to revisit the chapter.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell