- Why cout.flush() does not seem to "work"? - 9 Updates
- What's up with "Large Scale C++" - 7 Updates
- Idiots - 1 Update
| JiiPee <no@notvalid.com>: Nov 26 12:03AM On 25/11/2015 19:41, Luca Risolia wrote: >> beginning of the run. > Consider using std::clog instead of std::cout. Any output sent to the > former is immediately flushed (although this is not the only difference). But here I was more like wanting to deside myself when to flush everything. But it seems like Microsoft flushes when it wants. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 26 12:17AM On Thu, 2015-11-26, JiiPee wrote: >> former is immediately flushed (although this is not the only difference). > But here I was more like wanting to deside myself when to flush > everything. But it seems like Microsoft flushes when it wants. Well, if I look at your original posting, you wanted to print to cout Start... End but not make it actually print until later, when you flush. It seems to me that if you want something printed later, you have to print it later. For example, you can't expect cout to keep a gigabyte of text, waiting for your permission to actually output it. That's not its job. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Rosario19 <Ros@invalid.invalid>: Nov 26 12:20PM +0100 On Tue, 24 Nov 2015 20:09:17 +0000, JiiPee wrote: >ok, so cout might or might not flush if I do: >cout<< "Hello"; >at any time. in my understand when buffer of stdoud is full there is the flush in C if one has one string has "\n" the buffer is fhush when it meet "\n" if i remember well |
| JiiPee <no@notvalid.com>: Nov 26 06:56PM On 26/11/2015 00:17, Jorgen Grahn wrote: > of text, waiting for your permission to actually output it. That's > not its job. > /Jorgen ye sure I could print it later. Not sure why would I want to wait ... but there might be situations where you want to wait.. not sure... Just wanted some logic for this |
| JiiPee <no@notvalid.com>: Nov 26 06:56PM On 26/11/2015 00:17, Jorgen Grahn wrote: > Well, if I look at your original posting, you wanted to print to cout > Start... > End ye sure in that example we want it like that. But am talking generally.... |
| JiiPee <no@notvalid.com>: Nov 26 06:58PM On 26/11/2015 11:20, Rosario19 wrote: >> cout<< "Hello"; >> at any time. > in my understand when buffer of stdoud is full there is the flush But even if I cout only character: cout<< "s"; it flushes it straight away. |
| Vir Campestris <vir.campestris@invalid.invalid>: Nov 26 09:33PM On 26/11/2015 18:58, JiiPee wrote: > But even if I cout only character: > cout<< "s"; > it flushes it straight away. It can flush whenever it wants. There are ways to force it to flush, but AFAIK no way to make it hold on to characters you've told it to write. Why would it? Andy |
| "Öö Tiib" <ootiib@hot.ee>: Nov 26 01:54PM -0800 On Thursday, 26 November 2015 20:58:32 UTC+2, JiiPee wrote: > But even if I cout only character: > cout<< "s"; > it flushes it straight away. Yes, Alf P. Steinbach already wrote that *Visual Studio* flushes *terminal output* after every character. There are no output buffer/lazy output. You must make it clear to yourself what you want. Then it is easy to see what to do: * If you want to wait with output then wait. Do not output. * If you do not care then just output. * If you want to be sure that output is complete then flush the buffer (or with C++ streams use std::endl instead of '\r'). |
| JiiPee <no@notvalid.com>: Nov 26 10:07PM On 26/11/2015 21:54, Öö Tiib wrote: > * If you do not care then just output. > * If you want to be sure that output is complete then flush the buffer (or > with C++ streams use std::endl instead of '\r'). sure, those are the options |
| Ian Collins <ian-news@hotmail.com>: Nov 26 12:45PM +1300 Richard wrote: > If your team doesn't agree with the values in the agile manifesto, > then you have a tougher time of it. Sometimes you can transform a > team from inside, sometimes not. I've had a mixed experience introducing agile into teams. Two successful, one not for the reasons you cite above. As the old Meatloaf song goes, two out of three ain't bad! -- Ian Collins |
| woodbrian77@gmail.com: Nov 25 07:46PM -0800 On Monday, November 23, 2015 at 5:47:03 PM UTC-6, Paavo Helde wrote: > IMO, the main issue with large scale projects is that no single person > has a clear overview what the system does. Sorry, but I have to disagree. "The L-rd looks from heaven; He sees all the sons of men; From His dwelling place He looks out On all the inhabitants of the earth, He who fashions the hearts of them all, He who understands all their works." Psalms 33:13-15 "For who has known the mind of the L-rd, that he will instruct Him? But we have the mind of Christ." First Corinthians 2:16 "Unless the L-rd builds the house, they labor in vain that build it." Psalms 127:1 "And we know that G-d causes all things to work together for good to those who love G-d, to those who are called according to His purpose." Romans 8:28 G-d leads us through difficulties. He uses the difficulties to draw us closer to Him. Brian Ebenezer Enterprises http://webEbenezer.net |
| Ian Collins <ian-news@hotmail.com>: Nov 26 04:56PM +1300 >> IMO, the main issue with large scale projects is that no single person >> has a clear overview what the system does. > Sorry, but I have to disagree. There's a time and a place for proselytising, c.l.c++ isn't it. -- Ian Collins |
| Bo Persson <bop@gmb.dk>: Nov 26 04:59PM +0100 > according to His purpose." Romans 8:28 > G-d leads us through difficulties. He uses the difficulties > to draw us closer to Him. Easy on the sausages. |
| woodbrian77@gmail.com: Nov 26 08:33AM -0800 On Thursday, November 26, 2015 at 10:00:04 AM UTC-6, Bo Persson wrote: > > G-d leads us through difficulties. He uses the difficulties > > to draw us closer to Him. > Easy on the sausages. I believe in a different/better way. We should be able to do more with less. The way that others have been discussing will do less with more. It has diminishing returns. |
| Puppet_Sock <puppet_sock@hotmail.com>: Nov 26 09:08AM -0800 On Wednesday, November 25, 2015 at 6:20:03 PM UTC-5, Paavo Helde wrote: > to write their own. Sometimes the defects and problems would come out only > after some years of usage. It is more like an art to know when to reuse the > existing and when exactly the wheel needs reinventing. I'm not talking about reinventing. One of my big complaints about the existing tools is that they don't use standard libraries, nor even commercial code base that is widely available. Standard stuff like a matrix inversion routine has been done from scratch. Often three or four different ways in one code. And sadly often in an obfuscated way such that verifying it is correct is a total pain. So, for example, one code I have flattened my forhead on the terminal over has a matrix inversion routine with a fixed size matrix. So the code can only analyze one size array. Indeed, it would not be straightforward to change that size in the source code and re-compile, because the size appears in a bunch of places. So when the manager wanted to explore the consequences of changing the number of things this matrix represented, I had to tell him no. At least, not in the budget he suggested. This is FORTRAN from the 1970s in many cases. It started life when punch cards were the rage. I've even found Hollerith codes in there. It is really difficult to use, to understand, to maintain, and to verify as correct. And moving it to another platform is an Odyssey level task. I'm quite sure I could do better. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 26 01:43PM -0800 On Thursday, 26 November 2015 19:09:06 UTC+2, Puppet_Sock wrote: > from scratch. Often three or four different ways in > one code. And sadly often in an obfuscated way such > that verifying it is correct is a total pain. Matrix inversion is controversial topic. Inverting matrices is expensive and if code-base inverts matrices a lot then things are likely bad with it. Majority (likely all) of the problems solved with matrix inversion can be solved with cheaper methods. We can use use a variety of direct (like LU, QR, SVD or Cholesky decomposition), semi-direct (like conjugate gradients), or iterative (like multi-grid or over-relaxation) methods. The methods tend to make solution way cheaper than inverting matrices. It is possible that there are problems where inverting matrices can not be avoided or is more optimal but it is hard to find such examples. > and to verify as correct. And moving it to another > platform is an Odyssey level task. > I'm quite sure I could do better. Yes, what you wrote makes it sound likely that you can do same thing better even in FORTRAN. ;) The only trouble might be to find a team of people proficient with both math and C++. |
| asetofsymbols@gmail.com: Nov 26 08:38AM -0800 ) Use the memory allocated by std::vector<POD>::reserve() without constructing elements by bypassing std::vector's modification functions (e.g. push_back). Use this newsgroup with caution. /Flibble ------- For me, as the function variables Malloc function has to minimize operation alloc -free as a stack too Example m=malloc(size) r=malloc(size) ... free(r) free(m) Minimize free() as 1 operation as It was in one stack memory operation One can use the debugger for see Malloc - free alloc dealloc always the same address ... Or the same set of address I don't know if that minimize malloc instruction 100% for sure. But it would be good, if one thinking on the cpu, and memory already load |
| 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. |
No comments:
Post a Comment