[C++] how should function's noexcept signature being declared?

https://stackoverflow.com/questions/50273336/noexcept-specifier-with-default-arguments-construction

Question:
function should be mark 'noexcept' base on it's own block expressions or function's argument(including default argument)

Answer:
It's own block expressions.
The function argument(default argument) evaluation should be happened on the caller's expression.
If it fails, it will fail before function being called(stack pile up and run).

ISO:

If an initializer-clause is specified in a parameter-declaration this initializer-clause is used as a default argument. Default arguments will be used in calls where trailing arguments are missing.

Example: the declaration void point(int = 3, int = 4); declares a function that can be called with zero, one, or two arguments of type int. It can be called in any of these ways:point(1,2); point(1); point(); The last two calls are equivalent to point(1,4) and point(3,4) , respectively.

Note (in [intro.execution] Program execution):

Subexpressions involved in evaluating default arguments (8.3.6) are considered to be created in the expression that calls the function, not the expression that defines the default argument

[Defensive Programming]

Reading notes of
John Lakos "Defensive Programming Done Right, Part I"
John Lakos "Defensive Programming Done Right, Part II"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4075.pdf

Design by Contract:

1. What it does
2. What it returns
3. Essential Behavior
4. Undefined behavior unless...
5. Note that


Verification:
1. Preconditions
  RTFM read the fxcking manual
  Assert

2. Postconditions
  Component-level test drivers

3. Invariants
  Assert invatiants in the destructor


-----
4 things:
  1. component level testing
  2. peer review
  3. static analysis tool
  4. DP
-----

Why do we assert only in safe debug mode?

Put assert on postconditions? Time to confirm th test.

Must the code itself _preserve_ invariants even if one or more preconditions of a contract are violated?
NO!!!

-----

What is DP?
Redundant code that provides runtime checks to detect and report
(but not 'handle' or hide) defects in software.

DP good or bad?
Both.
add overhead, but help idenfity defects.

What are we defending against?
1. Bugs in software we use. (Not DP!)
2. Bugs we introduced. (No...)
3. Misuse by our clients. (YES!!)
-----

Fat interface / bad / not proper inheritance
Large interface / bad / not minimal/primitive
Wide contract / bad / No preconditions

------
Narrow contracts imply UB!

Assert inside the funciton. Don't just return 0/false/none

------
Should setXXX mem_fn return status?
NO!!!!

Returning status implies wide contract.

Wide contracts prevent defending against
  such errors in _any_ build mode.


Beware!! assert is expansive!!


Narror contract only check in debug mode.
Wide contract checks by every call!
------

Preconditions _always_ imply postconditions.

**
If a function cannot satisfy it's contract,
it must _not_ return normally.

------
abort() should be considered a viable alternative to
throw in virtually all cases(if exceptions are disabled)

-----
**
Good library components are exception-neutral! (via RAII)

-----
**
What should happen when the behavior is undefined?
Should what happens be part of the component-level contract?
  NO!! Otherwise it would be a behavior contract.
  Do not document UB!
  Otherwise it's not UB anymore!
-----

-----------------------------------
Implementing defensive checks.


---
What should happen if the client misuses library code??

Ask library component to warn us?

1. Document
2. Detect UB
3. Detect all UB?
4. How much CPU time should spend trying to detect misuse of library code?

a. Terminate the program
b. Thrown exception
  c. Save client work before terminate
  d. log error
  e. sent back to programming msg?


---
Plan(Part 1):
Provide 3 kinds of assert macros for library writer to use.

Assert_Opt(Expr)  < 5% CPU

Assert(Expr)  5% ~ 20% CPU

Assert_Safe(Expr) > 20%

---
Plan(Part 2)
Provide a global callback facility.

using handler = void (*)(const char* text, const char* file, int line)
// move the parameters into a single Struct type..


1. failAbort // print and terminate
2. failThrow // wrap into std::logic_error
3. failSleep // print to stderr and spin/sleep

---

e.g
void fun()
{
  auto result = library_func(); //library_func implement assert
}


---
Rule of thumb(guideline):
1. inline functions use Assert_Safe
2. Non-inline functions use Assert

---
Hard vs. Soft UB:
2 separate notion of UB.

1. Language UB (Hard UB)

2. Library UB (Soft UB)

With Library(i.e Soft) UB, (a contract violation)
nothing dire has happened yet, but it could easily lead to Language UB.

Soft UB is relative:
  . not privy to the implementation, might lead to Hard UB.
  . Contract violation can remain Soft UB.


--------
Compile macro build mode.

--------

Mixed-Mode Assertion Build

1. ABI incompatibility.
No.
  .all assertion-level modes musy be ABI compatible.
  .Only permitted side-effect is to invoke the failure handler.

2. Violating the ODR. Yes
-----------

c++11 noexcept: and C++14 follow this standard.
1. Use only for move constructors and move assignment
2. Use whereever there is a wide contract, and the operation must never throw.
3. Use whereever the operation must never throw in contract.

[C++11]default move constructor as noexcept

Is the default Move constructor defined as noexcept?

An inheriting constructor (12.9) and an implicitly declared special member function (Clause 12) have an exception-specification.

If f is an

• inheriting constructor 
• implicitly declared 
• default constructor
• copy constructor
• move constructor
• destructor
• copy assignment operator
• move assignment operator

its implicit exception-specification specifies the type-id T if and only if T is allowed by the exception-specification of a function directly invoked by f’s implicit definition;

f allows all exceptions if any function it directly invokes allows all exceptions, and f has the exception-specification noexcept(true) if every function it directly invokes allows no exceptions.

------------
std::allocator{} is _noexcept_

[C++11] destructor with noexcept

quote from Effective Modern C++:

By default, all memory deallocation functions and all destructors
—both user-defined and compiler-generated—
are implicitly noexcept.

There’s thus no need to declare them noexcept. (Doing so doesn’t hurt anything, it’s just unconventional.)

The only time a destructor is not implicitly noexcept is when a data member of the class (including inherited members and those contained inside other data members) is of a type that expressly states that its destructor may emit exceptions
(e.g., declares it “noexcept(false)”).

Such destructors are uncommon. There are none in the Standard Library.


--------
constexpr , noexcept are part of function interface.
and _Can't_ participate in function overload.