[opensuse-programming] C++ inheritance issue
I have a case where the compiler is giving me an error: ./FOO.H: In member function Bar<ItemType>::operator()(ItemType&)': ./FOO.H:447: error: `i_key' was not declared in this scope Class bar is defined: template <class ItemType> class Bar public FuBar<ItemType, type_t> And, i_key is defined as a protected member of FuBar: template <class ItemType, class ThisType> class FuBar : public Another<ItemType>, public RWTPtrorderedVector<ItemType> ..... protected: ThisType const & i_key; I'm using g++ version 3.4.5. g++ -MMD -MP -g -O3 -Wall -fpic -D__linux_x86_64__ -I. -I/<other included dirs> -D_RWCONFIG_rmd -c Foo.C -o Foo.o I can easily work around by adding a public accessor function, but this code does work on other company builds, but this is a simply access to a protected data element that should be visible from inheriting classes. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Fri, 2007-04-27 at 14:46 -0400, Jerry Feldman wrote:
I have a case where the compiler is giving me an error: ./FOO.H: In member function Bar<ItemType>::operator()(ItemType&)': ./FOO.H:447: error: `i_key' was not declared in this scope
I think you need to use this->i_key instead of i_key. The logic is this. C++ looks up nondependent names like i_key as soon as they are encountered. But it can't find i_key because it is possible for you to create an explicit specialization of FuBar in which i_key is not of type ThisType const &. Using this->i_key delays name lookup to the point of instantiation of the class, by which time its type will be known for certain. -- JDL --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On Fri, 2007-04-27 at 14:46 -0400, Jerry Feldman wrote:
I have a case where the compiler is giving me an error: ./FOO.H: In member function Bar<ItemType>::operator()(ItemType&)': ./FOO.H:447: error: `i_key' was not declared in this scope
I think you need to use this->i_key instead of i_key.
The logic is this. C++ looks up nondependent names like i_key as soon as they are encountered. But it can't find i_key because it is possible for you to create an explicit specialization of FuBar in which i_key is not of type ThisType const &. Using this->i_key delays name lookup to the point of instantiation of the class, by which time its type will be known for certain. No. this->i_key is equivalent to i_key in a member function. The issue is with the dual template arguments. i_key is defined in the
On Sat, 28 Apr 2007 07:45:41 +0100 John D Lamb <J.D.Lamb@btinternet.com> wrote: base class as: ThisType const & i_key; But the inheriting class does not include the ThisType template parameter. The correct solution, as I found out yesterday afternoon is to refer to i_key as fully qualified: FuBar<ItemType, type_t>::i_key; The calling function is a member of bar with is defined as: template <class ItemType> class Bar : public FuBar<ItemType, type_t> Since this code actually works in the company's other product, I was looking at some of the compiler options rather than the correct C++ solution. (BTW: type_t is simply a typedef to an enumeration). Actually there are 4 different classes, where 2 take type_t, 1 std:string, and the fourth, std::vector<type_t>. It's amazing how much you look at something and know the solution, but can't think of it. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Sat, 2007-04-28 at 11:00 -0400, Jerry Feldman wrote:
No. this->i_key is equivalent to i_key in a member function. The issue is with the dual template arguments. i_key is defined in the base class as: ThisType const & i_key;
But the inheriting class does not include the ThisType template parameter. The correct solution, as I found out yesterday afternoon is to refer to i_key as fully qualified: FuBar<ItemType, type_t>::i_key;
That should also work because it makes i_key nondependent and I'm not surprised you spotted that one so quickly. Was there something about the context of i_key that made this->i_key not work? I don't think I've encountered a context in which it would fail, but it wouldn't surprise me if there are some. My instinct says we've found alternative solutions to the same problem. Mine avoids some problems with virtual function calls, but I suspect there is going to be some occasion when it won't work. -- JDL --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On Sat, 28 Apr 2007 18:10:59 +0100 John D Lamb <J.D.Lamb@btinternet.com> wrote:
On Sat, 2007-04-28 at 11:00 -0400, Jerry Feldman wrote:
No. this->i_key is equivalent to i_key in a member function. The issue is with the dual template arguments. i_key is defined in the base class as: ThisType const & i_key;
But the inheriting class does not include the ThisType template parameter. The correct solution, as I found out yesterday afternoon is to refer to i_key as fully qualified: FuBar<ItemType, type_t>::i_key;
That should also work because it makes i_key nondependent and I'm not surprised you spotted that one so quickly.
Was there something about the context of i_key that made this->i_key not work? I don't think I've encountered a context in which it would fail, but it wouldn't surprise me if there are some.
My instinct says we've found alternative solutions to the same problem. Mine avoids some problems with virtual function calls, but I suspect there is going to be some occasion when it won't work. In this case, i_key is a member of the base class: FuBar<ItemType, type_t> I think the problem is the compiler is unable to resolve i_key because of the second template parameter. I'll double check using 'this->.
-- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Sat, 2007-04-28 at 11:00 -0400, Jerry Feldman wrote:
No. this->i_key is equivalent to i_key in a member function. The issue is with the dual template arguments. i_key is defined in the base class as: ThisType const & i_key;
But the inheriting class does not include the ThisType template parameter. The correct solution, as I found out yesterday afternoon is to refer to i_key as fully qualified: FuBar<ItemType, type_t>::i_key;
That should also work because it makes i_key nondependent and I'm not surprised you spotted that one so quickly.
Was there something about the context of i_key that made this->i_key not work? I don't think I've encountered a context in which it would fail, but it wouldn't surprise me if there are some.
My instinct says we've found alternative solutions to the same problem. Mine avoids some problems with virtual function calls, but I suspect there is going to be some occasion when it won't work. Hi John, I just changed the code from FuBar<ItemType, type_t>::i_key; to
On Sat, 28 Apr 2007 18:10:59 +0100 John D Lamb <J.D.Lamb@btinternet.com> wrote: this->i_key, and that also resolved the issue. I appreciate your response on this. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Mon, 2007-04-30 at 09:07 -0400, Jerry Feldman wrote:
My instinct says we've found alternative solutions to the same problem. Mine avoids some problems with virtual function calls, but I suspect there is going to be some occasion when it won't work. Hi John, I just changed the code from FuBar<ItemType, type_t>::i_key; to this->i_key, and that also resolved the issue. I appreciate your response on this.
I think the this->i_key version is probably better if it's available, but, by chance, I found an example where it doesn't work in some code I wrote a couple of years ago: class NextTrail : private Next<boost::graph_traits<cycleCentre::Graph>::vertices_size_type>{ ... }; bool NextTrail::operator()( VertexTrail* trail ){ ... while( Next<boost::graph_traits<Graph>::vertices_size_type>::operator()() ){ ... } ... } I haven't worked out yet, why this doesn't work. Maybe its because of the private inheritance, but it does show that using this->operator()() isn't guaranteed to work. -- JDL --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
I think the this->i_key version is probably better if it's available, but, by chance, I found an example where it doesn't work in some code I wrote a couple of years ago:
class NextTrail : private Next<boost::graph_traits<cycleCentre::Graph>::vertices_size_type>{ ... };
bool NextTrail::operator()( VertexTrail* trail ){ ... while( Next<boost::graph_traits<Graph>::vertices_size_type>::operator()() ){ ... } ... }
I haven't worked out yet, why this doesn't work. Maybe its because of the private inheritance, but it does show that using this->operator()() isn't guaranteed to work. I tested the use of the this, and it worked fine, and I changed the code accordingly. But I have another related problem: template <fooo> class FuBar { ...
On Mon, 30 Apr 2007 21:47:19 +0100 John D Lamb <J.D.Lamb@btinternet.com> wrote: protected: FuBar(fooo *pf); ... }; template <fooo> class Bar: public Fubar<fooo> ... class BarFoo } Bar::Barfoo::Barfoo(fooo *pf) ... FuBar(fooo *pf); At this point, it does not allow me to use the FuBar constructor. The solution was that I simply declared the FuBar(fooo *pf); constructor as a public member, which worked. Both Bar and BarFoo inherit FuBar, and should be able to call a protected constructor. My exact syntax might be a bit off. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
participants (2)
-
Jerry Feldman -
John D Lamb