From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-04 21:36:54
"Justin M. Lewis" wrote:
> I have thought about that, yes. And, as these were first made, I'll go
> through their history again. Originally it was only for out values, that
> was my original use. I had discussions with some people on IRC, someone
> there split the code into 2 classes, out and in_out, and on top of that, he
> made them different. out params did NOT allow you access to the internal
> object at all, it ONLY gave you a = operator so you could assign the
> internal object something. Both classes at one point had asserts to make
> sure the internal data was modified in some way before the destruction of
> the out or in_out object. I found that to be annoying, because I may not
> simply want to assign a value to an out object. I may want to use one of
> its member functions to modify it, or initialize it. So, I gave both
> classes cast operators, so I could get the internal data, then removed the
> assert, because it was in the way now. Now, you MIGHT be able to set these
> classes up in such a way that you can access the member functions of an out
> object, but, not get a reference to it still, so you can't just grab it and
> start screwing with it however you want. The problem is, you still have no
> way of determining which member functions inside the object depend on the
> current state of the object, and which ones don't. So, ultimately, no
> matter how you do this, some of the burden of not breaking the system falls
> on the programmer.
OK. What happens if we turn this around?
We're pretty sure we can't have pure out parameters (at least not
without a lot of pain). Then again, we're almost certain we can have
pure in parameters. So, why not use in_out<> for both out (since pure
out parameters don't exist in C++ anyway) and in/out parameters, and
in<> for pure in parameters?
> That's a good thing though, all that maintenance keeps us employed.
Ahh, yes, the worthy goal of staying employed rather than adding value
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk