Re: Templates and access checking
From: Jari Kalevi Savolainen (jaksavol_at_hytti.uku.fi)
Date: 01/04/05
- Next message: Bob Hairgrove: "Re: Strange behaviour, bug in Borland compiler?"
- Previous message: Joona I Palaste: "Re: compile C programs with UNIX system calls (= Unix Programs??)"
- In reply to: Victor Bazarov: "Re: Templates and access checking"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 4 Jan 2005 17:55:31 +0200
On Tue, 4 Jan 2005, Victor Bazarov wrote:
> Several.
>
> First, why did you reply to another, unrelated, thread instead of starting
> a new one? Not a good idea.
That was my honest intention, mistake on my part.
>
> Second, I am not sure what you expect. c_store<A,A> and c_store<A,B> are
> two distinct and unrelated types. Unless you tell them to be friends of
> each other, there is no seeing of any privates.
Yes.
>
> Third, if you really need a design suggestion, post the real problem you
> are trying to solve instead of a hypothetical, contrived, and non-working
> solution.
>
I tried to provide a small compact code sample. Too small maybe and the
copy constructor I chose because I need to deep copy dynamically allocated
memory.
> Now, there are several work-arounds. A friend member function would be
> one. You can make them (instantiations) all friends of each other. You
> can have a member function that simply returns a value of 'data'. I am
> not sure what "exposure" you're afraid of.
Will try. Not sure if I've tried this.
The 'real' problem involves ptrs/dynamic memory. Keeping the pointer
private is my goal.
> A common base class probably
> won't work since an instance is not allowed to see even protected members
> of an object of another derived type.
It can be done but you need to bounce pointers around.
Not going to get any deeper into how, but it works.
But it creates the same problem as methods returning ptr/value need to be
public.
> Another solution is to drop the
> 'multiType' from the main template and _always_ have it for members:
>
> template<class T> class c_store {
> T data;
> public:
> template<class mT> c_store(mT md = 3) : data(md * 3) {}
> c_store(c_store const & cs) : data(cs.data) {} // actually no need
> };
>
> That of course may not be acceptable if you do need distinct types like
> c_store<int,int> and c_store<int,double>. But I cannot conclude that from
> the example you gave, that's why you need to state the real problem.
>
Again I obviously provided bad code sample, in my 'real' project it really
makes a difference and solution:
> template<class mT> c_store(mT md = 3) : data(md * 3) {}
Could result in unexpected behauvior, of course this is one way to do it
but it could easily lead to a situation where template generates code that
compiles fine but results are unexpected because the types are unsuitable
for operations performed.
> Please elaborate why these work-arounds are not suitable in your case.
>
> As to whether there was a discussion, try groups.google.com, that's a very
> good source of information that has been discussed. Yes, you'd need to
> dig through some posts. But that's what the search is for. Computer
> memory is much more reliable than human, keep that in mind.
Did that but couldn't find anything specific to this.
>
> Victor
>
- Next message: Bob Hairgrove: "Re: Strange behaviour, bug in Borland compiler?"
- Previous message: Joona I Palaste: "Re: compile C programs with UNIX system calls (= Unix Programs??)"
- In reply to: Victor Bazarov: "Re: Templates and access checking"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
