1 Standalone Functions

A function is “standalone” if it is not declared as a member of a class or a struct.

The canonical example of a standalone function is the one that starts off the execution of every program:

int main (int argc, char** argv)
{
  ⋮
  return 0;
}

But there are certainly others.

double sqrt(double x);  // Compute the square root of x
double abs(double z);   // Compute the absolute value of z

The list of parameters in a function’s declaration are called its formal parameters.

To call a standalone function, you simply write its name in an expression, followed by a parenthesized list of expressions that give the actual data you want used in the computation, the actual parameters.

double num = abs(3.0);     // formal parameter z gets an actual parameter of 3.0
cout << sqrt(num) << endl; // formal parameter x gets an actual parameter of num

Suppose that I was writing code for part of a bookstore’s inventory system. I might have the idea of a class Book. Now, in an older programming language that had only standalone functions, I might expect to write code like this:

for (Book b: inventory)
{
  Book sequel = b;
  setTitle(sequel, "The Further Adventures of " + getTitle(b));
  addToInventory(sequel);
}

That would be based upon standalone functions for getTitle() and setTitle(), which might look like this:

struct Book {
    std::string title;
     ⋮
};

std::string getTitle(const Book& book)
{
  return book.title;
}

void setTitle(Book& book, const std::String& newTitle)
{
  book.title = newTitle;
}

In current practice, programs tend to have relatively few standalone functions. The bulk of the functions in most programs are member functions.

2 Member Functions

A member function is a function that is declared within a class or struct.

Returning to our Book example, a more modern style would make getTitle and setTitle into member functions:

I would likely write something like this in book.h:

class Book {
    std::string title;
     ⋮
public:
     ⋮
    std::string getTitle() const;
    void setTitle(const std::String& newTitle);
};

And then in book.cpp, I would put:

std::string Book::getTitle() const
{
  return title;
}

void Book::setTitle(const std::String& newTitle)
{
  title = newTitle;
}

Member functions are called by putting the object that they are applied to on the left, followed by a ‘.’ (or -> if we are using pointers), then the function name and remaining parameters.

for (Book b: inventory)
{
  Book sequel = b;
  sequel.setTitle("The Further Adventures of " + b.getTitle());
  addToInventory(sequel);
}

Compare this to the earlier standalone function version:

  setTitle(sequel, "The Further Adventures of " + getTitle(b));

and you can see how member functions simply shift the first parameter of each call outside of the parentheses and to the left. This is considered to be more expressive and suggestive of the function’s being a member of the class, analogous to the data members, but it is, in the end, more a matter of style than of substance.

2.1 This is the Mysterious Missing Parameter

It’s easy enough to see that the calls to the functions

setTitle(aBook, "War and Peace II"); // standalone
aBook.setTitle("War and Peace II"); // member

actually provide the same number of parameters, but how do we reconcile the following declarations?

void setTitle (Book& b, const std::string& newTitle); // standalone 

class Book
{
    ⋮
    void setTitle (const std::string& newTitle); // member
    ⋮
};

Clearly the standalone version is declared with two parameters, but the member function with only one. How does the member function know which book to set the title of?

The answer lies in a bit of sleight-of-hand by the C++ compiler. Member functions have an implicit parameter that we never type out as part of the declaration, but that the compiler automatically supplies. This implicit parameter is the first “true” parameter to the function, it’s data type is a pointer to a value of the class type, and its name is “this”.

class Book
{
    ⋮
    void setTitle (const std::string& newTitle); // This is what we type
    /*
    void setTitle (Book* this, const std::string& newTitle); // This is what the compiler does
    */
    ⋮
};

When we call a member function, the compiler does a similar bit of legerdemain:

aBook.setTitle ("The Adventures of Sherlock Holmes");

is actually translated as

Book::setTitle (&aBook, "The Adventures of Sherlock Holmes");

• The Book:: prefix indicates that we are calling a function declared inside the class Book.
• The & is the “address-of” operator, so &aBook gets a pointer to aBook.

When we provide the function body for the member function setTitle, we can do so like this:

void Book::setTitle (const std::string& newTitle)
// really:  void Book::setTitle (Book* this, const std::string& newTitle)
{
    this->title = newTitle;
}

