On 6/27/12, Chiheng Xu <chiheng...@gmail.com> wrote: > On Jun 19, 2012, Lawrence Crowl <cr...@google.com> wrote: > > <p>Function prototypes for extern functions should only occur in > > header files. Functions should be ordered within source files to > > minimize the number of function prototypes, by defining them before > > @@ -121,13 +208,13 @@ > > necessary, to break mutually recursive cycles.</p> > > If you always put entry functions in the bottom of a source file, and > generically, always put upper layer functions below the lower layer > functions. Then probably there will be no need for function prototypes > in a source file.
This text is not a change. I would prefer to not address changes to it in this patch. >> +<h4><a name="Namespace_Use">Namespaces</a></h4> >> + >> +<p> >> +Namespaces are encouraged. >> +All separable libraries should have a unique global namespace. >> +All individual tools should have a unique global namespace. >> +Nested include directories names should map to nested namespaces when >> possible. >> +</p> > > Do all people have a consensus on the use of namespace ? Well, we really only know about objections, and I have not seen any. >> +<p> >> +Header files should have neither <code>using</code> directives >> +nor namespace-scope <code>using</code> declarations. >> +</p> >> + >> +<p> >> +There is no alternative to <code>using</code> declarations >> +in class definitions to manage names within an inheritance hierarchy, >> +so they are necessarily permitted. >> +</p> You must have a draft copy. That second paragraph is not in the patch. >> +<h4><a name="Standard_Library">The Standard Library</a></h4> >> + >> +<p> >> +Use of the standard library is permitted. >> +Note, however, that it is currently not usable with garbage collected >> data. >> +</p> >> + >> +<p> >> +For compiler messages, indeed any text that needs i18n, >> +should continue to use the existing facilities. >> +</p> >> + >> +<p> >> +For long-term code, at least for now, >> +we will continue to use <code>printf</code> style I/O >> +rather than <code><iostream></code> style I/O. >> +For quick debugging code, >> +<code><iostream></code> is permitted. >> +</p> > > Is iostream really suitable or necessary for GCC ? It is sometime suitable and not necessary. > Have you think about writing another thinner interface, like > Java's IO stream. We probably should not implement yet another I/O interface. We should either use the existing GCC facilities, or use the standard C/C++ facilities. A third set would increase the learning curve. -- Lawrence Crowl
