You're done once the data reaches here. There's no guaranteed way to
bypass this caching, nor any value in doing so for most applications
(certainly any application using fstream). We can pretend it does not
exist.

Moving data between processors is actually pretty cheap, especially
compared to making system calls. However, if more system calls than

Well. That's more than 10 years!

Anyways, given how the MS compiler handles C and C++, my personaly guess
would be that they compile their kernel code with the C++ compiler mode
but write mostly "C" code. I may be totally wrong of course.

What information is this statement based on?

In C++11 you can do this:

int myints[] = { 16, 2, 77, 29 };
std::vector<int> fifth(std::begin(myints), std::end(myints));

It might even be standard to omit the "std::begin()" part and use
'myints' directly as the first parameter, as std::end() probably always
returns an int* in this case. In other words:

That issue isn't caused by the sender, only by the receiver's Usenet client.
Text lines which exceed 77 characters are perfectly valid, and they are
properly handled by some Usenet clients. The only problem which may be
associated with them is that some Usenet clients do a bad job handling long

Op 18-May-12 0:13, Mike Copeland schreef:

I vaguely remember there was an issue with the iostream implementation
that came with Visual Studio 6.0 which made it very slow. I believe it
had to do something with constantly syncing with the stdio, and that it
could be disabled.

I don't understand what you're getting at. It's obvious from his
posting that A and B only exist as placeholder names in the posting
itself. And it's obvious from *our* postings that we don't like that.
What's there to argue about?

...

I don't want to be involved in a heated discussion about that, too.

I wasn't telling him he didn't need it -- I was *asking* him.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

well I think A and B are poor names. I really hope the actual code doesn't use them. How do you /know/ A and B have meaning and responsibilities assigned to them?

Besides we do know that A "manages requests/commands from external systems". So ProcessExternalCommand:: seems pretty reasonable.

That's such a "windowsy" answer. "If you can't do it, you don't need it."

"Can be used safely" != "safe".

Did you miss the "optimize the code on a type-by-type basis" part?

On 17 May 2012 21:28:53 GMT, sc...@slp53.sl.home (Scott Lurndal)
wrote:

If he was going to do something that system dependent, it would be far
better to just use the Windows CopyFile() API.

Look at the public methods of the filebuf object in the fstream to set
you own buffer.

scott

I can't repeat that result here (Linux, gcc -Os).

fVar2 << line << endl;

./filecopy 0.89s user 2.81s system 98% cpu 3.774 total
./filecopy 0.78s user 2.77s system 97% cpu 3.623 total
./filecopy 0.68s user 2.68s system 98% cpu 3.421 total

fVar2 << line << '\n';

./filecopy 0.36s user 0.19s system 97% cpu 0.565 total

Instead, for this context I'd suggest:
fVar2 << line << '\n';

Also, fstream exposes a read() member function. You can do the same
fixed-size buffer approach, and that may get you better results. As
is, you're reading in potentially very small lines, resulting in more
work than necessary.

You need to learn your tools. Determine if it's an optimized build or
not, and get back to us. If you're using default settings, there's
probably a toolbar with a couple dropdowns, one for "config" and one
for "platform". Currently, the toolbar in my IDE reads; "Debug"
"Win32". Change "Debug" to "Release", compile, run, and see if that

In article <p4etr.3$l...@news.usenetserve r.com>, sc...@slp53.sl.home
says...

That's not the point here: I'm writing applications that do a lot of
text file I/o and am trying to convert fgets/fputs/setbuf logic (with C-
style strings) to fstream/string processing. My first tests of such

In article <slrnjraqrk.rk7.grahn+n...@fra ilea.sa.invalid>,
grahn+n...@snipabacken.se says...
And doing so (appending the '\n' to "line" prior to writing it) has
no effect. I.e.

while(getline(fVar1, line))
{
line +='\n';
fVar2 << line;
}

Same 12x-13x performance degradation with this code versus

Doing so has no effect whatsoever; code follows:

line +='\n';
fVar2 << line;

In article <d6c93c71-68ed-42a0-a7fd-79337 601c170@googlegroups.com>,
carte...@gmail.com says...
Okay, that's useful. Guess I'll have to append a '\n' to the data
line prior to the "<<" operator. 8<}}

In article <a328e357-9312-4971-99ba-1b18c 2f21d86
@s9g2000pbc.googlegroups.com>, joshuamaur...@gmail.com says...
Unfortunately, a "silly answer": I don't know what compiler flags
and/or efficiencies are involved (don't know how to find out...), and
it's VS6.0 (which everyone here condemns, but it's all I have.