[10] Constructors
(Part of C++ FAQ Lite, Copyright © 1991-2001, Marshall Cline, cline@parashift.com)

FAQs in section [10]:

[10.1] What's the deal with constructors?

Constructors build objects from dust.

Constructors are like "init functions". They turn a pile of arbitrary bits into a living object. Minimally they initialize internally used fields. They may also allocate resources (memory, files, semaphores, sockets, etc).

"ctor" is a typical abbreviation for constructor.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.2] Is there any difference between List x; and List x();?

A big difference!

Suppose that List is the name of some class. Then function f() declares a local List object called x:

 void f()
 {
   List x;     // Local object named x (of class List)
   // ...
 }

But function g() declares a function called x() that returns a List:

 void g()
 {
   List x();   // Function named x (that returns a List)
   // ...
 }

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.3] How can I make a constructor call another constructor as a primitive?

No way.

Dragons be here: if you call another constructor, the compiler initializes a temporary local object; it does not initialize this object. You can combine both constructors by using a default parameter, or you can share their common code in a private init() member function.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.4] Is the default constructor for Fred always Fred::Fred()?

No. A "default constructor" is a constructor that can be called with no arguments. Thus a constructor that takes no arguments is certainly a default constructor:

 class Fred {
 public:
   Fred();   // Default constructor: can be called with no args
   // ...
 };

However it is possible (and even likely) that a default constructor can take arguments, provided they are given default values:

 class Fred {
 public:
   Fred(int i=3, int j=5);   // Default constructor: can be called with no args
   // ...
 };

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.5] Which constructor gets called when I create an array of Fred objects?

Fred's default constructor (except as discussed below).

There is no way to tell the compiler to call a different constructor (except as discussed below). If your class Fred doesn't have a default constructor, attempting to create an array of Fred objects is trapped as an error at compile time.

 class Fred {
 public:
   Fred(int i, int j);
   // ... assume there is no default constructor in class Fred ...
 };
 
 int main()
 {
   Fred a[10];               // ERROR: Fred doesn't have a default constructor
   Fred* p = new Fred[10];   // ERROR: Fred doesn't have a default constructor
 }

However if you are constructing an object of the standard std::vector<Fred> rather than an array of Fred (which you probably should be doing anyway since arrays are evil), you don't have to have a default constructor in class Fred, since you can give the std::vector a Fred object to be used to initialize the elements:

 #include <vector>
 
 int main()
 {
   std::vector<Fred> a(10, Fred(5,7));
   // The 10 Fred objects in std::vector a will be initialized with Fred(5,7).
   // ...
 }

Even though you ought to use a std::vector rather than an array, there are times when an array might be the right thing to do, and for those, there is the "explicit initialization of arrays" syntax. Here's how it looks:

 class Fred {
 public:
   Fred(int i, int j);
   // ... assume there is no default constructor in class Fred ...
 };
 
 int main()
 {
   Fred a[10] = {
     Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7),
     Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7), Fred(5,7)
   };
 
   // The 10 Fred objects in array a will be initialized with Fred(5,7).
   // ...
 }

Of course you don't have to do Fred(5,7) for every entry — you can put in any numbers you want, even parameters or other variables. The point is that this syntax is (a) doable but (b) not as nice as the std::vector syntax. Remember this: arrays are evil — unless there is a compelling reason to use an array, use a std::vector instead.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.6] Should my constructors use "initialization lists" or "assignment"? UPDATED!

[Recently rewrote (in 4/01) and reworded various things thanks to Stan Brown (in 8/01). Click here to go to the next FAQ in the "chain" of recent changes.]

Initialization lists. In fact, constructors should initialize all member objects in the initialization list.

For example, this constructor initializes member object x_ using an initialization list: Fred::Fred() : x_(whatever) { }. The most common benefit of doing this is improved performance. For example, if the expression whatever is the same as member variable x_, the result of the whatever expression is constructed directly inside x_ — the compiler does not make a separate copy of the object. Even if the types are not the same, the compiler is usually able to do a better job with initialization lists than with assignments.

The other (inefficient) way to build constructors is via assignment, such as: Fred::Fred() { x_ = whatever; }. In this case the expression whatever causes a separate, temporary object to be created, and this temporary object is passed into the x_ object's assignment operator. Then that temporary object is destructed at the ;. That's inefficient.

