C / C++ / MFC

19-Jan-15 14:32

I would like to get better grasp on how C++ class is instantiated / initialized.
Here is a part of what I assume relevant code I like to have help with.
The USBHost class has a method "Task" which is basically a state machine and I am currently trying to figure out how is this state machine "advanced".
Before I can get to that I need better understanding how is the class initialized.
I have put my basic questions as comments to this code snippet.
If someone can also apply descriptive terminology and / or explain the syntax it would be nice, but nothing elaborate.
Appreciate your time.
Thanks
Vaclav

static uint32_t usb_error = 0; // is (global) static initialized to 0 as default anyway?
static uint32_t usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE; // this state is not defined as 0 - this is OK

/**
* \brief USBHost class constructor.
*/
USBHost::USBHost() : bmHubPre(0) // may be a default USB hub 0 , not sure
{
usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE; // why "initialized " again here?

init();
}

/**
* \brief Initialize USBHost class.
*/
void USBHost::init()
{
devConfigIndex = 0; // USB (device ?) default index
bmHubPre = 0; // is this necessary? see constructor parameter
}

Jochen Arndt19-Jan-15 21:18

Jochen Arndt

19-Jan-15 21:18

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 init function 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 of usb_task_state to 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:

C++

// Header file
class USBHost
{
    // ...
protected:
    static uint32_t usb_error;
    static uint32_t usb_task_state;
}

C++

// Source file
uint32_t USBHost::usb_error = 0;
uint32_t USBHost::usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE;

David A. Gray8-Apr-15 20:25

David A. Gray

8-Apr-15 20:25

usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE; // why "initialized " again here?

usb_task state declares a new variable of type usb_task that is a member of the class.

Jochen Arndt8-Apr-15 20:51

Jochen Arndt

8-Apr-15 20:51

But there is an underscore between usb_task and state.

David A. Gray9-Apr-15 11:05

David A. Gray

9-Apr-15 11:05

I apologize; I missed the underscore. Never mind.

CPallini20-Jan-15 1:52

20-Jan-15 1:52

It doesn't look a good example.

Quote:
static uint32_t usb_error = 0; // is (global) static initialized to 0 as default anyway?

Yes, however it doesn't harm.

The other pieces of code are ugly and your observations right.

Albert Holguin20-Jan-15 4:40

20-Jan-15 4:40

Like others mentioned this isn't the cleanest example, but I'll also take a stab at explaining some of these things...

C++

static uint32_t usb_error = 0;   // is (global) static initialized to 0 as default anyway? 
static uint32_t usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE; // this state is not defined as 0 - this is OK

Initializing a global (or a static) outside of the user function or class is always good practice. The compiler may or may not initialize for you, but why risk it.

C++

USBHost::USBHost() : bmHubPre(0) // may be a default USB hub 0 , not sure 
{
     usb_task_state = USB_DETACHED_SUBSTATE_INITIALIZE; // why "initialized " again here? 
 
     init();
}

This is initializing a global that is in an undefined state back to the default. Remember that if there was an instance of USBHost that existed, he might have left the state of the variable in some unknown state. Like someone else mentioned however, this initialization does imply you should only ever have one instance of this class... otherwise you'll have a conflict with the state of this variable. With that said though, it is resetting itself, so you should be able to delete the object when not in use and make a new one when you do need it.

void USBHost::init()
{
     devConfigIndex     = 0;            // USB (device ?) default index
     bmHubPre     = 0;            // is this necessary? see constructor parameter
}

init() methods are usually made when there may be a need to initialize variables outside of the constructor, or alternatively, when there are multiple constructors that all need to initialize the same variables. For example, there may be some code that gets called when the USB device gets to a certain state that requires re-initialization.... rather than destruct the object and start all over, the init() may be called to re-initialize.

Vaclav_20-Jan-15 6:22

20-Jan-15 6:22

Thanks guys, I really appreciate your help.
This class is to make USB host (Arduino) communicate with USB devices and so far I'll be happy if I can work with one device / one instance of the class. Eventually I'll need a USB hub (as USB device) to work with multiple devices so I'll make sure multiple instances of this class can exist.

I sure wish there was an easier way to "see" the objects hierarchy in Arduino code.
But I feel I am really pushing my luck with this toy hardware.
Thanks
Vaclav

Albert Holguin20-Jan-15 6:50

20-Jan-15 6:50

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".

Vaclav_20-Jan-15 16:43

20-Jan-15 16:43

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."

Albert Holguin21-Jan-15 3:14

21-Jan-15 3:14

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_21-Jan-15 16:00

21-Jan-15 16:00

Albert,
this doxygen is a FANTASTIC tool!
Thanks a milion!
Vaclav

CPallini20-Jan-15 7:56

20-Jan-15 7:56

Quote:
The compiler may or may not initialize for you, but why risk it.

That is not exactly true. The C++ standard specify that such variables 'shall be zero-initialized', hence no risk, unless the compiler is not compliant.

Albert Holguin20-Jan-15 8:05

20-Jan-15 8:05

CPallini wrote:
The C++ standard specify that such variables 'shall be zero-initialized'

Was this in every C++ standard since the original? ...I don't really know...but if it wasn't, it's not worth any savings in writing. Plus it makes it easier to read.

CPallini20-Jan-15 9:14

20-Jan-15 9:14

Albert Holguin wrote:
Was this in every C++ standard since the original? ...I don't really know...

I think so (it comes from C).

Albert Holguin wrote:
it's not worth any savings in writing. Plus it makes it easier to read.

I completely agree on that.

Albert Holguin20-Jan-15 9:57

20-Jan-15 9:57

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).

CPallini20-Jan-15 10:26

[SOLVED] Re: C++ class initialization

20-Jan-15 10:26

Hehe, Lua on my side.

Vaclav_22-Jan-15 8:00

Re: [SOLVED] Re: C++ class initialization

22-Jan-15 8:00

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

CPallini22-Jan-15 9:06

Re: [REOPEN} C++ class initialization and scheme

22-Jan-15 9:06

Glad you found useful info. Anyway I still think that code is ugly.

Vaclav_23-Jan-15 6:49

Re: [REOPEN} C++ class initialization and scheme

23-Jan-15 6:49

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

Mike Nordell2-Feb-15 10:14

Mike Nordell

2-Feb-15 10:14

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<Shape*> 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 Smile | :)

)

Re: [REOPEN} C++ class initialization and scheme

Vaclav_2-Feb-15 10:57