tags:

views:

186

answers:

3
A: 

Your Ptr class has a non-const pointer member. You will not be able to assign a const Base* without some unsafe casts. Do you want that? Try this instead:

template <class f, class g>
class Ptr
{
   public:
    Ptr(){};
    Ptr(Base<f,g,Ptr<f,g> > const* a) { in = *a; }
    Base<f,g,Ptr<f,g> >* operator->()
    {
        return &in;
    };

    Base<f,g,Ptr<f,g> >& operator*()
    {
        return in;
    };

private:
    Base<f,g,Ptr<f,g> > in;
};
dirkgently
Hmm. Looks good, but if Base<f, g, Ptr<f, g> > has a member of type Ptr<f, g>, this will create an infinite-sized class. But I haven't figured out what the OP's trying to do so I'm not sure if that's likely to be the case...
j_random_hacker
Sorry, that's not a feasible option: I have to keep a pointer to the original object in this case not the object itself in order to do things with the addresses later (it's not nice code).The full version of it is a Neural Network simulator, so it'd take about a week to explain the full situation!
Ed Woodcock
+1  A: 

according your example you should do

Ptr( const Base< f,g, Ptr< f, g > >* a )
{
   in = const_cast< Base<f,g,Ptr<f,g> >* > ( a );
}

ps: I don't like const_cast and in similar cases I try to avoid this. Maybe need do two implementation of Ptr for const and non const arguments.

bb
"Invalid use of const_cast with type ‘Ptr<double, double>’, which is not a pointer, reference, nor a pointer-to-data-member type."I already said this was not a option.
Ed Woodcock
I don't know why you can't compile my sample. I tested this on my msvc 2005 compiler - all ok. Please provide most detailed information about your problem.
bb
I understand that the code SHOULD compile. However, for completely unknown and probably incredibly complex reasons it doesn't, as I said in the question. I'll remove the -1 but you should really read the question before answering.
Ed Woodcock
Sorry, I really read your question, it had misspelling errors, I fixed it and compiled, all worked.If it not compiles now, could you send me comlette code file? I will have chance to find problem.
bb
+2  A: 

I think you need to define a separate class to wrap pointers to const, since not only the arguments of the constructor, but also the return types of the operators should be changed to const versions. If you make the ConstPtr a friend of Ptr, this should work out quite nicely:

template<...>
class ConstPtr {
  const Base<...> *in;
  ConstPtr(Base<...>* a) { in = a; }
  ConstPtr(const Base<...>* a) { in = a; }
  ConstPtr(const Ptr<...> &a) { in = a.in; }
  ...
};

To construct wrappers from raw pointers you could add an overloaded function, more or less like this:

template<..., class P>
P make_ptr(Base<...> *t);

template<...>
Ptr<...> make_ptr< ..., Ptr<...> >(Base<...> *t) {
  return Ptr(t);
}

template<...>
ConstPtr<...> make_ptr< ..., ConstPtr<...> >(const Base<...> *t) {
  return ConstPtr(t)
}
sth
Any chance of being a little more verbose on the friend syntax? It's not working as I expected and I'd like to see what you actually had in mind!
Ed Woodcock
My plan was to put "friend ConstPtr<...>;" in the definition of "Ptr<...>", to let the constructor of ConstPtr access "a.in". I haven't tested it though and maybe there are some complications due to the templates.
sth
Ok, that's what I did. Is there any way to throw it into a ConstPtr automatically? It's not an option to have distinct classes for the two opti
Ed Woodcock
options* (Javascript is REALLY screwy on linux sometimes)
Ed Woodcock
Edited and added a "factory function". But in the end, you won't get a simple Ptr<a,b> out of the poniter to const, you will be stuck with two different types one way or another. After all, the const and the non-const version are two different things.
sth