As if that wasn't bad enough, there's another source of inefficiency when using assignment in a constructor: the member object will get fully constructed by its default constructor, and this might, for example, allocate some default amount of memory or open some default file. All this work could be for naught if the whatever expression and/or assignment operator causes the object to close that file and/or release that memory (e.g., if the default constructor didn't allocate a large enough pool of memory or if it opened the wrong file).

Conclusion: All other things being equal, your code will run faster if you use initialization lists rather than assignment.

Note: There is no performance difference if the type of x_ is some built-in/intrinsic type, such as int or char* or float. But even in these cases, my personal preference is to set those data members in the initialization list rather than via assignment for consistency.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.7] Should you use the this pointer in the constructor? UPDATED!

[Recently rewrote because of a suggestion from Perry Rapp (in 4/01) and wordsmithing thanks to Stan Brown (in 8/01). Click here to go to the next FAQ in the "chain" of recent changes.]

Some people feel you should not use the this pointer in a constructor because the object is not fully formed yet. However you can use this in the constructor (in the {body} and even in the initialization list) if you are careful.

Here is something that always works: the {body} of a constructor (or a function called from the constructor) can reliably access the data members declared in a base class and/or the data members declared in the constructor's own class. This is because all those data members are guaranteed to have been fully constructed by the time the constructor's {body} starts executing.

Here is something that never works: the {body} of a constructor (or a function called from the constructor) cannot get down to a derived class by calling a virtual member function that is overridden in the derived class. If your goal was to get to the overridden function in the derived class, you won't get what you want. Note that you won't get to the override in the derived class independent of how you call the virtual member function: explicitly using the this pointer (e.g., this->method()), implicitly using the this pointer (e.g., method()), or even calling some other function that calls the virtual member function on your this object. The bottom line is this: even if the caller is constructing an object of a derived class, during the constructor of the base class, your object is not yet of that derived class. You have been warned.

Here is something that sometimes works: if you pass any of the data members in this object to another data member's initializer, you must make sure that the other data member has already been initialized. The good news is that you can determine whether the other data member has (or has not) been initialized using some straightforward language rules that are independent of the particular compiler you're using. The bad news it that you have to know those language rules (e.g., base class sub-objects are initialized first (look up the order if you have multiple and/or virtual inheritance!), then data members defined in the class are initialized in the order in which they appear in the class declaration). If you don't know these rules, then don't pass any data member from the this object (regardless of whether or not you explicitly use the this keyword) to any other data member's initializer! And if you do know the rules, please be careful.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.8] What is the "Named Constructor Idiom"?

A technique that provides more intuitive and/or safer construction operations for users of your class.

The problem is that constructors always have the same name as the class. Therefore the only way to differentiate between the various constructors of a class is by the parameter list. But if there are lots of constructors, the differences between them become somewhat subtle and error prone.

With the Named Constructor Idiom, you declare all the class's constructors in the private or protected sections, and you provide public static methods that return an object. These static methods are the so-called "Named Constructors." In general there is one such static method for each different way to construct an object.

For example, suppose we are building a Point class that represents a position on the X-Y plane. Turns out there are two common ways to specify a 2-space coordinate: rectangular coordinates (X+Y), polar coordinates (Radius+Angle). (Don't worry if you can't remember these; the point isn't the particulars of coordinate systems; the point is that there are several ways to create a Point object.) Unfortunately the parameters for these two coordinate systems are the same: two floats. This would create an ambiguity error in the overloaded constructors:

 class Point {
 public:
   Point(float x, float y);     // Rectangular coordinates
   Point(float r, float a);     // Polar coordinates (radius and angle)
   // ERROR: Overload is Ambiguous: Point::Point(float,float)
 };
 
 int main()
 {
   Point p = Point(5.7, 1.2);   // Ambiguous: Which coordinate system?
 }

One way to solve this ambiguity is to use the Named Constructor Idiom:

 #include <cmath>               // To get sin() and cos()
 
 class Point {
 public:
   static Point rectangular(float x, float y);      // Rectangular coord's
   static Point polar(float radius, float angle);   // Polar coordinates
   // These static methods are the so-called "named constructors"
   // ...
 private:
   Point(float x, float y);     // Rectangular coordinates
   float x_, y_;
 };
 
 inline Point::Point(float x, float y)
 : x_(x), y_(y) { }
 
 inline Point Point::rectangular(float x, float y)
 { return Point(x, y); }
 
 inline Point Point::polar(float radius, float angle)
 { return Point(radius*cos(angle), radius*sin(angle)); }

Now the users of Point have a clear and unambiguous syntax for creating Points in either coordinate system:

 int main()
 {
   Point p1 = Point::rectangular(5.7, 1.2);   // Obviously rectangular
   Point p2 = Point::polar(5.7, 1.2);         // Obviously polar
 }

Make sure your constructors are in the protected section if you expect Point to have derived classes.

The Named Constructor Idiom can also be used to make sure your objects are always created via new.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.9] Why can't I initialize my static member data in my constructor's initialization list? UPDATED!

