• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 21 subscribers
  • Views 1097 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Can someone advice for pointers for void objects?

Jack Sawsan 

void *MyConfigDetail;

if (x)
{
  ((TType1 *) MyConfigDetail) = DetailCacheBeans;
}
else
{
  ((TType2 *) MyConfigDetail) = DetailailCacheHam;
}

</rpr>

But I am unable to access the "MyConfigDetail" elements as

 MyConfigDetail->Forks = 22;            // for example

Why not?

Parents
  • 0 in reply to Jack Sawsan

    No, it is not.

    Very great care should be used when "upgrading" a pointer.

    It is almost always a bad sw design if a naked pointer has to be typecast like that. You may implement a generic list with void pointers, but then you normally create a new level of abstraction to get access functions that makes sure you insert pointers of type xx, and get back pointers of type xx, in which case the code that accesses the field Forks doesn't need any type cast.

    There are many great ways to write lousy code that are hard to maintain. This is one of the top-ten ways - and definitely at the top half of the list...

Reply
  • 0 in reply to Jack Sawsan

    No, it is not.

    Very great care should be used when "upgrading" a pointer.

    It is almost always a bad sw design if a naked pointer has to be typecast like that. You may implement a generic list with void pointers, but then you normally create a new level of abstraction to get access functions that makes sure you insert pointers of type xx, and get back pointers of type xx, in which case the code that accesses the field Forks doesn't need any type cast.

    There are many great ways to write lousy code that are hard to maintain. This is one of the top-ten ways - and definitely at the top half of the list...

Children