[CXX-1121] Include MONGOCXX_CALL and BSONCXX_CALL macros with function definitions Created: 07/Nov/16 Updated: 27/Mar/17 Resolved: 27/Mar/17 |
|
| Status: | Closed |
| Project: | C++ Driver |
| Component/s: | Portability |
| Affects Version/s: | None |
| Fix Version/s: | 3.2.0-rc0 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | David Golden | Assignee: | Samuel Rossi (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
From our internal discussions, we believe that putting the calling convention declarations on both the declaration and definition of non-class functions will reduce the risk of errors if end users override compiler flags with a different default calling convention. As part of the work for this ticket, we should audit the declarations for all of the non-method functions in our API should specify BSONCXX_CALL or MONGOCXX_CALL. |
| Comments |
| Comment by Githook User [ 27/Mar/17 ] | |||||
|
Author: {u'username': u'saghm', u'name': u'Saghm Rossi', u'email': u'saghmrossi@gmail.com'}Message: | |||||
| Comment by Samuel Rossi (Inactive) [ 27/Mar/17 ] | |||||
|
Testing on evergeen after rebase with master | |||||
| Comment by Andrew Morrow (Inactive) [ 14/Mar/17 ] | |||||
|
My guess, and I am guessing a bit here, is that you don't need to adorn the lambdas in cases like the above. Why? Because if the lambda wasn't compatible with the signature in the std::function declaration, I'd expect a diagnostic. | |||||
| Comment by David Golden [ 13/Mar/17 ] | |||||
|
FWIW, from MSVC Lambda Expressions in C++11:
| |||||
| Comment by David Golden [ 10/Mar/17 ] | |||||
|
FWIW: Re MONGOCX_CALL with std::function, see this SO post. (But I've seen some other posts implying there are problems.) In any case, in pool.hpp and pool.cpp, we only use that std::function for our custom destructor, so I think we only need to add MONGOCXX_CALL on pool::_release:
I'm not sure if that's exactly right (untested), but I think something like that might be what we need to ensure pool::_release has the right type for the pool::entry type regardless if users change the default calling convention. |