<mosfox@yandex.ru> wrote in message news:c08a6g$2kld$1@digitaldaemon.com...
> If we have more complicated objects than ints and reals and bools
> (for example - vectors, armies, rockets, planets...), then we would have
more
> possible operations on them. Some of such operations will be used
> frequently. Remember scalar and cross products of vectors.
> You could overload "*" operator to get scalar product.
> Why not to overload "@" operator in order to get cross product?
> Or i must use "%" or "~" only?
>
> We find in specification
> "Since ++e is defined to be semantically equivalent to (e += 1), the
> expression ++e is rewritten as (e += 1), and then checking for operator
> overloading is done. The situation is analogous for --e".
> But who says that e is such an object that operation ++ is comutative?
>
> Example:
>
> Army a1 = new Army();
> a1++; // to add 1 soldier on the right flank
> ++a1; // to add 1 soldier on the left flank

I'm assuming you're continuing in an ironic vein, as that's just monstrous nonsense. Any serious code review of such code would mark it "must try again".



>
>
>
>
>
>
>
>
>
>
> In article <c06f1p$2kkr$2@digitaldaemon.com>, Matthew says...
> >
> >To do what?
> >
> >Please provide examples of what you intend, so we can give you opinions
> >
> >"Yan" <Yan_member@pathlink.com> wrote in message news:c0695d$2b15$1@digitaldaemon.com...
> >> I would like to propose a possibility to
> >> over(?)load operators "!","#","?","$" (both - unary and binary)
> >> Thanx
> >> Yan
> >>
> >>
> >
> >
>
>

unicode is useless on a keyboard. thats why ascii only should be used. there is no need for anything more. it just makes typing much more hell.

"Mark J. Brudnak" <mjbrudna@oakland.edu> schrieb im Newsbeitrag news:c08vi8$198c$1@digitaldaemon.com...
> <snip>
>
> > You could overload "*" operator to get scalar product.
> > Why not to overload "@" operator in order to get cross product?
> > Or i must use "%" or "~" only?
> >
>
> FWIW I think it would be a mistake to add more ASCII characters as operators.  UNICODE provides a rich set of mathematical symbols which are available for use.  To create a dot product operator, the unicode symbol
for
> "DOT" (unicode 22C5) should be used.  To create a cross product operator,
> the UNICODE symbol for "CROSS PRODUCT" (unicode 00D7) should be used.
>
> This is what I had in mind when I posted the following:
>
> http://www.digitalmars.com/drn-bin/wwwnews?D/19736
>
> Also, IMO overloaded operators should not be used unless they have a clear meaning in mathmatics and make code easier to read.
>
> Mark.
>
> <snip>
>
>

Yan wrote:
> In article <c08aj5$2l2v$1@digitaldaemon.com>, Andy Friesen says...
> 
>>
>>How about a method called 'dot'? :)
> 
> 
> dot(dot(dot(dot(a,dot(b,dot(c,d))),e),f),g) ... %-/
> 
> ..OR...
> 
> ((a@(b@(c@d))@e)@f)@g

For one, I've never been a subscriber of the Perlish notion of attaching some arbitrary meaning to an arbitrary operator because it's convenient. (I'm not a fan of Perl in general, but I digress)

For another, I thought dotting two vectors yielded a scalar, in this particular case.

Lastly, neither of those two examples are the least bit intelligible, but at least I can guess that the dot product operation is involved in the first.

 -- andy

Andy Friesen wrote:

> For one, I've never been a subscriber of the Perlish notion of attaching some arbitrary meaning to an arbitrary operator because it's convenient. (I'm not a fan of Perl in general, but I digress)
>
C uses allot of symbols with arbitrary meanings too. It's just that people have gotten use to them.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:
> Andy Friesen wrote:
> 
>> For one, I've never been a subscriber of the Perlish notion of attaching some arbitrary meaning to an arbitrary operator because it's convenient. (I'm not a fan of Perl in general, but I digress)
>>
> C uses allot of symbols with arbitrary meanings too. It's just that people have gotten use to them.
> 

Right, but I won't get anywhere by suggesting that ! be dropped in favour of 'not' and so forth.  I'll settle for nipping it in the bud, as it were. :)

 -- andy