Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
On 2015-05-12 7:57 PM, Karl Tomlinson wrote: Ehsan Akhgari writes: On Monday, May 11, 2015, Xidorn Quan quanxunz...@gmail.com wrote: On Tue, May 12, 2015 at 7:29 AM, Ehsan Akhgari ehsan.akhg...@gmail.com javascript:_e(%7B%7D,'cvml','ehsan.akhg...@gmail.com'); wrote: On 2015-04-30 7:57 AM, Xidorn Quan wrote: I guess we probably should forbid using any expression with side effect for member initializers. Hmm, why should we restrict them more than what can appear in the constructor initializer list Because it seems to me that, the member initializers are more obscure for their initializing order. Given they can be disperced widely in different places, it would be far harder to reason out the correctness from a piece of code if the initializers could have side effect. That's a good point! But I think expressions with side effects doesn't really narrow down the issue. It's more an expression that can affect what other expressions in the initializer list get evaluated to. And even that issue is not specific to C++11 member initializers, the old school ones are similarly affected (and in fact the initialization order is exactly the same, based on the order of declarations, bases first.) but at least with those you will get a compiler warning if you mistype the initialization order in the body of the constructor... In short, I still don't see an issue that is specific to C++11 member initializers. I think it is not so much the order or initialization or dependencies on other members that is different here but the fact that member initializers may be dispersed in different parts of the code, well away from the constructors, where one would usually look for initialization side effects. This is actually a great point! I assume one could argue that the constructors of member variables may have side effects and that code is not near the owning classes constructor. However, member variable constructors do not have access to private data or methods in the owning class. I assume member initializers do have this access. Yes, they do. I expect things will be clearest if member initializers are used only for effects on the associated member. Yeah, I agree! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
Ehsan Akhgari writes: On Monday, May 11, 2015, Xidorn Quan quanxunz...@gmail.com wrote: On Tue, May 12, 2015 at 7:29 AM, Ehsan Akhgari ehsan.akhg...@gmail.com javascript:_e(%7B%7D,'cvml','ehsan.akhg...@gmail.com'); wrote: On 2015-04-30 7:57 AM, Xidorn Quan wrote: I guess we probably should forbid using any expression with side effect for member initializers. Hmm, why should we restrict them more than what can appear in the constructor initializer list Because it seems to me that, the member initializers are more obscure for their initializing order. Given they can be disperced widely in different places, it would be far harder to reason out the correctness from a piece of code if the initializers could have side effect. That's a good point! But I think expressions with side effects doesn't really narrow down the issue. It's more an expression that can affect what other expressions in the initializer list get evaluated to. And even that issue is not specific to C++11 member initializers, the old school ones are similarly affected (and in fact the initialization order is exactly the same, based on the order of declarations, bases first.) but at least with those you will get a compiler warning if you mistype the initialization order in the body of the constructor... In short, I still don't see an issue that is specific to C++11 member initializers. I think it is not so much the order or initialization or dependencies on other members that is different here but the fact that member initializers may be dispersed in different parts of the code, well away from the constructors, where one would usually look for initialization side effects. I assume one could argue that the constructors of member variables may have side effects and that code is not near the owning classes constructor. However, member variable constructors do not have access to private data or methods in the owning class. I assume member initializers do have this access. I expect things will be clearest if member initializers are used only for effects on the associated member. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
On Monday, May 11, 2015, Xidorn Quan quanxunz...@gmail.com wrote: On Tue, May 12, 2015 at 7:29 AM, Ehsan Akhgari ehsan.akhg...@gmail.com javascript:_e(%7B%7D,'cvml','ehsan.akhg...@gmail.com'); wrote: On 2015-04-30 7:57 AM, Xidorn Quan wrote: On Thu, Apr 30, 2015 at 10:14 PM, Robert O'Callahan rob...@ocallahan.org javascript:_e(%7B%7D,'cvml','rob...@ocallahan.org'); wrote: On Sat, Mar 21, 2015 at 4:14 AM, bo...@mozilla.com javascript:_e(%7B%7D,'cvml','bo...@mozilla.com'); wrote: * member initializers Should we have any rules around these, or should we use them indiscriminately? I wonder particularly about initializers which are complicated expressions. I guess we probably should forbid using any expression with side effect for member initializers. Hmm, why should we restrict them more than what can appear in the constructor initializer list Because it seems to me that, the member initializers are more obscure for their initializing order. Given they can be disperced widely in different places, it would be far harder to reason out the correctness from a piece of code if the initializers could have side effect. That's a good point! But I think expressions with side effects doesn't really narrow down the issue. It's more an expression that can affect what other expressions in the initializer list get evaluated to. And even that issue is not specific to C++11 member initializers, the old school ones are similarly affected (and in fact the initialization order is exactly the same, based on the order of declarations, bases first.) but at least with those you will get a compiler warning if you mistype the initialization order in the body of the constructor... In short, I still don't see an issue that is specific to C++11 member initializers. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
On 2015-04-30 7:57 AM, Xidorn Quan wrote: On Thu, Apr 30, 2015 at 10:14 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 21, 2015 at 4:14 AM, bo...@mozilla.com wrote: * member initializers Should we have any rules around these, or should we use them indiscriminately? I wonder particularly about initializers which are complicated expressions. I guess we probably should forbid using any expression with side effect for member initializers. Hmm, why should we restrict them more than what can appear in the constructor initializer list? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
On 5/11/2015 2:29 PM, Ehsan Akhgari wrote: On 2015-04-30 7:57 AM, Xidorn Quan wrote: On Thu, Apr 30, 2015 at 10:14 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 21, 2015 at 4:14 AM, bo...@mozilla.com wrote: * member initializers Should we have any rules around these, or should we use them indiscriminately? I wonder particularly about initializers which are complicated expressions. I guess we probably should forbid using any expression with side effect for member initializers. Hmm, why should we restrict them more than what can appear in the constructor initializer list? I believe MSVC does have some problems with complex member initializers, but I don't recall details offhand. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
On Sat, Mar 21, 2015 at 4:14 AM, bo...@mozilla.com wrote: * member initializers Should we have any rules around these, or should we use them indiscriminately? I wonder particularly about initializers which are complicated expressions. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
On Thu, Apr 30, 2015 at 10:14 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 21, 2015 at 4:14 AM, bo...@mozilla.com wrote: * member initializers Should we have any rules around these, or should we use them indiscriminately? I wonder particularly about initializers which are complicated expressions. I guess we probably should forbid using any expression with side effect for member initializers. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
On Friday, March 20, 2015 at 4:14:47 PM UTC+1, bo...@mozilla.com wrote: I was asked to repost this in a new thread in case it got lost ... I have now updated the two MDN pages (that I know of) to reflect that gcc-4.7 or later is now required. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Linux_Prerequisites https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code This has made the following C++11 features available for use in Mozilla code: * member initializers * template aliases * delegated constructors * override and final as C++ keywords Cheers, Bob Great :) I already started using template aliases in bug 1139552 (landed a week ago), not realizing they required GCC 4.7+. It seems I chose a good time for it! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
On 2015-03-20 11:14 AM, bo...@mozilla.com wrote: I was asked to repost this in a new thread in case it got lost ... I have now updated the two MDN pages (that I know of) to reflect that gcc-4.7 or later is now required. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Linux_Prerequisites https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code This has made the following C++11 features available for use in Mozilla code: * member initializers * template aliases * delegated constructors * override and final as C++ keywords Thanks, Bob! I filed bug 1145631 to replace MOZ_OVERRIDE and MOZ_FINAL with the respective keywords. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38
I was asked to repost this in a new thread in case it got lost ... I have now updated the two MDN pages (that I know of) to reflect that gcc-4.7 or later is now required. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Linux_Prerequisites https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code This has made the following C++11 features available for use in Mozilla code: * member initializers * template aliases * delegated constructors * override and final as C++ keywords Cheers, Bob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
