Re: [boost] Alternate Format Mechanism

From: j.adelman_at_[hidden]
Date: 2002-02-12 05:43:16

Quoting Karl Nelson <kenelson_at_[hidden]>:

> First suggestion then.
> 
> Rename it "reorder()".  One more letter, but it 
gets
> out of the "what do we want in formatting" 
discussion.
> Limited scope things get going faster than 
others.

Sounds good.  It certainly describes what it does 
better.  I'll do a reorder/basic_reorder trick to 
make it terse for the most common use.  Oh, and 
I'll add an allocator argument, while I'm 
thinking of it.

> Format is already pretty tied up with 2 
discussions and 
> the boost submission which using format for 
both reorder
> and printf-format was generally regarded as a 
bad idea. 
> 
> 
> Second suggestion.  
> 
> Don't use "%1" this is too easily confused with 
other 
> formats ie.  Is this a printf format or yours?
>    I see %1s.
> 
> Use [1] (boost suggestion) or {1} (.NET).  Also 
this avoids
> the ending tag problem.

That sounds reasonable; this was just my default 
choice because it had been used a lot, rather 
than a thought-out decision.  Alternatively, I 
could make this a parameter with a default, but 
this may add too much complexity.  I could also 
add a means to specify the format as a 
vector<int> & a seperation character, for if 
there is a non-translation use.  One thing I'd 
like opinions on is whether 0-based counting is a 
good thing, or should be replaced with 1-based 
counting.

[snip]

> > >   - doesn't really handle use with strings, 
but
> > >      you can do that through
> > > 
> > >      ostringstream os;
> > >      os << format<char>("%2 %1")<< a >> b 
> > <<endf;
> > >      string s=os.str();
> > > 
> > >    (This seems error prone in that don't 
streams
> > >     expect their buffer to stay the type 
they 
> > created?)
> > 
> > All I can say to that is: If they do, they 
are 
> > severely broken -- basic_iostream doesn't 
have 
> > virtual functions and hiding virtual 
functions is 
> > flawed; and relying on the return type of 
rdbuf() 
> > being something other than the declared 
return 
> > type requires a (dynamic) cast, whose error 
> > condition should be checked.  If this isn't 
the 
> > way in which rdbuf() is supposed to be used, 
why 
> > isn't it protected?
> 
> Okay I am wrong here.  
> 
> Checking g++, they keep the stringstreambuf in
> the class and thus don't access the copy kept by
> ostream.  Thus you can make it work, but you are
> going to have to document that things like 
> below are an error
> 
>    ostringstream os;
>    os << format<char>("%1 %2")
>    os << i;
>    string s=os.str();
> 
> Here the string stream will not have gotten the 
charactors
> yet as it is still trapped in your proxy buffer.
> 
> Carefully document interactions here and then 
submit.

Certainly.  Perhaps there should be a companion 
class for doing things with strings.  I could 
rewrite the logic to shortcut things like "%0 %
1", but I think this would just break when things 
actually get reordered.

I rechecked the (draft) standard and although I 
think it is rather unclear because it has 
stringbuf::rdbuf() and filebuf::rdbuf() hiding 
the ios_base::rdbuf(), I am sure that it does not 
permit anything which is not what I expect.  
There remains one problem, which I think I can 
fix by specifying sync():

cout<<reorder("%1 %0");
cout<<foo>>encrypt(bar)<<baz>>snafu<<encrypt();

where encrypt(...) is some other manipulator 
which replaces the buffer, and encrypt() marks 
when that goes out of effect.  After baz, my code 
replaces the original buffer, which means that 
snafu will not be encrypted as expected.  I may 
write such an encrypt and see if there is common 
functionality which I can factor out; this may be 
necessary to make these buffer-replacers co-
operate.

[Stroustrup has such an encrypt as one of his 
exercises.  At least I assume he expects this 
kind of answer, as widen() isn't called when the 
output characters are of type char.]

> > > > manipulators and other output operators 
> > return 
> > > > ostreams.
> > > > 
> > > > This gives me a syntax like:
> > > > 
> > > > complex<double> a=4,b=5,c=11,d=67;
> > > > cout<< format<char>("%1 %3 %2 %4 ");
> > > > cout<< a >> b >> c >> d >> "foo!" << endl;
> > > 
> > > This seems dangerous if iostreams are used.
> > 
> > Yes.  I wish there was another operator with 
the 
> > same precedence.  As I say, the only good 
thing 
> > is that the << or >> or manipulator nearest 
the 
> > stream object controls the input/output 
semantics.
> > Thus,
> > 
> > fstream file("somefile");
> > file<<format<char>("%1 %3 %2 %4 ");
> > file<< 5 >> 6 >> 7 >> 8 >> endl;
> > 
> > is all output, not an erroroneous attempt to 
> > input into literals.  Of course, one could 
still 
> > easily do
> > 
> > file<<format<char>("%1 %2")<<foo;
> > file>>bar>>baz;
> > 
> > and be suprised when bar and baz don't get 
output.
> > Both
> > 
> > file<<format<char>("%1 %2")<<foo;
> > file>>hex<<bar>>endl;
> > 
> > file<<format<char>("%1 %2")<<foo;
> > file>>bar>>"\n";
> > 
> > and variations thereon naturally cause 
errors.  
> > The only way in which it gives maximal 
surprise 
> > is when you have an 
> > iostream>>var1>>var2>>...>>varn; statement 
with 
> > no literals and no attempts to do un"tabbed" 
> > output.
> 
> This is a fair bit of a downer.  But lets see 
if 
> others feel is a problem.
> 
> --Karl

Cheers,

James

-------------------------------------------------
This mail sent through UK Online webmail