call const function from non const function

[Fabian Wein]

Hi,

is there a way to call a const function from non const function?

I have a non-const

List GetList();

and want my

bool Count() const;

implemented as

bool Foo::Count(...) const
{
return GetList().GetSi ze();
}

Is there any not to dirty cast trick?

Thanks, Fabian

[Muk]

Is GetList() a member function of class Foo? The const keyword on
Count() is telling the compiler that Count() will not modify Foo. If
GetList() is a member of Foo and does modify Foo you could use a
const_cast to solve your problem. See a similar example here --->
http://msdn2.microsoft.com/en-us/lib...5h(VS.80).aspx

On Jul 25, 12:47 pm, Fabian Wein <[e-mail]>
wrote:

Hi,

is there a way to call a const function from non const function?

I have a non-const

List GetList();

and want my

bool Count() const;

implemented as

bool Foo::Count(...) const
{
return GetList().GetSi ze();

}

Is there any not to dirty cast trick?

Thanks, Fabian

[Neelesh Bodas]

On Jul 25, 9:47 pm, Fabian Wein <[e-mail]>
wrote:

Hi,

is there a way to call a const function from non const function?

A const function can always be called from a non-const function.

You probably meant the reverse way: "calling a non-const function from
a const function".

I have a non-const

List GetList();

and want my

bool Count() const;

implemented as

bool Foo::Count(...) const
{
return GetList().GetSi ze();

If your GetList() is changing the logical constness of the object,
then your Count function, which relies on GetList, should, at the
first place, be non-const.

Alternatively, if the Count function, as the name indicates, is
supposed to return just a count (or do anything that doesnot alter
logical constness of the object) then you should probably provide a
way to do this through helper functions that donot alter the logical
constness.

In other words, if you are trying to define a const function in terms
of a non-const function, you probably need to modify the design.

-N

[Fabian Wein]

Alf P. Steinbach wrote:

Provide an additional const version of GetList.

But then I need another return type as the GetList() returns a list of
non-const pointers.

There is a trick for doing that via templates, but it's generally not
used because it doesn't pay enough. Also, there have been suggestions
for additional syntax to handle that code duplication. All such
suggestions have resulted in exactly nothing: there's no real demand.

To be honest I also rarely have such a problem.

Regards, Fabian

[Fabian Wein]

Hi,

Is GetList() a member function of class Foo? The const keyword on
Count() is telling the compiler that Count() will not modify Foo. If
GetList() is a member of Foo and does modify Foo you could use a
const_cast to solve your problem. See a similar example here --->
http://msdn2.microsoft.com/en-us/lib...5h(VS.80).aspx

Yest, it is Vector<Pointer* Foo::GetList().

GetList() cannot be const as one could modify the object via
the returned pointers.

But my Count()

bool Foo::Count(...) const
{
return GetList().GetSi ze();
}

would make sure that the object is not altered.

I don't see how I could use cost_cast here.

Fabian

[Fabian Wein]

Hi,

A const function can always be called from a non-const function.

You probably meant the reverse way: "calling a non-const function from
a const function".

Sorry - your are perfeclty right.

>

>I have a non-const

List GetList();

and want my

bool Count() const;

implemented as

bool Foo::Count(...) const
{
return GetList().GetSi ze();

If your GetList() is changing the logical constness of the object,
then your Count function, which relies on GetList, should, at the
first place, be non-const.

GetList() returns pointers to content of the object. Hence one
could alter the object via the return value and such the GetList()
cannot be const. My Count() implementation would assure that
the object is not altered.

Alternatively, if the Count function, as the name indicates, is
supposed to return just a count (or do anything that doesnot alter
logical constness of the object) then you should probably provide a
way to do this through helper functions that donot alter the logical
constness.

In other words, if you are trying to define a const function in terms
of a non-const function, you probably need to modify the design.

I find my intendet design good:

Vector<Pointers *Foo::GetList()
cannot be const due to the result alowing modification.

int Foo::Count() const
{ return GetList().GetSi ze(); }

or bool Foo::Has() const
{ return GetList().GetSi ze() 0; }

would not involve copy & paste code.

I ommited the parameters of the methods.

Regards, Fabian

[terminator]

On Jul 26, 10:19 am, Fabian Wein <[e-mail]>
wrote:

Hi,

Is GetList() a member function of class Foo? The const keyword on
Count() is telling the compiler that Count() will not modify Foo. If
GetList() is a member of Foo and does modify Foo you could use a
const_cast to solve your problem. See a similar example here --->
http://msdn2.microsoft.com/en-us/lib...5h(VS.80).aspx

Yest, it is Vector<Pointer* Foo::GetList().

GetList() cannot be const as one could modify the object via
the returned pointers.

you had better provide a 'const' version for 'GetList()' but I you
will face the trouble of calling a none-const function inside a
'const' one,but this is just like calling a function taking a none-
const object on a const one.In your code the const object is of the
type that owns the member function:

Vector<Pointer* Foo::GetList();
const Vector<Pointer* Foo::GetList()c onst{
return const_cast<Foo* >(this)->GetList();
};

but this is really bad manors since the vector - which may be a very
large one - is copied which has both overheads: memory and runtime.

>
But my Count()

bool Foo::Count(...) const
{
return GetList().GetSi ze();

}

would make sure that the object is not altered.

I don't see how I could use cost_cast here.

you need operate on 'this' since 'bool Foo::Count() const' just
means:'const Foo* this'.
const_cast<Foo* >(this)->GetList().GetS ize();//cast 'this' from 'const
Foo*' to 'Foo*'

but you had better try to avoid such casts.

regards,
FM