From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-04-24 17:09:06
"Justin M. Lewis" wrote:
>
> I'd be against the idea of doing something like
>
> const int x;
> func1(x);
> func2(x);
> func3(const_cast<int &>(x));
I didn't suggested anything of the sort.
> When I see const on a variable I expect it to not change anywhere. I'm
> against violating const when possible, so I wouldn't do it as a general
> design rule. const would lose all meaning in a program where you started
> const_casting all over.
Maybe I'm missing something since I missed the beginning of this thread. Can you explain what the intention of the proposed class and its usage (from both the caller and the callee), please?
> And, as far as the macro goes
> > #define in_out( obj ) obj
> There's no guaranteed enforcement there. People who feel like using it
> might, those who don't feel like using it won't. So, no one would have to
> follow the rule. With the classes, they're type checked at compile time, if
> you don't specify func3(out(x)); with my method, it will not compile.
> People calling my function would have to decorate the function call
> appropriately.
OK. I think I see what you're getting at. And now, I think I'm starting to like the idea. OTOH, I also still think such usage would be most useful to large objects only -- small objects should be returned from the function.
Noel
-- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.