Ahh, agreed with your example below. Keep the crud out of the
classes. Although for simple getAttr/setAttr methods (or any trivial
one-line method), there is an argument that inline class definitions
are certainly cleaner. Perhaps only allow inline in class defs if it
fits on one line.
This directly goes against the example pointed out in the document
you referenced (since it is only one line), but the extra function
definition for 'return len;' seems excessive.
-Eric
On Mon, Feb 08, 2010 at 11:29:56AM -0800, Monty Taylor wrote:
> Ah - so this brings me to the next thing I was going to suggest, which
> is to move inline method bodies out of the class definition (also
> suggested in the Ellemtel standard [1]) If we do that, it also solves
> the "want to keep parameter name for documentation reason, but need to
> remove it because it's unused in the inline method body" problem. Like so:
>
> class Foo
> {
> public:
> explicit Foo(std::string &name_in);
> void doSomething(int x, int y);
> private:
> std::string name;
> };
>
> inline void Foo::doSomething(int x, int)
> {
> string new_name(name);
> for(int num= 0; num < x; ++num)
> {
> new_name.append(name);
> }
> name= new_name;
> }
>
> This way our classes start to be more readable as interfaces but we keep
> inline functions in the headers for the speed reasons.
>
> Thoughts?
>
> [1] http://www.doc.ic.ac.uk/lab/cplus/c++.rules/chap6.html#sect2
>
> Eric Day wrote:
> > In the case that some private vars are required before public/protected
> > methods (inline methods), is it preferred to put *all* vars in a
> > private section before the methods, or only the ones required? I
> > would say all vars so you don't have two var sections, and to make
> > packing possibly more efficient.
> >
> > While I agree with public before private for API readability,
> > I still am not sure this is the most practical. Because the
> > inline-requiring-private-vars case is somewhat common, I would almost
> > propose private before public so we don't have a bunch of classes
> > with what looks like different styles.
> >
> > Also, I'm not saying language designers are always correct in their
> > vision, but the fact that the 'default' access level is private may
> > say something about what should come first. :)
> >
> > I could go either way.
> >
> > -Eric
> >
> > On Mon, Feb 08, 2010 at 01:01:05PM -0500, Jay Pipes wrote:
> >> ++
> >>
> >> On Mon, Feb 8, 2010 at 12:35 PM, Monty Taylor <[email protected]>
> >> wrote:
> >>
> >> Padraig O'Sullivan wrote:
> >> > Hi!
> >> >
> >> > I was working on a class today in Drizzle and wasn't sure what the
> >> > coding standard is with regard to declaration order i.e. public
> >> before
> >> > private or private before public. There is a sub-section on this in
> >> > the coding standards right now which indicates no conclusion was
> >> made:
> >> >
> >> > http://drizzle.org/wiki/Coding_Standards#Declaration_Order
> >> >
> >> > Personally, I prefer public before private. But I'd like to at least
> >> > choose one order and place it in the coding standards so we can be
> >> > consistent.
> >>
> >> Both the Google C++ coding standards [1] and the Ellemtel C++
> >> standards
> >> [2] require public: then protected: then private:. [3][4] I tend to
> >> agree... when I start reading a class def, I'm usually looking for API
> >> first, and I can read further if I want to see implementation details.
> >>
> >> So my vote is to swipe the text from the Google standard (I like their
> >> supplementary text too.
> >>
> >> [1] http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
> >> [2] http://www.doc.ic.ac.uk/lab/cplus/c++.rules/
> >> [3]
> >>
> >> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Declaration_Order
> >> [4] http://www.doc.ic.ac.uk/lab/cplus/c++.rules/chap6.html#sect1
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~drizzle-discuss
> >> Post to A A : [email protected]
> >> Unsubscribe : https://launchpad.net/~drizzle-discuss
> >> More help A : https://help.launchpad.net/ListHelp
> >
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~drizzle-discuss
> >> Post to : [email protected]
> >> Unsubscribe : https://launchpad.net/~drizzle-discuss
> >> More help : https://help.launchpad.net/ListHelp
> >
> >
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
