Tuesday, November 24, 2015

Digest for comp.lang.c++@googlegroups.com - 14 updates in 4 topics

Noob <dontspam@me.com>: Nov 24 08:18PM -0200

On 21/11/2015 11:08, Jorgen Grahn wrote:
 
> Whenever a piece of code deviates from that, I spend a few seconds to
> check it for correctness.
 
> /Jorgen
 
Yes, I think this is a good point. Also valid in Fortran. I had that
construct in that form for historical reasons. I've already changed
it to the "standard" form. Thank you.
 
BTW: I know this is not the place for such off-topic and subjective
stuff, but I'm really enjoying C++. I always thought that the real
advantage of C++ over Fortran was the ease for OOP (which Fortran kind
of supports nowadays), but now I see that template metaprogramming is
one of C++'s strongest points.
 
I'm already using a profiler and I think it's telling me that my
program is spending a considerable amount of time in allocations. Maybe
I should not use std::vector so indiscriminately. I'll let it be for the
moment because I don't think this will be reason for concern after I
include the really intensive computations.
 
Cheers.
JiiPee <no@notvalid.com>: Nov 24 07:21PM

I understood that cout flushes only after we call flush().
But if I run a code (Visual Studio):
 
cout<<"Start ....\n";
 
<doing something many seconds, like Sleep or a long for-loop>
 
cout<<"End";
cout.flush();
 
But this does not work like expected: it straight away prints
"Start...." and then waits some seconds (bce of sleep or for loop) and
then prints "End". why does cout flush immedistely when running the
program even though nothing flushes it?
 
I am expecting everything to be printed at the end and nothing at the
beginning of the run.
scott@slp53.sl.home (Scott Lurndal): Nov 24 07:48PM

>I understood that cout flushes only after we call flush().
>But if I run a code (Visual Studio):
 
>cout<<"Start ....\n";
 
The '\n' causes the flush.
Barry Schwarz <schwarzb@dqel.com>: Nov 24 11:52AM -0800


>I understood that cout flushes only after we call flush().
 
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
 
>cout.flush();
 
>But this does not work like expected: it straight away prints
>"Start...." and then waits some seconds (bce of sleep or for loop) and
 
On many hosted systems, the \n will cause the data to be sent.
 
>then prints "End". why does cout flush immedistely when running the
>program even though nothing flushes it?
 
It would have been interesting if you had placed a similar delay
between outputting the text and flushing the stream. Then you would
have been able to determine if the cout stream on your system waits
for a flush or a \n.
 
>I am expecting everything to be printed at the end and nothing at the
>beginning of the run.
 
Just to compound matters, the system could behave differently for that
last output if you are sending data to a disk file as opposed to the
monitor.
 
--
Remove del for email
JiiPee <no@notvalid.com>: Nov 24 08:03PM

On 24/11/2015 19:48, Scott Lurndal wrote:
>> But if I run a code (Visual Studio):
 
>> cout<<"Start ....\n";
> The '\n' causes the flush.
 
But if I take out \n I still get the same result . Here is my code:
 
int main()
{
int n;
string x;
 
cout << "start";
 
std::this_thread::sleep_for(std::chrono::milliseconds(5000));
 
cout << "finished";
return 0;
}
JiiPee <no@notvalid.com>: Nov 24 08:07PM

On 24/11/2015 19:52, Barry Schwarz wrote:
> guaranteed to send all the data in the buffer to the device. However,
> the system is allowed to send the data or a portion of it any other
> time it deems it appropriate.
 
ok, so I guess a compiler can deside to flush whenever it wants...
 
> between outputting the text and flushing the stream. Then you would
> have been able to determine if the cout stream on your system waits
> for a flush or a \n.
 
but there was no delay when I did the first cout (without a flush or
even \n). So flush does not seem to make any difference here.
JiiPee <no@notvalid.com>: Nov 24 08:09PM

On 24/11/2015 19:52, Barry Schwarz wrote:
> guaranteed to send all the data in the buffer to the device. However,
> the system is allowed to send the data or a portion of it any other
> time it deems it appropriate.
 
ok, so cout might or might not flush if I do:
cout<< "Hello";
at any time.
Vir Campestris <vir.campestris@invalid.invalid>: Nov 24 09:06PM

On 24/11/2015 20:09, JiiPee wrote:
> ok, so cout might or might not flush if I do:
> cout<< "Hello";
> at any time.
 
That's correct. But push a std::endl and it will flush. (but not
_necessarily_ a \n)
 
See http://en.cppreference.com/w/cpp/io/manip/endl
 
Andy
Geoff <geoff@invalid.invalid>: Nov 24 01:14PM -0800

>> the system is allowed to send the data or a portion of it any other
>> time it deems it appropriate.
 
>ok, so I guess a compiler can deside to flush whenever it wants...
 
The compiler doesn't get to choose.
 
It's the operating system that determines what gets "flushed" and
when. The system can send the output immediately or after some
indeterminate delay which will be a function of what the state of the
system is at that moment. A console window may not be "busy" and
therefore the data appears without delay.
 
