| Paavo Helde <myfirstname@osa.pri.ee>: Oct 01 12:54AM -0500 ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:data-members- > The data members are the key to understanding > the implementation. Therefore, they must be declared first. Normally, a class would be implemented once and used many times. So the usage aspect is far more important than the implementation. For using the class one does not need to understand the implementation (requiring this could become very counter-productive); one rather needs to understand the public interface instead. So the interface part is used and needed for both for the class users and class developers, whereas the implementation part is only needed for class developers. Viewed this way, it is immediately clear which part is more important and should come first in the class definition. In an ideal world the implementation part of the class would be split off and placed only in the implementation file, but unfortunately this is not the way how C++ works. Cheers Paavo |
| "Öö Tiib" <ootiib@hot.ee>: Oct 01 05:36AM -0700 > Private types and functions can be placed with private data. > --------------------------------------------- > I suggest to make the data members first. Why you suggest impossible things? It is typically impossible to have data members before "types: classes, enums, and aliases (using)" since the data member declarations often use the types and then it won't compile. Also you don't elaborate so it is perhaps how you like to see your own code that is written for yourself. That is however something what no one else cares about. |
| Daniel <danielaparker@gmail.com>: Oct 01 05:55AM -0700 On Thursday, October 1, 2015 at 1:54:41 AM UTC-4, Paavo Helde wrote: > class developers, whereas the implementation part is only needed for class > developers. Viewed this way, it is immediately clear which part is more > important and should come first in the class definition. Au contraire, it isn't clear at all :-) Would it make any difference to a typical user of, say, std::string, if the author of std::basic_string arranged the constituents with private data members first? There may have been a time when C++ header files were less implementation and more interface, but they were never wholly that, and with today's header only-template libraries and proxy returns, far less so. In fact, typical users of std::string are going to consult cppreferenc.com or cplusplus.com, not the header. And they want to see documentation for std::string, not std::basic_string. And if a function returns a proxy, they want to see what it resolves to, not some incomprehensible template thing. And more generally, any class exposed to users deserves some API docs, markdown and wiki make this easy. In Java, which puts everything in the class body, and supports generated API docs, the convention is to put the private data members first, to make life easier for the implementer and maintainer. It seems reasonable to me. Daniel |
| scott@slp53.sl.home (Scott Lurndal): Oct 01 01:04PM >> be first, and the first last." Matthew 20:15,16 >> http://webEbenezer.net >One presumes class data members would be private, else what's the point of having a class? The default security for a class is private. Thus, one presumes that unless otherwise specified, the data members would be private regardless of where in the class definition they occur. |
| Daniel <danielaparker@gmail.com>: Oct 01 06:33AM -0700 On Thursday, October 1, 2015 at 8:37:07 AM UTC-4, Öö Tiib wrote: > "types: classes, enums, and aliases (using)" since the data > member declarations often use the types and then it won't > compile. Even if Brian's coding standards were completely unbending (if they had, for example, been given to him by his god), I am sure that with only a little thought (very little), he would have a work around for that difficulty. But generally speaking people who would like to see data members first are more likely to be practical people who would not be dogmatic on that point. The argument for public - protected - private, in that order, is more one of convention, that's typically how it's done in C++. Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 01 05:32PM +0100 On 30/09/2015 23:47, Stefan Ram wrote: > struct pair { T1 first; T2 second; ... }} > But, I agree that it's better to make data members private > /if/ the class should happen to have invariants. I disagree: any non-const data members that contribute to a class invariant MUST be private. > constructor when one has not yet read their declarations, > for example? The data members are the key to understanding > the implementation. Therefore, they must be declared first. I strongly disagree: data members that must be private (see above) are an implementation detail of the class and SHOULD be declared last. When considering the USERS of class rather than the IMPLEMENTERS of a class then you need to think in terms of ABSTRACTIONS not data members when looking at classes with invariants. > more close to the data member. But very-high level functions > of the class, who do not need direct access to the data > members should be non-members. Perhaps you are saying here that you should prefer free functions to public members? If so then I agree however I am not sure about your "high-level" and "low-level" classification. Private members should appear after public members. /Flibble |
| woodbrian77@gmail.com: Oct 01 10:41AM -0700 On Thursday, October 1, 2015 at 7:37:07 AM UTC-5, Öö Tiib wrote: > "types: classes, enums, and aliases (using)" since the data > member declarations often use the types and then it won't > compile. Types Data Ctors, dtors Functions If you don't have local typess the data is first. > Also you don't elaborate so it is perhaps how you like > to see your own code that is written for yourself. That is > however something what no one else cares about. The guideline doesn't elaborate either. From what I can tell a lot of people write classes the way I suggested. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| "Öö Tiib" <ootiib@hot.ee>: Oct 01 11:19AM -0700 > The guideline doesn't elaborate either. > From what I can tell a lot of people write classes the way > I suggested. Things that are meant to be read are usually organized so that what is meant for biggest audience comes first and details schmetails last. In a class the public interface is what concerns most of the readers, so plain old courtesy is to put it first. If you write the code for yourself only then it does not matter but then also why should others care what conventions you use? |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 01 06:35PM On Thu, 2015-10-01, Daniel wrote: > to a typical user of, say, std::string, if the author of > std::basic_string arranged the constituents with private data members > first? Probably not, but almost none of the header files out there are <string> ... > implementation and more interface, but they were never wholly that, > and with today's header only-template libraries and proxy returns, far > less so. I think the vast majority of header files will always contain plain non-templated classes (and function prototypes, and so on). And even with moderate use of templates, where's the problem? template<class T> class Foo { ... }; doesn't need to be unreadable than a normal class. Reading the GNU version of std::basic_string ... yes, it's unreadable. But that's because a) its interface is so big b) it mixes public and private blocks. I count eight or nine switches public, private, public again ... c) the documentation is included. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| j4n bur53 <janburse@fastmail.fm>: Oct 02 12:00AM +0200 Hi, Daniel schrieb: > supports generated API docs, the convention is to put > the private data members first, to make life easier for > the implementer and maintainer. It seems reasonable to me. Yes, thats true, the fields are usually mentioned first, and usually they are made private, and the access is mediated through setters and getters, if at all. But then came Android, and for performance reasons it was recommended not to make private fields, but instead public fields without setters and getters. In general there are no strict rules what should come first and what should come later. Also note there are is not only public and private visibility, but also package local also for fields, and protected only for methods and constructors. Further the API docs generators have a parameter which visibility level should go into the doc. If you have the desire you can generate an API doc that contains even the private class members. Bye |
| j4n bur53 <janburse@fastmail.fm>: Oct 02 12:01AM +0200 j4n bur53 schrieb: > In general there are no strict rules what should come > first and what should come later. Mainly because Java doesn't need forward declarations. There is a small exception, constants need to refer to already defined and constant evaluable expressions. |
| ram@zedat.fu-berlin.de (Stefan Ram): Oct 01 01:51AM >>a common language for communicating string data between different >>parts of the program. >Which is why the C++ standard library has strings. I can write my class mystring, and many library functions (such as ::std::copy and ::std::find below) will accept it. #include <vector> #include <iostream> #include <ostream> #include <iterator> #include <algorithm> #include <cstring> template< typename T >struct mystring_base : public std::vector< T > { using ::std::vector< T >::vector; void append( T const * const str ) { ::std::copy ( str, str + ::std::strlen( str ), ::std::back_inserter( *this )); } void print() { ::std::copy /* here I use "copy" to copy my string! */ ( ::std::begin( *this ), ::std::end( *this ), ::std::ostream_iterator<char>( ::std::cout)); }}; using mystring = mystring_base< char >; int main() { mystring mystring; mystring.append( "alpha" ); ::std::cout << ::std::find /* here I use the library function */ ( ::std::begin( mystring ), /* to find the 'p' in my string */ ::std::end( mystring ), 'p' )- ::std::begin( mystring ) << '\n'; mystring.print(); } This program prints: 2 alpha »2« is the position of »p« in »alpha«. NB: Nowhere does my program mention or use the C++ standard ::std::string class. (I lost my copy of gcc 5 and had to use gcc 4.9, so I had to change some »cbegin« back into »begin«.) Newsgroups: comp.lang.c,comp.lang.c++ |
| ram@zedat.fu-berlin.de (Stefan Ram): Oct 01 01:09PM >In Java, which puts everything in the class body, and >supports generated API docs, the convention is to put the >private data members first, The Java standard library uses public data members too (just as I showed them before in C++'s »::std::pair«). For example, package java.awt.geom; public abstract class Point2D { public static class Double { public double x; public double y; ... }} . See the docs with the public fields at docs.oracle.com/javase/8/docs/api/java/awt/geom/Point2D.Double.html A sole exception would be the case when a class has /invariants/. In this case, data members might be made »private«. Newsgroups: comp.lang.c++,comp.lang.java.programmer |
| ram@zedat.fu-berlin.de (Stefan Ram): Oct 01 01:12PM Supersedes: <public-20151001140758@ram.dialup.fu-berlin.de> [modified Newsgroups header] >In Java, which puts everything in the class body, and >supports generated API docs, the convention is to put the >private data members first, The Java standard library uses public data members too (just as I showed them before in C++'s »::std::pair«). For example, package java.awt.geom; public abstract class Point2D { public static class Double { public double x; public double y; ... }} . See the docs with the public fields at docs.oracle.com/javase/8/docs/api/java/awt/geom/Point2D.Double.html A sole exception would be the case when a class has /invariants/. In this case, data members might be made »private«. Newsgroups: comp.lang.c++,comp.lang.java.programmer |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment