Edward Rosten wrote:
>
> On Apr 14, 6:55 pm, Chris Becke <chris.be...@gmail.com> wrote:
>>
>> This is not a question about boost. or c++0x, or TR1.
>>
>> Its a rant. A rant because, as a programmer with too much grey in my hair,
>
> I
>>
>> feel that c++ has rather gone sideways, has gotten ugly, and some of the
>> large elephants in the room are being ignored.
>>
>> I refer to the sorry state of operator's new and delete, and operator
>> overloading in general.
>>
>> I have a specific objection to operators new and delete, but it stems from
>> my general objection to operator overloading: namely that there is no
>> facility at all to create custom operators. And, without the facility to
>> define our own operators, operators like 'new' and 'delete' are
>
> syntactical
>>
>> warts on the language.
>
> The question is, can you come up with a set of rules for creating
> operators, that is possible to implement?
>
> Haskell has a nice solution. A 2-ary function can be turned into an
> operator using backticks (IIRC). So, for fome function foo(a, b) you
> can instead write:
>
> a `foo` b.
>
> In Haskell, you can also define operators as a collection of symbols,
> but this is easier than in C++ because C++ allows operators to be
> placed one after another with no whitespace between them. For
> instance, in C++ you could not define a ** operator because imagine
> the case:
>
> float a, *b;
> a**b;
>
> a**b should be a*(*b) or operator**(a, b)?
>
> Finally, Haskell lets one define the precedence order and
> associativity of operators. This is crucial for the new operators to
> lead to usable code.
>
>
> I suppose that the backtics style of operator could be implemented
> quite easily. It could be a direct substitution a `foo` b -> foo(a,b),
> with resolution occurring after the substitution. One may even be able
> to implement it for unary operators too, but then the compiler would
> have to deduce the arity of the function. If there are many overloads,
> this could be really rather hard to figure out.
>
> The second case is trickier due to the parsing rules. One option is to
> have a large number of operators pre-defined, but they don't do
> anything, they're just there to be overloaded. I think this would not
> be too hard to implement since they would be just like normal
> operators. A more complex option would be to allow operators to be
> defined, but detect and disallow any ambiguous operators.
>
> That would require modifying the parser to allow arbitrary collections
> of symbols to be  considered as operator.
>
> The final step would be to modify the parser to allow precedence and
> associativity to be specified.
>
> So, while I agree in principle, it would have to be specified with
> great care.
>

If we freed up restrictions on #define we could use mathematical
symbols (from the relevant unicode page for example) and #define them
to an appropriate overloaded operator. Now the user can write as he
thinks and the compiler will see what it can parse.


#define <some glyph>  +
#define <some other glyph> ^

etc.

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

Uzytkownik "Chris Becke" <chris.becke@gmail.com> napisal w wiadomosci
news:1271234296.712017@vasbyt.isdsl.net...
> This is not a question about boost. or c++0x, or TR1.
>
> Its a rant. A rant because, as a programmer with too much grey in my hair,
I
> feel that c++ has rather gone sideways, has gotten ugly, and some of the
> large elephants in the room are being ignored.
>
> I refer to the sorry state of operator's new and delete, and operator
> overloading in general.
>

There is very little reason to use operator new or operator delete in
general code.  Use std::auto_ptr and std::vector instead.  So, if your code
is peppered with new and delete, it is time to clean up.  The only place
where they can stay is an implementation of a custom allocator.

Since they actually should not be used, they are not a good example of
operator overloading because an operator to be overloaded is expected to be
generally useful in its original meaning.

IMHO,
Chris


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

This is not a question about boost. or c++0x, or TR1.

Its a rant. A rant because, as a programmer with too much grey in my hair, I
feel that c++ has rather gone sideways, has gotten ugly, and some of the
large elephants in the room are being ignored.

I refer to the sorry state of operator's new and delete, and operator
overloading in general.

I have a specific objection to operators new and delete, but it stems from
my general objection to operator overloading: namely that there is no
facility at all to create custom operators. And, without the facility to
define our own operators, operators like 'new' and 'delete' are syntactical
warts on the language.

On the one hand, their existence acknowledges the utility of a syntax where
one can write statements of the form:

   verb object;

rather than the more usual C & C++ 'function call' forms

   object.verb();
 or
   verb(object);

If the new and delete operators were not aberrations, but built uding an
underlying syntax, whereby programmers could define their own custom
operators, then a whole range of expressive and powerful syntaxes would
become available:

Given a Matrix class with a "translate" operation, instead of writing:

  Matrix a,b,c;
  c = a.translate(b);

we could write

  c = a translate b;

Which isn't such a huge leap until one considers how much more clearly that
would express a compound statement.

  c = (a translate b) translate d;
vs.
  c = d.translate(a.trandlate(b));

Also, creating an operator definition syntax where operators new and delete
are constructable by user code, one could instead conceive of enabling other
memory management paradigms:

As an example, one could add operators "retain" and "release" to implement a
reference counting syntax.

 SomeClass* a, b;
 a = new SomeClass;
 b = retain a;
 retain b;
 release b;
 release b;
 release a;

Sure, we can do that with boost smart pointers, but its not the reference
counting ability, so much as the potential elegance of the syntax.


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

On 14 avr, 18:55, Chris Becke <chris.be...@gmail.com> wrote:
> This is not a question about boost. or c++0x, or TR1.
>
> Its a rant. [...]
> but it stems from
> my general objection to operator overloading: namely that there is no
> facility at all to create custom operators.

