Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.object
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.alpha.net!uwm.edu!math.ohio-state.edu!scipio.cyberstore.ca!vanbc.wimsey.com!molienergy!janr
From: janr@molienergy.bc.ca (Jan Reimers)
Subject: Re: C++ Productivity
Message-ID: <1995Feb8.161815.21417@molienergy.bc.ca>
Date: Wed, 8 Feb 95 16:18:15 GMT
References: <1995Feb1.184049.16332@rcmcon.com> <D3E33s.DCp@da_vinci.ecte.uswc.uswest.com> <1995Feb6.113136@di.epfl.ch>
Organization: Moli Energy 1990 Ltd., Burnaby, B.C., CANADA
Lines: 31
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:111777 comp.lang.smalltalk:20592 comp.object:26419

In article <1995Feb6.113136@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
>In article <D3E33s.DCp@da_vinci.ecte.uswc.uswest.com>, tblanch@lookout (Todd Blanchard) writes:
>
>|> 
>|> That C++ is so hard to use correctly *is* a weakness of the language.
>|> The language is too big, too much code gets called unexpectedly.  A
>|> perfect example is a program where I had to inherit from a vender
>|> supplied class.  The class had a const char* operator.  I thought this
>|> would get used when I said:
>|> 
>|> cout << myObject << endl;
>|> 
>|> It was, sort of but my object was first copied onto the stack, then
>|> converted.  The vender code was not copy safe and had pointer based
>|> memory.  The app went down in flames and I spent 2 days figuring this
>|> out.  This happens all the time in wonderful C++. 
>
>The problem here is that you don't really have complete control over
>abstractions in C++. It would be nice to say that there is no op=
>for some classes and then have the compiler check this statically.
>This is easier said than done since the ramifications of such a
>decision are not trivial. Ada makes the distinction between types that
>have an assignement operation and those that don't but it wouldn't
>be just a trivial change to add this to C++.
>

Why not just make op= private?


-- 
janr@molienergy.bc.ca
