🚀 go-pugleaf

In article <xsospe5me40.fsf@juicer.cs.rpi.edu> vandevod@cs.rpi.edu
(David Vandevoorde) writes:

|> >>>>> "JK" == J Kanze <kanze@gabi-soft.fr> writes:
|> [...]
|> JK> Well, I agree fully that it is bad programming practice to let
|> JK> exceptions propagate out of a destructor.  At present, however, it
|> JK> is legal C++ (although if the committee were to declare it
|> JK> undefined behavior, they wouldn't get any objections from me), and
|> JK> as such, should be taken into consideration when designing a
|> JK> *standard* library component.  (I *don't* take it into
|> JK> consideration when designing my own components.  But: if you don't
|> JK> like my style, you aren't obliged to use my components.  Everyone
|>                                                              ^^^^^^^^
|> JK> has to use the standard components, however.)
|>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> I would like to contest that ;-)

Yes.  I should have said: everyone should be able to use the standard
components.

|> Given the kind of overhead in the ``auto_ptr nouveau'', I'm unlikely
|> to want to use it... and nothing prevents me from that. As far as I
|> know, auto_ptr does not have any connections with the rest of the
|> language (i.e., if it were dropped, there would be no repercussions).
|> Furthermore, it's really not hard to fashion a auto_ptr-like template
|> that fits one's desired semantics.

|> In that light, it seems to me that a standard auto_ptr is a little
|> overkill... Fortunately, I'm not forced to use it and so don't care
|> too much.

The problem is one of maintainance.  I'm fairly sure that most of the
readers of this forum would have no difficulty crafting a variant of
auto_ptr which is exactly adapted to their particular style.  Doing so,
however, means one more thing to learn for anyone trying to maintain
your code.  So if the standard class comes anywhere close to what I
want or need, I will be using it, instead of my own.

Note that almost by definition, a standard class is not optimal for a
particular use.  What makes it valuable as a standard is that it is
adequate for a wide range of uses.  If some part of your application
makes intensive use of this class, you might want to declare a typedef,
to facilitate changing it later, if profiling really does show a
problem.  (My experience is that it's amazing how rarely such things
really are a problem, and that generally, they aren't what you were
expecting anyway.)
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]