Hello together,
i was trying to find out, how to cast an unsigned int to a class pointer. I´m using a stm32 under µVision4. I read something about reinterpret casts, and that they´re not that runtime efficient. And i don´t see (know) the reason why i´m forced to use a function wich checks the adress if it really holds the class type; plus i´m not sure if this is even supported on the µC. if i do it the "noobish" way tmpPtr = (myClass)adressHolder; i´m told a sufficient constructor is missing. For what information do i have to search, if i want to make up such a constructor on my own.
Backround: I have a bunch of classes and they all have "prev" and "nxt" pointer of thier own typ to form up a list. This means i have implemented a Get-, and Set- method to access the previous and next adress holder. Since i want to use descent (don´t know if it is the correct english word), i had the idea to implement the Get, Set methods with unsigend int parameter and cast them to the type i need, when required.
Greetings, Justus
That looks like you're going about this whole thing bass-ackwards. C++ has way better methods for doing that, involving either templates (see STL's <dequeue> et al.) or inheritance of members and methods from shared base classes.
Even in C, pointers aren't really all that compatible with integers. You shouldn't even think about it for C++ object pointers.
thanks for keywords! I´ll check for them.
Ah, "inheritance" was the word i needed by writing "descent". But afaik, templates also critical in embedded systems. At the moment i´m doing it by casteing the usigned int back to a class pointer and it works. But what is the reason not to do so? An unsigned int has the width of the asdresses wich exists in a 32bit Controller. Or is it just the danger to cast it into an type wich it doesen´t really point to?
"But what is the reason not to do so?
The main reason? That you are programming in C with the C++ language.
That you are ignoring that C++ was designed for objects, and so added specific language extensions for inheritance from base classes. That C++ added support for virtual methods, constructors, destructors, ...
how can i ignore someting i don´t know about?
But what is the reason not to do so?
The reason is that currently you're fighting your tools instead of using them properly. The reason is that you're reinventing the wheel while riding a train.
Don´t u think, that my questions mostly refer to a suffer of knowledge rather than doing "wrong" things with awareness? And on the other hand, when my knowledge isn´t enough to estimate if a c++ feature is suitable for a µControler/embedded system, then i rather reinvent the wheel instead of using something where i don´t know what system requirements are needed.
Easily --- because the original, literal meaning of "to ignore" is "to know nothing about". Only later did it gain the additional meaning of "to not make use of something you have"
But really, you must be kidding. There's just no way you believe you're programming C++ and not know about inheritance.
So either program in C.
Or spend some hours looking at an entry-level C++ textbook. That C++ book will quite quickly cover these issues.
But as Hans-Bernhard Broeker said, the base form of the word "ignorant" means: - Lacking knowledge or awareness in general; uneducated or unsophisticated. - Lacking knowledge, information, or awareness about something in particular: "ignorant of astronomy".
In this case, you are lacking knowledge of C++. So you try to bend it to write C programs when C++ has specifically added functionality for object-oriented programs.
C++ was designed to allow C code to be compiled with a minimum of adjustments, to allow incremental move from strict C to full C++. But that doesn't mean you should write object-oriented code (which is in the C++ domain) by using C constructs like typecasting of untyped pointers etc.
It doesn't take many hours to pick up what the important C++ additions are - but you should preferably settle for using a single base class and ignore that C++ also supports multiple inheritance. Having multiple base classes means people can't read the source code and actually understand the actual implications of call order for constructors, destructors etc.
If you are good with C++, then there are even special books that concentrates on just describing the differences from C to C++.
And on the other hand, when my knowledge isn´t enough to estimate if a c++ feature is suitable for a µControler/embedded system, then i rather reinvent the wheel instead of using something where i don´t know what system requirements are needed.
That makes no sense. If you not just lack basic knowledge to make an informed decision, but know you lack it, then it's never the right conclusion to just make the decision anyway. You should improve your knowledge instead.
Like I said: re-inventing the wheel is embarrassing enough on its own, even if you're lucky enough that yours don't come out square. But it's truly ridiculous when you do that while already sitting in a wheeled vehicle, so all you would have had to do to spare you the effort is take a look down out the window.
That makes no sense.
You may or may not agree with it, but linguistically it does make perfect sense.