Not going to happen.
C++ is hard enough to parse as it is.


> Given a Matrix class with a "translate" operation, instead of writing:
>
>   Matrix a,b,c;
>   c = a.translate(b);
>
> we could write
>
>   c = a translate b;
>
> Which isn't such a huge leap until one considers how much more clearly
that
> would express a compound statement.
>
>   c = (a translate b) translate d;
> vs.
>   c = d.translate(a.trandlate(b));

There are plenty of binary operators to choose from.
You could also do a | translate(b) | translate(d)


> Also, creating an operator definition syntax where operators new and
delete
> are constructable by user code, one could instead conceive of enabling
other
> memory management paradigms:
>
> As an example, one could add operators "retain" and "release" to implement
a
> reference counting syntax.
>
>  SomeClass* a, b;
>  a = new SomeClass;
>  b = retain a;
>  retain b;
>  release b;
>  release b;
>  release a;
>
> Sure, we can do that with boost smart pointers, but its not the reference
> counting ability, so much as the potential elegance of the syntax.

I don't see what this brings compared to overloading constructors and
destructors.
Also, such code is not exception-safe.


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

On 4/14/2010 10:55 AM, Chris Becke wrote:

> This is not a question about boost. or c++0x, or TR1.
>
> Its a rant. A rant because, as a programmer with too much grey in my
> hair, I
> feel that c++ has rather gone sideways, has gotten ugly, and some of the
> large elephants in the room are being ignored.
>
> I refer to the sorry state of operator's new and delete, and operator
> overloading in general.
>
> I have a specific objection to operators new and delete, but it stems from
> my general objection to operator overloading: namely that there is no
> facility at all to create custom operators. And, without the facility to
> define our own operators, operators like 'new' and 'delete' are syntactical
> warts on the language.
>
> On the one hand, their existence acknowledges the utility of a syntax where
> one can write statements of the form:
>
> verb object;
>
> rather than the more usual C & C++ 'function call' forms
>
> object.verb();
> or
> verb(object);
>
> If the new and delete operators were not aberrations, but built uding an
> underlying syntax, whereby programmers could define their own custom
> operators, then a whole range of expressive and powerful syntaxes would
> become available:
>
> Given a Matrix class with a "translate" operation, instead of writing:
>
> Matrix a,b,c;
> c = a.translate(b);
>
> we could write
>
> c = a translate b;
>
> Which isn't such a huge leap until one considers how much more clearly that
> would express a compound statement.
>
> c = (a translate b) translate d;
> vs.
> c = d.translate(a.trandlate(b));
>
> Also, creating an operator definition syntax where operators new and delete
> are constructable by user code, one could instead conceive of enabling
> other
> memory management paradigms:
>
> As an example, one could add operators "retain" and "release" to
> implement a
> reference counting syntax.
>
> SomeClass* a, b;
> a = new SomeClass;
> b = retain a;
> retain b;
> release b;
> release b;
> release a;
>
> Sure, we can do that with boost smart pointers, but its not the reference
> counting ability, so much as the potential elegance of the syntax.
>
Almost sounds like you're asking for LISP :-)

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

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

On Apr 14, 6:55 pm, Chris Becke <chris.be...@gmail.com> wrote:
> This is not a question about boost. or c++0x, or TR1.
>
> Its a rant. A rant because, as a programmer with too much grey in my hair,
I
> feel that c++ has rather gone sideways, has gotten ugly, and some of the
> large elephants in the room are being ignored.
>
> I refer to the sorry state of operator's new and delete, and operator
> overloading in general.
>
> I have a specific objection to operators new and delete, but it stems from
> my general objection to operator overloading: namely that there is no
> facility at all to create custom operators. And, without the facility to
> define our own operators, operators like 'new' and 'delete' are
syntactical
> warts on the language.

The question is, can you come up with a set of rules for creating
operators, that is possible to implement?

Haskell has a nice solution. A 2-ary function can be turned into an
operator using backticks (IIRC). So, for fome function foo(a, b) you
can instead write:

a `foo` b.

In Haskell, you can also define operators as a collection of symbols,
but this is easier than in C++ because C++ allows operators to be
placed one after another with no whitespace between them. For
instance, in C++ you could not define a ** operator because imagine
the case:

float a, *b;
a**b;

a**b should be a*(*b) or operator**(a, b)?

Finally, Haskell lets one define the precedence order and
associativity of operators. This is crucial for the new operators to
lead to usable code.


I suppose that the backtics style of operator could be implemented
quite easily. It could be a direct substitution a `foo` b -> foo(a,b),
with resolution occurring after the substitution. One may even be able
to implement it for unary operators too, but then the compiler would
have to deduce the arity of the function. If there are many overloads,
this could be really rather hard to figure out.

The second case is trickier due to the parsing rules. One option is to
have a large number of operators pre-defined, but they don't do
anything, they're just there to be overloaded. I think this would not
be too hard to implement since they would be just like normal
operators. A more complex option would be to allow operators to be
defined, but detect and disallow any ambiguous operators.

That would require modifying the parser to allow arbitrary collections
of symbols to be  considered as operator.

The final step would be to modify the parser to allow precedence and
associativity to be specified.

So, while I agree in principle, it would have to be specified with
great care.

-Ed






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