However, these is one final magic trick available from the compiler. Within the body of a member function, we can almost always omit the phrase this-> wherever it appears. As a consequence, the vast majority of the member function code you will ever read or write will never mention this:

void Book::setTitle (const std::string& newTitle)
// really:  void Book::setTitle (Book* this, const std::string& newTitle)
{
    title = newTitle;
}

You will occasionally find yourself in situations where you need to use this explicitly. One is when you need to manipulate the entire object rather than just its members. For example:

class Book
{
  ⋮
  void putIntoDisplayWindow (BookStore& store);
  ⋮
};
    ⋮

void Book::putIntoDisplayWindow (BookStore& store)
{
  store.window.add(*this);   
}

Another situation where you need to use this is when failing to do so would cause ambiguity. For example, suppose that we had declared our setTitle member function like this:

class Book
{
    ⋮
    void setTitle (const std::string& title);
    ⋮
private:
    std::string title;
};

so that we would be tempted to implement it like this:

void Book::setTitle (const std::string& title)
{
  title = title;
}

The highlighted assignment does not do what we want because of the ambiguity of what “title” refers to. We want the first “title” to be the data member and the second “title” to be the function parameter. But, in fact, the compile is going to assume that both refer to the function parameter.

There are three ways to fix this:

1. Rename the function parameter to, e.g., newTitle and write the assignment as title = newTitle;
2. Rename the data member to, e.g., _title and write the assignment as _title = title;
3. Don’t rename anything, but rewrite the assignment as this->title = title;

Within the C++ programming community, you will encounter each of these three options. It’s something of a matter of personal style. Many programmers will give all of their data members a prefix such as an underscore (_title) or “the” (theTitle). Other programmers will use the “the” prefix for their function parameter names. A smaller number of programmers will not worry about it, but simply use an explicit this-> when necessary. (The majority of programmers will argue that using the same name for a data member and a function parameter is just asking for trouble, however, because it’s all too easy to forget a this-> when you really need it).

2.2 Const Member Functions

In general, some of the parameters to a function may be inputs that the function body will look at but not change, and other parameters are outputs that the function body will change. There are also in-out parameters that the function body look both at the initial value passed in, but also changes that value as output.

You should be used to the idea that you can look at a function’s parameter list and tell whether a parameter is pure input or some form of output (either output only or an in-out combo).

int doSomething (Book b1, Book& b2, const Book& b3);

• b1 is passed by copy, so it is an input to this function.
• b2 is passed as a reference, so it is an output or in-out for this function.
• b3 is passed as a const reference, so it is an input to this function.

2.2.1 Const Correctness

A good C++ class designer will be very careful to designate which member functions are const or not, and which function parameters are const or not.

A class declaration is const correct if

1. Each member function has been marked as const if and only if it does not need to change the object it is applied to.
2. Each function parameter is passed as a non-const reference if it serves as an output (or in-out) of the function, passed by copy or as a const reference if it is input only.

2.3.1 Constructors can be used to declare variables

The most common use for a constructor is in declaring new variables, e.g.,

Book myBook ("My Autobiography", 2022);

Storage space for myBook is reserved, and then the constructor is called to initialize that storage.

Constructors with one parameter

If a constructor takes exactly one parameter, C++ actually allows the declaration to be written two different ways.

For example, if we had

class Counter {
 public:
    Counter(int initialValue); 
      ⋮
};

then we could create a new counter like this

    Counter ctr(100);  // the "normal" syntax for calling a constructor

or like this:

    Counter ctr = 100;  // the "special" syntax for a constructor with 1 parameter

They both mean exactly the same thing. The ‘=’ is not an assignment – it’s an alternative syntax to the use of parentheses.

2.3.2 Constructors are still functions

Constructors can also be called just like any function. In that case, they are used to initialize a new value of the class type and they return that newly constructed value to their caller.

addToCatalog (catalog, Book("My Autobiography", 2022));

is logically equivalent to

Book temp ("My Autobiography", 2022);
addToCatalog (catalog, temp);

2.4 Some Constructors are Special

There are a few patterns for constructors that are so common in C++ that they have been given names.

2.4.1 Default Constructors

A default constructor is a constructor that can be called with no parameters.

If you were to write, for example,

std::string s1;

you are invoking the default constructor for std::string (which initializes the variable to the empty string).

Most often, default constructors are declared with no parameters:

