标签: functions

Jack Ganssle posted a blog about a book called Understanding and Using C Pointers by Richard M. Reese. I'm a hardware design engineer by trade. The best you can say is that I dabble in the software side of things. The subtleties of pointers have long confused me, so I decided to purchase this book.   Personally, I think this book is well worth the price if you want to move beyond the "training wheel" stage of C programming. I learned a lot. Unfortunately, I didn’t learn as much as I thought I'd learned, because I cannot wrap my brain around a programming problem.   Here's the deal. This all pertains to my current BADASS Display project, which -- as you will doubtless recall -- is going to feature a 16x16 array of tri-colored LEDs as illustrated below.     I'm actually using Adafruit's NeoPixel Strips for this little beauty, with the control of the display being performed by an Arduino Mega microcontroller development board.   I'm planning on using 16 NeoPixel strips, each containing 16 pixels, and each implementing one of the vertical columns in the array. The idea is to take an audio stream from my iPad, split out its spectral components into sixteen frequency "buckets," and then present the results in spectrum-analyzer-form on my display. (I'm still pondering how to extract the frequency spectrum data from the audio stream, but that's a problem for another day.)   Purely for the sake of discussion, let's assume that my NeoPixel strips are named "strip ," "strip ,"… "strip ." Meanwhile, the lowest LED (i.e., the one nearest to the bottom of the array) on each strip is numbered 0, while the highest LED is numbered 15. Let's further assume that whatever is processing my audio stream, it generates a series of sixteen five-bit values called "bucket ," "bucket ,"… "bucket ." Each of these five-bit values represents the current amplitude associated with that bucket, from 00000 2 (no LEDS lit) to 10000 2 (all LEDs lit).   Actually, my previous statement is not strictly true, because these five-bit values actually represent the number of the highest (vertically speaking) LED being lit. The way in which we subsequently display this information depends on what we wish to do -- we could display a solid bar of LEDs from LED 0 up to and including the LED in question, or we could simply light up this topmost LED, or… the list goes on.   But we are wandering off into the weeds. What I would ideally like to do is to have a function called "lightStrip()" that I can call from the main body of my program. Perhaps something like the following:     But then we come to the way in which the folks at Adafruit have created their libraries and instantiate their NeoPixel strips. I think this is done in C++, but -- thankfully -- the gory details are hidden from me. A stripped-down version of the instantiation might look something like the following:     The first parameter is the number of pixels in your strip (16 in this case), while the second parameter is the number of the digital I/O pin you wish to use to drive this strip (1 in this case).   Later on, in the body of your code, you can use calls like the following:     In the case of the "strip.setPixelColor()" function call, "i" is the number of the pixel (ranging from 0 to 15 in our case) whose color you wish to specify using three eight-bit values for the red, green, and blue channels. The interesting thing is that the "strip.setPixelColor()" function doesn’t actually drive the strip itself. It just stores the new color values in an array in memory. This means you can specify the color values of any and all elements in the strip without actually writing to the strip each time.   Once we have all of our ducks in a row, as it were, we use the "strip.show()" function to upload all of the color values into the strip. Now, we can instantiate multiple strips called "strip0," "strip1," "strip2," and so forth if we wish. But this is where I grind to a halt. How can I pass these different strips into my "lightStrip()" function? I know that in regular C it's possible to pass a pointer to one function as an argument into another function, but how does that relate to what I'm talking about here? All I can say is that any thoughts you care to share will be very gratefully received.

