usefulness of const_cast

248 просмотров
Перейти к первому непрочитанному сообщению

Lakshman KNVSM

не прочитано,
3 июн. 1999 г., 03:00:0003.06.1999
Hi,
could someone explain the "usefulness" of <const_cast>?

Just to initiate discussion, I am taking an example.

Is this function valid :

f(const char* str)
{
char* bad = const_cast<char*>(str);
bad[2] = '\0';
}

Assume str is a pointer to a string that is at least 3 characters long.

Now, if the function is legal C++ :

1. Is this function prototype not deceptive ie. a user of this function
assumes that his string will not be modified (from the prototype), but
the function is modifying it.

2. Another issue is that this <const_cast> is not guaranteed to work if
the declared type of actual argument is "const char*" and not "char*".


Hence, this cast must not be used at all on parameters, right? Taking
this into account, how "useful" is this cast? Do we use it on local
variables?
But then, if one knows that the value of a variable is going to be
changed, one will not and should not declare the variable const at all.

thanks in advance,
Lakshman.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

Philip Gibbs

не прочитано,
3 июн. 1999 г., 03:00:0003.06.1999
In article <7j526q$6f1$1...@nnrp1.deja.com>, Lakshman KNVSM
<knv...@yahoo.com> writes

> could someone explain the "usefulness" of <const_cast>?
>
>Just to initiate discussion, I am taking an example.
>
>Is this function valid :
>
>f(const char* str)
>{
> char* bad = const_cast<char*>(str);
> bad[2] = '\0';
>}
>

This is well-formed code but it is a very dangerous way to use
const_cast for the reasons you gave.

One situation where you might find yourself safely using const_cast
is if you are using a library of functions or classes where const
correctness has not been used as it should.

For example, you may want to use the following function:

int size( char* x );

and you may have a const string

const char* x = "cast ye...";

and you want to make the call:

int s = size(x);

You know that this function does not modify x but
the compiler objects. You have several options
including:

-- remove the const modifier from the type of x,
but this will take const correctness out of your
code and may lead to a cascade of other problems.

-- rewrite the library with the function size in it,
but this may be difficult or even impossible for
whatever reasons

-- use a const_cast as follows

int s = size(const_cast<char*>(x))

Now all is well so long as the function size really
does not modify the string. The const_cast is
intended to be ugly and easy to find so that anyone
looking at the code knows that a design fault in the
library has forced such a drastic action.

Francis Glassborow

не прочитано,
3 июн. 1999 г., 03:00:0003.06.1999
In article <7j526q$6f1$1...@nnrp1.deja.com>, Lakshman KNVSM
<knv...@yahoo.com> writes
>Hi,

> could someone explain the "usefulness" of <const_cast>?

The classic example is when implementing something such as strtok. You
want it to return a char const * when the second parameter is a char
const * but a plain char * when the second parameter is a char *

The solution is to write an implementation of:

char const * strtok (char *, char const *);

and then provide the overload with a forwarding function:

char * strtok(char * s1, char * s2){
return const_cast<char *> strtok(s1, const_cast<char const *> s2);
}

It is also useful when adding cv qualification to an argument to force
the selection of a required overload (as in the body in the above
example).

>

Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

Darin Adler

не прочитано,
3 июн. 1999 г., 03:00:0003.06.1999
I looked through my programs and found that all my uses of const_cast where
when I was calling routines in libraries that I didn't write. Here's a
detailed example, simplified for pedagogical purposes.

Let's say there's a library that includes these two function declarations.

void ReadData(void*, unsigned long);
void WriteData(void*, unsigned long);

The people who wrote the library should have declared the WriteData
parameter to be const void*, since it doesn't modify the data passed in, but
they didn't. Now here's a piece of a client program.

void WriteText(const char* text)
{
WriteData(text, std::strlen(text));
}

Unfortunately, this won't compile because const char* can't be converted
into void*. To use the library routine, I need to remove the const. I'll
need to use a cast. I'd like to be sure that I'm not accidentally making any
other change to the type and I'd like to avoid any use of the old-style
casts. So I write it like this.

void WriteText(const char* text)
{
WriteData(const_cast<char*>(text), std::strlen(text));
}