[Recently added a "," in the initialization list thanks to Yaroslav Mironov (in 4/01). Click here to go to the next FAQ in the "chain" of recent changes.]

Because you must explicitly define your class's static data members.

Fred.h:

 class Fred {
 public:
   Fred();
   // ...
 private:
   int i_;
   static int j_;
 };

Fred.cpp (or Fred.C or whatever):

 Fred::Fred()
   : i_(10)  // OK: you can (and should) initialize member data this way
   , j_(42)  // Error: you cannot initialize static member data like this
 {
   // ...
 }
 
 // You must define static data members this way:
 int Fred::j_ = 42;

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.10] Why are classes with static data members getting linker errors?

Because static data members must be explicitly defined in exactly one compilation unit. If you didn't do this, you'll probably get an "undefined external" linker error. For example:

 // Fred.h
 
 class Fred {
 public:
   // ...
 private:
   static int j_;   // Declares static data member Fred::j_
   // ...
 };

The linker will holler at you ("Fred::j_ is not defined") unless you define (as opposed to merely declare) Fred::j_ in (exactly) one of your source files:

 // Fred.cpp
 
 #include "Fred.h"
 
 int Fred::j_ = some_expression_evaluating_to_an_int;
 
 // Alternatively, if you wish to use the implicit 0 value for static ints:
 // int Fred::j_;

The usual place to define static data members of class Fred is file Fred.cpp (or Fred.C or whatever source file extension you use).

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.11] What's the "static initialization order fiasco"? UPDATED!

[Recently closed loophole wrt built-in/intrinsic types thanks to Cyril Schmidt (in 8/01). Click here to go to the next FAQ in the "chain" of recent changes.]

A subtle way to kill your project.

The static initialization order fiasco is a very subtle and commonly misunderstood aspect of C++. Unfortunately it's very hard to detect — the errors occur before main() begins.

In short, suppose you have two static objects x and y which exist in separate source files, say x.cpp and y.cpp. Suppose further that the initialization for the y object (typically the y object's constructor) calls some method on the x object.

That's it. It's that simple.

The tragedy is that you have a 50%-50% chance of dying. If the compilation unit for x.cpp happens to get initialized first, all is well. But if the compilation unit for y.cpp get initialized first, then y's initialization will get run before x's initialization, and you're toast. E.g., y's constructor could call a method on the x object, yet the x object hasn't yet been constructed.

I hear they're hiring down at McDonalds. Enjoy your new job flipping burgers.

If you think it's "exciting" to play Russian Roulette with live rounds in half the chambers, you can stop reading here. On the other hand if you like to improve your chances of survival by preventing disasters in a systematic way, you probably want to read the next FAQ.

Note: The static initialization order fiasco can also, in some cases, apply to built-in/intrinsic types.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.12] How do I prevent the "static initialization order fiasco"? UPDATED!

[Recently closed loophole wrt built-in/intrinsic types thanks to Cyril Schmidt (in 8/01). Click here to go to the next FAQ in the "chain" of recent changes.]

Use the "construct on first use" idiom, which simply means to wrap your static object inside a function.

For example, suppose you have two classes, Fred and Barney. There is a global Fred object called x, and a global Barney object called y. Barney's constructor invokes the goBowling() method on the x object. The file x.cpp defines the x object:

 // File x.cpp
 #include "Fred.hpp"
 Fred x;

The file y.cpp defines the y object:

 // File y.cpp
 #include "Barney.hpp"
 Barney y;

