|
Re: What's Your Address?
|
Posted: Apr 10, 2005 9:11 AM
|
|
> 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 :-)
|
|