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
