This is not a full review of the proposed Boost.Local library, I've reviewed only Local Exits and a potential merge with Boost.ScopeExit. I vote NOT to merge Local Exits with Boost.ScopeExit for the following reasons: - Local Exits feature gives two different interfaces ("variadic" and "sequencing"). In my opinion, it should only document C++0X interface and have a section called something like "What if I don't have a C++0X compliant compiler?" where it will explain an alternative interface for a transitional period. Some compilers already support enough C++0X features to let you develop a "perfect" interface. - Binding of variables should be modeled after lambda captures. This means no this_ and no void. I really like void and I'd added it if Lorenzo came up with the idea at the time when Boost.ScopeExit was still in development. - For the same reason, const bind& and bind& should be removed from the interface. Regards, Alex
On Sat, Nov 19, 2011 at 3:59 PM, Alexander Nasonov <alnsn@yandex.ru> wrote:
This is not a full review of the proposed Boost.Local library, I've reviewed only Local Exits and a potential merge with Boost.ScopeExit.
Hello Alex and thank you very much for your comments.
I vote NOT to merge Local Exits with Boost.ScopeExit for the following reasons:
I have no problem with local exits and scope exits remaining separate. Local exits will additionally provide no bindings (void), const bindings, and binding of this_.
- Local Exits feature gives two different interfaces ("variadic" and "sequencing"). In my opinion, it should only document C++0X interface and have a section called something like "What if I don't have a C++0X compliant compiler?" where it will explain an
Yes, the same comment was made by Vicente and Thomas for the entire Boost.Local. I am happy to just document the variadic syntax and have an Annex with the sequencing syntax.
alternative interface for a transitional period. Some compilers already support enough C++0X features to let you develop a "perfect" interface. - Binding of variables should be modeled after lambda captures. This means no this_ and no void. I really like void and I'd added it if Lorenzo came up with the idea at the time when Boost.ScopeExit was still in development.
FYI, I can write pp code that transforms void, this_, etc into lambda captures. For example: TO_CAPTURE(void) // expand to [] TO_CAPTURE(this_, &x) // expand to [this, &x] TO_CAPTURE( (this_) (&x) ) // expand to [this, &x] This way SCOPE_EXIT(void) and SCOPE_EXIT( (this_) (&x) ) or even SCOPE_EXIT(this_, &x) could support void and this_ while still working on both C++03 and C++11...
- For the same reason, const bind& and bind& should be removed from the interface.
Well, if local exits are not merged with scope exits, local exits can keep const bind&, bind&, this_, void, etc. Thank you for your comments. --Lorenzo
Le 19/11/11 23:08, Lorenzo Caminiti a écrit :
On Sat, Nov 19, 2011 at 3:59 PM, Alexander Nasonov<alnsn@yandex.ru> wrote:
This is not a full review of the proposed Boost.Local library, I've reviewed only Local Exits and a potential merge with Boost.ScopeExit. Hello Alex and thank you very much for your comments.
I vote NOT to merge Local Exits with Boost.ScopeExit for the following reasons: I have no problem with local exits and scope exits remaining separate. Local exits will additionally provide no bindings (void), const bindings, and binding of this_.
- Local Exits feature gives two different interfaces ("variadic" and "sequencing"). In my opinion, it should only document C++0X interface and have a section called something like "What if I don't have a C++0X compliant compiler?" where it will explain an Yes, the same comment was made by Vicente and Thomas for the entire Boost.Local. I am happy to just document the variadic syntax and have an Annex with the sequencing syntax.
alternative interface for a transitional period. Some compilers already support enough C++0X features to let you develop a "perfect" interface. - Binding of variables should be modeled after lambda captures. This means no this_ and no void. I really like void and I'd added it if Lorenzo came up with the idea at the time when Boost.ScopeExit was still in development.
FYI, I can write pp code that transforms void, this_, etc into lambda captures. For example:
TO_CAPTURE(void) // expand to [] TO_CAPTURE(this_,&x) // expand to [this,&x] TO_CAPTURE( (this_) (&x) ) // expand to [this,&x]
This way SCOPE_EXIT(void) and SCOPE_EXIT( (this_) (&x) ) or even SCOPE_EXIT(this_,&x) could support void and this_ while still working on both C++03 and C++11...
- For the same reason, const bind& and bind& should be removed from the interface. Well, if local exits are not merged with scope exits, local exits can keep const bind&, bind&, this_, void, etc.
Hi Lorenzo, I wouldn't want two libraries providing Scope Exit idiom in Boost with only a minor binding difference, this will be confusing. I don't know if you have explained this in the document , but could you try to explain here (or point where in the documentation) what are the clear advantages of capturing void, this or capturing by const&. Alex, could you explain why (a part form following the lambda capture), you don't want to accept these new bindings in ScopedExit? Best, Vicente
Vicente J. Botet Escriba wrote:
Le 19/11/11 23:08, Lorenzo Caminiti a écrit :
... FYI, I can write pp code that transforms void, this_, etc into lambda captures. For example:
TO_CAPTURE(void) // expand to [] TO_CAPTURE(this_,&x) // expand to [this,&x] TO_CAPTURE( (this_) (&x) ) // expand to [this,&x]
This way SCOPE_EXIT(void) and SCOPE_EXIT( (this_) (&x) ) or even SCOPE_EXIT(this_,&x) could support void and this_ while still working on both C++03 and C++11...
- For the same reason, const bind& and bind& should be removed from the interface. Well, if local exits are not merged with scope exits, local exits can keep const bind&, bind&, this_, void, etc.
... Alex, could you explain why (a part form following the lambda capture), you don't want to accept these new bindings in ScopedExit?
Because binding syntax in Local is not compatible with ScopeExit captures. If Lorenzo can add support for this_ and void extensions (with emphasis on extensions), I'd be fine with this. Alex
On Sun, Nov 20, 2011 at 4:36 AM, Alexander Nasonov <alnsn@yandex.ru> wrote:
Vicente J. Botet Escriba wrote:
Le 19/11/11 23:08, Lorenzo Caminiti a écrit :
... FYI, I can write pp code that transforms void, this_, etc into lambda captures. For example:
TO_CAPTURE(void) // expand to [] TO_CAPTURE(this_,&x) // expand to [this,&x] TO_CAPTURE( (this_) (&x) ) // expand to [this,&x]
This way SCOPE_EXIT(void) and SCOPE_EXIT( (this_) (&x) ) or even SCOPE_EXIT(this_,&x) could support void and this_ while still working on both C++03 and C++11...
- For the same reason, const bind& and bind& should be removed from the interface. Well, if local exits are not merged with scope exits, local exits can keep const bind&, bind&, this_, void, etc.
... Alex, could you explain why (a part form following the lambda capture), you don't want to accept these new bindings in ScopedExit?
Because binding syntax in Local is not compatible with ScopeExit captures. If Lorenzo can add support for this_ and void extensions (with emphasis on extensions), I'd be fine with this.
1. One challenge (from a pp implementation prospective) is that reference bindings start with the non-alphanumeric symbol & which limits that pp manipulations I can do on such a token (i.e., I cannot CAT in from of it). Because of that, I'd need to try to implement the macros before I can be sure 100% but I think the following should be possible (because the parenthesis wrapping (&x) helps): SCOPE_EXIT( (&x) (y) ) // current SCOPE_EXIT( (&x) (this_) (y) ) // extension to support this_ SCOPE_EXIT( void ) // extension to support no bindings It should be possible to also transform all of the above to lambda bindings (respectively [&x, y], [&x, this, y], and []) for a C++11 implementation of ScopeExit. In C++03 implementation of scope exits you will have to use this_ (not this) within the scope exit to access the object, in C++11 it could be implemented so you can use both or either this_ and this. 2. I do not think I can support const binding instead: SCOPE_EXIT( (const &x) (const this_) (const y) ) // no, I can't do this Because &x starts with & so I cannot CAT it in front to see if it starts with const as in "const &x", plus C++11 lambdas do not support const bindings anyway. 3. Also I do not think I can also support the variadic syntax: SCOPE_EXIT(&x, y) // no, I can't do this Because I'd need to CAT in front &x to distinguish SCOPE_EXIT(&x) from SCOPE_EXIT(void) given that &x is no longer wrapped within extra parenthesis as in SCOPE_EXIT( (&x) ). If I make 1) the improvements for void and this_ to ScopeExit (which I am very happy to try to make) then the only advantage of local exits are 2) const bindings and 3) variadics syntax. I think that both 2) and 3) are not necessary for the scope exit construct so I'd think that local exits can be removed from Boost.Local and replaced by ScopeExit with the improvements above. P.S. If someone really neededs 2) const bindings and 3) variadics for their scope exits, they could trivially program the following using Boost.Local: struct scope_exit { scope_exit(function<void ()> f) : f_(f) {} ~scope_exit() { f_(); } private: function<void ()> f_; }; // some local scope void BOOST_LOCAL_FUNCTION(const capture& x, capture this_, const capture y) { // const and variadics ... // clean up code } BOOST_LOCAL_FUNCTION_END(on_exit1) scope_exit exit1(on_exit1); HTH, --Lorenzo
participants (3)
-
Alexander Nasonov -
Lorenzo Caminiti -
Vicente J. Botet Escriba