Like other casts, I try to use const_cast as few times as possible but no
fewer. One way to reduce the number of casts is to fix the problem by adding
my own overload for WriteData like this,

inline void WriteData(const void* data, unsigned long length)
{
WriteData(const_cast<void*>(data), length);
}

The nice thing about this is that I now need only include the header file
with my overloaded WriteData and I don't have to use const_cast in any of
the client code.

-- Darin

Steve Clamage

не прочитано,
3 июн. 1999 г., 03:00:0003.06.1999
Lakshman KNVSM <knv...@yahoo.com> writes:

> could someone explain the "usefulness" of <const_cast>?

"Const" doesn't mean "can't change". It means "clients aren't
allowed to change it."

You might declare an object const because you don't want
anyone to modify it. But since you own the object, you might
also want to reserve the right to make changes by casting away
const.

The introduction of mutable class members reduced the need
for casting away const, however.

--
Steve Clamage, stephen...@sun.com

Dave Harris

не прочитано,
3 июн. 1999 г., 03:00:0003.06.1999
knv...@yahoo.com (Lakshman KNVSM) wrote:
> could someone explain the "usefulness" of <const_cast>?

For example:
const char *strchr( const char *str, char ch );
char *strchr( char *str, char ch );

const char *strchr( const char *str, char ch ) {
for ( ; *str != 0; ++str)
if (*str == ch)
return str;
return 0;
}

inline char *strchr( char *str, char ch ) {
return const_cast<char *>(
strchr( const_cast<const char *>( str ), ch ) );
}

The result of strchr() points to the first occurrence of ch in str, or 0
if there is no occurrence. We want the type of the result to be the same
as the type of the argument, so we need (at least) 2 versions. Rather than
replicate the code, it is convenient to define one in terms of the other
using casts.

OK. We actually have 2 casts there. The first, to const, is always safe.
We need it to avoid an infinite recurse. We need the second to get the
result back how we want it. It is safe because we know its argument was
non-const before we started, and the round trip is always safe.

Actually the VC++ 6.0 documentation gives the signature as:
char *strchr( const char *str, char ch );

so my version may be a non-standard form. If so, the standard version is
not type-safe.

Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."

Robert J. Peters

не прочитано,
3 июн. 1999 г., 03:00:0003.06.1999
Lakshman KNVSM <knv...@yahoo.com> writes:

>
> Hi,


> could someone explain the "usefulness" of <const_cast>?

[snip]

I find I most often used const_cast's when I must call a
non-const-correct function from a third-party C library. Inspection of
the source for such a library function verifies that indeed the
function does not modify its argument. The most typical situation is
with string literals, where I have in my own code either

const char* const aCString = "cstring";

or

const string aCppString = "cppstring";

and I want to call a library function

void useString(char* theString);

that is known not to modify its argument. Then I have to call this
function with either

useString(const_cast<char *>(aCString));

or

useString(const_cast<char *>(aCppString.c_str()));

