Embedded Systems Design - March 2008 - (Page 10)

0308esd.p09to14 2/13/08 7:42 PM Page 10 programming pointers For object declarations that are valid in both C and C++, the rule for deciding when an object declaration is also a deﬁnition is—surprisingly—simpler in C++ than in C. In C++, an object declaration is also a deﬁnition unless it contains an extern speciﬁer and no initializer. For example, all of the following object declarations are also deﬁnitions in C++: int i; static int j; extern int k = 0; // deﬁnition // deﬁnition // deﬁnition // foo.c #include “foo.h” int foo(int n) { } to ensure that the function deﬁned in the source is working with the same declaration(s) as in the header. After preprocessing, the translation unit contains: int foo(int n); int foo(int n) { } // from the header They are deﬁnitions whether they appear at ﬁle scope, namespace scope, or block scope. The following object declaration is not a deﬁnition: extern int m; // non-deﬁning declaration Again, the rule I just cited is how C++ distinguishes object definitions from other object declarations. The cor- From the compiler’s viewpoint, these are two declarations for the same function in the same scope. They refer to the same function because they have linkage. responding rule in C is complicated by the added presence of these things called tentative definitions. A tentative definition is an object declaration that might also be a definition, or it might not, depending on the presence of other definitions. In truth, the previous declarations for i and j are tentative definitions in C. C++ doesn’t recognize tentative definitions, so some combinations of object declarations that are valid in C aren’t valid in C++. The C++ rule for distinguishing object deﬁnitions from other object declarations works equally well in C as in C++. If you follow that rule in C, you won’t go wrong. THE CONCEPT OF LINKAGE In some cases, C and C++ let you declare the same entity more than once, in different translation units, different scopes of the same translation unit, or even in the same scope. For example, the common C technique for packaging a library function is to declare the function in a header: // foo.h int foo(int n); which declares the function twice. The second declaration is also the deﬁnition. From the compiler’s viewpoint, these are two declarations for the same function in the same scope. They refer to the same function because they have linkage. C and C++ provide for three levels of linkage: • A name with no linkage denotes an entity that can’t be referenced via names from anywhere else. • A name with internal linkage denotes an entity that can • be referenced via names declared in the same scope or in other scopes of the same translation unit. A name with external linkage denotes an entity that can be referenced via names declared in the same scope or in other scopes of the same translation unit (just as with internal linkage), or additionally in other translation units. Both function and object names can have either internal or external linkage. Object names can also have no linkage. Beyond that, all other names in C have no linkage. In contrast, other names in C++ can have external linkage, including names for classes, enumeration types and constants, namespaces, references, and templates. References and function templates can also have internal linkage. LINKAGE FOR FUNCTIONS A function declared without a storage class speciﬁer normally has external linkage by default. Placing the keyword extern in a function declaration such as: extern int foo(int n); and deﬁne the function in a corresponding source ﬁle. That source ﬁle should include the header, as in: has no effect. With or without the extern speciﬁer, you 10 MARCH 2008 | embedded systems design | www.embedded.com http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - March 2008

Embedded Systems Design - March 2008 Contents #Include Programming Pointers Designing DSP-based Motor Control Using Fuzzy Logic Hardware/Software Verification Enters the Atomic Age Efficient CRC Calculation with Minimal Memory Footprint Programming Your Own Microcontroller Advertising Index Break Points Marketplace

Embedded Systems Design - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.