class Shipment
{
 public:
    Shipment();  // default constructor
       ⋮
};

It can be called like this:

Shipment aShipment;

A constructor can also qualify as a default constructor if it provides default values for all of its parameters:

class Book
{
 public:
    Book (const std::string& theTitle = std::string(), int year = 2000);
       ⋮
 private:
    std::string title;
    int year; 
};

The three declarations below are all equivalent:

Book b;
Book b(std::string());
Book b(std::string(), 2000);

Default Constructors and arrays

Default constructors are important because, when we create an array of class values, e.g.,

Shipment deliveries[100];

the default constructor for that type is used to initialize every element of the new array.

If a class does not have a default constructor, then you cannot create arrays of that class.

2.4.2 Copy Constructors

Another special constructor is one that takes a single parameter, a const reference to the class being constructed, e.g.,

class Book {
 public:
    Book(); // default constructor
    Book (const Book&); // copy constructor
       ⋮
};

This is called the copy constructor because it is used to create an object that is a copy of another.

What makes copy constructors special is not how they work, but, rather, how often they get used.

Where are Copy Constructors Used?

The copy constructor gets used in 5 situations:

2.4.3 Initialization Lists

There are actually two stages to the execution of a constructor:

1. The data members of the class are initialized.
2. The function body of the constructor is run.

This code is actually a bit inefficient:

Book::Book (const std::string& theTitle, int theYear)
{
  title = theTitle;
  year = theYear;
}

The reason I say that is because those two assignment statements in the function body are not initializing the data. They are actually replacing the values of the already initialized data members.

• The title will have been initialized using the std::string default constructor, which initializes it to an empty string.
• The year will be initialized using the default rules for ints, which, as it happens, are to do nothing at all.

Only after the data members have all been initialized does the code inside the { } start to execute.

It would be more efficient to start off initializing the data members to the values we want, so that we don’t need to reassign them a few microseconds later. This can be done by adding an initialization list to the implementation fo the constructor.

An initialization list is a comma-separated list of the data members of the class, each followed, in parentheses, by the parameters that we would supply to a constructor to initialize that data member. The whole list appears between the function header and the body, with a colon (‘:’) right in front of it:

Book::Book (const std::string& theTitle, int theYear)
: title(theTitle), year(theYear)
{
}

In simple classes like Book, it may not matter a whole lot whether you use initialization lists or wait until the function body to reassign the proper values. There are, however, situations in which a data member can only be initialized in the initialization list:

• If a data member is a reference (because references can only be initialized – they cannot be reassigned afterwards.)
• If a data member is declared as const (because const values can only be initialized – they cannot be reassigned afterwards.)

2.5 Destructors

The flip-side of initializing new objects is cleaning up when old objects are going away. Just as C++ provides special functions, constructors, for handling initialization, it also provides special functions, destructors, for handling clean-up.

A destructor for the class Foo is a function of the form

~Foo();

You must never call a destructor explicitly.

Instead the compiler generates a call to an object’s destructor when

• Execution passes outside of the { ... } within which the object was declared. For example, if we wrote

  if (someTest)
    {
     Book b = text361;
     cout << b.getTitle() << endl;
    }
  
  

  what the compiler would actually generate would be something along the lines of

  if (someTest)
    {
     Book b = text361;
     cout << b.getTitle() << endl;
     b.~Book();  // implicitly generated by the compiler
    }
  

• When we delete a pointer to an object, the object’s destructor is (implicitly) called prior to actually recovering the memory occupied by the object. For example, if we were to write:

    Book *bPointer = new Book(text361); // initialized using copy constructor
       ⋮
    cout << bPointer->getTitle() << endl;
    delete bPointer;
  

  what the compiler would actually generate would be something along the lines of

    Book *bPointer = new Book(text361); // initialized using copy constructor
       ⋮
    cout << bPointer->getTitle() << endl;
    bPointer->~Book();
    free(bPointer);  // recover memory at the address in bPointer
  
  

The most common use of destructors is to prevent memory leaks when classes have data members that are pointers to objects allocated on the heap.

For example, suppose that we wanted to track the authors of a book:

class Book {
 public:
     Book(const std::string& theTitle = std::string());
     ~Book();
        ⋮
     void addAuthor (const Author& author);
     int numAuthors() const;
     Author getAuthor(int index) const;
        ⋮
 private:
     std::string title;
     int nAuthors;
     static const int maxAuthors = 12;
     Author* array;
};

