Re: [boost] Re: Ongoing review of printf-like formatting. MSVC prospective

From: Samuel Krempp (krempp_at_[hidden])
Date: 2002-01-21 18:57:25

On Mon, 2002-01-21 at 21:10, rogeeff wrote:

> Sorry for my ignorance, but could provide a specific examples why?
> Is there manipulators that need t obe passed by non-const reference. 
> Also since manipulators are either function pointers or very small 

those function pointers, for instance, can not be passed as const
references. (don't ask me why !)
we have to pass them by value, or non-const reference.

> classes it should not be a problem to pass them by value (I do not 
> say it's better then const reference, my point is that passing by 
> value is not big deal).

yep, I agree, for usual manipulators.
So I guess this is what I will choose for the MSVC compatibility mode.

For the general case, having the const / non-const reference  choice 
is a bit less restrictive. (we never know what kind of manipulators a
user could come with, for which no copy operator is supplied..)

> > > friend std::basic_ostream<charT, Traits>& 
> > > operator<< <>( std::basic_ostream<charT, Traits>& , 
> > >                const basic_format& ); 
> > > What does this syntax mean here? MSVC works without <>.

[ my poor attempt at an explanation ]

> I did not get it. Does this mean that folloeing syntax is valid:

I myself am not very strong on those matters, so my explanation was
poor..

> class A {
> friend  void foo<> ( B&, A const& );
> };

if foo was declared before, like, for instance :

template<class T1, class T2>
void foo(T1&, T2 const &);

then the above friend declaration is OK.

> What template function was specialized and what were default 
> parameters? Would not be better to declare like this:

well, the friend declaration above refers to the foo template,
specialised for (T1 = B, T2 = A).

>  template friend void foo<> ( B&, A const& );

No, we'd use the 'template' keyword here only if we want more than one
instance  of the foo template to be declared friends.
In our previous sample, it was not the case. (we just wanted to refer to
*one* given instance of the foo template)

e.g. the following would be correct :
template<class T1, class T2>  friend void foo( T1&, T2 const& );

( Note : a strange limitation here, is that you have to either fully
specialize, or not at all. no partial specialisation is allowed by the
standard. )

Here's what happens with g++ 3.0 when I delete the '<>' :

/home/sam/progs/BoostCustom/boost/format/format_class.hpp:87: warning:
friend 
   declaration `std::basic_ostream<_CharT, _Traits>& 
   boost::format::operator<<(std::basic_ostream<_CharT, _Traits>&, const
   boost::format::basic_format<charT, Traits>&)' declares a non-template
   function
/home/sam/progs/BoostCustom/boost/format/format_class.hpp:87: warning:
(if this 
   is not what you intended, make sure the function template has already
been 
   declared and add <> after the function name here)
-Wno-non-template-friend 
   disables this warning.

This warning is clear (so very unusual from g++ :-)

Ah, maybe NSVC would accept 

friend std::basic_ostream<charT, Traits>& 
operator<< <charT, Traits>( std::basic_ostream<charT, Traits>& , 
               const basic_format& ); 

In fact, we can just as well explicitly give the template parameters,
here. And maybe that's enough for MSVC to understant the friend
declaration.

> >  
> > Do you mean MSVC requires to delete the '<>', 
> > or simply that it also works without ?
> 
> MSVC reject <>.

according to the norm, it should require it, not reject it.

> > portability and benchmarking does not mix very well.
> 
> Why? it could be interesting to know performance results on different 
> iostreams implementations. It is portable in most part.

in most part, yes.. but it's not crucial for the library, and needs a
bit of work to be MSVC compatible. so my first idea is to let my
laziness decide and get rid of the file :)

but ok, I'll try to make it portable.
BTW, the nullStream should compile with MSVC, since its author uses this
compiler.. 
arh, I'll look into that later.

> > I'm not sure we should force the stream into 'the true
> > standard-compliant default state',
> > because the user of this stream library might expect the non-
> standard
> > default state, and be surprised by the behaviour of format.
> 
> But your test modules should. To have defined behavior to compare to.

well, once this is tested correct on one platform with a correct stream
library, we can assum the code handling alignment in format is correct.

Anyway, I'm starting to think the problem is not just that the internal
stream is created with improper stream state, 
but rather that the stream code does wrong things with alignments in
some cases. (and we can't do anything against that. just try to see
whether the mistake is in the stream library or format itself..)

> > > 3. Not enough comments.
> > > 
> > > If you will look onto implementation you see a lot of purely 
> > > commented huge blocks of code (see parse or parse_Pdirective for 
> > > examples).
> >
> > You mean there are huge blocks of code that are within comments ?
> > I didn't find any, in parse or parse_Pdirective.
> 
> I meant they did not have them at all.

ah ok.
parse does have a few comments, including algorithm-level ones :
    // A: find upper_bound on num_items and allocates arrays
    // B: Now the real parsing of the format string :
    // C: set some member data :
 
but alas, I found that writing parsing code is just lots of details, and
gives not much philosophy to write about..

even with 10 more lines of comment, I don't think it would become more
clear.

If you don't need to go in more details than the A / B / C steps, praise
the lord for your luck ! :-)

parse_Pdirective is worse.
there's 2 big switch statements, with lots of details in between..

I plan to precisely comment the effects / results of those 2 functions
(and all others), but I doubt adding intermediate-level (between
algorithm-level and  close-to-the-code level) comments to the parse
functions would benefit readers.

Still, I need to at least explicit the assertions that are maintained
along the code (e.g. if  the index in the format-string excedes range,
the parse_Pdirective throws - or returns false) and what exceptions are
thrown, etc..

-- 
Samuel