... | ... | @@ -236,7 +236,7 @@ leave the comment in this case). |
|
|
Operator overloading is allowed when it's considered intuitive and
|
|
|
helpful for improving code readability. But care should be taken,
|
|
|
because often it could be only intuitive for that developer who
|
|
|
introduced it. If it doesn't look intuitive for the reviewer, the
|
|
|
introduced it. If it doesn't look intuitive for the reviewer, the
|
|
|
developer has responsibility to convince the reviewer; if it fails the
|
|
|
default action is to use non operator method/function for that
|
|
|
purpose.
|
... | ... | @@ -465,7 +465,7 @@ function(const boost::shared_ptr<DataType>& param) { |
|
|
|
|
|
## Exception-safe getters and string-production methods
|
|
|
|
|
|
Unless there's a compelling reason to do so neither member value getter methods nor and string-production methods, such as toString(), should throw exceptions. Normally a class member is prevented from ever having an invalid value so there is arguably a getter never has a reason to throw, and string-production methods should always be safe to invoke once a class has been instantiated. Both types of methods are commonly used as log statement arguments where one should not have to worry about catching exceptions.
|
|
|
Unless there's a compelling reason to do so neither member value getter methods nor and string-production methods, such as `toString()`, should throw exceptions. Normally a class member is prevented from ever having an invalid value so there is arguably a getter never has a reason to throw, and string-production methods should always be safe to invoke once a class has been instantiated. Both types of methods are commonly used as log statement arguments where one should not have to worry about catching exceptions.
|
|
|
|
|
|
## Namespaces
|
|
|
|
... | ... | @@ -693,7 +693,7 @@ The old `reservation-mode` parameter has been replaced with `reservations-global |
|
|
|
|
|
# DB schema versions
|
|
|
|
|
|
For a long time Kea had a concept of having major and minor versions of the schema, with minor being bumped for backward compatible changes. The original idea was that it would be possible to move back and forth between releases. This was never implemented and never works, as all the back ends made explicit check that both major and minor must match. Also, it is often questionable what is and what is not a backward incompatible change. Finally, we never had any chance to test this backward compatibility. As such, around June 2021, we decided to move to a simpler scheme.
|
|
|
For a long time Kea had a concept of having major and minor versions of the schema, with minor being bumped for backward compatible changes. The original idea was that it would be possible to move back and forth between releases. This was never implemented and never works, as all the back ends made explicit check that both major and minor must match. Also, it is often questionable what is and what is not a backward incompatible change. Finally, we never had any chance to test this backward compatibility. As such, around June 2021, we decided to move to a simpler scheme.
|
|
|
|
|
|
When a schema is changed, we always bump major version and minor always remains at zero. Technically, we could get rid of the minor version, but we want to keep it for backward compatibility *cough*. See rationale [here](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1257#note_220860).
|
|
|
|
... | ... | @@ -712,4 +712,4 @@ they are not part of the Kea's coding guidelines. |
|
|
|
|
|
* Google: https://google.github.io/styleguide/cppguide.html
|
|
|
* Mozilla: https://firefox-source-docs.mozilla.org/code-quality/coding-style/index.html
|
|
|
* XORP: https://fossies.org/linux/xorp/devnotes/coding-style.txt |
|
|
\ No newline at end of file |
|
|
* XORP: https://fossies.org/linux/xorp/devnotes/coding-style.txt |