Several weeks ago I read Jack Ganssle's blog about a book called Understanding and Using C Pointers by Richard M. Reese. I'm a hardware design engineer by trade. The best you can say is that I dabble in the software side of things. The subtleties of pointers have long confused me, so I decided to purchase this book.   Personally, I think this book is well worth the price if you want to move beyond the "training wheel" stage of C programming. I learned a lot. Unfortunately, I didn’t learn as much as I thought I'd learned, because I cannot wrap my brain around a programming problem.   Here's the deal. This all pertains to my current BADASS Display project, which -- as you will doubtless recall -- is going to feature a 16x16 array of tri-colored LEDs as illustrated below.     I'm actually using Adafruit's NeoPixel Strips for this little beauty, with the control of the display being performed by an Arduino Mega microcontroller development board.   I'm planning on using 16 NeoPixel strips, each containing 16 pixels, and each implementing one of the vertical columns in the array. The idea is to take an audio stream from my iPad, split out its spectral components into sixteen frequency "buckets," and then present the results in spectrum-analyzer-form on my display. (I'm still pondering how to extract the frequency spectrum data from the audio stream, but that's a problem for another day.)   Purely for the sake of discussion, let's assume that my NeoPixel strips are named "strip ," "strip ,"… "strip ." Meanwhile, the lowest LED (i.e., the one nearest to the bottom of the array) on each strip is numbered 0, while the highest LED is numbered 15. Let's further assume that whatever is processing my audio stream, it generates a series of sixteen five-bit values called "bucket ," "bucket ,"… "bucket ." Each of these five-bit values represents the current amplitude associated with that bucket, from 00000 2 (no LEDS lit) to 10000 2 (all LEDs lit).   Actually, my previous statement is not strictly true, because these five-bit values actually represent the number of the highest (vertically speaking) LED being lit. The way in which we subsequently display this information depends on what we wish to do -- we could display a solid bar of LEDs from LED 0 up to and including the LED in question, or we could simply light up this topmost LED, or… the list goes on.   But we are wandering off into the weeds. What I would ideally like to do is to have a function called "lightStrip()" that I can call from the main body of my program. Perhaps something like the following:     But then we come to the way in which the folks at Adafruit have created their libraries and instantiate their NeoPixel strips. I think this is done in C++, but -- thankfully -- the gory details are hidden from me. A stripped-down version of the instantiation might look something like the following:     The first parameter is the number of pixels in your strip (16 in this case), while the second parameter is the number of the digital I/O pin you wish to use to drive this strip (1 in this case).   Later on, in the body of your code, you can use calls like the following:     In the case of the "strip.setPixelColor()" function call, "i" is the number of the pixel (ranging from 0 to 15 in our case) whose color you wish to specify using three eight-bit values for the red, green, and blue channels. The interesting thing is that the "strip.setPixelColor()" function doesn’t actually drive the strip itself. It just stores the new color values in an array in memory. This means you can specify the color values of any and all elements in the strip without actually writing to the strip each time.   Once we have all of our ducks in a row, as it were, we use the "strip.show()" function to upload all of the color values into the strip. Now, we can instantiate multiple strips called "strip0," "strip1," "strip2," and so forth if we wish. But this is where I grind to a halt. How can I pass these different strips into my "lightStrip()" function? I know that in regular C it's possible to pass a pointer to one function as an argument into another function, but how does that relate to what I'm talking about here? All I can say is that any thoughts you care to share will be very gratefully received.

