There are equally as many cases where you *don't* want the output to be atomic.  It is slower to write into this temporary buffer, before sending the final buffer to the stream, than to write directly into the stream's buffer.  Besides, you don't usually know how big of a buffer you're going to need before you start writing.

Streams are always buffered, right?  If so there's a nice Flush() command
somewhere.

Unbuffered streams are horribly inefficient.

Sean

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:boec1m$1j08$3@digitaldaemon.com...
> > This got me thinking about message chaining in Object C and SmallTalk
(or
> > message cascading...)
> > Maybe a whole new syntax could help and possibly replace printf and ~.
> > Something like
> >
> >   stdout.printf["hello", " world", 47, "\nbar", ("%06i\n", 62)];
> >   string.cat["a", "bc", 47, "def"];
> >
> > would turn into
> >
> >   stdout.printf("hello").printf("
> > world").printf(47).printf("\nbar").printf("%06i\n", 62);
> >   string.cat("a").cat("bc").cat(47).cat("def");
> >
> > I haven't thought about if this syntax conflicts with anything else or
is
> > implementable ;-)
> > -Ben
>
> I think the point of the concatenated (not concatenating, mind you) syntax
> is that the write operation would be atomic, which would certainly need to
> be the case to system streams such as the log stream, and to process-wide
> streams in
> a multi-threaded process.
>
> If your example translates to a function that does that, by concatenating all input in a buffer, and then sending that to the requisite output
stream
> in a single operation, then I would think it worth pursuing.

That is not a problem.  It's "writing" directly into the stream's buffer. The actual write happens upon buffer flushes.

Sean

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:boec1l$1j08$2@digitaldaemon.com...
> You lose atomicity of write.
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:boe43g$16ri$1@digitaldaemon.com...
> > Why not implement it like this?:
> >
> > void print(... args)
> > {
> >     foreach(v in args)
> >         v.print(stdout);
> > }
> >
> > Every type then would be required to provide a print function to a
stream.
> > There could be several such functions (auto-generated if not explicitly provided, of course) that read and write to/from text or binary streams. The auto-generated functions would perhaps just call the base class
> function
> > then print the new members.
> >
> > Sean

Because typesafe varargs is useful for lots of things besides I/O.

Sean

"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:boe5fs$18se$1@digitaldaemon.com...
>
> Why not make IO a more formal operation.
>
> Introduce a new keyword "write"
>
> Syntax: write object, param [,param]*;
>

"Walter" <walter@digitalmars.com> wrote in message news:bojg4f$2qpr$1@digitaldaemon.com...
> > On the other hand it doesn't solve the inefficiency problem of "C++ <<",
> > effecitivly producing a flood of
> >    func(this,fmt[,type])
> > calls.
>
> I'm not sure why C++'s way fares so poorly. What it won't need to do is
have
> a specialized parser for printf's format string, which takes time.

We went over a way to reduce that inefficiency at one point.

We actually did measure considerable overhead in the printf string parsing, in our game at one point, the font drawing function was routing everything thru sprintf.  The signature of the draw function was:

void Font::Draw(Vc3, Color, char const*, ...);

When we changed

Font().Draw(Vc3(40,50), Color::red, "My big long string");

to:

Font().Draw(Vc3(40,50), Color::red, "%s", "My big long string");

we got a huge savings.

Sean

> I'm not buying into your dogma.

Probably wise, as I think I had my Devil's Advocate head on in this discussion

I'm sorry, maybe I wasn't clear in what I was suggesting.  I was suggesting that the following expression:
	stdout ~ ("%d", foo);
would call the following member function:
	class Stdout {
		Stdout cat(char[], int);
	}
whereas simple uses (without parens) would get mapped to single-argument versions of cat().  So this line:
	stdout ~ "asdf" ~ ("%d", foo);
would be exactly equivalent to
	stdout.cat("asdf").cat("%d", foo);

Russ

Walter wrote:
> In general, a~b is overloaded by looking at the types of a and the types of
> b. The type of a here is Stdout. The type of b, however, is the type of foo.
> That isn't going to use the overload of ().
> 
>>>>What about this syntax:
>>>>
>>>>stdout ~ "asdf" ~ ("%d", foo);

This all doesn't help me, to output objects of my own classes, does it?

Walter wrote:

> (Note that it retains the power of printf!) The issue here is how the syntax
> stdout("foo")("bar") looks. In C++ it would look like stdout<<"foo"<<"bar"
> which I don't find appealing.

stdout << "foo" << "bar";

Does indeed not loop very appealing. I personally would have liked better:

stdout << "foo", "bar", i, "\n", "second line", nl;

Jan

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:bod3l8$2o2j$1@digitaldaemon.com...
> Old italian hackers use USA keyboards, but not all employers agree to buy
one
> for every developer.

I hate to be annoying <g>, but a USA keyboard can be had for $9.99 around here. Mine cost $19.99, but that's only because I just cannot stand the oversized Enter key that substitutes for the \ key. Every time I hit \, I get Enter instead and the command gets prematurely executed, sometimes with disastrous results:

    rm -r foo\bar

becomes:

    rm -r foo

Argggh! Why can't these layouts be standardized?

C++ tried to get around the keyboard problem by introducing digraphs. When that failed, trigraphs were introduced. That's failed too, and now there's \uxxxx, etc.

(By failed I mean that I see a lot of code from all over the world, and never once have I seen any code outside of a test suite that used digraphs, trigraphs, or \u or \U.)

The C/C++ experiments with this show that there isn't a known decent solution. What I do to input funky characters is cut & paste them from a palette of them.

> I hate to be annoying <g>, but a USA keyboard can be had for $9.99 around
> here. Mine cost $19.99, but that's only because I just cannot stand the
> oversized Enter key that substitutes for the \ key. Every time I hit \, I
> get Enter instead and the command gets prematurely executed, sometimes with
> disastrous results:


I have that large Enter. What used to bug me is backspace being smaller and me constantly bumping the insert key; that is, until I pulled the key out :D


-- 
Christopher E. Miller
www.dprogramming.com
irc.dprogramming.com #D