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

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-21 15:10:37

--- In boost_at_y..., Samuel Krempp <krempp_at_c...> wrote:
> 
> > template<typename T> operator[](constT&) definition is moved in.
> > template<typename T> operator[](T&) declaration is excluded 
> > completely. Why would you need both? MSVC produces an ambiguity 
> > errors if present ( the same everywhere further).
> 
> in case you want to format an object, of which you can not take a 
const
> reference..
> Well okay, for arguments sticking to (const T&) should not be a 
problem,
> users should provide const ways to print their objects anyway.
> 
> but for passing manipulators, it's different :

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 
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).
[...]

> 
> > friend std::basic_ostream<charT, Traits>& 
> > operator<< <>( std::basic_ostream<charT, Traits>& , 
> >                const basic_format& ); 
> > What does this syntax mean here? MSVC works without <>.
> 
> the '<>' means the operator we refer to is a template, with implicit
> template parameters.
> g++-3.0 gently asked me to add this, so I obeyed..
> I think that without '<>' it would refer to the operator with the 
same
> signature, but non-template.
> for a given set of template parameters, we could indeed have the 
choice
> between a template operator<<, and a non-template one (which is
> preferred by the general resolution mechanism)

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

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

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

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

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

MSVC reject <>.

> > bench_variants.cc
> 
> I guess I'll simply launch it on my machine, put some results in a 
HTML
> file, and remove the file from the archive.
> 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.

> 
> 
> > 1. Default allignment. The library seems to make some asumptions 
> > about default ostream allignment( what in the standard?) Anyway 
it is 
[...] 
> > different in STLPort implmentation. So you can imagine that most 
of 
> > you tests/asserts are failing. I assume that format could try to 
> 
> yes, alignment problems were the toughest, so I wrote most of the 
tests
> to check it was working okay.
> 
> > enforce desired default value itself ( I even tried to so by 
setting 
> 
> 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.

> 
> > 2. Hex format. The library seems t omake some asumptions abould 
> > default hex format., which is seems to be different on my 
> > implementation. Moreover I sometimes getting 0X instead of 0x. 
Maybe 
> > something wrong with hex handling flags?
> 
> 0X should happen only when using 'uppercase' flags. (E, G, and X 
instead
> of e, g, and x)

I do not know. Let see how your version will work.

> > 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.

[...]

> > This is just an example. The main point is to merge all comments 
in 
> > one place in a form of descriptive algorithm. This is espesially 
> > importance in all nontrivial implementations which is format is 
> > consist of. Details level is up to you.
> 
> Indeed it is quite nice.
> But it depends on the context. This kind of comments suits this 
function
> nicely.
> But for the big and ugly parse_Pdirective, filled with details and
> special cases, it's harder to merge all the step-by-step comments 
in one
> place.
> For this function, the 'algorithm' would either take 2 lines, 
> or be as long as the function definition..

That is another thing. You may think about separating part of the 
long function code into helper function. It greatly improve code 
readability. Each helper function could have separate algorithm 
description. In general comments should be enough.  No need to 
comment a trivial things like:
++cur_arg_   // increment current argument (not in your code, only 
example)

But it should be clear what is going on. And for that purpose You can 
put as much comments as you need.

> 
> 
> Thanks for your many suggestions
> -- 
> Samuel

Gennadiy.