Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #10445 > unrolled thread

Cannot access protected from base class?

Back to article view | Back to comp.lang.c++

Contents

  Cannot access protected from base class? Nephi Immortal <immortalnephi@gmail.com> - 2011-09-24 14:03 -0700
    Re: Cannot access protected from base class? Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-24 20:14 -0400
      Re: Cannot access protected from base class? Nephi Immortal <immortalnephi@gmail.com> - 2011-09-24 17:24 -0700
        Re: Cannot access protected from base class? Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-24 23:56 -0400
          Re: Cannot access protected from base class? Nephi Immortal <immortalnephi@gmail.com> - 2011-09-25 16:18 -0700
            Re: Cannot access protected from base class? Ian Collins <ian-news@hotmail.com> - 2011-09-26 15:05 +1300
            Re: Cannot access protected from base class? Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-25 22:38 -0400
              Re: Cannot access protected from base class? Nephi Immortal <immortalnephi@gmail.com> - 2011-09-25 20:42 -0700
                Re: Cannot access protected from base class? Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-26 00:20 -0400

#10445 — Cannot access protected from base class?

	I discussed functionoids and pointer to member functions a long time
ago.  The template is the best option over functionoids because of the
performance issue.  Unfortunately, template does not support pointer
to member function array.
	I am surprised to see that C++ Compiler reports an error to say any
member function cannot access to protected from base class, but
ordinary function worked.  Very absurb?


class Obj1
{
protected:
	static void Run1()
	{
	}

	void errRun1()
	{
	}
};

class Obj2
{
protected:
	static void Run2()
	{
	}

	void errRun2()
	{
	}
};

class Obj3
{
protected:
	static void Run3()
	{
	}

	void errRun3()
	{
	}
};

class Obj :
	public Obj1,
	public Obj2,
	public Obj3
{
public:
	void Run( int index )
	{
		static void ( * const pRun[ 3 ] )() =
		{
			Run1,
			Run2,
			Run3
		};

		pRun[ index ]();
	}

	void errRun( int index )
	{
		static void ( Obj::* const pRun[ 3 ] )() =
		{
			&Obj1::errRun1,
			&Obj2::errRun2,
			&Obj3::errRun3
		};

		( this->*pRun[ index ] )();
	}
};


int main()
{
	Obj obj;

	obj.Run( 0 );
	obj.Run( 1 );
	obj.Run( 2 );

	obj.errRun( 0 );
	obj.errRun( 1 );
	obj.errRun( 2 );

	return 0;
}

Debug Win32 ------
  Main.cpp
c:\my projects\main.cpp(315): error C2248: 'Obj1::errRun1' : cannot
access protected member declared in class 'Obj1'
          c:\my projects\main.cpp(264) : see declaration of
'Obj1::errRun1'
          c:\my projects\main.cpp(258) : see declaration of 'Obj1'
c:\my projects\main.cpp(316): error C2248: 'Obj2::errRun2' : cannot
access protected member declared in class 'Obj2'
          c:\my projects\main.cpp(276) : see declaration of
'Obj2::errRun2'
          c:\my projects\main.cpp(270) : see declaration of 'Obj2'
c:\my projects\main.cpp(318): error C2248: 'Obj3::errRun3' : cannot
access protected member declared in class 'Obj3'
          c:\my projects\main.cpp(288) : see declaration of
'Obj3::errRun3'
          c:\my projects\main.cpp(282) : see declaration of 'Obj3'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
==========

	Can you please answer my question?  Can hundred of base classes or
thousands of base classes be inherited into ONE derived class through
multiple inheritance?  The option is the best if derived class has the
ability to create large pointer to member function array in order to
create command object.

[toc] | [next] | [standalone]

#10448

On 9/24/11 5:03 PM, Nephi Immortal wrote:
> 	I discussed functionoids and pointer to member functions a long time
> ago.  The template is the best option over functionoids because of the
> performance issue.  Unfortunately, template does not support pointer
> to member function array.
> 	I am surprised to see that C++ Compiler reports an error to say any
> member function cannot access to protected from base class, but
> ordinary function worked.  Very absurb?
>
>

A derived class can only access the protected parts of a base camp 
through the derived class, not directly from the base camp.

In your example, rather than using Obj1::run, use Obj::run. since Obj 
has inherited them, it can access them there.

I will also add that this structure seems awkward. While having a large 
number of base classes is allowed, it feels like inheritance is being 
forced in a place where it really doesn't fit.

