refactor(c/driver/postgresql): Cleanups for result_helper signatures #2261
Conversation
c/driver/postgresql/result_helper.h
Outdated
| @@ -89,7 +89,7 @@ class PqResultRow { | |||
| PqResultRow() : result_(nullptr), row_num_(-1) {} | |||
| PqResultRow(PGresult* result, int row_num) : result_(result), row_num_(row_num) {} | |||
|
|
|||
| PqRecord operator[](const int& col_num) const { | |||
| PqRecord operator[](int col_num) const noexcept { | |||
There was a problem hiding this comment.
Note the change in the paramater declaration from const int& to int
It may not matter, but I believe the const reference type just adds an unnecessary layer of indirection
There was a problem hiding this comment.
Yeah, AFAIK there is little reason to use const int&
|
Something else to note about the |
Researching this some more I think there may be too much usage of noexcept in the current PR implementation. Here are guidelines I found from the stdlib: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf My take on it is that many of these methods are "narrow" (i.e. they have some precondition / state) so probably not worth marking this way. |
|
|
|
OK cool - I'll scale the noexcept back a lot here.
FWIW the cpp core guidelines suggest that you may still want to mark functions that can throw because of OOM issues as noexcept: |
|
Ah, good to know. I suppose that means on the contrary nearly everything here could be noexcept, since we don't use exceptions...but in that case we may as well disable exceptions altogether if we're that sure |
No description provided.