Fluent C
by Christopher Preschern
Copyright 2023 Christopher Preschern. All rights reserved.
Printed in the United States of America.
Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.
OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.
- Acquisitions Editor: Brian Guerin
- Development Editor: Corbin Collins
- Production Editor: Jonathon Owen
- Copyeditor: Piper Editorial Consulting, LLC
- Proofreader: Justin Billing
- Indexer: Judith McConville
- Interior Designer: David Futato
- Cover Designer: Karen Montgomery
- Illustrator: Kate Dullea
- October 2022: First Edition
Revision History for the First Edition
- 2022-10-14: First Release
See https://oreilly.com/catalog/errata.csp?isbn=9781492097334 for release details.
The OReilly logo is a registered trademark of OReilly Media, Inc. Fluent C, the cover image, and related trade dress are trademarks of OReilly Media, Inc.
The views expressed in this work are those of the author and do not represent the publishers views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
978-1-492-09733-4
[LSI]
Preface
You picked up this book to move your programming skills one step forward. That is good, because youll definitely benefit from the hands-on knowledge provided in this book. If you have a lot of experience programming in C, youll learn the details of good design decisions and about their benefits and drawbacks. If you are fairly new to C programming, youll find guidance about design decisions, and youll see how these decisions are applied bit by bit to running code examples for building larger scale programs.
The book answers questions such as how to structure a C program, how to cope with error handling, or how to design flexible interfaces. As you learn more about C programming, questions often pop up, such as the following:
Should I return any error information I have?
Should I use the global variable errno
to do that?
Should I have few functions with many parameters or the other way around?
How do I build a flexible interface?
How can I build basic things like an iterator?
For object-oriented languages, most of these questions are answered to a great extent by the Gang of Four book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Prentice Hall, 1997). Design patterns provide a programmer with best practices on how objects should interact and which object owns which other kinds of objects. Also, design patterns show how such objects can be grouped together.
However, for procedural programming languages like C, most of these design patterns cannot be implemented in the way described by the Gang of Four. There are no native object-oriented mechanisms in C. It is possible to emulate inheritance or polymorphism in the C programming language, but that might not be the first choice, because such emulation makes things unfamiliar for programmers who are used to programming C and are not used to programming with object-oriented languages like C++ and using concepts like inheritance and polymorphism. Such programmers may want to stick to their native C programming style that they are used to. However, with the native C programming style, not all object-oriented design patterns guidance is usable, or at least the specific implementation of the idea presented in a design pattern is not provided for non-object-oriented programming languages.
And that is where we stand: we want to program in C, but we cannot directly use most of the knowledge documented in design patterns. This book shows how to bridge this gap and implement hands-on design knowledge for the C programming language.
Why I Wrote This Book
Let me tell you why the knowledge gathered in this book turned out to be very important for me and why such knowledge is hard to find.
In school I learned C programming as my first programming language. Just like every new C programmer, I wondered why arrays start with index 0, and I first rather randomly tried out how to place the operators *
and &
in order to finally get the C pointer magic working.
At university I learned how C syntax actually works and how it translates to bits and bytes on the hardware. With that knowledge I was able to write small programs that worked very well. However, I still had trouble understanding why longer code looked the way it did, and I certainly wouldnt have come up with solutions like the following:
typedef
struct
INTERNAL_DRIVER_STRUCT
*
DRIVER_HANDLE
;
typedef
void
(
*
DriverSend_FP
)(
char
byte
);
typedef
char
(
*
DriverReceive_FP
)();
typedef
void
(
*
DriverIOCTL_FP
)(
int
ioctl
,
void
*
context
);
struct
DriverFunctions
{
DriverSend_FP
fpSend
;
DriverReceive_FP
fpReceive
;
DriverIOCTL_FP
fpIOCTL
;
};
DRIVER_HANDLE
driverCreate
(
void
*
initArg
,
struct
DriverFunctions
f
);
void
driverDestroy
(
DRIVER_HANDLE
h
);
void
sendByte
(
DRIVER_HANDLE
h
,
char
byte
);
char
receiveByte
(
DRIVER_HANDLE
h
);
void
driverIOCTL
(
DRIVER_HANDLE
h
,
int
ioctl
,
void
*
context
);
Looking at code like that prompted many questions:
Why have function pointers in the struct
?
Why do the functions need that DRIVER_HANDLE
?
What is an IOCTL, and why would I not have separate functions instead?
Why have explicit create and destroy functions?