Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!usc!bloom-beacon!eru!luth!sunic!mcsun!tuvie!inst182
From: inst182@tuvie (Inst.f.Techn.Informatik)
Newsgroups: comp.lang.c++
Subject: Formatted Output Revisited
Message-ID: <738@tuvie>
Date: 16 Oct 89 12:09:53 GMT
Organization: TU Vienna EDP-Center, Vienna, AUSTRIA
Lines: 113



It's high time the problem of formatted output be addressed.
   
The current method of providing formatted output ( the form()
function with format strings a` la `C') is not a particularly 
logical and/or efficient method. Here are some reasons AGAINST 
using form():
	
	+ no optimization can be done; if you want to output
	  even a trivial thing like form("d=%d\n",d) and you       
	  have to parse the output string over and over again.
	+ since form() is declared as somthing like 
		char *form(char *format, ...);
	  no typechecking can be done (neither at compile- nor 
	  at runtime). Things like 
		{
			int *a;
			*a = 1;
			printf("%d\n",a);
		}
	  have happend to almost anyone of us, we dont want this
	  to happen in `C++' as well.
	+ Extending form to handle user-defined types is impossible.
	  (Ok, maybe *YOU* fancy writing a new form() function
	  for each and every of your programs. Most of us don't.)
	  So if form() becomes a standard, it will mess up one 
	  of the main ideas that seem to be behind the development 
	  of C++, namely that you should be able to handle your own
	  classes no different from the standard classes. 

One possible solution is to introduce a new operator that handles
formatting. A nice thing would be to write:
	cout <<4:2<<5.2:6:4;
The precedence would have to be between the likes of + and <<.
But obviously the colon is not suitable because of its use in ?:,
invalidating all C++ code thus far written.
 
Moreover, `:' is difficult to spot. Two unused ASCII characters remain:
`@' and `#'. So what about 
	cout <<4#2<<5.2#6#4;
or
	cout <<4@2<<5.2@6@4;

The definition of # could be something like:

	operator#:	int x int -> int_form
	operator#:	int_form x int -> int_form_form
	
	operator<<:	ostream& x int_form_form -> ostream&

and a constructor 		

	int_form_form:	int_form -> int_form_form

It is also possible to use the new operator to also specify a format 
string:
	cout <<4#'x'#2<<5.2#'f'#6#4;
( The format character would have to go in the first place, because 
the 2nd and 3rd call to operator# are optional.)

Other possibilities involve using both `#' and `@':

	cout <<4#2@'x';
or 
	cout <<4@'x'#2;

This also handles format characters.

The advantages of this method are:

	+ Typechecking is possible at compile-time.
	+ This concept can be used with user-defined types as well.
	+ The use of a format operator logically extends the idea of
	  using input/output operators. 
	+ Optimization is possible: If the operator# functions are
	  inlined, constant propagation can be used to select the 
	  most efficient formatting algorithm. (NOt the whole
	  operator# needs to be inline code, but only some 
	  kind of switch() statement which selects the right call
	  to the formatting function.)
	+ It doesn't involve writing a lot of extra chars. (That's
	  important!!! :-)
	  [ You also could use a format(int val, int fchar, int x1 
	    = defvalue1, int x2 = defvalue2). But this involves
	    a lot more characters. ]
	
Some arguments against this idea and possible answers:

	+ Who needs new operators, this is supposed to be an OO-C,
	  not a new language.
	++ The new() and delete() operators didn't exist in C either.

	+ We don't want to mess up the language with output, format,
	  i/o operations. That's library stuff.
	++ Nor do I. Let's put the implementation of the operator in
	   a library (see also: optimization when inlining). If 
	   someone wants to write her/his own output functions, he needs
	   not include the header file. The operator per se is 
	   value-free. Only the implementation makes it a formatted output
	   operator. If you want it do have any other meaning, you can
	   implement it, to do whatever you like. Just like <<.


 +----------------------------------------------------------------------------+ 
 |       ____  ____      |                                                    |
 |      /   / / / /      |                Michael K. Gschwind                 |
 |     /   / / / /       |                                                    |
 |     ---/              |----------------------------------------------------|
 |       /               |                                                    |
 |   ___/                |       ...!uunet!mcvax!tuvie!eimoni!gschwind        |
 |                       |                                                    |
 +----------------------------------------------------------------------------+