In my previous blogs, I've been explaining how virtual functions behave in C++ and how you can obtain similar behaviour in C. A few months ago, I showed how to emulate a polymorphic C++ class (a class with at least one virtual function) as a C structure that has an additional member commonly called a vptr (VEE-pointer). 1 The vptr points to a table of function pointers called a vtbl (VEE-table). The past two months, I showed how to initialise the vptr in base and derived class objects. 2, 3 This month, I'll explain the concept of pure virtual functions in C++. Although C doesn't provide native support for the concept, it's still applicable in C. As in my prior articles, my sample classes represent an assortment of two-dimensional geometric shapes such as circle, rectangle, and triangle, all derived from a common base class called shape. The type hierarchy looks like: The C++ definition for the shape base class looks in part like: class shape { shape(color o, color f); // constructor virtual double area() const; virtual double perimeter() const; ~~~ private: color outline, fill; }; and the definition for the circle class (derived from shape) looks like: class circle: public shape { public: circle(double r, color o, color f); // constructor virtual double area() const; virtual double perimeter() const; ~~~ private: double radius; }; The definition for the circle's area function is as you should expect: double circle::area() const { return pi * radius * radius; } The rectangle class derived from shape has members height and width instead of radius. The rectangle's area function is also as you should expect: double rectangle::area() const { return height * width; } What does shape's area function look like? For that matter, what's a shape that's neither a circle, nor a rectangle, nor any other type derived from base class shape? Remember, the shape class represents a common interface for all shapes. For example, you can define a C++ function: double volume(shape const *s, height h) { return s-area() * h; } which computes the volume of a solid with a base whose shape is s and whose height is h. You can then write: v = volume(c, 4.2); to compute the volume of a cylinder whose base is circle c and whose height is 4.2. Alternatively, you can define volume's parameter s as a reference instead of a pointer, as in: double volume(shape const s, height h) { return s.area() * h; } Then you don't need to take the address of volume's first argument explicitly, as in: v = volume(c, 4.2); You get the same result whether you use a pointer or a reference. With the hierarchy of shapes, it's meaningful to use a "pointer to shape" or a "reference to shape" to refer to a circle, rectangle, or triangle, or possibly some other shape that you might derive from the base class shape. It's also meaningful to have a shape object that's the base class part of some derived class object. However, it's not meaningful to have a shape object that's just a shape. A meaningful shape has a radius, or a height and a width, or some other attributes that define its physical extent. A shape that's just a shape has no such attributes. Nonetheless, declaring an area function in the shape class is a meaningful thing to do. That function declaration becomes part of the interface for every shape derived from the base class shape. That is, it's a way of forcing derived classes such as circle and rectangle to have an area function. Although declaring an area function for shape is meaningful, defining it is not because the base class lacks the attributes it needs to compute its area. Pure virtual functions provide a way to avoid defining such functions that have no meaningful implementation. In C++, you declare a virtual function as a pure virtual function simply by placing = 0 at the end of the function heading in the function declaration. For example, in: class shape { public: shape(color o, color f); // constructor virtual double area() const = 0; virtual double perimeter() const = 0; ~~~ private: color outline, fill; }; the area and perimeter functions are now pure virtual functions. You need not define them for class shape. If shape's area and perimeter functions are undefined, what happens when you try to call them? I'll explain that in my next column. I'll also look at what you have to do to approximate the same behaviour in C. Endnotes: 1. Saks, Dan, " Implementing Virtual functions in C ," Eetindia.co.in, August 14, 2012. 2. Saks, Dan, " How to properly initialise polymorphic objects ," Eetindia.co.in, October 25, 2012. 3. Saks, Dan, " Learn to Initialise derived polymorphic objects ," Eetindia.co.in, November 22, 2012.  

I have previously discussed polymorphic types and virtual functions. I showed how to implement virtual functions in C in a way that generates machine code similar to what you get with virtual function in C++.More specifically, I showed how to emulate a polymorphic C++ class (a class with at least one virtual function) as a C structure that has an additional member commonly called a vptr (VEE-pointer). The vptr points to a table of function pointers called a vtbl (VEE-table). Last month, I showed how to initialise the vptr in base class objects . This month, I'll look at initializing derived class objects. My sample classes represent an assortment of two-dimensional geometric shapes such as circle, rectangle, and triangle, all derived from a common base class called shape. The C++ definition for the shape base class looks in part like: class shape { public: shape(color o, color f); // constructor virtual double area() const; virtual double perimeter() const; private: color outline, fill; }; In C, the comparable declarations look like: // shape.h—a C base class for shapes #ifndef SHAPE_H_INCLUDED #define SHAPE_H_INCLUDED typedef struct shape shape; typedef struct shape_vtbl shape_vtbl; struct shape_vtbl { double (*area)(shape const *s); double (*perimeter)(shape const *s); }; struct shape { shape_vtbl *vptr; color outline, fill; }; void shape_construct(shape *s, color o, color f); double shape_area(shape const *s); double shape_perimeter(shape const *s); #endif As I showed last month, you can define the shape vtbl object in a source file that also defines the member functions of the shape "class": // shape.c—a C base class for shapes #include "shape.h" ~~~ static shape_vtbl the_shape_vtbl = { shape_area, shape_perimeter }; void shape_construct(shape *s, color o, color f) { s-vptr = the_shape_vtbl; s-outline = o; s-fill = f; } In C++, the definition for a circle class derived from shape looks like: class circle: public shape { public: circle(double r, color o, color f); // constructor virtual double area() const; virtual double perimeter() const; ~~~ private: double radius; }; Derivation defines an "is a" or "is a kind of" relationship between the derived and base class. That is, it lets you substitute a derived class object, such as a circle or rectangle, for a base class shape object. For example, given a C++ function such as: void f(shape *p) { ~~~ p-perimeter(); // virtual call to shape's perimeter ~~~ } you can pass it a derived class object, as in: circle c; ~~~ f(c); // pass a circle as a shape and it computes the circle's perimeter correctly. With a little more effort, you can emulate this behaviour in C. In C, you have to explicitly mention the vptr in virtual function calls, as in: void f(shape *p) { ~~~ p-vptr-perimeter(p); virtual call to shape's perimeter ~~~ } You also need an explicit cast to convert a "pointer to derived" into "pointer to base", as in: circle c; ~~~ f((shape *)c); // pass a circle as a shape This substitution works (f will compute the circle's perimeter correctly) only if the vptr has the same offset in the derived class object as it does in a base class object. The easiest way to satisfy this requirement is to implement each derived class type in C as a structure whose first member has the base class type, as in: // circle.h – a C class for circle derived from shape #ifndef CIRCLE_H_INCLUDED #define CIRCLE_H_INCLUDED #include "shape.h" typedef struct circle circle; struct circle { shape base; // the base class subobject double radius; }; void circle_construct(circle *c, double r, color o, color f); #endif The base member of the circle structure above includes all the members inherited from the shape base class, including vptr. The definition for the circle_construct function appears, along with the circle vtbl object, in a separate source file: // circle.c—circle implementation ~~~ #include "circle.h" double circle_area(circle const *c) { return PI * c-radius * c-radius; } double circle_perimeter(circle const *c) { return 2 * PI * c-radius; } typedef struct circle_vtbl circle_vtbl; struct circle_vtbl { double (*area)(circle const *); double (*perimeter)(circle const *); }; static circle_vtbl the_circle_vtbl = { circle_area, circle_perimeter }; void circle_construct(circle *c, double r, color o, color f) { shape_construct(c-base, o, f); c-base.vptr = (shape_vtbl *)the_circle_vtbl; c-radius = r; } The circle_construct function implements behaviour comparable to a C++ constructor. It calls the shape_construct function to initialise the base class part. However, shape_construct sets the vptr to point to shape's vtbl, which is correct for the base class shape, but not for the derived class circle. Thus, circle_construct needs to reassign the vptr to point to circle's vtbl. This assignment requires a cast because circle_vtbl isn't exactly the same type as shape_vtbl. The two structures have the same memory layout, but the corresponding pointers in the different structures point to functions with slightly different types. Thus, the derived class constructor contains two assignments to the vptr. The second assignment completely overwrites the value assigned by the first. Ideally, the compiler will "optimise away" the first assignment. However, the compiler can do this optimisation only if it can see both assignments in the context of the derived class constructor, which it can do only if the base class constructor is an inline function. If you define the shape_construct function as inline, you should move the function definition to the shape.h header file. When you do that, you must also give the_shape_vtbl external linkage by removing the keyword static from its definition, as in: // shape.c—a C base class for shapes ~~~ shape_vtbl the_shape_vtbl = { // used to be static shape_area, shape_perimeter }; ~~~ If your C compiler supports the inline keyword (from C99), then the shape.h header would look in part like: // shape.h—a C base class for shapes ~~~ typedef struct shape shape; ~~~ typedef struct shape_vtbl shape_vtbl; struct shape_vtbl { double (*area)(shape const *s); double (*perimeter)(shape const *s); }; extern shape_vtbl the_shape_vtbl; struct shape { shape_vtbl *vptr; color outline, fill; }; inline void shape_construct(shape *s, color o, color f) { s-vptr = the_shape_vtbl; s-outline = o; s-fill = f; } If your compiler doesn't support the keyword inline, then you can implement the constructor as a macro: #define shape_construct(s, o, f) ( \ (s)-vptr = the_shape_vtbl, \ (s)-outline = (o), \ (s)-fill = (f) \ ) Either way, a compiler with a decent optimiser should eliminate the redundant assignment to the vptr. Once again, you don't have to worry about any of this in C++. With C++, the compiler automatically generates code to initialise the vptr properly.  

