"is protected within this context" error

[H. S.]

I am getting this error if I try to compile the file demarcated below.
What I am missing here? I am using g++ (GCC) 3.3.5 (Debian 1:3.3.5-8).

{tp2}> g++ -ansi -g -Wall tp2.cc -o tp2
tp2.cc: In member function `void Other::DoSomething()':
tp2.cc:11: error: `int Base::iX' is protected
tp2.cc:29: error: within this context
// %< %< ----------------------------------- %< %<
#include <cstdio>
#include <iostream>

class Base{
public:
Base();

protected:
int iX;
};

Base::Base():iX(7){}

class Derived:public Base{};

class Other{
public:
Derived* D;
void DoSomething();
};

void Other::DoSomething(){
std::cout << D->iX;
}

int main(){}

// %< %< ----------------------------------- %< %<
Thanks,
->HS

--
Please remove the underscores ( the '_' symbols) from my email address
to obtain the correct one. Apologies, but the fudging is to remove spam.

[Victor Bazarov]

"H. S." <g_**************@yahoo.com> wrote...

I am getting this error if I try to compile the file demarcated below.
What I am missing here? I am using g++ (GCC) 3.3.5 (Debian 1:3.3.5-8).

{tp2}> g++ -ansi -g -Wall tp2.cc -o tp2
tp2.cc: In member function `void Other::DoSomething()':
tp2.cc:11: error: `int Base::iX' is protected
tp2.cc:29: error: within this context
// %< %< ----------------------------------- %< %<
#include <cstdio>
#include <iostream>

class Base{
public:
Base();

protected:
int iX;
};

Base::Base():iX(7){}

class Derived:public Base{};

class Other{
public:
Derived* D;
void DoSomething();
};

void Other::DoSomething(){
std::cout << D->iX;
iX is not a public member of 'Derived', you cannot expect it to be
accessible in an unrelated function. Only public members of Derived
are allowed to be used (accessed) in non-members (or somebody else's
members).
}

int main(){}

// %< %< ----------------------------------- %< %<

V

[H. S.]

Apparently, _Victor Bazarov_, on 23/03/05 23:35,typed:

"H. S." <g_**************@yahoo.com> wrote...

I am getting this error if I try to compile the file demarcated below.
What I am missing here? I am using g++ (GCC) 3.3.5 (Debian 1:3.3.5-8).

{tp2}> g++ -ansi -g -Wall tp2.cc -o tp2
tp2.cc: In member function `void Other::DoSomething()':
tp2.cc:11: error: `int Base::iX' is protected
tp2.cc:29: error: within this context
// %< %< ----------------------------------- %< %<
#include <cstdio>
#include <iostream>

class Base{
public:
Base();

protected:
int iX;
};

Base::Base():iX(7){}

class Derived:public Base{};

class Other{
public:
Derived* D;
void DoSomething();
};

void Other::DoSomething(){
std::cout << D->iX;

iX is not a public member of 'Derived', you cannot expect it to be
accessible in an unrelated function. Only public members of Derived
are allowed to be used (accessed) in non-members (or somebody else's
members).

I am actually trying to compile a set of numerical libraries (ARPACK++
to be precise). The library was written, IIRC, in or around 1997 in C++.
I have already removed quite a few compiler errors. But I am still
getting an error similar to the above. I went through the library's code
and gave the minimal example in my original post which reproduced the
compiler error.

So, presumably the method was allowed/valid when the library was
written. And obviously it has changed. Just for knowledge's sake, when
and why did that happen?

But more important, what change would you suggest I make to the library
to remove that error. I do not want to mess more than necessary with the
library's code.

Thanks a ton,
->HS
--
Please remove the underscores ( the '_' symbols) from my email address
to obtain the correct one. Apologies, but the fudging is to remove spam.

[Victor Bazarov]

H. S. wrote:

[...]
So, presumably the method was allowed/valid when the library was
written.
There is no proof of that, of course. Besides, AFA my knowledge of C++
and its evolution goes, accessing protected members has *never* been
allowed from an unrelated function.
And obviously it has changed. Just for knowledge's sake, when
and why did that happen?
When? Probably when you changed something in the code. Why? How should
anybody know but you? Seriously, do you know what "protected" means and
what it is for? Then you should be able to conclude the same things as I
did.
But more important, what change would you suggest I make to the library
to remove that error. I do not want to mess more than necessary with the
library's code.

Without seeing (and trying to compile) the original (1997) code, there is
no way to say what's needed. FWIW it could be that the class from which
you're trying to access the protected member *used to be* in the hierarchy
and somehow got out. It *could* be that the member you're trying to get
to *used to be* public but now it's protected. Which one it is, what to
do about it, is impossible for us to conclude without seeing the real code
in its entirety and its original form (which supposedly compiled).

I assure you the language did not change *so* drastically in the past ten
years that some ten year old code would suddenly not compile due to *that*
obvious of an error.

Good luck and post again soon.

V

[H. S.]

Apparently, _Victor Bazarov_, on 24/03/05 09:44,typed:

H. S. wrote:

[...]
So, presumably the method was allowed/valid when the library was written.

There is no proof of that, of course. Besides, AFA my knowledge of C++
and its evolution goes, accessing protected members has *never* been
allowed from an unrelated function.

> And obviously it has changed. Just for knowledge's sake, when

and why did that happen?

When? Probably when you changed something in the code. Why? How should
anybody know but you? Seriously, do you know what "protected" means and
what it is for? Then you should be able to conclude the same things as I
did.

I am no C++ guru, but otherwise yes, I do know what protected means and
how to use it. And I did see the problem once I saw the compiler error
and looked at the library's source code. But again, it is not my source
code, I am only trying to compile it and have had to modiy it a bit.

But more important, what change would you suggest I make to the
library to remove that error. I do not want to mess more than
necessary with the library's code.

Without seeing (and trying to compile) the original (1997) code, there is
no way to say what's needed. FWIW it could be that the class from which

Well, for completeness' sake (and for any brave soul who might wanna try
this out), the original source code can be found here:
http://www.caam.rice.edu/software/ARPACK/arpack++.html