Then it is likely that the array of authors would be allocated on the heap by the constructor:

Book::Book(const std::string& theTitle)
: title(theTitle), nAuthors(0), authors(new Author[maxAuthors])
{
}

in which case, the appropriate action for the destructor would be to free up that memory

Book::~Book()
{
    delete [] authors;
}

Without that destructor, every book object would, when constructed, allocate an array on the heap, and that block of memory would remain, unusable, after each book object had disappeared.

3 Inline functions

Many of the member functions we have given as examples are simple enough that we might consider an alternate approach, declaring them as inline functions.

3.1 Static Member Functions

4.1 Ordinary Overloading

If we write

void foo(int i) 
{
  cout << "my parameter is an integer" << endl;
}

void foo(std::string s) 
{
  cout << "my parameter is a string" << endl;
}

void foo(int i, std:string s)
{
  cout << "I have two parameters" << endl;
}


⋮

foo(0);
foo("hello");
foo(42, "42");

We would expect to see the output:

my parameter is an integer
my parameter is a string
I have two parameters

The compiler looks at the data types of the actual parameters in the function calls and compares them to the data types of the formal parameters in the function declarations. It chooses whichever function actually matches the parameter types supplied.

Overloading is very common in C++. We actually had an example of it earlier:

class Book {
 public:
    Book(); // default constructor
    Book (const Book&); // copy constructor
       ⋮
};

Both functions have the same name (“Book”), but one takes no parameters and the other takes a single parameter of type const Book&, so the compiler can easily determine that

Book b1;

calls the default constructor and

Book b2 (b1);

calls the copy constructor.

4.2 Operator Overloading

One of the truly delightful, or demonic, depending on your point of view, aspects of C++ is that almost every operator in the language can be declared in our own functions. In most programming languages, we can write things like “ x+y ” or “ x<y ” only if x and y are integers, floating point numbers, or some other pre-defined type in the language. In C++, we can add these operators to any class we design, if we feel that they are appropriate.

The basic idea is really very simple.

Almost of the things we use as operators, including

+ - * / | & < > <= >= = == != ++ -- -> += -= *= /=

can be overloaded.

This is also true of some things you probably don’t consider as operators (the [ ] used in array indexing and the ( ) used in function calls). There are only a few things that look like operators but cannot be overloaded: ‘.’ and ‘::’.

All of those operator symbols are actually “syntactic sugar” for a function whose name is formed by appending the operator itself to the word “operator” .

For example, if you write a + b*(-c), that’s actually just a shorthand for

operator+(a, operator*(b, operator-(c)))

and if you write

testValue = (x <= y);

that’s actually a shorthand for

