In article <KANZE.93Sep30185232@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>In article <rfgCE5p6t.7p0@netcom.com> rfg@netcom.com (Ronald F.
>Guilmette) writes:
>
>|> >In article <27milbINNsoj@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>|> >|In article <27maq1$aup@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
>|> >|Unless operator overloading can be made local to a compilation unit or
>|> >|class, you run the problem of conflicting changes from unrelated modules.
>
>|> Just a clarification.
>
>|> All user-defined entities (e.g. objects, functions, operators, etc.) only
>|> have significance within (and/or relevance to) those translation units which
>|> actually contain declarations and/or definitions of the entities in question.
>
>Well, it would be nice.  Barry Margolin's post, however, pointed out a
>case where this was definitly *not* the case: overloading '::operator new()'.

Humm.... that raises an interesting question.  What if I have:

 static operator new (size_t size) { /* ... */ }

in some translation unit?  Does it have an effect only within the current
translation unit?

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

>In article <27milbINNsoj@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>|In article <27maq1$aup@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
>|Unless operator overloading can be made local to a compilation unit or
>|class, you run the problem of conflicting changes from unrelated modules.

Just a clarification.

All user-defined entities (e.g. objects, functions, operators, etc.) only
have significance within (and/or relevance to) those translation units which
actually contain declarations and/or definitions of the entities in question.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCE5p6t.7p0@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

|> >In article <27milbINNsoj@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
|> >|In article <27maq1$aup@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
|> >|Unless operator overloading can be made local to a compilation unit or
|> >|class, you run the problem of conflicting changes from unrelated modules.

|> Just a clarification.

|> All user-defined entities (e.g. objects, functions, operators, etc.) only
|> have significance within (and/or relevance to) those translation units which
|> actually contain declarations and/or definitions of the entities in question.

Well, it would be nice.  Barry Margolin's post, however, pointed out a
case where this was definitly *not* the case: overloading '::operator new()'.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <rfgCE5p6t.7p0@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>In article <27milbINNsoj@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>>|In article <27maq1$aup@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
>>|Unless operator overloading can be made local to a compilation unit or
>>|class, you run the problem of conflicting changes from unrelated modules.

>All user-defined entities (e.g. objects, functions, operators, etc.) only
>have significance within (and/or relevance to) those translation units which
>actually contain declarations and/or definitions of the entities in question.

True.  But there are still problems likely to occur.  For example, if
you're trying to use libraries from two vendors within the same translation
unit, you would probably be #include'ing their header files.  If they
declare their operator overloadings there then you'll get multiple
definitions.

Of course, you can have the same problem if they choose conflicting class
names.  But that's an old, recognized problem, and there are people working
on namespace management solutions.
--
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

kanze@us-es.sel.de (James Kanze) writes:

>Well, it would be nice.  Barry Margolin's post, however, pointed out a
>case where this was definitly *not* the case: overloading '::operator new()'.

Yes.  One small point: I think you should call this "overriding"
::operator new() rather than "overloading" it.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <27milbINNsoj@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
|In article <27maq1$aup@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
|Unless operator overloading can be made local to a compilation unit or
|class, you run the problem of conflicting changes from unrelated modules.
|For instance, if defining operator+(char*,char*) were allowed, a library
|implementor might do it.  If a program that uses the library also tries to
|define this you'll get a conflict.  Or what if you try to link to two
|libraries that each provide such a definition?

This problem already exists, for example in the form of overloadable
global operator new.  What if more than one library each tries to
provide its own definition of global operator new?

In response to the ARM's "extensible but not mutable" rationale, in
article <27g8jj$13m@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU
writes:

> Personally, I find this particular rationale rather shaky.  Protect
> from WHOSE abuse, exactly?

Code that already works will still work unless you break the implemen-
tation of classes the code uses.  In particular, existing bodies of
ANSI C code should still do the same thing (unless they depend on
sizeof enums, implicit casts from (void *), or the like).  I see it as
protecting a library from its clients - the only way to break the
library is to actually alter its source, a useful property from C.

In article <27ichj$6r7@hebron.connected.com>, khan@hebron.connected.com (Erik Seaberg) writes:
> In response to the ARM's "extensible but not mutable" rationale, in
> article <27g8jj$13m@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU
> writes:
>
> > Personally, I find this particular rationale [for requiring that
> > the type of at least one operand of a user-defined operator be a
> > class, pointer to class, or reference to class] rather shaky.  Protect
> > from WHOSE abuse, exactly?
>
> Code that already works will still work unless you break the implemen-
> tation of classes the code uses.  In particular, existing bodies of
> ANSI C code should still do the same thing (unless they depend on
> sizeof enums, implicit casts from (void *), or the like).  I see it as
> protecting a library from its clients - the only way to break the
> library is to actually alter its source, a useful property from C.

*FLAME ON [Don't bother responding; the following is merely a release
of steam.  All personal attacks in it are completely inadvertent]*

Yes, yes, this is an all-too-familiar refrain.  I heard it MANY times
during the development of Ada, and I often had cause to wonder how
many of the intricate and lengthy passages that people complain about
in that language's manual are due to non-orthogonal ``methodological''
restrictions of this well-intentioned sort.

The point is that in the process of protecting us from idiots who
redefine int operator+(int,int) as arithmetic minus and expect their
programs to work, we are also "protected" from direct definition of
operator+ on, e.g., char*, where it is not pre-defined.

Besides, if someone actually WAS idiotic enough to do one of the nasty
things this restriction prohibits, isn't his code likely to cause me
so many problems anyway that fixing this one is like bailing the
Titanic with a teaspoon?

"It is impossible to design a language that prevents bad programming
and harmful to try."

*FLAME OFF*

Ah! That feels MUCH better.  Thank you for your indulgence.

P. Hilfinger

In article <27maq1$aup@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
>The point is that in the process of protecting us from idiots who
>redefine int operator+(int,int) as arithmetic minus and expect their
>programs to work, we are also "protected" from direct definition of
>operator+ on, e.g., char*, where it is not pre-defined.

Unless operator overloading can be made local to a compilation unit or
class, you run the problem of conflicting changes from unrelated modules.
For instance, if defining operator+(char*,char*) were allowed, a library
implementor might do it.  If a program that uses the library also tries to
define this you'll get a conflict.  Or what if you try to link to two
libraries that each provide such a definition?

Classes are the unit of modularity in C++.  Built-in types are global, and
you're asking for trouble when you allow programmers to customize the
behavior of globals.  In essense, such overloads become part of the public
interface of a module, restricting what the module user can do and what
other modules may be linked with it.

>"It is impossible to design a language that prevents bad programming
>and harmful to try."

But why include features that provide little benefit and can cause much
trouble?  Operator overloading is simply minor syntactic sugar and is
hardly necessary.  Why entice programmers to violate modularity just for
this?
--
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar