C++ class initialization
-
I was just having a discussion on initializing variables with a coworker. We're working with python a lot and the absence of declarations is driving me mad. Python is simple and fast to write but you can definitely make some very ugly code with it (large classes with multiple inheritance within the same python file, ugh).
-
Vaclav_Sal wrote:
I sure wish there was an easier way to "see" the objects hierarchy in Arduino code.
I'm not sure where you got the code from, but there's auto-documentation engines such as Doxygen[^] that should make object hierarchies easier to see. A lot of open source projects use this type of "auto-documentation".
-
Thanks, this especially may be what I am looking for. "Doxygen can also visualize the relations between the various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams, which are all generated automatically."
Here's an example of what doxygen can generate (this is some open source radio framework)... http://gnuradio.org/doc/doxygen-3.6/classgr_1_1filter_1_1adaptive__fir__ccf__impl.html[^]
-
Vaclav_Sal wrote:
I sure wish there was an easier way to "see" the objects hierarchy in Arduino code.
I'm not sure where you got the code from, but there's auto-documentation engines such as Doxygen[^] that should make object hierarchies easier to see. A lot of open source projects use this type of "auto-documentation".
-
FYI After very brief usage of doxygen I have found that I indeed have several USBHost classes initialized hence I need to clean up current definition - especially the static global "members". Appreciate all your help. Vaclav
-
FYI After very brief usage of doxygen I have found that I indeed have several USBHost classes initialized hence I need to clean up current definition - especially the static global "members". Appreciate all your help. Vaclav
I am sorry to reopen this, but I just need confirmation that I am on the right track in reorganizing the code. I only hope I can describe my plan. Basically I have 3 USB classes. I hesitate to call them “objects “ for now. To bypass Arduino “help” ( trampling on my code ) I have this flow. It may be overkill but it is working so far. C_Main Cprocess USB (device) - “interface “ class member of Cprocess (my code) (device)Controller – controls the USB device – mouse is working (mostly cut and paste) USBHost - a native access to Arduino Due USB port for now used / tested as a state machine to retrieve USB configuration from attached USB device ( works so so )(also mostly cut and paste from ATmel) I would like to have all of these USB(device), (device) Controller, and USBHost in some kind of hierarchy. As you pointed out to me , the “problem” is that USBHost class itself is “global” and some of the class parameters – for example state of the “state machine” are also global. I can fix that. Eventually I need to control all of the devices on the USB (bus) and would like your opinion if the above scheme is OK as a base. Many thanks for your time , appreciate it very much Vaclav
-
I am sorry to reopen this, but I just need confirmation that I am on the right track in reorganizing the code. I only hope I can describe my plan. Basically I have 3 USB classes. I hesitate to call them “objects “ for now. To bypass Arduino “help” ( trampling on my code ) I have this flow. It may be overkill but it is working so far. C_Main Cprocess USB (device) - “interface “ class member of Cprocess (my code) (device)Controller – controls the USB device – mouse is working (mostly cut and paste) USBHost - a native access to Arduino Due USB port for now used / tested as a state machine to retrieve USB configuration from attached USB device ( works so so )(also mostly cut and paste from ATmel) I would like to have all of these USB(device), (device) Controller, and USBHost in some kind of hierarchy. As you pointed out to me , the “problem” is that USBHost class itself is “global” and some of the class parameters – for example state of the “state machine” are also global. I can fix that. Eventually I need to control all of the devices on the USB (bus) and would like your opinion if the above scheme is OK as a base. Many thanks for your time , appreciate it very much Vaclav
Some basics: Is-a = inheritance. If you inherit type B from A, then you can use type B as type A. Also see Liskov Substitution Principle (LSP). Example:
class Shape { virtual void Draw() = 0; /* ... */ };
class Circle : public Shape { void Draw(); };A Circle is-a Shape, so type Circle inherits type Shape. Note that this is all about behavior (interface), so you can treat a pointer or reference to any subclass of Shape as if it was a Shape with respect to Shape's interface (in this case a single
Draw()function). Has-a = aggregating. Example:class Canvas {
public: void Draw();
private: set m_shapes;
};A Canvas can hold one or more Shape's, of any concrete subtype, and most likely Canvas::Draw will iterate over the shapes it holds, calling their Draw method. For clarity, you may want to think of Canvas::Draw as Canvas::DrawShapes. For the particular case where you are to have one, and only one, object of a specific type, you may want to have a look at making it a Singleton. I hope this attempt at a simple explanation of the concepts can help you come up with a design. While drawing has nothing at all to do with USB, the concepts of inheritance and aggregation are the same. For project after project. (NOTE: code-formatting was done for compactness, please do not copy as-is :-) )
-
Some basics: Is-a = inheritance. If you inherit type B from A, then you can use type B as type A. Also see Liskov Substitution Principle (LSP). Example:
class Shape { virtual void Draw() = 0; /* ... */ };
class Circle : public Shape { void Draw(); };A Circle is-a Shape, so type Circle inherits type Shape. Note that this is all about behavior (interface), so you can treat a pointer or reference to any subclass of Shape as if it was a Shape with respect to Shape's interface (in this case a single
Draw()function). Has-a = aggregating. Example:class Canvas {
public: void Draw();
private: set m_shapes;
};A Canvas can hold one or more Shape's, of any concrete subtype, and most likely Canvas::Draw will iterate over the shapes it holds, calling their Draw method. For clarity, you may want to think of Canvas::Draw as Canvas::DrawShapes. For the particular case where you are to have one, and only one, object of a specific type, you may want to have a look at making it a Singleton. I hope this attempt at a simple explanation of the concepts can help you come up with a design. While drawing has nothing at all to do with USB, the concepts of inheritance and aggregation are the same. For project after project. (NOTE: code-formatting was done for compactness, please do not copy as-is :-) )
Mike, thanks for reply. I just found another copy of the USBHost class and in the few comments attached to it they use term singleton. So your comment arrived just in time. I really need to dig into this because the sample code I have been playing with does not work when more than one USB devices are on the USB bus. I think I got the "static class" concept but still struggling with how each inherited class uses global state variables - since each USB device maintains his own state machine. Thanks Vaclav
-
Mike, thanks for reply. I just found another copy of the USBHost class and in the few comments attached to it they use term singleton. So your comment arrived just in time. I really need to dig into this because the sample code I have been playing with does not work when more than one USB devices are on the USB bus. I think I got the "static class" concept but still struggling with how each inherited class uses global state variables - since each USB device maintains his own state machine. Thanks Vaclav
To me, just based on this comment, it seems you'd have: A "base", the driver. The singleton. This owns one or more USBBus objects, each handling a physical connection. These in turn owns zero or more USBDevice's, each representing a device on that bus. Each USBDevice would in turn probably have one or more "functions" (e.g. a USB mouse with buttons, wheel, and some more clickable buttons could easily present 3 or more functions/sub-devices). It also seems logical that each device (and function and so on) might need (hold) a reference to its owner, to f.ex. be able to notify it about events. Not to mention the obvious - verify correctness in such a highly dynamic and unpredictable system :-) I see no obvious reason any of the USB types should ever touch the global/static parts. But should the need arise; don't give them access to the data (if you ever used MFC, consider that the anti-thesis of good design). Instead provide them an interface - and not only an interface that returns a ref or ptr to the global/static var's, but something that actually do some work. Which brings me to another good rule-of-thumb (actually, this one is more like a law of nature): - Interfaces shall be minimal and complete. Additionally: - Member functions should do two things; Use the object's state (directly or indirectly), and not leak the objects state to the outside. If a function is not using the object's state, it has no business being a member function (not counting corner cases). If it's not hiding the internal state, it's "leaking" it to other types to use or abuse, and making it hard-to-impossible to change the implementation later on. That last point, not leaking internal state to the outside, is worth hammering in over and over until you say "Obviously, anything else would be insanity!". Later, if needed, "on the side" you might even find it useful to have a "registry" of devices, no matter what bus they are on, to save lookup time or whatever. F.ex. the system input handler might poll you about input events, and then you could have one list of devices dedicated to HID input. Another case could be the user requests "Put all storage devices to sleep" and instead of walking the busses and their devices (which in turn may have an expander (hub-ish) with another bus to dive into) you have a single list to iterate. You get the idea. ++luck;
-
static uint32_t usb_error = 0; // is (global) static initialized to 0 as default anyway?
Don't care about what the compiler does. Variables that may be read before they are written should be always initialized.
usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE; // why "initialized " again here?
The variable will probably changed by the class. When creating another instance, the value is not the initial one.
bmHubPre = 0; // is this necessary? see constructor parameter
The variable is set in the constructor but the
initfunction may be called multiple times. Overall this is a bad example. When using global static variables with a class, you must ensure that only one instance of the class exists. To detect multiple instances some kind of check should be implemented. For your class this can be done by moving the re-initialization ofusb_task_stateto the destructor and checking the value in the constructor:ASSERT(usb_task_state == USB_DETACHED_SUBSTATE_INITIALIZE);
Generally there is no need to use a class when that uses global static variables. When global variables are really necessary, they should be at least members of the class:
// Header file
class USBHost
{
// ...
protected:
static uint32_t usb_error;
static uint32_t usb_task_state;
}// Source file
uint32_t USBHost::usb_error = 0;
uint32_t USBHost::usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE;usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE; // why "initialized " again here?
usb_task statedeclares a new variable of typeusb_taskthat is a member of the class. -
usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE; // why "initialized " again here?
usb_task statedeclares a new variable of typeusb_taskthat is a member of the class.But there is an underscore between usb_task and state.
-
But there is an underscore between usb_task and state.
I apologize; I missed the underscore. Never mind.
