In this excerpt (Chapter 26) of his book, Imperfect C++, author Matthew Wilson convinces us that overloading the address-of operator is not a very good idea.

http://www.artima.com/cppsource/YourAddress.html

> In this excerpt (Chapter 26) of his book, Imperfect C++,
> author Matthew Wilson convinces us that overloading the
> address-of operator is not a very good idea.

Even though I respect Matthew's work deeply, I am not thoroughly convinced that overloading the address-of is neccessarily a bad idea.

I have written a blog post outlining a possible use case for overloading the address-of operator, based on an idea of using undeletable pointer types at http://www.artima.com/weblogs/viewpost.jsp?thread=102857

Hmmm... somehow I can't get rid of the feeling that the beloved occupation of all the C++ gurus is to search for imaginative ways how to break the language [which is quite fragile anyway], and then to write papers and books saying: "Rule 456: Don't ever do this...." :-)))

Overloading &operator() is of course (IMHO) fundamentally broken since the purpose of any operator overloading should be to provide syntactic sugar and not to change semantics -- and I can't see any purpose for which you may want to overload the &operator() anyway... This includes the "un-deletable" trick too: if the standard defines what can be fed to the delete operator, then there must be a cleaner way to deal with it (encapsulation?) than trying to trick&break it it using another tricky&broken language feature...

I have to agree with Pasko. It seems like doing clever things like this create code that is hard to fathom. Basic things like operators working (or not working) in unusual ways does not contribute to more readable and maintainable code.

I am not suggesting anything tricky, simply that the return type of a new operation should not be the same as the return type of an address-of operation. I don't see how what I am suggesting is particularly clever, just perhaps slightly uncoventional. (Mind you, many of the conventions we are familiar with are more than a little bit outdated).

The problem I have with your motivating example is that it is not motivating, since it applies a behavioural trait to a class based on an invalid use of an instance: distinctly flawed reasoning.

If you'd shown an adaptive template being applied to the instance that'd have been another matter. The possibility of that means the technique remains worth some interest.

But, overall, I fear that, just as C++ is not a functional language, neither it is a declarative language, and trying to do much of either risks causing the eyes of most good, diligent, capable, productivity-focused engineers to glaze.

This exposes a flank on the enormous elephant in our (the C++) living room, that many of the tricks that many of us examine are just too tricky. This is an issue that's taking more and more of my time, as I spend a lot of time using Python and Ruby and other languages, but I have not yet reached any kind of point of comfort.

Hmmm, maybe that long awaited blog should get kicked into gear ...

Not sure if the guru comment's meant to apply to Chris or to me. If it's to me, thanks with the usual self-deprecating denials. :-)

If it is me, then I'm afraid my message is not getting through at all. Although it's quite true that C++ is intellectually satisfying in its own right, by virtue of being an infinite playground for the perverse, I feel that my take on it is always one of the pragmatist trying to find a reasonably clear path through.

The approach I aim for, and which Imperfect C++ takes explicitly, is that there are good principles to follow / techniques to use, but that one often encounters situations where the rules must (or expediently should) be broken. [I'm guessing from your comment you've not read Imperfect C++ yet. I'd be interested, though concerned, if you have the same opinion after doing so.]

For me, programming knowledge and wisdom has most often been gained on this border between the dutiful and the reckless, and it is that area that I most often inhabit as a writer. I'm sorry if this sniffs of a disingenuous way of generating wordage, but I can promise you that's not the case. And though I can't speak for other authors - some of whose work I have the reaction to that you've had (and I expect they do to mine) - my guess is that all are doing the same. (After all, why else would one do it? It certainly isn't for the cash. Nor can it be for the unalloyed warm reactions of the C++ audience, which'd have to be one of the most informed and vocal in the business. <g>)


Regarding your observation about the language, it's simply necessary for effective mastery of C++ to grok the ramification of stack based variables. It's not always easy, of course ...

Ooops... The comment should be read they way it was written: with the smiling face afterwards... :-)

4 Matthew: the message got through; what I've found sad was that messages like this needs to be written at all... or perhaps to rephrase it a bit - that the language is defined in such a way that there is need for messages like this... and the ensuing discussion is of course confirmation of the old truth that messengers do sometimes have dangerous life... :-)

