Replacing a void* in C++

[Jim Langston]

I am using some code that I got that uses a form a message dispatching where
the data is passed via a void*. I don't like void*'s so am experimenting
with a different way to do them in C++. I don't use boost, and this is what
I've come up with so far, but it seems fairly ugly.

In actual use the final handler that handles the data would know what type
the data should be based on other paramaters in the function call, so this
is just proof of concept.

Has anyone a better idea? I tend to like MessageHandler2 using a reference
instead of a pointer.

#include <iostream>
#include <string>

struct AIMsg
{
public:
AIMsg( const std::string& MsgType ): MsgType( MsgType ) {}
std::string MsgType;
virtual ~AIMsg() {}
};

template <class Tclass Message: public AIMsg
{
public:
Message(): AIMsg( typeid(T).name( ) ) {}
T Value;
};

void MessageHandler( AIMsg* Msg )
{
if ( Msg->MsgType == typeid(float).n ame() )
std::cout << dynamic_cast<Me ssage<float>*>( Msg )->Value << "\n";
else if ( Msg->MsgType == typeid(int).nam e() )
std::cout << dynamic_cast<Me ssage<int>*>( Msg )->Value << "\n";
}

void MessageHandler2 ( AIMsg& Msg )
{
if ( Msg.MsgType == typeid(float).n ame() )
std::cout << dynamic_cast<Me ssage<float>* >( &Msg )->Value << "\n";
if ( Msg.MsgType == typeid(int).nam e() )
std::cout << dynamic_cast<Me ssage<int>* >( &Msg )->Value << "\n";
}

int main()
{
Message<floatBa r;
Bar.Value = 54321.123f;
MessageHandler( &Bar );
MessageHandler2 ( Bar );

Message<intBar2 ;
Bar2.Value = 123;
MessageHandler( &Bar2 );
MessageHandler2 ( Bar2 );

return 0;
}

[Chris ( Val )]

On Sep 28, 10:33 am, "Jim Langston" <tazmas...@rock etmail.comwrote :

I am using some code that I got that uses a form a message dispatching where
the data is passed via a void*. I don't like void*'s so am experimenting
with a different way to do them in C++. I don't use boost, and this is what
I've come up with so far, but it seems fairly ugly.

In actual use the final handler that handles the data would know what type
the data should be based on other paramaters in the function call, so this
is just proof of concept.

Has anyone a better idea? I tend to like MessageHandler2 using a reference
instead of a pointer.

I don't completely understand why you require 2 classes, but you
could look into template specialisation to see if that helps you.

I just wanted to make the point that unless it has changed in the
recent standard, relying on an accurate string from the 'typeid'
"name()" member is not reliable, and implementation dependant; if
a string is returned at all.

Additionally, I don't think it is being used effectively the way
you have it.

For example, the construct "typeid( float ).name()" will always
produce the same hard coded result on one side of the evaluation,
provided a valid result is available for evaluation.

Much better to use something like the following, so you're
not bound to that hard coded construct:

template<typena me A, typename Bbool isEqual( A a, B b ) {
return typeid( a ) == typeid( b );
}

int main()
{
char A(0);
int B(0);
long C(0);

std::cout << std::boolalpha << isEqual( A, A ) << '\n';
std::cout << std::boolalpha << isEqual( A, B ) << '\n';
std::cout << std::boolalpha << isEqual( A, C ) << '\n';

return 0;
}

-- OUTPUT --
true
false
false

Cheers,
Chris Val

[Jim Langston]

"Chris ( Val )" <ch******@gmail .comwrote in message
news:11******** **************@ 22g2000hsm.goog legroups.com...

On Sep 28, 10:33 am, "Jim Langston" <tazmas...@rock etmail.comwrote :

>I am using some code that I got that uses a form a message dispatching
where
the data is passed via a void*. I don't like void*'s so am experimenting
with a different way to do them in C++. I don't use boost, and this is
what
I've come up with so far, but it seems fairly ugly.