Last month, I explained how C++ compilers typically implement virtual functions by illustrating how using virtual functions affects the storage layout for objects ( Setting storage layout for polymorphic objects ). This month, I'll continue by showing how to implement virtual functions in C in a way that generates machine code very similar to what you get from C++. As before, my sample classes represent an assortment of two-dimensional geometric shapes such as circle, rectangle, and triangle, all derived from a common base class called shape. In C++, the definition for the base class shape looks like: class shape { public: shape(); // constructor virtual double area() const; virtual double perimeter() const; private: coordinates position; color outline, fill; }; The area and perimeter member functions are virtual. A class, such as shape, with a least one virtual function is a polymorphic type . C++ compilers typically add a hidden pointer to each polymorphic type. That pointer is commonly called a vptr and it points to a table of function pointers called a vtbl . You can implement a polymorphic shape type in C using the following declarations: // shape.h—base class for shapes #ifndef SHAPE_H_INCLUDED #define SHAPE_H_INCLUDED typedef struct shape shape; typedef struct shape_vtbl shape_vtbl; struct shape_vtbl { double (*area)(shape const *s); double (*perimeter)(shape const *s); }; struct shape { shape_vtbl *vptr; coordinates position; color outline, fill; }; #endif A class derived from a polymorphic base class will be polymorphic as well, and it inherits the base class's vptr. The vptr must have the same offset in the base class subobject (the base class portion) of a derived class object as it does in a base class object. In C++, the definition for a circle class derived from shape looks like: class circle: public shape { public: circle(double r); // constructor virtual double area() const; virtual double perimeter() const; private: double radius; }; In C, the declarations for a polymorphic circle type look like: // circle.h – circle derived from shape #ifndef CIRCLE_H_INCLUDED #define CIRCLE_H_INCLUDED #include "shape.h" typedef struct circle circle; struct circle { shape base; // the base class sub-object double radius; }; void circle_construct(circle *c, double r); #endif The base member of the circle structure above includes all the members inherited from the shape base class, including vptr. The circle_construct function initializes a circle, including its vptr. I'll cover the details of initializing the vptr in an upcoming column. As I showed last month, the C++ definition for a rectangle class derived from shape looks a lot like the definition for circle: class rectangle: public shape { public: rectangle(double h, double w); virtual double area() const; virtual double perimeter() const; private: double height, width; }; Similarly, the C declarations for a polymorphic rectangle type look a lot like the declarations for circle: // rectangle.h—rectangle interface #ifndef RECTANGLE_H_INCLUDED #define RECTANGLE_H_INCLUDED #include "shape.h" typedef struct rectangle rectangle; struct rectangle { shape base; // the base class sub-object double height, width; }; void rectangle_construct(rectangle *t, double h, double w); #endif In C++, a call to the virtual area function applied to a shape looks exactly like a non-virtual call, as in: shape *s; ~~~ s-area(); If s points to a circle (the dynamic type of *s is circle), then the call above calls circle::area. If s points to a rectangle, then the call above calls rectangle::area. C doesn't provide explicit support for classes with member functions. In C, you simply use ordinary functions to emulate member functions. For example: circle_area(c); applies the circle_area function to circle c. You get the same runtime performance as a C++ member function call, but without any compile-time checking to enforce access control. In C, virtual function calls look unlike any other kind of function call. For example, a call to the virtual area function applied to a shape looks like: shape *s; ~~~ s-vptr-area(s); In this case, if s points to a circle (the dynamic type of *s is circle), then the call above calls circle_area. If s points to a rectangle, then the call above calls rectangle_area. As I hinted earlier, this works only if you initialise the vptr properly, something I'll cover in an upcoming column.