[toc] | [prev] | [next] | [standalone]

#10449

On Sep 24, 7:14 pm, Richard Damon <news.x.richardda...@xoxy.net>
wrote:
> On 9/24/11 5:03 PM, Nephi Immortal wrote:
>
> >    I discussed functionoids and pointer to member functions a long time
> > ago.  The template is the best option over functionoids because of the
> > performance issue.  Unfortunately, template does not support pointer
> > to member function array.
> >    I am surprised to see that C++ Compiler reports an error to say any
> > member function cannot access to protected from base class, but
> > ordinary function worked.  Very absurb?
>
> A derived class can only access the protected parts of a base camp
> through the derived class, not directly from the base camp.
>
> In your example, rather than using Obj1::run, use Obj::run. since Obj
> has inherited them, it can access them there.
>
> I will also add that this structure seems awkward. While having a large
> number of base classes is allowed, it feels like inheritance is being
> forced in a place where it really doesn't fit.

I understand, but I wonder if large number of base classes violate
rule and needs to make sure if more memory is sufficient.

[toc] | [prev] | [next] | [standalone]

#10450

On 9/24/11 8:24 PM, Nephi Immortal wrote:
> On Sep 24, 7:14 pm, Richard Damon<news.x.richardda...@xoxy.net>
> wrote:
>> On 9/24/11 5:03 PM, Nephi Immortal wrote:
>>
>>>     I discussed functionoids and pointer to member functions a long time
>>> ago.  The template is the best option over functionoids because of the
>>> performance issue.  Unfortunately, template does not support pointer
>>> to member function array.
>>>     I am surprised to see that C++ Compiler reports an error to say any
>>> member function cannot access to protected from base class, but
>>> ordinary function worked.  Very absurb?
>>
>> A derived class can only access the protected parts of a base camp
>> through the derived class, not directly from the base camp.
>>
>> In your example, rather than using Obj1::run, use Obj::run. since Obj
>> has inherited them, it can access them there.
>>
>> I will also add that this structure seems awkward. While having a large
>> number of base classes is allowed, it feels like inheritance is being
>> forced in a place where it really doesn't fit.
>
> I understand, but I wonder if large number of base classes violate
> rule and needs to make sure if more memory is sufficient.

A large number of base classes do not violate an inherent rule in C++. 
You will likely end up with a large object, as it needs to store all the 
base class members within it. It is possible that this may cause you to 
run out of memory, it somewhat depends on how many copies of this object 
are created.

I do think it is a sign of a problematical design.

[toc] | [prev] | [next] | [standalone]

#10493

On Sep 24, 10:56 pm, Richard Damon <news.x.richardda...@xoxy.net>
wrote:
> On 9/24/11 8:24 PM, Nephi Immortal wrote:
>
>
>
>
>
> > On Sep 24, 7:14 pm, Richard Damon<news.x.richardda...@xoxy.net>
> > wrote:
> >> On 9/24/11 5:03 PM, Nephi Immortal wrote:
>
> >>>     I discussed functionoids and pointer to member functions a long time
> >>> ago.  The template is the best option over functionoids because of the
> >>> performance issue.  Unfortunately, template does not support pointer
> >>> to member function array.
> >>>     I am surprised to see that C++ Compiler reports an error to say any
> >>> member function cannot access to protected from base class, but
> >>> ordinary function worked.  Very absurb?
>
> >> A derived class can only access the protected parts of a base camp
> >> through the derived class, not directly from the base camp.
>
> >> In your example, rather than using Obj1::run, use Obj::run. since Obj
> >> has inherited them, it can access them there.
>
> >> I will also add that this structure seems awkward. While having a large
> >> number of base classes is allowed, it feels like inheritance is being
> >> forced in a place where it really doesn't fit.
>
> > I understand, but I wonder if large number of base classes violate
> > rule and needs to make sure if more memory is sufficient.
>
> A large number of base classes do not violate an inherent rule in C++.
> You will likely end up with a large object, as it needs to store all the
> base class members within it. It is possible that this may cause you to
> run out of memory, it somewhat depends on how many copies of this object
> are created.
>
> I do think it is a sign of a problematical design.- Hide quoted text -
>
> - Show quoted text -

	I am aware of design flaw, but careful design is better.  Large
number of base classes into one derived class is the option to replace
virtual functions because of the performance issue and template is not
the option unless you want pointer to member function array.
	All member functions in each base class should be static.  The