In actual use the final handler that handles the data would know what
type
the data should be based on other paramaters in the function call, so
this
is just proof of concept.

Has anyone a better idea? I tend to like MessageHandler2 using a
reference
instead of a pointer.

I don't completely understand why you require 2 classes, but you
could look into template specialisation to see if that helps you.

I just wanted to make the point that unless it has changed in the
recent standard, relying on an accurate string from the 'typeid'
"name()" member is not reliable, and implementation dependant; if
a string is returned at all.

Additionally, I don't think it is being used effectively the way
you have it.

For example, the construct "typeid( float ).name()" will always
produce the same hard coded result on one side of the evaluation,
provided a valid result is available for evaluation.

Much better to use something like the following, so you're
not bound to that hard coded construct:

template<typena me A, typename Bbool isEqual( A a, B b ) {
return typeid( a ) == typeid( b );
}

int main()
{
char A(0);
int B(0);
long C(0);

std::cout << std::boolalpha << isEqual( A, A ) << '\n';
std::cout << std::boolalpha << isEqual( A, B ) << '\n';
std::cout << std::boolalpha << isEqual( A, C ) << '\n';

return 0;
}

-- OUTPUT --
true
false
false

I would rather not hard code any types at all. I'm working with existing
code that recieves messages such as:

bool MinerGlobalStat e::OnMessage(Mi ner* pMiner, const Telegram& msg)

With Telegram defined as:
struct Telegram
{
int Sender;
int Receiver;
int Msg;
double DispatchTime;
void* ExtraInfo;
// constructor etc...
}

It is the void* ExtraInfo I am trying to make a little more friendly. In the
OnMessage I have to do things such as:
int Amount = *reinterpret_ca st<int*>( msg.ExtraInfo );

Which, okay, usually, is okay. But, somewhere someone may have stuck an int
in there instead of a float or such. Not very typesafe. And I don't like
the reinterpret_cas t.

What would be ideal would be to move the ExtraInfo out of Telegram and make
it a paramater in OnMessage changing the signature to:
bool MinerGlobalStat e::OnMessage(Mi ner* pMiner, const Telegram& msg, const
float& ExtraInfo)

A different class may have it declared:

bool CookStew::OnMes sage(MinersWife * wife, const Telegram& msg, const
SomeClass& ExtraInfo)

or such.

The existing code I'm working with has many source files and I don't really
want to have to redesign the whole class heirarchy to use the visitor
pattern, and also there may be a case where one message handler may need to
have the ExtraInfo as different typed depending on the Msg paramater of the
Telegram.

I know that void*'s were used a lot in C callbacks and had hoped that by now
someone had a good way to deal with them in C++. Upcasting doesn't seem to
be working. Trying to upcast an AIMsg* to a Message<float>* didn't work and
got me nowhere.

Trying to google for "change void* in C++" doesn't help has void is found
too many places in function/method returns. It looks like somewhere I'm
going to have to do a dymaic_cast or a reinterpret_cas t and am trying to
stick any such ugliness away from the onmessage methods.

[Jim Langston]

"Alf P. Steinbach" <al***@start.no wrote in message
news:13******** *****@corp.supe rnews.com...

>* Jim Langston:

>>
Trying to google for "change void* in C++" doesn't help has void is found
too many places in function/method returns. It looks like somewhere I'm
going to have to do a dymaic_cast or a reinterpret_cas t and am trying to
stick any such ugliness away from the onmessage methods.

Check out the visitor pattern.

I've been reading up on the visitor pattern, and if I was to develop this
class heirarchy from scratch, I'd probalby use that. However, I don't see
how using the visitor pattern helps with converting a void * in an existing
class heirarchy. Unless I'm missing something or my googles for "visitor
pattern c++" are not showing a specific usage for this case.

[Chris ( Val )]

On Sep 29, 5:11 am, "Jim Langston" <tazmas...@rock etmail.comwrote :

"Chris ( Val )" <chris...@gmail .comwrote in messagenews:11* *************** ******@22g2000h sm.googlegroups .com...