For completeness the Barney constructor might look something like this:

 // File Barney.cpp
 #include "Barney.hpp"
 
 Barney::Barney()
 {
   // ...
   x.goBowling();
   // ...
 }

As described above, the disaster occurs if y is constructed before x, which happens 50% of the time since they're in different source files.

There are many solutions to this problem, but a very simple and completely portable solution is to replace the global Fred object, x, with a global function, x(), that returns the Fred object by reference.

 // File x.cpp
 
 #include "Fred.hpp"
 
 Fred& x()
 {
   static Fred* ans = new Fred();
   return *ans;
 }

Since static local objects are constructed the first time control flows over their declaration (only), the above new Fred() statement will only happen once: the first time x() is called. Every subsequent call will return the same Fred object (the one pointed to by ans). Then all you do is change your usages of x to x():

 // File Barney.cpp
 #include "Barney.hpp"
 
 Barney::Barney()
 {
   // ...
   x().goBowling();
   // ...
 }

This is called the Construct On First Use Idiom because it does just that: the global Fred object is constructed on its first use.

The downside of this approach is that the Fred object is never destructed. There is another technique that answers this concern, but it needs to be used with care since it creates the possibility of another (equally nasty) problem.

Note: The static initialization order fiasco can also, in some cases, apply to built-in/intrinsic types.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.13] Why doesn't the construct-on-first-use idiom use a static object instead of a static pointer? NEW!

[Recently created (in 8/01). Click here to go to the next FAQ in the "chain" of recent changes.]

Short answer: it's possible to use a static object rather than a static pointer, but doing so opens up another (equally subtle, equally nasty) problem.

Long answer: sometimes people worry about the fact that the previous solution "leaks." In many cases, this is not a problem, but it is a problem in some cases. Note: even though the object pointed to by ans in the previous FAQ is never deleted, the memory doesn't actually "leak" when the program exits since the operating system automatically reclaims all the memory in a program's heap when that program exits. In other words, the only time you'd need to worry about this is when the destructor for the Fred object performs some important action (such as writing something to a file) that must occur sometime while the program is exiting.

In those cases where the construct-on-first-use object (the Fred, in this case) needs to eventually get destructed, you might consider changing function x() as follows:

 // File x.cpp
 
 #include "Fred.hpp"
 
 Fred& x()
 {
   static Fred ans;  // was static Fred* ans = new Fred();
   return ans;       // was return *ans;
 }

However there is (or rather, may be) a rather subtle problem with this change. To understand this potential problem, let's remember why we're doing all this in the first place: we need to make 100% sure our static object (a) gets constructed prior to its first use and (b) doesn't get destructed until after its last use. Obviously it would be a disaster if any static object got used either before construction or after destruction. The message here is that you need to worry about two situations (static initialization and static deinitialization), not just one.

By changing the declaration from static Fred* ans = new Fred(); to static Fred ans;, we still correctly handle the initialization situation but we no longer handle the deinitialization situation. For example, if there are 3 static objects, say a, b and c, that use ans during their destructors, the only way to avoid a static deinitialization disaster is if ans is destructed after all three, which is, perhaps, only a one in four chance of success.

In the common case the odds are actually much worse than that. In fact, the common case all but guarantees you'll have a static deinitialization disaster. The reason is a combination of the following three items: [1] The common case is when the objects that use ans during destruction also use ans during construction. [2] One of those objects, say a, triggers the construction of ans, meaning the constructor for a starts before the constructor for ans. [3] Static objects are destructed in the reverse order of construction — first constructed is last destructed. Putting those together means a will get destructed after ans, which is a static deinitialization disaster: a's destructor will use ans after it's been destructed. Bang, you're dead.

There is a third approach that handles both the static initialization and static deinitialization situations, but it has other non-trivial costs. I'm too lazy (and busy!) to write any more FAQs today so if you're interested in that third approach, you'll have to buy a book that describes that third approach in detail. The C++ FAQs book is one of those books, and it also gives the cost/benefit analysis to decide if/when that third approach should be used.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.14] How do I prevent the "static initialization order fiasco" for my static data members? UPDATED!

[Recently closed loophole wrt built-in/intrinsic types thanks to Cyril Schmidt (in 8/01). Click here to go to the next FAQ in the "chain" of recent changes.]

Just use the same technique just described, but this time use a static member function rather than a global function.

