steve@vsi1.UUCP (Steve Maurer) (01/09/88)
I have a bone to pick with operator overloading. While
I must admit that it can be convienient at times, it suffers the
same problems that you get when dealing with someone who goes
crazy with #define's , or virtually anything written in Forth :
Essentially, every programmer becomes his own language designer,
and the whole thing gets totally unreadable.
Consider the following:
foo(int i)
{
i #= i ^^ i @& i;
}
what does it do?? You will never know unless you start digging
through miles of include/lib files.
Steve Maurermerlin@hqda-ai.UUCP (David S. Hayes) (01/10/88)
A programmer can go crazy with #defines already. While C++
operator overloading can be a temptation for a bad programmer to
redesign the language, that is not a sufficient reason to
eliminate overloading. There are such temptations in every
language, but that doesn't make a convincing argument for going
back to writing our programs in binary.
Bad programmers write bad programs, no matter what language
you give them. Their failings are not cause for the rest of us to
give up a useful tool.
--
David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900
UUCP: *!uunet!cos!hqda-ai!merlin ARPA: ai01@hios-pent.arpaark@alice.UUCP (01/10/88)
In article <240@vsi1.UUCP>, steve@vsi1.UUCP writes: > Consider the following: > > foo(int i) > { > i #= i ^^ i @& i; > } > > what does it do?? You will never know unless you start digging > through miles of include/lib files. Consider the following: foo (int i) { f (i, g (k (i, i), i)); } What does it do?? You will never know unless you start digging through miles of include/lib files.
bs@alice.UUCP (01/10/88)
Steve Maurer from Vicom Systems Inc. San Jose, Cal. writes > I have a bone to pick with operator overloading. While > I must admit that it can be convienient at times, it suffers the > same problems that you get when dealing with someone who goes > crazy with #define's , or virtually anything written in Forth : > Essentially, every programmer becomes his own language designer, > and the whole thing gets totally unreadable. > > Consider the following: > > foo(int i) > { > i #= i ^^ i @& i; > } > > what does it do?? You will never know unless you start digging > through miles of include/lib files. It certainly does look obscure! I cannot even begin to imagine what it might mean. I wonder which language it is supposed to be? `Obfuscated C' maybe? >>>>>>> It is not C++ <<<<<<< C++ allows you to define meanings for the existing operators for user defiend types. It does NOT (1) enable you to define new operators or in other ways change the syntax of C++ (2) enable you to change the meaning of operators applied to the built-in types. These `restrictions' are enforced exactly to avoid nonsense such as your example above. Furthermore, it is strongly recommended to use operator overloading ONLY where there is an established notation in some field of application to adopt. Standard examples are: Complex z1, z2; ... z1 += z2*complex(i,-j)+1.0; // += * and + overloaded Vector v1(100), v2(100); ... v1[i] = 7; ... v1 = v2; // subscripting and assignment overloaded Most people would agree that given half way reasonable defininitions of the types and operators involved this code is far more readable than the standard C alternatives. If inline functions are used judicially the run-time efficiency will also be good. There are of course still truly horrible things that can be done with the C++ operator overloading mechanism (such as defining + to be an assignment operator or / to mean multiply), but then any mechanism can be abused and I know of no useful language where horrors of similar magnitude cannot be committed without the use of operator overloading. In real use it may be a nastier problem that in C++ one cannot introduce an exponentiation operator (**, ^^, or whatever) unless, of course, the ANSI C committe suddenly reverses its stand on this issue and provides an exponentiation operator for C. At least one can overload the pow() function so that you automatically get the appropriate algorithm for pow(10,7); // pow(int,int) invoked pow(10.0, 7.0); // pow(double,double) invoked pow(z1,2.3); // pow(complex,double) invoked provided, of course, that you have included the proper header file. - Bjarne Stroustrup (AT&T Bell Labs, Murray Hill)
gvcormack@watdragon.waterloo.edu (Gordon V. Cormack) (01/10/88)
In article <240@vsi1.UUCP>, steve@vsi1.UUCP (Steve Maurer) writes: (as an indictment of operator overloading). > > foo(int i) > { > i #= i ^^ i @& i; > } > > what does it do?? You will never know unless you start digging > through miles of include/lib files. Would it be clearer as foo(int i) { glorp_assign(i, fred(xyz_arrows(i,i),nerf(i))); } -- Gordon V. Cormack CS Dept, University of Waterloo, Canada N2L 3G1 gvcormack@waterloo { .CSNET or .CDN or .EDU } gvcormack@water { UUCP or BITNET }
gore@nucsrl.UUCP (Jacob Gore) (01/11/88)
/ nucsrl:comp.lang.c++ / steve@vsi1.UUCP (Steve Maurer) / Jan 8, 1988 / > I have a bone to pick with operator overloading. [...] >Consider the following: > > foo(int i) > { > i #= i ^^ i @& i; > } > >what does it do?? [...] It was my impression that in C++ you could not define operators with new names -- only overload existing names. (The overloaded operators keep the associativity and precedence qualities of the built-in operators of the same name, right?) But anyway, no language can prevent a determined nut from writing programs with confusing semantics. What should we "consider harmful" next, alphanumeric variable names? Consider the following: nonobservance(int depressant) { hoke = unhampered + serf / chiaroscuro; } What does IT do? If a programmer does wants to write clear programs, then a better language will support that goal, while a worse language will get in the way. Names of operators should be picked in such a way that they make sense for the context in which they are used. This is harder to do when you cannot define your own operators, and harder yet to do when you cannot even overload predefined operator names. Jacob Gore gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {gargoyle,ihnp4,chinet}!nucsrl!gore
kens@hpldola.UUCP (01/11/88)
On the contrary, C++ operator overloading isn't powerful enough. My complaint about operator overloading in C++ is that it only allows redefinition of the existing operators, not the declaration of new operators (with potentially mixfix syntax). (I'm quite aware of the problems in parsing such languages; the difficulty does not make my point moot.) In most disciplines notations have evolved to make the concepts common to that discipline easy to express in an unambiguous manner. Some classic examples include vector algebra, the Einstein summation convention, and bras and kets from quantum mechanics. None of these notations may be expressed easily in C++, and all of them are desirable from an application standpoint. The use of existing notations can contribute not only to readability but to productivity through making simple semantic errors more apparent. I won't argue the point that the facility can be abused. This merely points out that software developers must agree on common notation for an application and document thoroughly the notation used. Ken Shrum hplabs!hpldola!kens
wlp@calmasd.GE.COM (Walter Peterson) (01/13/88)
One fact that most people seem to forget in regards to operator overloading
is that we have used it for years in virtually every high order language.
FORTRAN, C, Pascal, etc. all effectively use operator overloading, even if
they do not allow the programmer to extend the overloading that already exists
in the language definition. Consider the following code segments:
FORTRAN
.
.
.
INUM = INUM + 5 * ICOUNT
AREAL = AREAL * BREAL
AREAL = AREAL + CREAL
IVAL = IVAL / 2
.
.
.
Pascal
.
.
Num, Val : Integer;
Percent, Score, Max, Bonus : Real;
.
.
Num = Num * Val + 1;
Percent = (Score / Max) + Bonus;
Val = Val * Num / 2;
.
.
In these examples there are overloaded operators. In every high level language
that I can think of the assignment, addition, subtraction, multiplication and
division operators are overloaded ( as are the logical operators,
exponentiation and most if not all other operators ). Additionally some
languages further overload the addition operator to allow concatenation of
strings.
The point is that there is nothing new to programmers about the use of operator
overloading; we have all been using it for years, even if we didn't know it.
Yes, we have all made the mistake of trying to perform invalid mixed-mode
arithmetic, but just imagine how many more mistakes we would make if we had to
learn to use a different set of operators for each and every type in C !
The advantages of being able to overload operators for user defined types far
outweigh the potential disadvantages ( most of which are caused by sloppy
programming ).
--
Walt Peterson GE-Calma San Diego R&D
"The opinions expressed here are my own and do not necessarily reflect those
GE, GE-Calma nor anyone else.
...{ucbvax|decvax}!sdcsvax!calmasd!wlp wlp@calmasd.GE.COMmitsu@well.UUCP (Mitsuharu Hadeishi) (01/13/88)
The philosophy of C++ was similar to that of C: rather than trying to force programmers into good programming practice by limiting them to only "safe" procedures (forcing extensions to the language or creative practices such as those employed in the various dialects of Pascal), you give them the power to hang themselves; or save themselves a lot of hassle. It is possible to write structured, modular programs in C without too much difficulty; it is also possible to write unreadable and unstructured code. The facilities are there; you are free to use or abuse them as you wish. C++ has extended this philosophy even further. By providing all sorts of neat new features, one is now able to write code that approximates the object-oriented style. However, if not applied carefully, this can lead to disaster (such as the code fragment you mention.) However, operator overloading, if applied carefully, can give you tremendous leaps forward in both readability and stability of source code. For example, the type "varstr" which means "variable-length string" was defined here, and is used as follows: varstr a = "I am a"; varstr b = "I am b"; varstr c = a + b; varstr d = "I am d"; d += " " + a; cout << a << "\n" << b << "\n"; cout << c << "\n" << d << "\n"; This code is eminently readable, and what's more, we re-implemented varstr in two completely different ways, and yet the above code still worked. Why? Because the source code is at a higher level of abstraction than the implementation mechanism. I can change the implementation of operator+ from an inline to a function call, and this does not affect the source code. I can use reference count garbage collection to reduce unnecessary copying (thereby radically changing both the internal representation of varstr as well as changing the way one would use it inline) without modifying source. In C, such a change would be so radical one would have to completely rewrite any source code that manipulated such a beast (or resort to writing everything as function calls) and output and conversion between varstr and a normal C string would have to be changed (whereas before you might write varstr.str, afterward you might write varstr.p->str). In C++ you simply need to change the class declaration and modify a few inlines, and you need not change one line of source. Another great use of overloaded operators is the support of mathematical types. For example, in the early days of the Amiga the C compiler only supported a fairly cumbersome IEEE-standard floating point. There was, however, a built-in quick-but-inaccurate floating point that was useful for doing fast calculations. To get to it, though, you needed to do some horrible manipulations and calls to library functions; you couldn't just write a = b * c. With C++, however, one could easily create inline operators which did the conversion to the library function calls, obviating the need for a new compiler just to handle the different floating point calling conventions. And on an on. Of course, operator overloading can be misused much more easily than it can be used properly, but the same goes for the design of classes (it is easy to write a poorly designed class which works but ends up making code harder, not easier, to read.) C++ operator overloading is an indispensable and useful feature of the language, and like all powerful tools, not to be fooled with lightly. -Mitsu Hadeishi Electronic Arts
marti@ethz.UUCP (Robert Marti) (01/13/88)
In article <4538@watdragon.waterloo.edu>, gvcormack@watdragon.waterloo.edu (Gordon V. Cormack) writes: > In article <240@vsi1.UUCP>, steve@vsi1.UUCP (Steve Maurer) writes: > (as an indictment of operator overloading). > > > foo(int i) { i #= i ^^ i @& i; } > > > > what does it do?? You will never know unless you start digging > > through miles of include/lib files. > > Would it be clearer as > > foo(int i) { glorp_assign(i, fred(xyz_arrows(i,i),nerf(i))); } Disregarding the fact that Maurer's example is not legal in C++, both examples suffer from the same problems if (operator or function) overloading is used: 1. As mentioned in Maurer's original posting, you may have to search your source files for the appropriate operator or function definitions for quite a while. 2. Overloading may unintentionally defeat type checking. Personally, I think the (more restricted) form of overloading you get by subclassing and inheritance is all you really need. The argument for operator overloading -- namely that it is nice to use an operator such as + for adding complex numbers, vectors, etc -- is just not good enough for me. After all, this is just syntactic sugaring! -- Robert Marti Phone: +41 1 256 52 36 Institut fur Informatik ETH Zentrum/SOT CSNET/ARPA: marti%ifi.ethz.ch@relay.cs.net CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti
steve@vsi1.UUCP (01/16/88)
> [Edited for brevity] > > The philosophy of C++ was similar to that of C: rather > than trying to force programmers into good programming practice by > limiting them to only "safe" procedures (forcing extensions to the > language or creative practices such as those employed in the various > dialects of Pascal), you give them the power to hang themselves; or > save themselves a lot of hassle. > > For example, the type "varstr" which means "variable-length > string" was defined here, and is used as follows: > > varstr a = "I am a"; > varstr b = "I am b"; > varstr c = a + b; > varstr d = "I am d"; > > d += " " + a; > > cout << a << "\n" << b << "\n"; > cout << c << "\n" << d << "\n"; > > This code is eminently readable, and what's more, we re-implemented > varstr in two completely different ways, and yet the above code still > worked. Why? Because the source code is at a higher level of abstraction > than the implementation mechanism. > > And on an on. Of course, operator overloading can be misused > much more easily than it can be used properly, but the same goes for > the design of classes (it is easy to write a poorly designed class > which works but ends up making code harder, not easier, to read.) C++ > operator overloading is an indispensable and useful feature of the language, > and like all powerful tools, not to be fooled with lightly. > > -Mitsu Hadeishi > Electronic Arts The one thing all defenders of any particular language will do when confronted by criticism of a particular feature, is to say: "look how useful it is in this situation; look what I can do with it". All languages have strong points, which clever examples can make good use of (yes even Cobol). However, this is not what should guide the reviewer when determining the merits of any language. Rather: How much does this language or feature improve the ability to generate reliable, maintainable, and flexible code; and at what cost in human and/or machine efficiency is it bought? The thing that troubles me most about Operator overloading is that definitions of basic operations, once static, are now contextual depending upon the values of the particular programmer who wrote the header definition code. This is _by no means_ "bad" programming practice, but simply the inherent method by which you must use Operator overloading. And I believe, after seeing similar do it yourself language design schemes (in Forth and Structured Macro Assembly), that it can become the single greatest obstruction to maintenence and portability of any program Plus '+' for instance, has always meant arithmetic addition. Despite arithmetic operators being "Overloaded" for different methods of machine storage, in traditional languages the basic definition does not change. Yet in the above example, we see '+' used for concatination. Is concatination now the same as addition? If so, is '-' the same as deletion? Do '<', '>', and '==' stand for string comparison? Does '/' divide or deallocate the string somehow? The answer is Yes, No, and Maybe, depending upon the definitions in force under this brand of include files. Perhaps strings aren't the best example. After all, they are treated uniformly by C convention, and there are few legal operations one might perform on them. Instead, lets take for example... 2 dimentional arrays. What shall we define for them? Does '+' mean "combine into a 4 dimentional array", "add each seperate element together, depositing the results in a 2x array", or "give me the sum total of all these numbers" ? Does '*' indicate multiplication? Or does it mean take the dot product? What does '/' do?? The answers are quite system (or program) dependent. The above examples, I reiterate, are not "bad" programming practice in C++. They simply reflect the result of allowing each programmer to select his own favorite notational convenience, and forcing him to use a very limited set of operators which may not correspond well (or at all) with the true functionality he is attempting to emulate. Certainly standard operator notations may develop for commonly used nomenclatures, but there is no guarantee that any such convention may apply on any given machine, and there may very well be rival conventions. The alternative, of course, is to have every program carry around its own operator definition environment. Multiple standards will then be the norm, and could become almost as much of a pain as switching between System 5 and 4.3BSD. This is what, in my opinion, kills Forth, despite some extremely clever environments which some people have created for it. The language essentially becomes a haven for "loner" programmers, whose programs don't execute until a large portion of their specialized environment is loaded first. Now perhaps I have overemphasized the point about the inherent dangers to Overloaded Operators too much, at least I certainly hope so. However, I am still not sure. While Mr. Mitsu Hadeishi is correct in saying that C allows programmers the power to 'hang themselves, or save a lot of hassle', at least in C, it is the programmer himself who ends up being hanged. In C++, the original programmer may design what is to him an entirely natural and logical set of operators, never have any trouble, and yet still leave a set of extremely difficult to maintain code. Because of this, I feel that it is a poor design decision. I reserve the right to change my mind later, if and when a perfect, 100% recognized, operational notation standard natually develops for all common classes. However, I'm not holding my breath. Steve Maurer
chip@ateng.UUCP (Chip Salzenberg) (01/18/88)
In article <281@bernina.UUCP> marti@ethz.UUCP (Robert Marti) writes: >Personally, I think the (more restricted) form of overloading you get >by subclassing and inheritance is all you really need. The argument >for operator overloading -- namely that it is nice to use an operator >such as + for adding complex numbers, vectors, etc -- is just not >good enough for me. After all, this is just syntactic sugaring! Let us _not_ fall into the language wars again! No feature of C++ which is not present in C is "needed" in the sense of being indispensible. Otherwise, C would be useless, and we all know that it isn't. :-) Operator overloading is not necessary. Neither are classes nor function overloading nor inline functions. They are nice and they are useful, when used properly. C++ is an industrial-strength language. What some people seem to forget is that industrial-strength means "not safe for pets and small children." -- Chip Salzenberg UUCP: "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are a trade secret. "Anything that works is better than anything that doesn't." -- me
nevin1@ihlpf.ATT.COM (00704A-Liber) (01/19/88)
In article <265@vsi1.UUCP> steve@vsi1.UUCP (Steve Maurer) writes:
.
. The thing that troubles me most about Operator overloading is that
.definitions of basic operations, once static, are now contextual depending
.upon the values of the particular programmer who wrote the header definition
.code. This is _by no means_ "bad" programming practice, but simply the
.inherent method by which you must use Operator overloading. And I believe,
.after seeing similar do it yourself language design schemes (in Forth and
.Structured Macro Assembly), that it can become the single greatest
.obstruction to maintenence and portability of any program
Why is this problem any different then having undocumented function calls in C?
.Instead, lets take for example... 2 dimentional arrays.
.What shall we define for them? Does '+' mean "combine into a 4
.dimentional array", "add each seperate element together, depositing
.the results in a 2x array", or "give me the sum total of all these
.numbers" ? Does '*' indicate multiplication? Or does it mean take
.the dot product? What does '/' do?? The answers are quite system
.(or program) dependent.
Would a function addmatrix(array1, array2) mean "combine into a 4 dimensional
array", "add each separate element together, depositing the results in a 2x
array", or "give me the sum total of all these numbers", etc., etc.
Without proper documentation, code is not maintainable. Period. It has
nothing to do with overloading of operators.
--
_ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194
' ) ) "The secret compartment of my ring I fill
/ / _ , __o ____ with an Underdog super-energy pill."
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blahsteve@vsi1.UUCP (Steve Maurer) (01/22/88)
} } > Instead, lets take for example... 2 dimentional arrays. } > What shall we define for them? Does '+' mean "combine into a 4 } > dimentional array", "add each seperate element together, depositing } > the results in a 2x array", or "give me the sum total of all these } > numbers" ? Does '*' indicate multiplication? Or does it mean take } > the dot product? What does '/' do?? The answers are quite system } > (or program) dependent. } } Would a function addmatrix(array1, array2) mean "combine into a 4 dimensional } array", "add each separate element together, depositing the results in a 2x } array", or "give me the sum total of all these numbers", etc., etc. } -- NEVIN J. LIBER Your function "addmatrix()" is unlikely to be used in other peoples' programs unless they know about it. The plus "+" operator is used in most programs. No one is forcing me to call "addmatrix()" to add two arbitrary numbers together, I can use what I please. However with plus "+", I had better use it, and also remember your special function for it when I happen to use that class of data. Overloaded functions aren't bad because in general the number of levels of Overloading is kept to a reasonable minimum; with overloaded operators that just isn't the case. Lets assume you have your function 'addmatrix()', but instead some language designer instituted the rule so that it became a non-descriptive function name: "A". Then he said, "A" must be used in infix notation, with a certain predefined precidence and associativity level, no matter what the function is supposed to do. Then he said "A" isn't just yours, "A" will be used by everybody: you must expect name colision. Then he said "A" was in use in already existing code, so when you write your Overloaded routine, you had better get it right or a lot of other people's code may break. Would you still feel as comfortable? > I won't argue the point that the facility can be abused. This merely > points out that software developers must agree on common notation for > an application and document thoroughly the notation used. > Ken Shrum Any facility can be used or abused. But consider the mirror image of your argument: even the worst features in the world can be defended by saying, "If you don't make mistakes, there won't be a problem". That, to me is not a justifiable defense. Mistakes _will_ be made, and it is by by whether language additions help find them, or hide them, that they should be judged. Even if the writers to this newsgroup are general enthusiasts of operloaded operators, I wonder how long they will remain so when they have to start using debuggers on the resulting code. The levels of complexity can be enormous in trying to intuit the meaning of such code, so source level debuggers will probably break down awfully inside of Overloaded Op expressions. This is only a prediction, not anything I have experienced. (I haven't seen a source level debugger for C++ yet, any out there??) Steve Maurer
chip@ateng.UUCP (Chip Salzenberg) (01/22/88)
In article <265@vsi1.UUCP> steve@vsi1.UUCP (Steve Maurer) writes: > > The thing that troubles me most about Operator overloading is that >definitions of basic operations, once static, are now contextual depending >upon the values of the particular programmer who wrote the header definition >code. This is no big deal. C already has this "problem" with program-specific macros and libraries. Let's not fall into the trap of considering a facility to be good only if it's universally available in a standard form. >[Operator overloading] can become the single greatest >obstruction to maintenence and portability of any program... Just because it _can_ become a problem does not mean that it _will_. Unless the programmer allows it to become a problem, that is. >[re: using + to mean string concatenation] >Is concatenation now the same as addition? Of course not. Neither is writing to a CRT the same as writing to a file. Yet I have heard no one complain that they don't like the UNIX write() call just because they can't tell what it does by looking at it. > The above examples, I reiterate, are not "bad" programming practice >in C++. They simply reflect the result of allowing each programmer >to select his own favorite notational convenience, and forcing him to >use a very limited set of operators which may not correspond well >(or at all) with the true functionality he is attempting to emulate. With the possible exception of operator= (assignment), no programmer is ever _forced_ to use operators. If a programmer uses an operator to represent something quite different conceptually from the normal meaning of that operator, that programmer has written _bad code_. So should we limit all programmers just because some make mistakes? Of course not. >Certainly standard operator notations may develop for commonly used >nomenclatures, but there is no guarantee that any such convention may >apply on any given machine, and there may very well be rival conventions. Who cares? This isn't Smalltalk, where every class fits into one big hierarchy. C++ has lots of little hierarchies. Differing conventions don't break programs. > I reserve the right to change my mind later, if and when a >perfect, 100% recognized, operational notation standard natually >develops for all common classes. However, I'm not holding my breath. Anything 100% recognized is 100% fossilized, and must by definition be acceptable to all its users. (Can you say "ANSI C"?) If C++ were in that state, I'd move on to something less "standard" and more useful. -- Chip Salzenberg UUCP: "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are a trade secret. "Anything that works is better than anything that doesn't."
mtoy@xman.SGI.COM (Michael Toy -- The S.G.I. XMAN) (01/23/88)
This looks like an argument that is going nowhere, so I thought I'd go along
for the ride.
It appears to me that Steve Maurer's concern about operator overloading
is that things which used to be set in concrete, that you could rely
upon, like "+" meaning add, are now up in the air. And I beleive I
recall him being concerned about the meaning of a program changing
depending on which set of include files is used. Thus a line like "a
+= 3", which used to require very little mental energy to parse, now
requires you be intimate with the implementation of the type of "a" to
know exactly what that means. These concerns come from a desire to
have people write code which is "maintainable" by people other than the
original author.
So I have these observations:
1) The definition of "+" for two integers will never change. If I see
"int a,b; a = b + a;" I'll always know what that means regardless of
what include files I have, operator overloading is only valid for new
types. Thus C++ code written using exisiting C features is no less
maintainable than it would be if it were used in a pure C environment.
2) Even without operator overloading, it is necessary to be fairly familiar
with the functions and variables assocaited with a class in order to
understand code which uses instances for that class. Thus having to be
intimate with the type of "a" to understand "a += 3" is no worse than
having to know about "a" to understand "a::open"
3) If a class is "clean" (see The Book, Preface: Thinking about Programming
in C++) then it should be clear to one who understands the abstraction that
the class represents, what a particular overloaded operator means. And even if
it isn't exactly clear, (like to "*" mean dot product or some other thing)
a quick glance can fix that once and for all.
4) Exisiting C, through the use of #define already has keyword overloading
and you can never really know what a C program does unless you read all
it's include files. And yet, with a couple of infamous exceptions, people
have not gone crazy with this feature but have some managed to restrain
themselves and write, maintainable code even though the were given a very long
rope with which to hang themselves.
--
Michael Toy, secret identity: the XMAN at Silicon Graphics
{ames,decwrl,sun}!sgi!mtoytracer@stb.UUCP (Jeff Boeing) (02/11/88)
In article <8180001@nucsrl.UUCP> gore@nucsrl.UUCP (Jacob Gore) writes: >It was my impression that in C++ you could not define operators with new names >-- only overload existing names. Aw, dingleberries! Does that mean I can't overload an operator called "**" and use it for exponents?! Drageburgers. We're right back to Kernighan & Ritchie's old double pwr(double x, int y) function. -- Jeff Boeing (which is not my real name) | uunet!stb.uucp!tracer ------------------------------------------|------------------------ "All right, you weak bosons! You're not dealing with some obscure 9th-level by-the-book paladin anymore!" -- Sick Sword