4 Chris: if a 'determined specialist' decides at certain point that he wants to delete something, well.. he will find a way to do it... and no obstacle in the world (nor in the code :-) will stop him from doing it (or from doing something, which he will believe is equivalent to 'it')... c'est la vie :-)

> The problem I have with your motivating example is that it
> is not motivating, since it applies a behavioural trait to
> a class based on an invalid use of an
> instance: distinctly flawed reasoning.

I am specifically showing how to transform invalid uses permitted by the compiler into invalid uses prevented by the compiler. I really do not see how there is anything flawed about my reasoning.

I am suggesting in general that the compiler's role, and more specifically that of a type system, is to detect and prevent invalid usage at compile time. How else can I show this then by use examples of invalid usage?

At the risk of repeating myself, my point is that there are several separate types implicit in what is traditionally called a "pointer"

- address of an object
- a reference to a dynamically allocated object,
- a reference to an array of dynamically allocated objects,
- a reference to single item in an array of items

Each of the above is a perfect candidate for a type as it has its own set of operations, and are not intended to be used interchangeably.

The common way of thinking about pointers being equivalent is simply a flawed approach which has been carried over from C.

One easy way to correct this is to introduce a new pointer class, and have it returned from an address-of operation.

> If you'd shown an adaptive template being applied to the
> instance that'd have been another matter. The
> possibility of that means the technique remains worth some
> interest.
>
> But, overall, I fear that, just as C++ is not a functional
> language, neither it is a declarative language,

[I am missing something, because I didn't follow your segue into functional/declarative programming. Doesn't stop me from having a boisterous opinion of cours ;-) ]

I don't agree. You can write functional code in C++ just as easily as in any other language. The problem has been lack of imagination, effort and libraries along with what I find to be a somewhat puzzling attitude that C++ is only for imperative programming.