>> for a flush or a \n.
 
>but there was no delay when I did the first cout (without a flush or
>even \n). So flush does not seem to make any difference here.
 
This can't be observed in a primitive program such as you have posted.
There is nothing keeping the system "busy" enough to show an
observable delay and you have not bracketed the cout with any timer
with resolution fine enough to measure the delay between the cout and
the appearance of the text on a console.
 
Furthermore, program termination flushes all buffers so immediate
termination after cout << "finished"; causes immediate output without
delay (or at least measurable delay per above.
Geoff <geoff@invalid.invalid>: Nov 24 01:24PM -0800


> cout << "finished";
>return 0;
>}
 
Above is not compilable on my system. I'm using VS2010:
 
#include <Windows.h>
#include <iostream>
#include <string>
 
using namespace std;
 
int main()
{
string x;
 
cout << "start ";
 
Sleep(5000);
 
cout << "finished ";
return 0;
}
 
The console associated with this process is not blocked by Sleep().
The "start" is immediately transmitted and appears in the window.
The program defines the sequence of events:
cout
sleep
cout
terminate
 
Since there is no part of the process that blocks output to the
console it will flush the "start", then sleep, then cout again with
program termination producing an automatic flush of all remaining
output. The program is performing as the code specified. I can't think
of a method off-hand that might make the console busy such that it
won't display the output.
 
\n may or may not produce or influence flushing, only std::endl
guarantees that as far as I know.
Paavo Helde <myfirstname@osa.pri.ee>: Nov 23 05:46PM -0600

Puppet_Sock <puppet_sock@hotmail.com> wrote in news:f75b3dd3-14e1-49e3-
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
 
IMO, the main issue with large scale projects is that no single person
has a clear overview what the system does. This means that the whole
project must be to some extent regular or modular in the sense that one
can extend or modify it locally without breaking too much stuff
elsewhere. A great way to achieve that is of course, as suggested by
others, to break the project down into smaller components communicating
over well-defined interfaces. The size of a single component is limited
by the brain capacity of the dumbest developer in your team.
 
To ensure that the pieces work well together one needs to have automated
unit and integration tests. This is because when you combine the pieces
nobody can fully understand the emerging system any more, so dealing with
it must be automated. I would even say that if there is a managable
project without automated tests, then one cannot call it a large-scale
project, more or less by definition.
 
Disclaimer: I have not read the book either.
 
hth
Paavo
Puppet_Sock <puppet_sock@hotmail.com>: Nov 24 11:53AM -0800

On Monday, November 23, 2015 at 11:38:32 AM UTC-5, Alf P. Steinbach wrote:
> a team effort.
 
> So it's very much about leading a team and dealing with economy and
> politics.
 
[snips]
 
Any suggestions on good sources for reading on this?
 
> You would probably not go very wrong in adopting the coding guidelines
> book by Alexandrescu and Sutter, perhaps with some adjustments.
 
I have enjoyed work by each of these persons. Will
get their book.
 
[advice on object name collision snipped]
 
Thanks. It may change my choice of development tools.
Which choice is not made yet since not even the
proof-of-concept study is funded yet.
 
[advice on need for source code control snipped]
 
Aware of the need. Bracing myself to have that discussion
on some other forum. Not looking forward to it.
Puppet_Sock <puppet_sock@hotmail.com>: Nov 24 12:28PM -0800

On Monday, November 23, 2015 at 11:46:11 AM UTC-5, Jorgen Grahn wrote:
[snips]
> My first instinct (which may be wrong in this case) is that that's a
> warning signal. It's better if you can keep it smaller than "very
> large", or split it into smaller parts ...
 
Some times that isn't possible.
 
I hope I can split things up into a pile of individually
small objects, each with relatively simple interactions.
 
Problem is, the physical engineering system I'm trying
to solve has a lot of distinct parts, with a lot of
important interactions. And emperical correlations with
system properties, and so on. So there are going to be
a large number of those small objects, and a large number
of types of them. With rich behaviours. And the user
input is likely to be fairly rich. With a complicated
output for the user to look at.
 
So, the overall system is likely to be pretty complicated.
Or at least extensive.
 
This complexity is, by the way, one of the reasons I have
been having a job getting somebody to buy this project.
People agree it would be great to have the tool I suggest,
but nobody wants to pay for it. Even though there have
been three projects to search out what could and should
be done.
ram@zedat.fu-berlin.de (Stefan Ram): Nov 23 11:30PM

>on writing very large C++ programs would be gladly accepted.
>If the project I am trying to sell goes ahead, it could easily
>become very large.
 
How can one imagine a large program?
 
#include <iostream>
 
int main()
{
std::cout << "Hello, World!\n";
}
 
Expand all that is happening when »<<« is executed, and you
will see the complexity and size. It goes beyond the C++ library
right into the OS code for the console or file the program writes
to and further down into the graphics or disk driver.
 
»Fools ignore complexity.
Pragmatists suffer it.
Some can avoid it.
Geniuses remove it.«
 
ALAN PERLIS
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)