Suppose you have a class X that has a static Fred object:

 // File X.hpp
 
 class X {
 public:
   // ...
 
 private:
   static Fred x_;
 };

Naturally this static member is initialized separately:

 // File X.cpp
 
 #include "X.hpp"
 
 Fred X::x_;

Naturally also the Fred object will be used in one or more of X's methods:

 void X::someMethod()
 {
   x_.goBowling();
 }

But now the "disaster scenario" is if someone somewhere somehow calls this method before the Fred object gets constructed. For example, if someone else creates a static X object and invokes its someMethod() method during static initialization, then you're at the mercy of the compiler as to whether the compiler will construct X::x_ before or after the someMethod() is called. (Note that the ANSI/ISO C++ committee is working on this problem, but compilers aren't yet generally available that handle these changes; watch this space for an update in the future.)

In any event, it's always portable and safe to change the X::x_ static data member into a static member function:

 // File X.hpp
 
 class X {
 public:
   // ...
 
 private:
   static Fred& x();
 };

Naturally this static member is initialized separately:

 // File X.cpp
 
 #include "X.hpp"
 
 Fred& X::x()
 {
   static Fred* ans = new Fred();
   return *ans;
 }

Then you simply change any usages of x_ to x():

 void X::someMethod()
 {
   x().goBowling();
 }

If you're super performance sensitive and you're concerned about the overhead of an extra function call on each invocation of X::someMethod() you can set up a static Fred& instead. As you recall, static local are only initialized once (the first time control flows over their declaration), so this will call X::x() only once: the first time X::someMethod() is called:

 void X::someMethod()
 {
   static Fred& x = X::x();
   x.goBowling();
 }

Note: The static initialization order fiasco can also, in some cases, apply to built-in/intrinsic types.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.15] Do I need to worry about the "static initialization order fiasco" for variables of built-in/intrinsic types? NEW!

[Recently created thanks to Cyril Schmidt (in 8/01). Click here to go to the next FAQ in the "chain" of recent changes.]

Yes.

If you initialize your built-in/intrinsic type using a function call, the static initialization order fiasco is able to kill you just as bad as with user-defined/class types. For example, the following code shows the failure:

 #include <iostream>
 
 int f();  // forward declaration
 int g();  // forward declaration
 
 int x = f();
 int y = g();
 
 int f()
 {
   cout << "using 'y' (which is " << y << ")\n";
   return 3*y + 7;
 }
 
 int g()
 {
   cout << "initializing 'y'\n";
   return 5;
 }

The output of this little program will show that it uses y before initializing it. The solution, as before, is the Construct On First Use Idiom:

 #include <iostream>
 
 int f();  // forward declaration
 int g();  // forward declaration
 
 int& x()
 {
   static int ans = f();
   return ans;
 }
 
 int& y()
 {
   static int ans = g();
   return ans;
 }
 
 int f()
 {
   cout << "using 'y' (which is " << y() << ")\n";
   return 3*y() + 7;
 }
 
 int g()
 {
   cout << "initializing 'y'\n";
   return 5;
 }

Of course you might be able to simplify this by moving the initialization code for x and y into their respective functions:

 #include <iostream>
 
 int& y();  // forward declaration
 
 int& x()
 {
   static int ans;
 
   static bool firstTime = true;
   if (firstTime) {
     firstTime = false;
     cout << "using 'y' (which is " << y() << ")\n";
     ans = 3*y() + 7;
   }
 
   return ans;
 }
 
 int& y()
 {
   static int ans;
 
   static bool firstTime = true;
   if (firstTime) {
     firstTime = false;
     cout << "initializing 'y'\n";
     ans = 5;
   }
 
   return ans;
 }

And, if you can get rid of the print statements you can further simplify these to something really simple:

 int& y();  // forward declaration
 
 int& x()
 {
   static int ans = 3*y() + 7;
   return ans;
 }
 
 int& y()
 {
   static int ans = 5;
   return ans;
 }

Furthermore, since y is initialized using a constant expression, it no longer needs its wrapper function — it can be a simple variable again.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.16] How can I handle a constructor that fails?

Throw an exception. See [17.2] for details.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

[10.17] What is the "Named Parameter Idiom"? NEW!

[Recently created (in 4/01) and wordsmithing and added last paragraph with inspiration from Stan Brown (in 8/01). Click here to go to the next FAQ in the "chain" of recent changes.]

