Category: C++

C++ Programming for Scientists

Sponsor Advertisement

My image
  • Author: Roldan Pozo and Karin Remington
  • Format: Postscript, PDF (by chapter)
  • Price: free

NIST Course on C++ Programming for Scientists.

Chapters include:

  • Lecture 1: ANSI C
  • Lecture 2: C++ as a better C
  • Lecture 3: C++ Classes and Objects
  • Lecture 4: Objects in Scientific Computing
  • Lecture 5: Inheritance & Polymorphism
  • Lecture 6: Templates, Exceptions & Observations
  • Programming Examples
  • Scientific Library Examples

http://math.nist.gov/~RPozo/c++class/

A Beginners C++

Sponsor Advertisement

  • Author: Neil Gray
  • Format: Postscript, PDF (by chapter)
  • Price: free

This book is primarily intended to be a text for the programming component in an introductory two semester computer science course (some materials are a little advanced and might postponed to later semesters). This intent shows in terms of references to “students”, “assignments” and “later studies in computing”. However, the book should be equally suited to an individual who wants to learn how to program their own personal computer. If used as a text for an introductory computer science course, the contents of this book would normally be supplemented by a variety of other materials covering everything from “ethics” to “Turing machines”.

It is assumed that you are “computer literate”. In your school or college, or at work, you will have used word processing packages, and possibly other packages like spreadsheets and data bases. Although most schools do provide at a limited introduction to programming (usually in Pascal or possibly a dialect of Basic), this text does not rely on such past experience.

Note: this text was completed in 1996. C++ has been revised quite a bit since then! When the examples were written, C++’s “namespace” feature had been defined but was not supported on available compilers; so the examples don’t use namespace. (Of course, in modern C++ they should.)

Further, the iostream library has been updated. Some of the functions have changed their signatures; some features have been added, others removed.

So, be cautious with the code – it is well a little out of date.

Chapters include:

  • Computer Hardware
  • Programs: Instructions in the Computer
  • Operating Systems
  • Why have “high-level” languages?
  • C++ development environment
  • Sequence
  • Iteration
  • Selection
  • Simple use of files
  • Functions
  • Arrays
  • Programs with functions and arrays
  • Standard algorithms
  • Tools
  • Design and documentation
  • Enum, Struct, and Union
  • Examples using structs
  • Bits and pieces
  • Beginners’ Class
  • Dynamic data and pointers
  • Collections of data
  • A World of Interacting Objects
  • Intermediate class
  • Two more “trees”
  • Templates
  • Exceptions
  • Example: Supermarket
  • The Power of Inheritance and Polymorphism
  • Reusable designs
  • Frameworks for understanding

Read: A Beginner’s C++

Taligent’s Guide to Designing Programs: Well-Mannered Object-Oriented Design in C++

Sponsor Advertisement

My image
  • Author: Taligent Inc.
  • Format: online HTML
  • Price: free

A quick overview of Object-oriented program design, with special regard for operating-system development, this book will be of the greatest interest to those developers who are working with Taligent and its operating partners, as well as many other C++ programmers who are interested in a provocative summary of good OOP techniques.