The problem is at line 274 of include/arlnspen.h:
if ((A->n != B->n)||(A->m != B->m)) {

Here, the class contains A and B, pointers to another derived class, and
is trying to access the "n" and "m" members of the base class of the
drived class.

The code to see this is fairly simple:
class ARluNonSymPencil contains ARluNonSymMatrix<TYPE>* A and
ARluNonSymMatrix<TYPE>* B. And class ARluNonSymMatrix (defined in
arlnsmat.h) is derived from ARMatrix<TYPE> (defined in armat.h) which
has "m" and "n" as ints and are protected.

Note: You also need SuperLU package to compile ARPACK++. Found here:
http://crd.lbl.gov/~xiaoye/SuperLU/
you're trying to access the protected member *used to be* in the hierarchy
and somehow got out. It *could* be that the member you're trying to get
to *used to be* public but now it's protected. Which one it is, what t
do about it, is impossible for us to conclude without seeing the real code
in its entirety and its original form (which supposedly compiled).
See above. I am quite sure it originally compiled. The numerical library
seems to be quite popular.

I assure you the language did not change *so* drastically in the past ten
years that some ten year old code would suddenly not compile due to *that*
obvious of an error.
It would be nice if this indeed is the case. It would make my work a lot
easier. I could then get back to my real research work instead of trying
to compile this library.

Good luck and post again soon.

Thanks,
->HS

--
Please remove the underscores ( the '_' symbols) from my email address
to obtain the correct one. Apologies, but the fudging is to remove spam.

[Karl Heinz Buchegger]

"H. S." wrote:

Well, for completeness' sake (and for any brave soul who might wanna try
this out), the original source code can be found here:
http://www.caam.rice.edu/software/ARPACK/arpack++.html

There is also an email address of the original author.
Contact him and tell him about the problem.

--
Karl Heinz Buchegger
kb******@gascad.at

[H. S.]

Apparently, _Karl Heinz Buchegger_, on 24/03/05 10:54,typed:

"H. S." wrote:

Well, for completeness' sake (and for any brave soul who might wanna try
this out), the original source code can be found here:
http://www.caam.rice.edu/software/ARPACK/arpack++.html

There is also an email address of the original author.
Contact him and tell him about the problem.

I already did. It has been a couple of days and I am still waiting for
his response.

->HS

--
Please remove the underscores ( the '_' symbols) from my email address
to obtain the correct one. Apologies, but the fudging is to remove spam.

[Victor Bazarov]

H. S. wrote:

Apparently, _Victor Bazarov_, on 24/03/05 09:44,typed:

[...]
Without seeing (and trying to compile) the original (1997) code, there is
no way to say what's needed. FWIW it could be that the class from which

Well, for completeness' sake (and for any brave soul who might wanna try
this out), the original source code can be found here:
http://www.caam.rice.edu/software/ARPACK/arpack++.html

The problem is at line 274 of include/arlnspen.h:
if ((A->n != B->n)||(A->m != B->m)) {

To pick a nit, there is no such statement on the line 274 of
'include/srlnspen.h' in the package I just downloaded. It's on
line 674. :-)
[...]

The cause of the trouble is potentially the way 'friend' declaration
is processed. ARluNonSymMatrix declares some specialisation of the
template ARluNonSymPencil as friends. That _should_ give some of the
xxxPencil member functions (but only the ones specialised the same
way) permission to access any members of xxxMatrix. You have to make
sure that you use the proper specialisation. Only <df,df> and are
declared friends, along with <arcomplex<df>, df> where df is either
double or float. Could it be you're specialising your xxxPencil with
something other than double or float?

V

[H. S.]

Apparently, _Victor Bazarov_, on 24/03/05 12:07,typed:

H. S. wrote:

<SNIP>

The problem is at line 274 of include/arlnspen.h:
if ((A->n != B->n)||(A->m != B->m)) {

To pick a nit, there is no such statement on the line 274 of
'include/srlnspen.h' in the package I just downloaded. It's on
line 674. :-)

Yes, it is 674. Sorry about that typo.

[...]

The cause of the trouble is potentially the way 'friend' declaration
is processed. ARluNonSymMatrix declares some specialisation of the
template ARluNonSymPencil as friends. That _should_ give some of the
xxxPencil member functions (but only the ones specialised the same
way) permission to access any members of xxxMatrix. You have to make
sure that you use the proper specialisation. Only <df,df> and are
declared friends, along with <arcomplex<df>, df> where df is either
double or float. Could it be you're specialising your xxxPencil with
something other than double or float?

V

Let me have a more careful look at this before I report further. Thanks
for this explanation.
->HS

--
Please remove the underscores ( the '_' symbols) from my email address
to obtain the correct one. Apologies, but the fudging is to remove spam.