derived class will allocate approximately 4K to 32K memory if memory
contains derived class’ pointer and array of indirect pointers.
	You can always create many copies of derived objects, but static
member functions are shared by derived objects.  You create interface
class.  It includes one derived object definition in the class body.
	The client can select the number of objects before interface does the
job to process the derived object such as command object.

For example:

class Interface
{
public:
	void Run( int index )
	{
		cmdList.Execute( index );
	}

private:
	derivedObject cmdList;
};


	If you think that it is design flaw, please demonstrate another
option.

[toc] | [prev] | [next] | [standalone]

#10495

On 09/26/11 12:18 PM, Nephi Immortal wrote:
> On Sep 24, 10:56 pm, Richard Damon<news.x.richardda...@xoxy.net>
> wrote:
>> On 9/24/11 8:24 PM, Nephi Immortal wrote:
>>
>>> I understand, but I wonder if large number of base classes violate
>>> rule and needs to make sure if more memory is sufficient.
>>
>> A large number of base classes do not violate an inherent rule in C++.
>> You will likely end up with a large object, as it needs to store all the
>> base class members within it. It is possible that this may cause you to
>> run out of memory, it somewhat depends on how many copies of this object
>> are created.
>>
>> I do think it is a sign of a problematical design.- Hide quoted text -
>>
>> - Show quoted text -
>
> 	I am aware of design flaw, but careful design is better.  Large
> number of base classes into one derived class is the option to replace
> virtual functions because of the performance issue and template is not
> the option unless you want pointer to member function array.

What sort of a performance issue have you measured?

What makes templates unsuitable?  I don't understand the context of 
"unless you want pointer to member function array".

> 	If you think that it is design flaw, please demonstrate another
> option.

Exactly what problem are you trying to solve?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10496

On 9/25/11 7:18 PM, Nephi Immortal wrote:

> 	I am aware of design flaw, but careful design is better.  Large
> number of base classes into one derived class is the option to replace
> virtual functions because of the performance issue and template is not
> the option unless you want pointer to member function array.
> 	All member functions in each base class should be static.  The
> derived class will allocate approximately 4K to 32K memory if memory
> contains derived class’ pointer and array of indirect pointers.
> 	You can always create many copies of derived objects, but static
> member functions are shared by derived objects.  You create interface
> class.  It includes one derived object definition in the class body.
> 	The client can select the number of objects before interface does the
> job to process the derived object such as command object.
>
> For example:
>
> class Interface
> {
> public:
> 	void Run( int index )
> 	{
> 		cmdList.Execute( index );
> 	}
>
> private:
> 	derivedObject cmdList;
> };
>
>
> 	If you think that it is design flaw, please demonstrate another
> option.

I am not sure where you think you are going to gain in performance. Your 
dispatch function is apt to be as slow if not slower than a virtual 
function call, and your arrays of function pointers about as big 
combined as the virtual tables. If the base classes don't contain state, 
than composing them into this one super object doesn't by you anything, 
and if they do, your derived class is going to be very large since it 
has all of them.

[toc] | [prev] | [next] | [standalone]

#10498

On Sep 25, 9:38 pm, Richard Damon <news.x.richardda...@xoxy.net>
wrote:
> On 9/25/11 7:18 PM, Nephi Immortal wrote:
>
>
>
>
>
> >    I am aware of design flaw, but careful design is better.  Large
> > number of base classes into one derived class is the option to replace
> > virtual functions because of the performance issue and template is not
> > the option unless you want pointer to member function array.
> >    All member functions in each base class should be static.  The
> > derived class will allocate approximately 4K to 32K memory if memory
> > contains derived class pointer and array of indirect pointers.
> >    You can always create many copies of derived objects, but static
> > member functions are shared by derived objects.  You create interface
> > class.  It includes one derived object definition in the class body.
> >    The client can select the number of objects before interface does the
> > job to process the derived object such as command object.
>
> > For example:
>
> > class Interface
> > {
> > public:
> >    void Run( int index )
> >    {
> >            cmdList.Execute( index );
> >    }
>
> > private:
> >    derivedObject cmdList;
> > };
>
> >    If you think that it is design flaw, please demonstrate another
> > option.
>
> I am not sure where you think you are going to gain in performance. Your
> dispatch function is apt to be as slow if not slower than a virtual
> function call, and your arrays of function pointers about as big
> combined as the virtual tables. If the base classes don't contain state,
> than composing them into this one super object doesn't by you anything,
> and if they do, your derived class is going to be very large since it
> has all of them.- Hide quoted text -
>
> - Show quoted text -

	If you look at pointer to member function in C++ FAQ Lite, you will
