Re: [JS-internals] C++ coding style rule for keeping class fields together

> Is there a definition of "reasonable-sized" ? If a class is sufficiently complex, comprehension can be impeded if the methods are "far" from the definitions of the data they act on. Such a class would be "unreasonably-sized." The distinction is based on how many logical "pieces" of the struct

Re: [JS-internals] C++ coding style rule for keeping class fields together

Thanks, everyone. Since there seems to be as much consensus about this as there ever is, I went ahead and made the change. "For reasonable-sized classes, put all the fields together, at the top, immediately after any necessary typedefs. For unreasonably large classes, do whatever seems best (but

Re: [JS-internals] C++ coding style rule for keeping class fields together

On Thu, Sep 28, 2017 at 11:15:52AM -0700, Jim Blandy wrote: > On Thu, Sep 28, 2017 at 12:10 AM, Lars Hansen wrote: > > > (a) A lot of the code I work with already have > > fields-at-the-beginning as the predominant pattern in the smaller classes > > (jit, wasm) so this would

Re: [JS-internals] C++ coding style rule for keeping class fields together

There's also `ddbug`[0] for dumping layouts, but while such tools are useful, its annoying to be staring at a struct definition and not know what data members exist because their definitions interspersed with methods... [0] https://github.com/philipc/ddbug On Fri, Sep 29, 2017 at 2:43 AM, Lars

Re: [JS-internals] C++ coding style rule for keeping class fields together

On Thu, Sep 28, 2017 at 9:35 PM, Jason Orendorff wrote: > On Thu, Sep 28, 2017 at 2:10 AM, Lars Hansen wrote: > >> I dislike this proposal. (a) A lot of the code I work with already have >> fields-at-the-beginning as the predominant pattern in the

Re: [JS-internals] C++ coding style rule for keeping class fields together

On Thu, Sep 28, 2017, at 08:51 PM, Nicholas Nethercote wrote: > I sometimes want to know the memory layout of a class/struct. Having all > the fields together makes that a *lot* easier. Note that gdb's ptype command can help with this using "/m" which avoids printing methods. (And of course one

Re: [JS-internals] C++ coding style rule for keeping class fields together

I sometimes want to know the memory layout of a class/struct. Having all the fields together makes that a *lot* easier. Nick On Fri, Sep 29, 2017 at 5:35 AM, Jason Orendorff wrote: > On Thu, Sep 28, 2017 at 2:10 AM, Lars Hansen wrote: > > > I

Re: [JS-internals] C++ coding style rule for keeping class fields together

On Thu, Sep 28, 2017 at 2:10 AM, Lars Hansen wrote: > I dislike this proposal. (a) A lot of the code I work with already have > fields-at-the-beginning as the predominant pattern in the smaller classes > (jit, wasm) so this would be major churn for no gain. (b) For large >

Re: [JS-internals] C++ coding style rule for keeping class fields together

2017-09-28 20:25 GMT+02:00 Jim Blandy : > On Thu, Sep 28, 2017 at 1:55 AM, Benjamin Bouvier wrote: > >> Agreed with Lars. In particular regarding (b), I tend to read unknown code >> by starting with the data (the "what") then look at how it's manipulated >>

Re: [JS-internals] C++ coding style rule for keeping class fields together

On Thu, Sep 28, 2017 at 1:55 AM, Benjamin Bouvier wrote: > Agreed with Lars. In particular regarding (b), I tend to read unknown code > by starting with the data (the "what") then look at how it's manipulated > (the "how"). Jason and I are in firm agreement with you about

Re: [JS-internals] C++ coding style rule for keeping class fields together

On Thu, Sep 28, 2017 at 12:10 AM, Lars Hansen wrote: > (a) A lot of the code I work with already have > fields-at-the-beginning as the predominant pattern in the smaller classes > (jit, wasm) so this would be major churn for no gain. I think changing the proposal to allow

Re: [JS-internals] C++ coding style rule for keeping class fields together

I don't have an opinion on at-top vs. at-bottom and churn vs. benefits of regularity, but I do really dislike it when fields are mixed with methods. I often like to know I've seen everything so I can feel like I have a handle on the whole state machine of the class and for this purpose I find it

Re: [JS-internals] C++ coding style rule for keeping class fields together

Agreed with Lars. In particular regarding (b), I tend to read unknown code by starting with the data (the "what") then look at how it's manipulated (the "how"). This stylistic change would be a huge regression to me, and there are already some places where the fields are grouped at the end, which

Re: [JS-internals] C++ coding style rule for keeping class fields together

On Thu, Sep 28, 2017, at 12:18 AM, Jason Orendorff wrote: > I'd like to add a style rule: in a struct/class/union, put all the fields > (that is, non-static member variables) together, at the end This sounds good. Is there any reason not to propose this as a Gecko-wide style rule?

Re: [JS-internals] C++ coding style rule for keeping class fields together

On Wed, Sep 27, 2017 at 9:18 AM, Jason Orendorff wrote: > Hi everyone. > > I'd like to add a style rule: in a struct/class/union, put all the fields > (that is, non-static member variables) together, at the end. > > Maybe this is dumb, but while working with Rust I got

[JS-internals] C++ coding style rule for keeping class fields together

Hi everyone. I'd like to add a style rule: in a struct/class/union, put all the fields (that is, non-static member variables) together, at the end. Maybe this is dumb, but while working with Rust I got used to this. Rust doesn't allow methods to be defined within a struct or enum. And wow is it