Jari said:
Bit of code first:
template <typename storeType, typename multiType>
class c_store {
storeType data;
public:
c_store() {
data = multiType(3) * 3;
}
I'd do
c_store() : data(multiType(3)*3) {}
template<typename srcMultiType> //storeType has to match
c_store(const c_store<storeType, srcMultiType> & src) {
data = src.data;
}
};
c_store<int, int> a;
c_store<int, double> b(a);
And we have problems. Compilers report that data is private, which is what
they should do.
There are ways to work around this problem ofcourse, declare a friend
function that returns the data or have a base class that has public method
to do that(ptrs needed and stuff, hack and overkill).
Either way data exposure occurs aswell.
Is there a way to safely, not by some pointer hack, to get this done. I
haven't been able to come up with one yet.
And as everyone can see the Multitype is not a datamember of class
c_store, so the memory usage is the same for instance a and b. the
multiType is only used in methods as a local.
The code above certainly doesn't make much sense but I have a piece of
code where this sort of template usage is 'neat'. The tradeoff is the
exposure that the friend function creates.
Has there been discussion about this before? I'd very much would like to
see a standart where you could specify template parameters as 'not member
types'.
for example:
template<typename T, typename_onlycode U>
where typename_onlycode couldn't be used in datamember declarations.
Therefore no need for access checking.
Thoughts?
Several.
First, why did you reply to another, unrelated, thread instead of starting
a new one? Not a good idea.
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.
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.
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. 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. 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.
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.
Victor