Home > Archive > VC STL > January 2006 > alternatives to typeid on void*?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
alternatives to typeid on void*?
|
|
| ultranet 2006-01-10, 7:24 pm |
| i tried to define a shared function to avoid code duplication and pass void *
to it, and do typeid inside of it to differentiate on 1 line. But void *
can't be deref'ed. What are my options?
| |
| ultranet 2006-01-10, 7:24 pm |
|
"ultranet" wrote:
> i tried to define a shared function to avoid code duplication and pass void *
> to it, and do typeid inside of it to differentiate on 1 line. But void *
> can't be deref'ed. What are my options?
> 1
i ended up just using a bool, and not using typeid at all, given the void *
limitation.
| |
| Igor Tandetnik 2006-01-10, 7:24 pm |
| ultranet <ultranet@discussions.microsoft.com> wrote:
> i tried to define a shared function to avoid code duplication and
> pass void * to it, and do typeid inside of it to differentiate on 1
> line. But void * can't be deref'ed. What are my options?
Differentiate between what and what? Show some code.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| ultranet 2006-01-10, 7:24 pm |
|
"ultranet" wrote:
>
>
> "ultranet" wrote:
>
> i ended up just using a bool, and not using typeid at all, given the void *
> limitation.
rather, i'll pass type_info& to the method, instead of bool, to make it less
error prone.
| |
| ultranet 2006-01-10, 7:24 pm |
|
"Igor Tandetnik" wrote:
> ultranet <ultranet@discussions.microsoft.com> wrote:
>
> Differentiate between what and what? Show some code.
i need to pass a struct or an object to the same method, and they don't
share a supertype.
| |
| Igor Tandetnik 2006-01-10, 7:24 pm |
| ultranet <ultranet@discussions.microsoft.com> wrote:
> "Igor Tandetnik" wrote:
>
> i need to pass a struct or an object to the same method, and they
> don't share a supertype.
What _do_ they share? You say you want to avoid code duplication, so
presumably the two have something in common.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| Jeff F 2006-01-10, 7:24 pm |
| ultranet wrote:
> "Igor Tandetnik" wrote:
>
> i need to pass a struct or an object to the same method, and they
> don't share a supertype.
Lookup overloading:
void Func( const MyClass& aClass )
{
// do something with aClass
}
void Func( const MyStruct& aStruct )
{
// do something with aStruct
}
Jeff Flinn
| |
| ultranet 2006-01-10, 7:24 pm |
|
"Igor Tandetnik" wrote:
> What _do_ they share? You say you want to avoid code duplication, so
> presumably the two have something in common.
> --
The only thing that ties them together, is that one can be obtained from
another by using an accessor or a constructor.
struct is Date.
object is Calendar.
Whichever one is passed in, Calendar is used to call another method (Date is
made into a Calendar if needed). So the point is to avoid code duplication,
by passing it in a void *:
BOOL myfunction(double id, Info *info, void *ptr, const type_info& ptrType);
_DLL_EXPORT_ (BOOL, myfunction1(double Id, lInfo *info, Date dt))
{
return myfunction(Id, info, (void *)&dt, typeid(Date));
}
_DLL_EXPORT_ (BOOL, myfunction2(double Id, Info *info, const Calendar& clndr))
{
return GetPersonnelInfoBy(Id, info, (void *)&clndr, typeid(Calendar));
}
| |
| ultranet 2006-01-10, 7:24 pm |
|
"Jeff F" wrote:
> void Func( const MyClass& aClass )
> {
> // do something with aClass
> }
>
> void Func( const MyStruct& aStruct )
> {
> // do something with aStruct
> }
Well, yes, there is already a function for the struct. That function is
being deprecated, and a new one for the object is being defined. To avoid
code duplication, i am moving all code from existing function to the new
utility function, and passing either struct or object from the 2
similar-looking functions to the utility method. Technically, overloading was
ruled out because some people might allegedly be using it by proc address.
| |
| Igor Tandetnik 2006-01-10, 7:24 pm |
| ultranet <ultranet@discussions.microsoft.com> wrote:
> "Igor Tandetnik" wrote:
>
> The only thing that ties them together, is that one can be obtained
> from another by using an accessor or a constructor.
> struct is Date.
> object is Calendar.
>
> Whichever one is passed in, Calendar is used to call another method
> (Date is made into a Calendar if needed). So the point is to avoid
> code duplication, by passing it in a void *:
What code duplication?
void DoSomething(Date* dt) {
// Do actual work
}
void DoSomething(Calendar* c) {
DoSomething(c->getDate());
}
What exactly do you object to here?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| ultranet 2006-01-10, 7:24 pm |
| "Igor Tandetnik" wrote:
> What code duplication?
Anyway, this discussion is going sideways. There is code duplication that
cannot be avoided. My question was about typeid on void *.
The answer i came up w/ is that void * cannot be derefed, and typeid cannot
be used. So i'm using type_info& as an extra param, something that wouldn't
be needed in Java, or if the 2 types had a shared supertype.
| |
| Igor Tandetnik 2006-01-10, 7:24 pm |
| ultranet <ultranet@discussions.microsoft.com> wrote:
> "Igor Tandetnik" wrote:
>
> Anyway, this discussion is going sideways. There is code duplication
> that cannot be avoided. My question was about typeid on void *.
With all due respect, this is your mistake. You have a problem. You came
up with a solution. This solution does not work, or is in some way
deficient. You are coming to the newsgroup, stating your solution and
asking how you can fix it. You refuse to describe the initial problem
itself.
Believe me or not, your proposed solution may not be optimal. Chances
are, better solutions exist. Perhaps one of the participants on this
group can suggest one. However, it is hard to help you if you don't
describe the problem you are trying to solve, the goal you are trying to
achieve.
I highly recommend that you start from the beginning, preferably in a
new top-level post (messages buried deep in the thread might not get as
much attention). State your problem as well as the solutions you've
tried and the reason you are not satisfied with them. A small code
example helps tremendously - crystal balls are hard to come by these
days.
I'm sure you'll be pleasantly surprised by the quality of response a
well-put question attracts.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| Pete Becker 2006-01-10, 7:24 pm |
| ultranet wrote:
>
> So i'm using type_info& as an extra param, something that wouldn't
> be needed in Java, or if the 2 types had a shared supertype.
Something that wouldn't be needed in Java BECAUSE the 2 types share a
supertype. Everything is derived from Object, whether you need it or not.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
| |
| Stephen Howe 2006-01-13, 7:58 am |
| > Anyway, this discussion is going sideways. There is code duplication that
> cannot be avoided. My question was about typeid on void *.
> The answer i came up w/ is that void * cannot be derefed, and typeid
cannot
> be used. So i'm using type_info& as an extra param, something that
wouldn't
> be needed in Java, or if the 2 types had a shared supertype.
As Ivan said.
It is aways best to state what problem you are trying to solve rather than,
"I have decided on this solution; I have reached a brick wall on
implementing it, how do I get round it?" I have seen so many programmers
only consult newsgroups when they have reached the brick wall.
Once the problem is known by the newsgroup, you can be offered a range of
solutions and the pros and cons of each solution can be pointed out. It
might become clear to you which of the solutions best meets your needs.
With the latter, it is definitely worst option. It could be that there is a
better solution but you will never know because you never stated what
problem you are trying to solve.
Stephen Howe
| |
| Wayne A. King 2006-01-14, 7:00 pm |
| On Tue, 10 Jan 2006 13:06:04 -0800, "=?Utf-8?B?dWx0cmFuZXQ=?="
<ultranet@discussions.microsoft.com> wrote:
>i need to pass a struct or an object to the same method, and they don't
>share a supertype.
Can't you use a template with your function and test the typeid of the
object passed to it? Something like this:
class Date{};
struct Calendar{};
template <class T> MyNewFunc(T t)
{
cout << "You passed me an object of type "
<< typeid(t).name() << endl;
}
int main()
{
Calendar C;
MyNewFunc(C);
Date D;
MyNewFunc(D);
return 0;
}
--
Wayne A. King
(ba994@torfree.net, wayne.king@ablelink.org,
waking@idirect.com, Wayne_A_King@compuserve.com)
|
|
|
|
|