The alternative is to use a dynamically allocated c-style string
rather than a static or automatic c-string or c++-string. This avoids
the cast, but has the disadvantage that the const-ness that is
logically part of the design of my program is not reflected in the
source. I prefer to use the cast to reflect the fact that it is the
library, and not my design, that is incorrect. Of course, there is
always the possibility that the library function will change in a
future revision so that it does modify its argument. This requires
some diligence in re-checking the source (if it's available) of new
revisions, and maybe in pestering the library provider to make its
code const-correct.

****************************************************************
Robert J. Peters Computation and Neural Systems
rjpe...@klab.caltech.edu Caltech
(626) 395-2882 Mail Code 139-74
Pasadena, CA 91106

Dietmar Kuehl

не прочитано,
4 июн. 1999 г., 03:00:0004.06.1999
Hi,
Lakshman KNVSM (knv...@yahoo.com) wrote:
: could someone explain the "usefulness" of <const_cast>?

There is few need for const_cast in code which is designed with
const correctness in mind (actually, I can't think of any example
at all). However, there are two important reasons why const_cast
would be used in real world code:

- The code interface functions in a language which is not const
aware at all and thus the functions take non-const pointer
arguments.
- Parts of the application are not const correct. This is,
unfortunately, very common for various reasons (eg. the interfaces
where designed a long time ago when there was no const correctness
issues at all or the "designers" didn't care about const
correctness).

: Is this function valid :

It depends...

: f(const char* str)


: {
: char* bad = const_cast<char*>(str);
: bad[2] = '\0';

: }

If 'str' points to an object which is actually modifyable, it OK. If
'str' points to eg. to a string literal, it is false. However, you
should never use 'const_cast' in this fashion! The only reasonable
argument I can currently think of is interfacing functions which are
not constness aware.

: Hence, this cast must not be used at all on parameters, right?

Sometimes you *know* that a function taking a pointer or reference to
a non-const object will not change the object. For example, in early
days of const-correctness (where 'const_cast' was not yet implemented
by any compiler, potentially not even invented), this was the case for
'strlen()': This function does not modify its argument (and is thus
now correspondingly declared) but there was some time where the
argument was still declared as non-const pointer. In cases like this,
a 'const_cast' is acceptable.
--
<mailto:dietma...@claas-solutions.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic

John Potter

не прочитано,
4 июн. 1999 г., 03:00:0004.06.1999
Francis Glassborow <fra...@robinton.demon.co.uk> wrote:

: char * strtok(char * s1, char * s2){


: return const_cast<char *> strtok(s1, const_cast<char const *> s2);
: }

: It is also useful when adding cv qualification to an argument to force
: the selection of a required overload (as in the body in the above
: example).

No. strtok(s1, static_cast<char const*> s2);

Const_cast is for removing const not for adding it which may be
done with static_cast. Adding const is a standard conversion
which should (IMO) be done with static_cast. A const_cast should
trigger a panic button because something strange is being done.

John

Ron Natalie

не прочитано,
4 июн. 1999 г., 03:00:0004.06.1999
Steve Clamage wrote:

>
> Lakshman KNVSM <knv...@yahoo.com> writes:
>
> > could someone explain the "usefulness" of <const_cast>?
>
> "Const" doesn't mean "can't change". It means "clients aren't
> allowed to change it."
>
> You might declare an object const because you don't want
> anyone to modify it. But since you own the object, you might
> also want to reserve the right to make changes by casting away
> const.

Umm.. isn't this undefined behavior? Declaring something as
const and then casting away the const and changing it is
undefined. What you can do is getting back to an object
that was originally declared non-const even though you got
to it through a const intermediate.

John Potter

не прочитано,
4 июн. 1999 г., 03:00:0004.06.1999
Lakshman KNVSM <knv...@yahoo.com> wrote:

: Hi,
: could someone explain the "usefulness" of <const_cast>?

: Just to initiate discussion, I am taking an example.

: Is this function valid :

: f(const char* str)


: {
: char* bad = const_cast<char*>(str);
: bad[2] = '\0';
: }

: Assume str is a pointer to a string that is at least 3 characters long.

: Now, if the function is legal C++ :

It is legal, and all of your objections are valid. Here is a good
use of const_cast because it is safe.

class Container {
Element& find (Element const& target) {
// some complicted search that does not modify anything
return result;
}
Element const& find (Element const& target) const {
return const_cast<Container*>(this)->find(target);
}
};

Like most features of the language, it can be abused but has some
valid uses.

John

Siemel Naran

не прочитано,
8 июн. 1999 г., 03:00:0008.06.1999
On 3 Jun 1999 13:15:52 -0400, Lakshman KNVSM <knv...@yahoo.com> wrote:

> could someone explain the "usefulness" of <const_cast>?

Suppose you want to concatenate "world" to the minimum of two strings.
string a="Hello"; string b="hello";
std::min(a,b)+="world";

Alas, std::min takes two const T& and returns a const T&.
template <class T> inline
const T& min(const T& lhs, const T& rhs) { return lhs<rhs?lhs:rhs; }

So we must write
string a="Hello"; string b="hello";
const_cast<string&>(std::min(a,b))+="world";

--
----------------------------------
Siemel B. Naran (sbn...@uiuc.edu)
----------------------------------

Douglas Kvidera

не прочитано,
10 июн. 1999 г., 03:00:0010.06.1999

Francis Glassborow wrote:

> In article <7j526q$6f1$1...@nnrp1.deja.com>, Lakshman KNVSM
> <knv...@yahoo.com> writes
> >Hi,


> > could someone explain the "usefulness" of <const_cast>?
>

I use it often with lazy initialization:

class A
{
public:
A();
const B& getB() const;

private:
B* m_b;
};

A::A()
: m_b( 0 )
{
}

const B& A::getB() const
{
if ( ! m_b )
{
A* self = const_cast<A*>( this );
self->m_b = new B; // Can't just use m_b since it is const in this
const function
}
return *m_b;
}

You might wonder why I don't just do: "const_cast<B*>( m_b) = newB;"
The answer is my compiler (MS VC 4.1) doesn't like it. Any explanations of
whether this is non-standard would be appreciated.

--
This signature intentionally left blank
(Except for these two lines.)

Ali Cehreli

не прочитано,
11 июн. 1999 г., 03:00:0011.06.1999
One of the reasons the keyword "mutable" exists is to help the programmer
in such cases. Try the following if your compiler supports it.

Douglas Kvidera <dkvi...@sbt.net> wrote in article
<375FCAA1...@sbt.net>...


> I use it often with lazy initialization:
>
> class A
> {
> public:
> A();
> const B& getB() const;
>
> private:

// B* m_b;
mutable B* m_b;


> };
>
> A::A()
> : m_b( 0 )
> {
> }
>
> const B& A::getB() const
> {
> if ( ! m_b )
> {
> A* self = const_cast<A*>( this );
> self->m_b = new B; // Can't just use m_b since it is const in this
> const function
> }
> return *m_b;
> }
>

const B& A::getB() const
{
if ( ! m_b )
{

m_b = new B;
}
return *m_b;
}


Ali
--
Please remove the dot between Berkeley and Net
to get my correct e-mail address.

John Potter

не прочитано,
11 июн. 1999 г., 03:00:0011.06.1999
Douglas Kvidera <dkvi...@sbt.net> wrote:

: I use it often with lazy initialization:

: class A
: {
: public:
: A();
: const B& getB() const;

: private:
: B* m_b;
: };

: A::A()
: : m_b( 0 )
: {
: }

: const B& A::getB() const
: {
: if ( ! m_b )
: {
: A* self = const_cast<A*>( this );
: self->m_b = new B; // Can't just use m_b since it is const in this
: const function
: }
: return *m_b;

: }

: You might wonder why I don't just do: "const_cast<B*>( m_b) = newB;"


: The answer is my compiler (MS VC 4.1) doesn't like it. Any explanations
of
: whether this is non-standard would be appreciated.

You may have missed the meaning of the error message. What you have
done is to create a new temporary rvalue from m_b. Since it is a B*
which is a builtin type, the assignment operator requires an lvalue
and you get an error. Good thing or you would have assigned the
new B to a temporary pointer which immediately self destructed and
caused a memory leak.

What you want is an lvalue

const_cast<B*&>(m_b) = new B;

This removes the const from the lvalue m_b rather than creating a new
rvalue copy of it.

John

Ron Natalie

не прочитано,
11 июн. 1999 г., 03:00:0011.06.1999
Ali Cehreli wrote:
>
> One of the reasons the keyword "mutable" exists is to help the programmer
> in such cases. Try the following if your compiler supports it.
>

Which is good, because mutable has a defined behavior in such
an example, casting away const does not.

John Potter

не прочитано,
11 июн. 1999 г., 03:00:0011.06.1999
"Ali Cehreli" <ac...@Berkeley.Net.com> wrote:

: One of the reasons the keyword "mutable" exists is to help the programmer
: in such cases. Try the following if your compiler supports it.

: Douglas Kvidera <dkvi...@sbt.net> wrote in article
: <375FCAA1...@sbt.net>...


: > I use it often with lazy initialization:
: >
: > class A
: > {
: > public:
: > A();
: > const B& getB() const;
: >
: > private:

: // B* m_b;
: mutable B* m_b;

This is a very heavy const cast. It has removed const from all
member functions. It does have the advantage of being correct.
The original code would have undefined behavior if the object
were actually const rather than a non-const being accessed via
a const reference.

I will leave the sanity of the lazy initialization concept for
others to debate.

John

John Lund

не прочитано,
10 авг. 1999 г., 03:00:0010.08.1999
As others have mentioned here, on occasion I've also had to use const_casts
for compatibility with legacy interfaces. However, what could be done if a
similar situation happened with a const (or non-const) member function?
Thankfully, I haven't run into this ugly problem, so this question is more a
curiosity, but consider the following attempt to convert function pointers:

struct MyClass
{
void MyMutableFun() {}
void MyConstFun() const {}
};

int main()
{
// Attempt to convert a pointer to a mutable function const.
typedef void (MyClass::*TConstFun)() const;
TConstFun pcf;
pcf = &MyClass::MyMutableFun;
pcf = const_cast<TConstFun>(&MyClass::MyMutableFun);
pcf = reinterpret_cast<TConstFun>(&MyClass::MyMutableFun);

// Attempt to convert a pointer to a const function to mutable.
typedef void (MyClass::*TMutableFun)();
TMutableFun pmf;
pmf = &MyClass::MyConstFun;
pmf = const_cast<TMutableFun>(&MyClass::MyConstFun);
pmf = reinterpret_cast<TMutableFun>(&MyClass::MyConstFun);

return 0;
}

MSVC6 yields errors on the non-reinterpret casts. ("cannot convert ... Types
pointed to are unrelated; conversion requires reinterpret_cast, C-style cast
or function-style cast") Sun Workshop 5.0 rejects them all. ("Cannot cast
away constness," etc.)

I know this is evil, but it seems odd to me that a language as liberal as
C++ would reject it. Any thoughts? (Please keep flames and "yo' momma"
responses to a minimum.)

-john, jl...@allaire.com

Anders Pytte

не прочитано,
12 авг. 1999 г., 03:00:0012.08.1999
John,

Your sample built fine in Metroworks CW Pro5 C++! The other compilers are
laggards, I guess.

Anders.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Lisa Lippincott

не прочитано,
13 авг. 1999 г., 03:00:0013.08.1999
<jl...@allaire.com> wrote:
> struct MyClass
> {
> void MyMutableFun() {}
> void MyConstFun() const {}
> };
[...]

> // Attempt to convert a pointer to a mutable function const.
> typedef void (MyClass::*TConstFun)() const;
> TConstFun pcf;
> pcf = &MyClass::MyMutableFun;
> pcf = const_cast<TConstFun>(&MyClass::MyMutableFun);
> pcf = reinterpret_cast<TConstFun>(&MyClass::MyMutableFun);
>
> // Attempt to convert a pointer to a const function to mutable.
> typedef void (MyClass::*TMutableFun)();
> TMutableFun pmf;
> pmf = &MyClass::MyConstFun;
> pmf = const_cast<TMutableFun>(&MyClass::MyConstFun);
> pmf = reinterpret_cast<TMutableFun>(&MyClass::MyConstFun);

Only the reinterpret_casts are allowed, and their results are
implementation-defined. Of the compilers that have been polled, it looks
like only MSVC6 produces the correct result (!); Sun Workshop 5.0
should have accepted the reinterpret_casts, and Metroworks CW Pro5
should have rejected the implicit conversions and const_casts.

--Lisa Lippincott

Anders Pytte

не прочитано,
17 авг. 1999 г., 03:00:0017.08.1999
In article <120819991425222424%lisa_li...@advisories.com>, Lisa
Lippincott <lisa_li...@advisories.com> wrote:

><jl...@allaire.com> wrote:
>> struct MyClass
>> {
>> void MyMutableFun() {}
>> void MyConstFun() const {}
>> };
>[...]
>> // Attempt to convert a pointer to a mutable function const.
>> typedef void (MyClass::*TConstFun)() const;
>> TConstFun pcf;
>> pcf = &MyClass::MyMutableFun;
>> pcf = const_cast<TConstFun>(&MyClass::MyMutableFun);
>> pcf = reinterpret_cast<TConstFun>(&MyClass::MyMutableFun);
>>
>> // Attempt to convert a pointer to a const function to mutable.
>> typedef void (MyClass::*TMutableFun)();
>> TMutableFun pmf;
>> pmf = &MyClass::MyConstFun;
>> pmf = const_cast<TMutableFun>(&MyClass::MyConstFun);
>> pmf = reinterpret_cast<TMutableFun>(&MyClass::MyConstFun);
>
>Only the reinterpret_casts are allowed, and their results are
>implementation-defined. Of the compilers that have been polled, it looks
>like only MSVC6 produces the correct result (!); Sun Workshop 5.0
>should have accepted the reinterpret_casts, and Metroworks CW Pro5
>should have rejected the implicit conversions and const_casts.


Where do you find documentation of this?

Anders

Darin Adler

не прочитано,
17 авг. 1999 г., 03:00:0017.08.1999
<jl...@allaire.com> wrote:
>>> struct MyClass
>>> {
>>> void MyMutableFun() {}
>>> void MyConstFun() const {}
>>> };
>>[...]
>>> // Attempt to convert a pointer to a mutable function const.
>>> typedef void (MyClass::*TConstFun)() const;
>>> TConstFun pcf;
>>> pcf = &MyClass::MyMutableFun;
>>> pcf = const_cast<TConstFun>(&MyClass::MyMutableFun);
>>> pcf = reinterpret_cast<TConstFun>(&MyClass::MyMutableFun);
>>>
>>> // Attempt to convert a pointer to a const function to mutable.
>>> typedef void (MyClass::*TMutableFun)();
>>> TMutableFun pmf;
>>> pmf = &MyClass::MyConstFun;
>>> pmf = const_cast<TMutableFun>(&MyClass::MyConstFun);
>>> pmf = reinterpret_cast<TMutableFun>(&MyClass::MyConstFun);

Lisa Lippincott <lisa_li...@advisories.com> wrote:
>>Only the reinterpret_casts are allowed, and their results are
>>implementation-defined. Of the compilers that have been polled, it looks
>>like only MSVC6 produces the correct result (!); Sun Workshop 5.0
>>should have accepted the reinterpret_casts, and Metroworks CW Pro5
>>should have rejected the implicit conversions and const_casts.

Anders Pytte <and...@milkweed.com> wrote:
> Where do you find documentation of this?

The standard documents what const_cast can do in section 5.2.11
[expr.const.cast]. Paragraph 12 of this section is a note that specifically
says that conversions between a pointer to const member function and a
pointer to non-const member function are note allowed. The normative text of
the section itself (not including the note) doesn't say that you can do
this, which amounts to saying that you can't.

What reinterpret_cast can do is defined in section 5.2.10
[expr.reinterpret.cast]. This section makes it clear that you can do the
conversion with reinterpret_cast, but the result is unspecified (what Lisa
meant when she said "implementation-defined").

Implicit conversion doesn't work because a pointer to const member function
and pointer to non-const member function don't have the same type. That's
covered elsewhere in the standard.

-- Darin

Lisa Lippincott

не прочитано,
17 авг. 1999 г., 03:00:0017.08.1999
Regarding

>>> pcf = &MyClass::MyMutableFun;
>>> pcf = const_cast<TConstFun>(&MyClass::MyMutableFun);
>>> pcf = reinterpret_cast<TConstFun>(&MyClass::MyMutableFun);
and

>>> pmf = &MyClass::MyConstFun;
>>> pmf = const_cast<TMutableFun>(&MyClass::MyConstFun);
>>> pmf = reinterpret_cast<TMutableFun>(&MyClass::MyConstFun);

I wrote:
> Only the reinterpret_casts are allowed, and their results are
> implementation-defined. Of the compilers that have been polled, it looks
> like only MSVC6 produces the correct result (!); Sun Workshop 5.0
> should have accepted the reinterpret_casts, and Metroworks CW Pro5
> should have rejected the implicit conversions and const_casts.

Anders Pytte <and...@milkweed.com> asks:


> Where do you find documentation of this?

On the matter of which casts are allowed, I looked in the C++ standard.
No conversion in 4 [conv] or 5.2.11 [expr.const.cast] applies.
While not normative, the note in 5.2.11 paragraph 12 specifically
excludes const_casts of pointers to member functions.

5.2.10 [expr.reinterpret.cast] paragraph 9 does apply (although
the result may not be useful to you). The prohibition of casting
away constness in paragraph 2 does not apply; see paragraphs 8-11
of 5.2.11.

On the matter of which compilers allow which casts, I took the word
of other posters in this thread. The exclamation point indicates my
personal opinion of MSVC6.

--Lisa Lippincott

Ответить всем
Написать сообщение автору
Переслать
0 новых сообщений