Re: Why there is dereference in std::auto_ptr::operator->() ?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"Alex Blekhman" <tkfx.N05P4M@xxxxxxxxx> wrote in message
news:%23UDXvV%23dFHA.1136@xxxxxxxxxxxxxxxxxxxxxxx

> P.J. Plauger wrote:
>> Alex Blekhman wrote:
>>> Requirements are strict indeed. However, in my opinion,
>>> they ought not to prohibit certain freedom completely.
>>> Currently, auto_ptr hinders to return anything but T*
>>> from operator&. I can't see any benefit to auto_ptr in
>>> doing that.
>>
>> Good, write a version that doesn't and propose it to
>> WG21. The fact is that auto_ptr barely works as it
>> stands. It intentionally relies on a creative
>> interpretation of the antepenultimate draft of the C++
>> Standard which *no* compiler actually implemented at the
>> time. VC++ could support auto_ptr without kludges only
>> with V7.1. The design is an attempt to merge two or three
>> (of about 32) different use cases onto one class.
>> Naturally, it barely works for any one of those use
>> cases.
>
> That changes the picture. I can understand constraints that
> different compilers and/or usage patterns can impose on
> "one-size-fits-all" class.
>
>> Overloading operator& is *always* dangerous in C++. Using
>> auto_ptr for anything other than assured destruction of an
>> allocated object is equally dangerous. Feel free to
>> criticize the style with which auto_ptr is implemented,
>> or the design decisions that went into the current spec.
>> But until you can make something sing and dance that's
>> arguably better, your opinion doesn't carry a lot of
>> weight (IMO).
>
> It was not just criticizing in sake of criticizing. I'm far
> from competing with you in C++ field considering your
> experience and you're being one of leading persons in the
> industry. I honestly tried to understand auto_ptr
> implementation. When writing my own code I frequently look
> at STL classes to learn how things may be acomplished and
> why it's done in this way and not in another one. I was
> writing kind of smart pointer, so naturally I peeked at
> auto_ptr implementation for insights and was stumbled upon
> by auto_ptr::operator->. "Should I do it in my code, too?",
> "Is it by omission or on purpose? If on purpose, then what
> is the purpose?" - these question I asked myself. After
> thinking about it and trying to find the answer in
> literature I still wasn't able to figure out the reason. So,
> I posted the question in this NG. I'll take for granted your
> answer that dereference there is for reason. Probably, some
> day I'll find the case where it manifest itself.

Well, truth to tell it got there for historical reasons. And
as someone else (Daniels? Widmer?) pointed out in this thread,
the code isn't highly consistent. So I've changed our baseline
to call get more uniformly instead.

> Thanks kindly for your reply.

And thanks for listening.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


.

Relevant Pages

  • Re: Why there is dereference in std::auto_ptr::operator->() ?
    ... However, in my opinion, ... It was not just criticizing in sake of criticizing. ... "Is it by omission or on purpose? ... literature I still wasn't able to figure out the reason. ...
    (microsoft.public.vc.language)
  • Re: Add Downloads to Start Menu
    ... part, right part, as long as it's there doesn't it serve its purpose? ... Your opinion is the reason I posted what I thought was a common sense approach. ...
    (microsoft.public.windows.vista.security)
  • Re: Planet (Island) of Fire -- LIBTR/LBTR
    ... There is a natural law, ... "There may not be an 'I' in team, but there is an 'I' in Libertarian ... "Honesty Makes An Opinion Important, ... -- Thomas Paine, The Age Of Reason. ...
    (rec.arts.drwho)
  • Re: Todays Quote
    ... opinion, and I keep saying over and over that no one knows why Baha'u'llah ... there is no reason to address your opinions. ... mostly those of arbitration and ceremony. ... The Baha'i Faith has an administrative ...
    (talk.religion.bahai)