It's a fairly useful way to exploit method chaining.

The fundamental problem solved by the Named Parameter Idiom is that C++ only supports positional parameters. For example, a caller of a function isn't allowed to say, "Here's the value for formal parameter xyz, and this other thing is the value for formal parameter pqr." All you can do in C++ (and C and Java) is say, "Here's the first parameter, here's the second parameter, etc." The alternative, called named parameters and implemented in the language Ada, is especially useful if a function takes a large number of mostly default-able parameters.

Over the years people have cooked up lots of workarounds for the lack of named parameters in C and C++. One of these involves burying the parameter values in a string parameter then parsing this string at run-time. This is what's done in the second parameter of fopen(), for example. Another workaround is to combine all the boolean parameters in a bit-map, then the caller or's a bunch of bit-shifted constants together to produce the actual parameter. This is what's done in the second parameter of open(), for example. These approaches work, but the following technique produces caller-code that's more obvious, easier to write, easier to read, and is generally more elegant.

The idea, called the Named Parameter Idiom, is to change the function's parameters to methods of a newly created class, where all these methods return *this by reference. Then you simply rename the main function into a parameterless "do-it" method on that class.

We'll work an example to make the previous paragraph easier to understand.

The example will be for the "open a file" concept. Let's say that concept logically requires a parameter for the file's name, and optionally allows parameters for whether the file should be opened read-only vs. read-write vs. write-only, whether or not the file should be created if it doesn't already exist, whether the writing location should be at the end ("append") or the beginning ("overwrite"), the block-size if the file is to be created, whether the I/O is buffered or non-buffered, the buffer-size, whether it is to be shared vs. exclusive access, and probably a few others. If we implemented this concept using a normal function with positional parameters, the caller code would be very difficult to read: there'd be as many as 8 positional parameters, and the caller would probably make a lot of mistakes. So instead we use the Named Parameter Idiom.

Before we go through the implementation, here's what the caller code might look like, assuming you are willing to accept all the function's default parameters:

 File f = OpenFile("foo.txt");

That's the easy case. Now here's what it might look like if you want to change a bunch of the parameters.

 File f = OpenFile("foo.txt").
            readonly().
            createIfNotExist().
            appendWhenWriting().
            blockSize(1024).
            unbuffered().
            exclusiveAccess();

Notice how the "parameters", if it's fair to call them that, are in random order (they're not positional) and they all have names. So the programmer doesn't have to remember the order of the parameters, and the names are (hopefully) obvious.

So here's how to implement it: first we create a new class (OpenFile) that houses all the parameter values as private data members. Then all the methods (readonly(), blockSize(unsigned), etc.) return *this (that is, they return a reference to the OpenFile object, allowing the method calls to be chained. Finally we make the required parameter (the file's name, in this case) into a normal, positional, parameter on OpenFile's constructor.

 class File;
 
 class OpenFile {
 public:
   OpenFile(const string& filename);
     // sets all the default values for each data member
   OpenFile& readonly();  // changes readonly_ to true
   OpenFile& createIfNotExist();
   OpenFile& blockSize(unsigned nbytes);
   // ...
 private:
   friend File;
   bool readonly_;       // defaults to false [for example]
   // ...
   unsigned blockSize_;  // defaults to 4096 [for example]
   // ...
 };

The only other thing to do is make the constructor for class File to take an OpenFile object:

 class File {
 public:
   File(const OpenFile& params);
     // vacuums the actual params out of the OpenFile object
 
   // ...
 };

Note that OpenFile declares File as its friend, that way OpenFile doesn't need a bunch of (otherwise useless) public: get methods.

Since each member function in the chain returns a reference, there is no copying of objects and the chain is highly efficient. Furthermore, if the various member functions are inline, the generated object code will probably be on par with C-style code that sets various members of a struct. Of course if the member functions are not inline, there may be a slight increase in code size and a slight decrease in performance (but only if the construction occurs on the critical path of a CPU-bound program; this is a can of worms I'll try to avoid opening; read the C++ FAQs book for a rather thorough discussion of the issues), so it may, in this case, be a trade-off for making the code more reliable.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

E-Mail E-mail the author
[ C++ FAQ Lite | Table of contents | Subject index | About the author | © | Download your own copy ]
Revised Aug 15, 2001