#include <math.h>: sin(), log(), floor(), ceil(),
etc. // mathematical functions
#include <stdbool.h>: bool, true, false, etc. //
boolean types
#include <stdint.h>: int16_t, int32_t, int64_t, etc. // integral types
// etc.
<OSTypes.h>, which include SInt16 and UInt32 instead of int16_t and uint32_t,
respectively. Others are completely different implementations, such
as the ANSI Standard bool versions Apple's boolean . In this case, you must
convert return values back and forth between Apple API calls and
Standard C Library calls.
malloc() and free() are preferred over NewPtr() and DisposePtr(). Likewise, memcpy() and memmove() are preferred over BlockMove() and BlockMoveData(). However, sometimes you may require the
Apple equivalents for performance or functionality not available from
the ANSI functions. For example, the Standard fopen() would be insufficient if you require your
file to have a resource fork. Therefore, always be mindful of the
requirements of your project prior to making these decisions.
The ANSI C Library within C++
#include <xxxx.h> are deprecated in
C++ and replaced by those of the form #include <cxxxx>. Furthermore, C
Library items in C++ are inside the std namespace and are not available globally. Thus, C Library items
require either a std:: prefix
or a declaration of using namespace std; For example, the C snippet:
cout & Other <iostream> Classescout, which is an instantiation of
the ostream object. The C++ iostream classes are functional
replacements for the clunky <stdio.h> functions from C. Rather
than the cumbersome C snippet:
float radius;
double pi = 3.14159;
printf("Enter
the radius of a circle:\n");
scanf("%f", &radius);
if (radius <= 0.0)
fprintf(stderr, "Improper value returned for radius:
%2.3f", radius);
string.
It has basic constructors accepting standard char
*'s as well as other strings,
and you may wish to create your own utility functions to convert to
and from this type, particularly if you are dealing with other string
types, such as MFC's CString, PowerPlant's LString or Mac OS X's CFString.
There is also a wide character equivalent class wstring for those dealing with Unicode.
string class, there are a number of other extremely useful cross-platform
ANSI classes provided by C++ which you will wish to use when working
between multiple frameworks. One is auto_ptr<> , which is a templated smart pointer class. To use it, one
merely allocates an object with the traditional new keyword and
assign it to an auto_ptr<>. The auto_ptr<> class' destructor
will delete the memory associated with it, so that you need not be
concerned with chasing pointers. auto_ptr<>'s
can even pass ownership around when you wish them to.
auto_ptr<>'s point
only to one object at a time. When handling arrays of data, the ANSI
Standard Library has a number of objects to choose from. For
numerical data arrays, the valarray<> templated type is
perhaps the best, as it allows the array of data to be operated upon
as if it were a single value. For example, if val1 and val2 are two valarray's then val3
=val1 *val2 would be an array
of the products of the entries of val1 and val2 for each
index. All manner of arithmetic can be performed on valarray<>,
including standard math functions: val2 = sin(val1) creates a valarray<> which is a collection of the results of applying the sin() function upon each element of val1. "Slices" of valarray<>'s can also be
extracted. valarray<>'s are highly
optimized for mathematical calculations and are best suited for
numerical types.
complex data type. Unfortunately (as
briefly mentioned in last month's column), the complex data type in the ANSI C++ Standard conflicts with the one defined in
the ANSI C99 Standard. In C, complex is a suffix modifier to floating point data types, declared as such: double complex z; In C++ on the other hand, complex<> is a templated type
and is declared like so: complex<double> z; Either version is will likely fit your needs and it is merely a
matter of preference which to use.
STL Containers
Standard Template Library,
or STL. STL was designed by Alexander Stepanov in an attempt to create "uncompromisingly
generic algorithms". It was
implemented in other languages, such as Ada, prior to being ported to
C++, which happened in 1994. Initially, STL evolved independently from the C++ Standard Library, which
is why it is very different from the rest of C++. For example, while
most of the Library follows standard object oriented practices of
inheritance to absorb common functionality, STL objects are very loosely connected and share very little in the way
of an inheritance hierarchy. Despite this major difference in design
philosophy, the ANSI committee voted to accept most of STL into the Standard Library.
STL consists of these
components: Containers, Iterators, Algorithms & Functions, and
Adapters. Containers are different data structures used to hold
objects, such as vector (a one dimensional array), list (a doubly-linked list), queue (a FIFO model), stack (a LIFO model), deque (a
double-ended queue), and others. iterator's
are generalizations of pointers, including input iterators, output
iterators, forward iterators, bidirectional iterators, and more. (Not
all iterators are available to all containers.) Algorithms involve
optimized sorting, searching, swapping, etc. The important point here
is that algorithms are container-independent.
STL is designed for
performance, not for object design. This is why there is no common
base class amongst the containers and why each container has its own
iterator type. No special range checking is done, as target
performance is the priority.
STL has virtually all the container classes that one would need for an
advanced project. The only notable piece missing is a sparse array
class. In a cross-platform project, you would do very well in using STL objects as the universal underlying model,
translating into framework specific containers only when necessary.
Coming Up: With this 16th installment, we will stop here in our cross-platform
series and move onto more Macintosh-specific areas of interest. I
hope you have enjoyed reading this series as much as I have in
writing it. With Mac OS X 10.5 Leopard just around the corner, there
are a number of exciting new topics that we will be delving into in
the coming months. Please feel free to send your feedback and suggest
and topics for the future. See you in 30!
