By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,898 Members | 2,012 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,898 IT Pros & Developers. It's quick & easy.

Casting (void*)&foo

P: n/a
Is this approach safe?

class Foo
{
// Stuff
};

void func1 (void *)
{
// Do something
}

void func2 (const Foo& foo)
{
func1 ((void*)&foo); // Is this safe
}

Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

Jun 20 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Alex Vinokur wrote:
Is this approach safe?


Absolutely, for peculiar meanings of "safe". Some good rules of thumb:

* A C-style cast is never safe.
* A C-style cast to a void* is especially never safe.
* A C-style cast that disregards a const qualifier is ridiculously
especially never safe.
* And a C-style cast that tries to...

This approach is almost gratuitously unsafe. Please don't use this in
any real-world code. There are certainly some specific instances where
this approach is harmless, but in the main, this approach is just full
of all different kinds of things to avoid.

Jun 20 '06 #2

P: n/a
Alex Vinokur wrote:
Is this approach safe?

class Foo
{
// Stuff
};

void func1 (void *)
{
// Do something
}

void func2 (const Foo& foo)
{
func1 ((void*)&foo); // Is this safe
}


void func3 (const Foo * const p_foo)
{
func1 ((void*)p_foo);
}

Is function func3() more safe than func2()?
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

Jun 20 '06 #3

P: n/a
> void func3 (const Foo * const p_foo)
{
func1 ((void*)p_foo);
}

Is function func3() more safe than func2()?


Skydiving while drunk might be more safe than playing Russian roulette,
but I wouldn't want to do either.

Is it a C-style cast? Yep, check. Bad sign.

Is it a cast to void*? Yep, check. Bad sign.

Is it casting away constness? Yep, check. Bad sign.

Don't do this. If you're doing this in real code, please stop now.

Jun 20 '06 #4

P: n/a

Alex Vinokur wrote:
Alex Vinokur wrote:
Is this approach safe?

class Foo
{
// Stuff
};

void func1 (void *)
{
// Do something
}

void func2 (const Foo& foo)
{
func1 ((void*)&foo); // Is this safe
}


void func3 (const Foo * const p_foo)
{
func1 ((void*)p_foo);
}

Is function func3() more safe than func2()?


No, equally unsafe.

But why would you func1 have void* as parameter? That is the source of
your corruption. Any function calling func1 would be dubious.

Change func1 to receive a specific type, else unsafe - period.

Regards,

Werner

Jun 20 '06 #5

P: n/a
Alex Vinokur wrote:
Is this approach safe?

class Foo
{
// Stuff
};

void func1 (void *)
{
// Do something
}

void func2 (const Foo& foo)
{
func1 ((void*)&foo); // Is this safe
}


Since func1 actually dose nothing, despite the comment <g>, this code is
perfectly safe. If func1 is changed to do something that isn't safe,
then the code is not safe.

--

Pete Becker
Roundhouse Consulting, Ltd.
Jun 20 '06 #6

P: n/a
Alex Vinokur posted:
Is this approach safe?

class Foo
{
// Stuff
};

void func1 (void *)
{
// Do something
}

void func2 (const Foo& foo)
{
func1 ((void*)&foo); // Is this safe
}


Make an full program out of it first of all:
class Foo {};

void Func1( void* ) {}

void Func2( const Foo& foo )
{
Func1( (void*)&foo );
}

int main()
{
Foo obj;

Func2(obj);
}
The above program is well-formed and absent of undefined behaviour.

Style, on the other hand, is a different animal.

--

Frederick Gotham
Jun 20 '06 #7

P: n/a
Robert J. Hansen posted:
Alex Vinokur wrote:
Is this approach safe?
Absolutely, for peculiar meanings of "safe". Some good rules of thumb:

* A C-style cast is never safe.

Plenty of places where it's safe:

unsigned Func( unsigned long const val1, unsigned long const val2 )
{
return (unsigned)(val1 / val2);
}

* A C-style cast to a void* is especially never safe.

void *p;
void StoreAddress( void * const arg )
{
p = arg;
}
void AlterObject()
{
*static_cast<int *>(p) = 43;
}
int main()
{
int i;

StoreAddress( (void*)i );

/* Unneeded cast, but safe nonetheless *?

AlterObject();
}

* A C-style cast that disregards a const qualifier is ridiculously
especially never safe.

Again, it can be used to reinterpret_cast and const_cast in one foul
swoop.
The "new style" casts may be preferable over the "old style C casts", but
the old style C casts are as fully-fledged a feature of C++ as are the
"new style casts".
The one major advantage of C style casts is they're not as laborious to
type out:

(int)val

Versus:

static_cast<int>(val)
--

Frederick Gotham
Jun 20 '06 #8

P: n/a
In article <1150786821.704997.267180
@g10g2000cwb.googlegroups.com>,
al****@users.sourceforge.net says...
Is this approach safe?

class Foo
{
// Stuff
};

void func1 (void *)
{
// Do something
}

void func2 (const Foo& foo)
{
func1 ((void*)&foo); // Is this safe
}


Is it safe to:

1) strip somebody naked
2) search them to ensure they have no weapons
3) paint a few targets on them
4) parachute them into the middle of a pitched battle

?

Technically, these steps may not cause death by
themselves. Nonetheless, you've done just about
everything you can to ensure that poor "foo" isn't going
to survive this experience...

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jun 21 '06 #9

P: n/a

Frederick Gotham wrote:

The one major advantage of C style casts is they're not as laborious to
type out:

(int)val

Versus:

static_cast<int>(val)
Hmmm, given. One major advantage of C++ style casts is that they're
easy to find when looking for the source of your mistakes. Furthermore,
they concise. They have responsibility. They give certain guarantees.
An erroneous static_cast would fail to compile. C style casts compile
regardless of human error, and all humans make errors. For that reason,
I'll rather type .25 secs longer than look for a hard to find bug.

Regards,

Werner


--

Frederick Gotham


Jun 21 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.