> 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
: 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
that'd have been another matter. The
> possibility of that means the technique remains worth some
> 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
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 :-)