Simonson, Lucanus J wrote:
- Why can objects be default-constructible? ... - centroid says it throws an exception if the polygon does not contain any point. But how can a polygon not contain any points!? The constructor of a polygon should force it to have at least one
Mathias wrote: point.
Obviously, a default constructed polygon contains no points.
Yes, those two comments were indeed linked to show they were maybe inconsistent. Also, if there is a valid reason for polygons to be able to be empty, I think the algorithm shouldn't make the check but assume it as a precondition, possibly with a disactivable assert.
Polygons have to be default constructible so that they can be elements of a std container.
Thankfully, standard containers do not require objects to be default constructible, but only copy constructible. I'd personally be even happier if they required almost nothing at all, which hopefully they will.
Objects that are not default constructible are a pain.
Says who? Two-phase initialization is well known to be a pain. What's the point of having an object constructed that is not really initialized and usable? Constructors are made to enforce invariants. For some objects, it doesn't make sense to make to allow "emptiness" or "default" as a valid state, so we might as well not allow those states to exist. But anyway, that's another debate. I think it was discussed extensively lately in comp.lang.c++.moderated, so there is no need to discuss it here.
I have to deal with a legacy polygon type that is not default constructible, so I have a very clear idea about which way I prefer and why.
Dealing with non default-constructible types is no more difficult than dealing with default-constructible ones. If you have a very clear case where for polygons or something related to geometry it can lead to issues, feel free to expose it.