On Sep 28, 10:33 am, "Jim Langston" <tazmas...@rock etmail.comwrote :

I am using some code that I got that uses a form a message dispatching
where
the data is passed via a void*. I don't like void*'s so am experimenting
with a different way to do them in C++. I don't use boost, and this is
what
I've come up with so far, but it seems fairly ugly.

In actual use the final handler that handles the data would know what
type
the data should be based on other paramaters in the function call, so
this
is just proof of concept.

Has anyone a better idea? I tend to like MessageHandler2 using a
reference
instead of a pointer.

I don't completely understand why you require 2 classes, but you
could look into template specialisation to see if that helps you.

I just wanted to make the point that unless it has changed in the
recent standard, relying on an accurate string from the 'typeid'
"name()" member is not reliable, and implementation dependant; if
a string is returned at all.

Additionally, I don't think it is being used effectively the way
you have it.

For example, the construct "typeid( float ).name()" will always
produce the same hard coded result on one side of the evaluation,
provided a valid result is available for evaluation.

Much better to use something like the following, so you're
not bound to that hard coded construct:

template<typena me A, typename Bbool isEqual( A a, B b ) {
return typeid( a ) == typeid( b );
}

int main()
{
char A(0);
int B(0);
long C(0);

std::cout << std::boolalpha << isEqual( A, A ) << '\n';
std::cout << std::boolalpha << isEqual( A, B ) << '\n';
std::cout << std::boolalpha << isEqual( A, C ) << '\n';

return 0;
}

-- OUTPUT --
true
false
false

I would rather not hard code any types at all. I'm working with existing
code that recieves messages such as:

bool MinerGlobalStat e::OnMessage(Mi ner* pMiner, const Telegram& msg)

With Telegram defined as:
struct Telegram
{
int Sender;
int Receiver;
int Msg;
double DispatchTime;
void* ExtraInfo;
// constructor etc...

}

It is the void* ExtraInfo I am trying to make a little more friendly. In the
OnMessage I have to do things such as:
int Amount = *reinterpret_ca st<int*>( msg.ExtraInfo );

Which, okay, usually, is okay. But, somewhere someone may have stuck an int
in there instead of a float or such. Not very typesafe. And I don't like
the reinterpret_cas t.

[snip]

What are the data types are you only interested
in accepting?

When you say "instead of a float", does that mean
you require floats and floates only? or are doubles
legal according to your spec as well?

The reason I ask, is because I think your biggest
problem happens well before the OnMessage member
function.

Personally, I would stop the client entering the
wrong data type to begin with, and set up a
constraint to dissallow the wrong types to be
entered from the word go.

You could use teamplates and function overloading
to do this. Or even capture the data into a
std::stringstre am object and sort it out from
there.

[snip]

The existing code I'm working with has many source files and I don't really
want to have to redesign the whole class heirarchy to use the visitor
pattern, and also there may be a case where one message handler may need to
have the ExtraInfo as different typed depending on the Msg paramater of the
Telegram.

That visitor pattern looks different to ones
that I've seen in the past :-)

It is just a simple function acting polymorphically .

--
Chris Val

[rolkA]

On 28 sep, 21:11, "Jim Langston" <tazmas...@rock etmail.comwrote :

>
It is the void* ExtraInfo I am trying to make a little more friendly. In the
OnMessage I have to do things such as:
int Amount = *reinterpret_ca st<int*>( msg.ExtraInfo );

Which, okay, usually, is okay. But, somewhere someone may have stuck an int
in there instead of a float or such. Not very typesafe. And I don't like
the reinterpret_cas t.

Btw, with void* you dont have to use reinterpret_cas t. void* can be
casted to any pointer and any pointer can be casted to void*, with
static_cast. It's not THAT bad, I'm still using this for old-school
callbacks ("userdata") . What is VERY bad is to reinterpret POD (with a
pointer and a size).
Though it doesn't solve your problem, sorry ^_^