operator=(testValue, operator<=(x, y);

Now, this shorthand is so much easier to deal with that there’s seldom any good reason to actually write out the long form of these calls. But knowing the shorthand means that we can now declare new operators in the same way we declare new functions.

4.3 Example: Date Operations

Suppose that we were working with a class to manipulate calendar dates. We could start with a class like this:

class Date {
 private:
   int daysSinceEpoch;  
 public:
   Date ();
   Date (int day, int month, int year);
   
   int getDay() const;  
   void setDay (int day);
   
   int getMonth() const;
   void setMonth(int month);
   
   int getYear() const;
   void setYear();
   
   Date dateSomeDaysAway(int numDaysAway) const;
   int numberOfDaysApart(const Date& from) const;
};

This would let us write application code like:

Date rescheduleWeeklyMeeting(const Date& meeting)
{
    Date followUp = meeting.dateSomeDaysAway(7);
    return followUp;
}

or

void warnIfBookIsOverdue (const Date& checkoutDate, const Date& today)
{
    if (today.numberOfDaysApart(checkoutDate) > 21)
    {
        cout << "This book is overdue." << endl;
    }
}

The function bodies for the two operations given as

Date Date::dateSomeDaysAway(int numDaysAway) const
{
    Date result;
    result.daysSinceEpoch = daysSinceEpoch + numDaysAway;
    return result;
}
   
int Date::numberOfDaysApart(const Date& from) const
{
    return daysSinceEpoch - from.daysSinceEpoch;
}

Now, the names of the last two operations are a bit awkward. Perhaps you could think of better ones. But I honestly didn’t worry about it at the time because I knew that I was eventually going to replace these by operators.

class Date {
 private:
   int daysSinceEpoch;  
 public:
   Date ();
   Date (int day, int month, int year);
   
   int getDay() const;  
   void setDay (int day);
   
   int getMonth() const;
   void setMonth(int month);
   
   int getYear() const;
   void setYear();
   
   Date operator+(int numDaysAway) const;
   int operator-(const Date& from) const;
};

All that we have done here is to change the names of the two functions, not their behavior. And that’s all that would change in the C++ class declaration:

I think, however, that this makes for much nicer application code:

Date rescheduleWeeklyMeeting(const Date& meeting)
{
    Date followUp = meeting + 7;
    return followUp;
}

or

void warnIfBookIsOverdue (const Date& checkoutDate, const Date& today)
{
    if (today - checkoutDate > 21)
    {
        cout << "This book is overdue." << endl;
    }
}

For the eventual implementation, again, all that changes are the function names:

Date Date::operator+(int numDaysAway) const
{
    Date result;
    result.daysSinceEpoch = daysSinceEpoch + numDaysAway;
    return result;
}
   
int Date::operator-(const Date& from) const
{
    return daysSinceEpoch - from.daysSinceEpoch;
}

Operator functions seem to cause some students a great deal of anxiety, but they really aren’t all that complicated.

When we declare and implement them, it’s just a change to a function name that starts with “operator”.

It is only when we use them that their special nature comes out, as they provide us with a shortcut to writing out the full function name.

Not every class make sense with operators like “+” or “-”. I have no idea, for example, what it would even mean to add two Books together or to subtract one Book from another.

There are, however, a few operators that would make sense for Book and for almost all ADTs.

The most commonly overloaded operators are:

• The assignment operator, =
• The comparison operators == and <
• The output operator <<

We’ll talk about the assignment and comparison operators in some detail in later lessons, and we’ll look at the output operator in just a moment.

4.3.1 Standalone vs Member Operator Functions

One thing to watch for when using operator functions is the difference between standalone and member functions.

Let’s revisit the example of adding an integer number of days to a Date. I want to be able to write something like

Date today = getTodaysDate();
Date aWeekFromToday = today + 7;

One way to do that would be to have a standalone function:

Date operator+ (const Date& date, int nDays);

If we had that declaration, then when we write today + 7, the compiler matches our use of + against this declaration and translates it to operator+(today, 7).

What if we wanted to write:

Date today = getTodaysDate();
Date aWeekFromToday = today + 7;
Date alsoAWeekFromToday = 7 + today;

The + in the third line does not match our declared operator+, because the incoming parameters are int and Date rather than Date and int. So this would not compile. But it’s easily fixed. We just overload the operator+ function.

Date operator+ (const Date& date, int nDays);
inline Date operator+ (int nDays, const Date& date) 
{
   return date + nDays;  // call the first operator+ instead
}

But instead of using standalone functions, we can write operators as member functions instead:

class Date {
 private:
   int daysSinceEpoch;  
 public:
   Date ();
       ⋮ 
   Date operator+(int nDays) const;
};

Notice that this function appears to only have one parameter instead of the two that we need. But that’s just because it’s a member function. All (non-static) member functions have the implicit this parameter that does not appear within the parentheses.

If we have that declaration instead of our standalone versions, then the compiler will translate the call

Date today = getTodaysDate();
Date aWeekFromToday = today + 7;

to

Date today = getTodaysDate();
Date aWeekFromToday = today.operator+(7);

using the ‘.’ style call that we associate with the use of member functions.

But what if we wanted to say

Date today = getTodaysDate();
Date aWeekFromToday = today + 7;  // today.operator+(7)
Date alsoAWeekFromToday = 7 + today;  

Can we handle the second addition via a member function? No, we can’t. Because if it were a member function, then the compiler would be trying to translate 7 + today to 7.operator+(today), and that’s not legal. Every member function must always take a (pointer to a) value of its class type on the left of the function name. “7” isn’t a Date. “7” can’t be the first parameter to a call to a Date member function.

If we want to support our addition in either order, we can combine a member function with an overloaded version going in the other direction:

class Date {
 private:
   int daysSinceEpoch;  
 public:
   Date ();
       ⋮ 
   Date operator+(int nDays) const;
};

inline Date operator+ (int nDays, const Date& date) 
{
   return date + nDays;  // call the member function operator+
}

4.3.2 operator<<

I recommend that you always provide an output operator for every class you write, even if you don’t expect to use it in your final application.

My reason for this is quite practical. Sooner or later, you’re going to discover that your program isn’t working right. So how are you going to debug it? The most common thing to do is to add debugging output at all the spots where you think things might be going wrong. So you come to some statement:

  doSomethingTo(book1);

and you realize that it might be really useful to know just what the value of that book was before and after the call:

  cerr << "Before doSomethingTo: " << book1 << endl;
  doSomethingTo(book1);
  cerr << "After doSomethingTo: " << book1 << endl;

Now, if you have already written that operator<< function for your Book class, you can proceed immediately. If you haven’t written it already, do you really want to be writing and debugging a new function now, when you are already dealing with a different bug?

To add an output operator, we can add the appropriate declaration

class Book {
private:
	std::string title;
	std::string isbn;

	static const int MaxAuthors = 12;
	Author* authors;
	int numAuthors;

public:
	Book();
	Book(const std::string& title, const std::string& isbn);

	std::string getTitle() const {return title;}
	void setTitle(std::string theTitle) {title = theTitle;}

	void addAuthor (const Author&);
	int numberOfAuthors() const;
  Author getAuthor(int index) const;

	std::string getISBN() const {return isbn;}
	void setISBN(std::string id) {isbn = id;}
};

std::ostream& operator<< (std::ostream& out, const Book& book);

The output operator must be declared as a standalone outside of the class. That’s because, when we write

cout << book1; 

the first parameter is cout, which is not a Book. cout is a C++ std::ostream. So operator<< could only be a member function of class std::ostream. And that’s no good for our purposes. So if we want to support output of Book or Date or any of our other classes, we need to do it as an standalone, non-member function.

Another unusual point: notice the return value on the operator<< declaration. Each implementation of operator<< is supposed to return the output stream to which we are writing. It’s the fact that << is an expression that returns the stream we are writing to that let’s us write “chains” of output expressions like:

cout << book1 << " is better than " << book2 << endl;

which is treated by the compiler as if we had written:

(((cout << book1) << " is better than ") << book2) << endl;

Look at the second <<.

• What is it being given as its left-side parameter? It’s being given (cout << book1), the value returned by the first << operator.
• What do we expect a << to do with its left-side parameter? We expect it to write to it.

So, the left-hand parameter needs to be the output stream that we are writing all of this output to.

By convention, then, every implementation of operator<< returns the stream that it has just written into, so that a chain of << calls will, each in turn, pass the stream on to the next one in line.

Output of private data

Because the output operator is a standalone function, it will not have access to the private data members of the class.

That means that the most straightforward implementation will not compile:

std::ostream& operator<< (const std::ostream& out, const Book& book)
{
  out << book.title << "\n"    // error: data member title is private
      << book.isbn  << "\n";   // error: data member isbn is private
  return out;
}

There are 3 ways to get around this problem.

1. Restrict our function body to use of the public functions that provide access to the attributes of the class:

   std::ostream& operator<< (const std::ostream& out, const Book& book)
   {
     out << book.getTitle() << "\n"    
         << book.getIsbn()  << "\n";   
     return out;
   }
   

2. Create a member function that knows how to print and that can be called from the operator:

   class Book {
   private:
      ⋮
   public:
      ⋮
     void print (std::ostream& out) const;
   };
   
   std::ostream& operator<< (const std::ostream& out, const Book& book)
   {
     book.print(out);
     return out;
   }
       ⋮
   void Book::print(const std::ostream& out) const
   {
     out << title << "\n" 
         << book  << "\n";
   }
   

3. Make the operator a friend of the class. “Friends” in C++ have access to private data members;

   class Book {
   private:
      ⋮
      friend std::ostream& operator<< (const std::ostream& out, const Book& book);
   public:
      ⋮
   };
   
   std::ostream& operator<< (const std::ostream& out, const Book& book)
   {
     out << title << "\n" 
         << book  << "\n";
     return out;
   }
   

Which of these you choose is up to you. I tend to lean toward #3 myself, because it just makes sense that the output operator would be an member of the class, even though if the rules of the language say that we can’t declare it as one.