understand that it talks about functionoids.  It does say that if
performance is an issue, go ahead and use template instead of virtual
function.
	I clarify to say why I can’t use template because template does not
support pointer to member function array, but only one pointer to
member function is supported.

For example:

template< typename Obj, typename Fn >
void Run( Obj *pObj, Fn pFn )
{
	( pObj->*pFn )();
}

	If you use this function above, where is pointer to member function
array?  If it exists, you can only select one member function and put
it into Run’s parameter list.
	You saw my previous code above.  It has static pointer to member
function array in derived class’ Run( int index ).

[toc] | [prev] | [next] | [standalone]

#10499

On 9/25/11 11:42 PM, Nephi Immortal wrote:
> On Sep 25, 9:38 pm, Richard Damon<news.x.richardda...@xoxy.net>
> wrote:
>> On 9/25/11 7:18 PM, Nephi Immortal wrote:
>>
>>
>>
>>
>>
>>>     I am aware of design flaw, but careful design is better.  Large
>>> number of base classes into one derived class is the option to replace
>>> virtual functions because of the performance issue and template is not
>>> the option unless you want pointer to member function array.
>>>     All member functions in each base class should be static.  The
>>> derived class will allocate approximately 4K to 32K memory if memory
>>> contains derived class pointer and array of indirect pointers.
>>>     You can always create many copies of derived objects, but static
>>> member functions are shared by derived objects.  You create interface
>>> class.  It includes one derived object definition in the class body.
>>>     The client can select the number of objects before interface does the
>>> job to process the derived object such as command object.
>>
>>> For example:
>>
>>> class Interface
>>> {
>>> public:
>>>     void Run( int index )
>>>     {
>>>             cmdList.Execute( index );
>>>     }
>>
>>> private:
>>>     derivedObject cmdList;
>>> };
>>
>>>     If you think that it is design flaw, please demonstrate another
>>> option.
>>
>> I am not sure where you think you are going to gain in performance. Your
>> dispatch function is apt to be as slow if not slower than a virtual
>> function call, and your arrays of function pointers about as big
>> combined as the virtual tables. If the base classes don't contain state,
>> than composing them into this one super object doesn't by you anything,
>> and if they do, your derived class is going to be very large since it
>> has all of them.- Hide quoted text -
>>
>> - Show quoted text -
>
> 	If you look at pointer to member function in C++ FAQ Lite, you will
> understand that it talks about functionoids.  It does say that if
> performance is an issue, go ahead and use template instead of virtual
> function.
> 	I clarify to say why I can’t use template because template does not
> support pointer to member function array, but only one pointer to
> member function is supported.
>
> For example:
>
> template<  typename Obj, typename Fn>
> void Run( Obj *pObj, Fn pFn )
> {
> 	( pObj->*pFn )();
> }
>
> 	If you use this function above, where is pointer to member function
> array?  If it exists, you can only select one member function and put
> it into Run’s parameter list.
> 	You saw my previous code above.  It has static pointer to member
> function array in derived class’ Run( int index ).


The issue is that the gain you might get for using the template, you 
have lost by having to do the array lookup. I will also point out that 
you don't need the template at all in your design, all your functions 
can have the same type (pointer to member function of type derived), and 
all can take the same type of object, derived.

I think you are also being confused on what the FAQ says, the 
improvement that the functionoid can gain over the function call is when 
the compiler can see at compile time the type info and thus expand the 
template inline, and thus remove the function call. If you know which 
function to call, calling it directly will of course be slightly faster 
than going through the dispatch table, but your program structure is 
explicitly denying this operation by making them protected. Unless there 
is something more to be done in the dispatch routine, there is no reason 
they need to be protected.

I think that you need to step back from the design and rather than 
figure out which toys sound interesting to use, ask yourself what REALLY 
needs to be done (not HOW, but WHAT), and then look at the simplest way 
to achieve that.

 From what I have seen so far, all the objects being created so far are 
extraneous since they are holding no information, only disjoint pieces 
of code. If they do need to store state, does one client really need ALL 
of them present?

You also talk about gaining performance, have you actually implemented 
the straight forward method and found that the calling overhead is a 
significant factor?  The way you talk about the runctions "running 
commands" makes it sound like they do real work, which probably 
overshadows and slight inefficiencies in the calling.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web