From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,65cf1c5c90ed694 X-Google-Attributes: gid103376,public From: rodemann@mathematik.uni-ulm.de (Joerg Rodemann) Subject: Re: Ada vs. C++ (Readability) Date: 1997/09/10 Message-ID: <3416458e.0@news.uni-ulm.de>#1/1 X-Deja-AN: 271215648 References: <341566c7.0@news.uni-ulm.de> <5v4kie$jp1@panix.com> Organization: University of Ulm, SAI, Germany Newsgroups: comp.lang.ada Date: 1997-09-10T00:00:00+00:00 List-Id: Hyman Rosen (hymie@panix.com) wrote: > In article <341566c7.0@news.uni-ulm.de>, > Joerg Rodemann wrote: > > x = 1.00, 0.40, -1.00; > > > Well, I would interpret the lines the way they look - assigning a three > element vector to each of the variables. Do you somehow find this to be > unreadable? It looks straightforward to me! > The implementation is cute, of course. You forgot that assignment has > lower precedence than comma. In function syntax, those lines become > x.operator=(1.00).operator,(0.40).operator,(-1.00); > n.operator=(0.31).operator,(0.20).operator,(0.93); Whoops...seems I messed up the precedence rules. Guess how often I use the comma operator...?!! Well, many apologies for that here. I should have thought twice about it. > The comma operator has been prettily redefined to cause concatenation. Nevertheless, I can't help to think overloading here is not a good idea if you want someone else to read this. The only hint that the first two numbers are not omitted is that x is of type ray. Sure, once you know what is meant here it is a neat way for assigning vectors, at least if their dimension is not very high. I believe overloading is nice when the meaning of the operator/function is clearly to be guessed from its name or standard meaning. That is: you provide an abstract operation that has different implementations for each type. In this case the actual type is just relevant to get that function signature right (and the compiler can check that) but the general meaning should be obvious. IMHO this is not the case for the example above. Another comment, or question, about the expression templates: what about type safety? I understand that C++ templates are not in any way type safe wrt the instantion parameters. (E.g. try a list template with a print method that calls the type's print method...and instantiate that with an int or float.) I have not looked at the source of blitz++ nor have I any deep insights into expression templates at all so this is probably a question to the authors? Could you please clarify that? Sorry for the confusion again, yours Joerg -- rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann Phone: ++49-(0)711-5090670 | Flurstrasse 21, D-70372 Stuttgart, Germany -------------------------------+--------------------------------------------- rodemann@rus.uni-stuttgart.de | University of Stuttgart, Computing Center Phone: ++49-(0)711-685-5815 | Visualization Department, Office: 0.304 Fax: ++49-(0)711-678-7626 | Allmandring 30a, D-70550 Stuttgart, Germany