On 6/27/12, Martin Jambor <mjam...@suse.cz> wrote: > On Tue, Jun 26, 2012 at 11:06:15AM -0700, Lawrence Crowl wrote: > > On 6/26/12, Martin Jambor <mjam...@suse.cz> wrote: > > > On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote: > > > > +but think twice before using it in code > > > > +intended to last a long time. > > > > > > I think all committed code should be expected to have > > > long-lasting quality. I would not encourage people to think > > > otherwise and would drop the "long time" reference here. > > > If anybody ever commits something ugly to bridge a short time > > > period, it should only be done under the "maintainers grant > > > exceptions" rule anyway. > > > > > > > +</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> > > > > > > Similarly here, no quick and dirty debugging output should > > > ever be committed, we should not > > > > > > > +<h4><a name="stdlib">The Standard Library</a></h4> > > > > + > > > > +<p> > > > > +At present, C++ provides no great advantage for i18n. > > > > +GCC does type checking for <code>printf</code> arguments, > > > > +so the type insecurity of <code>printf</code> is moot, > > > > +but the clarity in layout persists. > > > > +For quick debugging output, <iostream> requires less work. > > > > +</p> > > > > > > The same applies here. > > > > The value of these changes depends on when the rules are > > enforced. If they are enforced only on trunk, then the changes > > seem fine to me. However, if they are enforced on branches, > > then they could unnecessarily slow down development. > > > > Comments? > > I think that if you have a private branch, you are basically > its maintainer and can grant yourself any exception from any > rule you want. Of course, that might make your life harder if > you later want to contribute the changes to the trunk, release > branches, other peple's branches and generally anywhere.
I am not concerned about private branches, but public branches for which sharing might be needed, but for which cleanup before going into trunk or a release is reasonable. C++ streams are much more convenient for free-form output than C-based solutions. Having said that, does anyone object to removing the permission to use C++ streams? -- Lawrence Crowl