[aside: I am currently working on a functional C++ library / programming language called Unimperative, and things are going very well. You can peek at an example at http://www.ootl.org/uni/standard.uni.htm but the documentation is not yet available]

> and trying
> to do much of either risks causing the eyes of most good,
> diligent, capable, productivity-focused engineers to
> glaze.

This sounds like you are suggesting that using C++ to write functional code would make me or anyone else the opposite of a good engineer (or you are suggesting that good engineers don't use functional code :-p ). I would obviously disagree. Besides, the same can be said for well-written imperative C++ code.

> This exposes a flank on the enormous elephant in our (the
> C++) living room, that many of the tricks that many of us
> examine are just too tricky. This is an issue
> that's taking more and more of my time, as I spend a lot
> of time using Python and Ruby and other languages, but I
> have not yet reached any kind of point of comfort.
> Hmmm, maybe that long awaited blog should get kicked into
> gear ...

I hope so, I for one would enjoy reading your blog :-)

> 4 Chris: if a 'determined specialist' decides at certain
> point that he wants to delete something, well.. he will
> find a way to do it... and no obstacle in the world (nor
> in the code :-) will stop him from doing it (or from doing
> something, which he will believe is equivalent to 'it')...
> c'est la vie :-)

The point is not to try and stop the determined specialist, but rather to make accidental invalid usage harder. In a more general sense this is precisely what a type system is supposed to do.

Allow me to draw an analogy to the discussion of static versus dynamic typing. Consider the following snippet of code in some dynamically typed language:


let x = 3;
let y = "hello";
print x + y;


Introducing static typing makes it easier to catch the error at line 3:


int x = 3;
string y = "hello";
print x + y; // doesn't compile


It appears you are suggesting that if a programmer can recast the types maliciously as in:


int x = 3;
string y = "hello";
print x + force_cast<int>(y); // compiles but erroneous


Then we shouldn't introduce static typing which would be clearly not a good idea.

AFAICT what Matthew is suggesting about my using flawed logic, would also have apply to the static typing argument I present here.

> > 4 Chris: if a 'determined specialist' decides at
> certain
> > point that he wants to delete something, well.. he will
> > find a way to do it... and no obstacle in the world
> (nor
> > in the code :-) will stop him from doing it (or from
> doing
> > something, which he will believe is equivalent to
> 'it')...
> > c'est la vie :-)
>
> The point is not to try and stop the determined
> specialist, but rather to make accidental invalid usage
> harder. In a more general sense this is precisely what a
> type system is supposed to do.

The question, I think, is where one draws the line. When does proscription become patronisation? Also, when does the complexity of the solution outweigh the difficulty in absorbing an idiom?

> AFAICT what Matthew is suggesting about my using flawed
> logic, would also have apply to the static typing argument
> I present here.

My problem with your motivating example was that you'd applied a trait to a type to avoid a problem with a use of an instance, i.e. you'd made a type undeleteable because one stack instance of it was misused.

My suggestion for refinement was to use an adaptive template to decorate the (type of the) instance, and leave that type as is.

> > The point is not to try and stop the determined
> > specialist, but rather to make accidental invalid usage
> > harder. In a more general sense this is precisely what
> a
> > type system is supposed to do.
>
> The question, I think, is where one draws the line. When
> does proscription become patronisation? Also, when does
> the complexity of the solution outweigh the difficulty in
> absorbing an idiom?
>
> > AFAICT what Matthew is suggesting about my using flawed
> > logic, would also have apply to the static typing
> argument
> > I present here.
>
> My problem with your motivating example was that you'd
> applied a trait to a type to avoid a problem with a use of
> an instance, i.e. you'd made a type undeleteable because
> one stack instance of it was misused.

I did not make the type undeletable. I simply prevented deletion of objects through pointers resulted from address-of operations. You can still just as easily assign the pointer type result of a new operation to a deletable pointer.

> My suggestion for refinement was to use an adaptive
> template to decorate the (type of the) instance, and leave
> that type as is.

That's another option, BUT it does not make my original example flawed logic.

> > > The point is not to try and stop the determined
> > > specialist, but rather to make accidental invalid
> usage
> > > harder. In a more general sense this is precisely
> what
> > a
> > > type system is supposed to do.
> >
> > The question, I think, is where one draws the line.
> When
> > does proscription become patronisation? Also, when does
> > the complexity of the solution outweigh the difficulty
> in
> > absorbing an idiom?
> >
> > > AFAICT what Matthew is suggesting about my using
> flawed
> > > logic, would also have apply to the static typing
> > argument
> > > I present here.
> >
> > My problem with your motivating example was that you'd
> > applied a trait to a type to avoid a problem with a use
> of
> > an instance, i.e. you'd made a type undeleteable
> because
> > one stack instance of it was misused.
>
> I did not make the type undeletable. I simply prevented
> deletion of objects through pointers resulted from
> address-of operations. You can still just as easily assign
> the pointer type result of a new operation to a deletable
> pointer.

Yes, I had failed to keep that part in mind. For some reason I was thinking you'd prevented deletion of heap allocation objects, such as

  delete new SomeObject();

whereas what you've prevented is the fatuous:

  delete &*(new SomeObject());

But notwithstanding that concession, I still maintain that applying traits to classes to handle misuse of instances is not sound reasoning. Since one could get into the scrape you've illustrated in your code (in http://www.artima.com/weblogs/viewpost.jsp?thread=102857) with any type, in principle every type that was to have stack instances should provided operator &() overloads.

And there're still the significant practical objections to using operator &() described in the chapter.

> > My suggestion for refinement was to use an adaptive
> > template to decorate the (type of the) instance, and
> leave
> > that type as is.
>
> That's another option, BUT it does not make my original
> example flawed logic.

No it doesn't, but my arguments given above do, I feel.

Anyway, we're at a debate dead-end here, methinks. I think your technique is interesting and useful, I'd just apply it in a different fashion, specifically via an undeleteable veneer. (Veneers are discussed in Chapter 21 of Imperfect C++, along with constraints for how to ensure they do not violate the principle against public non-virtual derivation; not that one needs to worry about such things when one is using one instance on the stack of course).

Here's my preferred use of your technique

  template <typename T>
  class undeleteable_veneer
    : public 
  {
  // Types
  public:
    typedef ::ootl::ptr<T, !::ootl::deletable> undeletable_ptr;

  // Construction - only showing default ctor; you can do the fwding ones yourself. ;)
  public:
    undeleteable_veneer()
    {}

  public:
    undeletable_ptr operator&()
    {
      return this;
    }
  };

  int main()
  {
    undeleteable_veneer<SomeObject> o;
    SomeObject* p;
    p = &o; // compiler error; undeletable pointers can not be assigned to raw pointers.
    delete p;
    return 0;
  }