Chapters include:

  • Architectural goals
  • Object-oriented architecture
  • All interfaces are expressed through objects
  • Commonality is managed through inheritance
  • Objects are leveraged wherever possible
  • Frameworks provide the foundation
  • Let resources find you
  • Putting it all together
  • Reflect the client’s view
  • Let resources find you
  • Express all interfaces through objects
  • Preserve class invariants
  • Object-oriented design with C++
  • C++ doesn’t express full object interface
  • C++ requires definition of special member functions
  • Use type inheritance to share protocol
  • Useimplementation inheritance to override behavior
  • Design the interfaces between the base and derived classes
  • Guarantee use of derived classes as arguments
  • Implement full protocol in derived classes
  • Preserve semantics in a derived class
  • Avoid deep nesting in lightweight objects
  • Be aware of problems with virtual bases
  • Avoid multiple occurrences of a base
  • Design performance in
  • Conduct performance analysis
  • Perform controlled experiments
  • Use static objects instead of temporaries
  • Use chunky iteration for performance
  • Use cache objects
  • Object bloat
  • Lost object focus
  • Hardening of the architecture
  • Structification
  • Modulitis
  • Managers are not objects
  • Collections of functions are not objects
  • Encapsulation leakage
  • Empty base classes
  • Overeducated base classes
  • Overachieving base classes
  • Distinguish is-a from has-a relationships
  • Include copyright notices
  • Use comments
  • Include function prototypes
  • Do not use code names in filenames
  • Enclose definitions in header files
  • Include only related classes in one file
  • Use specific names
  • But use generic names for abstract base classes
  • Avoid abbreviations
  • Use special names for copy, create, and adopt routines
  • Use global names only for classes
  • Follow member function conventions
  • State explicit use of public, private, and protected
  • Use separate class definition sections
  • Avoid raw C types with dimensions
  • Use dimensionless raw C types
  • Avoid type casting
  • Silent coercion
  • Cast operators
  • Use consistent return types for assignment operators
  • State typedef class names before specifications
  • Pass variables when possible
  • Use array arguments instead of pointers
  • Limit default arguments
  • Avoid functions with unspecified arguments (…)
  • Avoid returning pointers without allocation
  • Use pointers to make multiple references
  • Use references for a one-time reference
  • Allocate storage only if you must
  • Pretend everything is a primitive
  • Use const instead of #define constants
  • Use enum instead of sets of constants
  • Use inlines instead of function macros
  • Use templates for specialized functions and classes
  • Don’t use goto
  • Avoid magic numbers
  • Avoid bit flags (& and |)
  • Avoid using arrays as local variables or object fields
  • Avoid homegrown utility classes
  • Use the Name Server
  • Hide allocation inside a class
  • Don’t assume use of a heap
  • Clarify ownership of storage in interfaces
  • Don’t use very large local variables or members
  • Avoid static objects
  • Modifiable statics in a library
  • Consider alternatives to temporary objects
  • Binary compatibility considerations
  • Adding virtual and nonvirtual functions
  • Changing a function from inline to noninline
  • Removing private nonvirtual functions not called by inlines
  • Using classes internal to your implementation
  • Use virtual functions if overrides are possible
  • Rearranging, adding, and removing private data members with restrictions
  • Inlines that call something else
  • Inline function definitions in .C files
  • Inlines for extreme efficiency
  • Don’t write inlines in declarations
  • Inlines for exporting private and protected members
  • Empty special members
  • Virtual inline functions where the type is not known
  • Define class abstractions
  • Decide now what might be overridden later
  • When to use pure virtual functions
  • Private virtual functions to control access
  • Base class constructors cannot call virtual functions
  • Destructors are not automatically virtual
  • Switch statements indicate polymorphism
  • When to use virtual assignment
  • Exceptions checklist
  • Exceptions syntax
  • Avoid interface specification
  • Perform resource recovery
  • Automatic objects
  • Passing exceptions
  • TJanitor
  • What to subclass
  • When to subclass
  • When to signal an exception
  • When to recover an exception
  • Strive for uniform distribution
  • Do not implement Hash via member functions
  • When equality does not apply
  • Equality between different types
  • Taxonomy of surrogates
  • Explicit masters
  • Handle surrogates
  • Hidden masters
  • Surrogates that view masters
  • Follow naming conventions
  • Use copy semantics wherever possible
  • Avoid storage manipulation in open code
  • Allocate subobjects on the heap for debugging
  • Synchronization techniques
  • Synchronization and problems with memory access
  • Synchronization of global and static variables
  • Shared memory between tasks
  • Shared heaps
  • Shared memory problems with const
  • Static destructors for subsystem cleanup
  • Create objects in a valid state
  • Use flattening rather than dynamic class instantiation
  • Check for self-assignment with operator=:
  • Balance overloaded operators
  • Use static members as constructors
  • Differentiate overloaded constructors
  • Hide implementation classes
  • Use nil pointer deletion
  • Issues in overloading and overriding classes
  • Control class access
  • Language and hardware assumptions
  • Safe assumptions
  • Bad assumptions
  • Synchronization
  • Portable data
  • Assembly language
  • Nonportable code
  • Template conventions
  • Include file conventions
  • General rules for implementation classes
  • The example class: an owning stack
  • Sharing the implementation through private inheritance
  • Class definitions
  • Naming conventions
  • Instance variables
  • Type-specific methods and implementation class constructors and destructors
  • Inlining the class template’s public methods
  • Class templates that inherit from specialized classes
  • An implementation sharing example
  • Sharing the implementation by delegating to a member
  • An example of delegating to a member
  • The delegation example’s naming conventions
  • The delegating-to-a-member example

