You need two other constructors for Curve as well:

• Copy constructor: Curve(const Curve& cpy)
• (Possibly) Move constructor: Curve(Curve&& mov)

As a rule, *always* either explicitly declare or delete your copy constructor, as well as (possibly) your move constructor.

Also consider adding a constructor which can accept an initial segment.

You also need your assignment operators for copying and (possibly) moving from another Curve(): operator=(const Curve& cpy) and operator=(Curve&& mov). Like the corresponding constructors, these are two functions you should almost always define on data-oriented objects like this.

It may also be worthwhile adding operator+(Segment) and operator+(Curve) (as well as the += counterparts).

Wouldn't we want to allow reassignment?

The convention is indeed to just use if (segmentClosed), not spell out == true`.

This is something you want to avoid. Either test each of these behaviors separately before this test, or else directly access the attributes in question. You want a test to have a specific place to break, and a specific reason to break. Otherwise, debugging the test when it fails gets hard.

A full test suite should separately test each constructor, operator, and function of the class being tested. (This is what is meant by "code coverage")

Uhm...no, I think I read it wrong.

This time around, it makes even less sense. FlexArray::clear() always returns true (I should change it to not return anything), and it never throws an exception, so this clause really would never happen.

Essentially there are control points, beginning points of the curve and the endpoint. The ones starting with c imply a control point.