http://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/WM/WM_1.html

No Bugs!: Delivering Error-Free Code in C and C++

Sponsor Advertisement

  • Author: David Thielen
  • Format: PDF
  • Price: free

Most developers know that software is inherently buggy.  And most developers also, hopefully, want to eliminate these bugs before shipping a product.  This book is written for these people.

However, writing code with no major bugs (sorry, we haven’t yet reached the point of truly bug-free code yet), is a team effort.  It takes the work of more than just the developers.  It takes testers,  managers, support personnel, and many more.  And this book is aimed at these people too.

This book is designed to solve a problem – buggy code.  Because it is aimed at the problem instead of a specific audience (ie, just developers or just testers), parts of this book may not be interesting to certain audiences.  Chapters 3 – 10 are written mainly for developers.  Chapters 11 & 12 are written mainly for testers.

Yet the book is written to be read straight through.  If you want to develop minimally buggy code, then you have to understand all of the pieces that go into getting there.  Developers need to understand the test process.  Testers need to understand what the developers will be testing on their own. Most importantly, the managers and others responsible  for insuring that the whole organization works need to understand the process.  And as important, they need to insure that the process is actually being followed.

Finally, this book is written from the Windows/DOS/PC perspective.  While most of the ideas discussed are generic to any computing platform, many of the implementations are specific to the PC.  And some of the code is specific not only to the PC, but to specific compilers (stack checking has a tendency to be that way).

If you program on a platform other than the PC, in a language other than c, you will still find this book valuable but you will also find that it leaves a lot more work for you to incorporate the ideas here.

While this is an older book, written in the Win95 era, the first 2 chapters are still very relevant to the programmers of today.

Chapters include:

  • Introduction
  • What is a bug?
  • General Principles
  • Some Basic Tricks
  • Assert the World
  • Debug Printfs
  • Watching the Stack
  • Watching the Heap
  • File I/O
  • Special Tricks for c++
  • Special Tricks for assembly language
  • The Testing Process
  • Shipping the Product
  • Useful bug-discovery tools
  • Debug Message Boxes
  • Debug Second Monitor

Get the Book: No Bugs!
Get the additional disk content

RAD Studio 2007 Help: Win32

Sponsor Advertisement

My image
  • Author: CodeGear
  • Format: archived HTML
  • Price: free

This is a zipped HTML version of Win32 section of the original help files that were included with RAD Studio 2007 and C++ Builder 2007. It is also relevant to Delphi 2007.

A CodeGear Developer Network membership is needed in order to download the .zip file. Registration is free.

Contents include:

  • Developing Reports for Your Win32 Applications
  • Debugging C++ Applications with CodeGuard Error Reporting
  • C++ Examples
  • C++ Reference
  • Win32 Developer’s Guide
  • Developing Windows Applications with Win32 Forms
  • Windows Overview
  • Developing a Windows Application
  • Procedures
  • Database Procedures
  • Interoperable Applications Procedures
  • Reporting Procedures
  • VCL Procedures
  • Web Services Procedures
  • WebSnap Procedures
  • Developing Web Applications with WebSnap
  • Win32 Web Applications Overview
  • Building a WebSnap Application
  • Developing Web Services with Win32 Applications
  • Developing Database Applications for the Win32 Platform
  • dbGo Overview
  • dbExpress Components
  • BDE Overview
  • Getting Started with InterBase Express
  • Developing Applications with VCL Components
  • Developing COM Applications

http://cc.embarcadero.com/Item/24686