- What's up with "Large Scale C++" - 11 Updates
- Why cout.flush() does not seem to "work"? - 8 Updates
- Help improving this little function, if necessary. - 3 Updates
- Why cout.flush() does not seem to "work"? - 1 Update
| legalize+jeeves@mail.xmission.com (Richard): Nov 24 11:57PM [Please do not mail me a copy of your followup] Puppet_Sock <puppet_sock@hotmail.com> spake the secret code >On Monday, November 23, 2015 at 11:38:32 AM UTC-5, Alf P. Steinbach wrote: >> So it's very much about leading a team and dealing with economy and >> politics. Agreed. >[snips] >Any suggestions on good sources for reading on this? IMO, beyond specifics of the language involved, all software development projects small or large deal with the same problems. Most of these problems stem from the nature of software development and aren't really "solved" in any magical sort of way. You can read Fred Brooks's stories in "Mythical Man Month" <http://amzn.to/1MB5hGb> and the exact same stuff happens now as happened then in the 1960s/1970s. Some suggestions in no particular order: "Domain-Driven Design" by Eric Evans <http://amzn.to/1HldHCG> "Implementing Domain-Driven Design" by Vaughn Vernon <http://amzn.to/1Nr9pfr> These two books are complementary to each other with Vernon's coming 10 years after Evans' important contribution to OO architecture thinking. "Extreme Programming Explained", 2nd ed., by Kent Beck <http://amzn.to/1HldSxP> "Agile Software Development: The Cooperative Game" by Alistair Cockburn <http://amzn.to/1MB4NA0> A good exploration of agile software development. Beck's is more tactical and Cockburn's is more strategic. Kent Beck and Alistair Cockburn are both signers of the Agile Manifesto. <https://en.wikipedia.org/wiki/Agile_software_development#cite_note-12> "Modern C++ Programming with Test-Driven Development" by Jeff Langr <http://amzn.to/1T1I1D2> Excellent treatment of TDD using modern C++ for all the examples. "User Story Mapping" by Jeff Patton <http://amzn.to/1T1IOnj> Excellent discussion on how to make sure you are not just building something, but building the *right* thing. Disclaimer: I've known Jeff Patton and Alistair Cockburn for years. I recommend their books because they are full of great stuff. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Robert Wessel <robertwessel2@yahoo.com>: Nov 24 06:05PM -0600 On Tue, 24 Nov 2015 12:28:24 -0800 (PST), Puppet_Sock >but nobody wants to pay for it. Even though there have >been three projects to search out what could and should >be done. Well, software development is expensive (and I don't mean to imply that the only form of payment for that expense is money), and large projects are *very* expensive, and have a very high risk of failure. And given how many times people have been burned, it's no wonder that they're shy about committing financially to a big project, especially if you don't have a track record, or the project definition includes a bunch of hand waving, not to mention the risk that the long development time itself poses (the world may just move on from the requirement). Anyway, you might consider trying to structure this incrementally. So you can build a reasonable sized thing that can demonstrate that the project is on the right track. For a sufficiently large project, you may end up planning several milestones. At some point you have shippable product, but again, you may want to get there before you can do everything. At each milestone the investors can evaluate where things are, how the marketing is changing, and how the system is starting to shape up, not to mention your performance. But basically some reasonable sized bites may be an easier sell than one big project. OTOH, that's certainly worse for you - the investors might just lose interest at some point, and you've got little recourse. |
| seeplus <gizmomaker@bigpond.com>: Nov 25 12:04AM -0800 On Tuesday, November 24, 2015 at 2:23:24 AM UTC+11, Puppet_Sock wrote: > So, some time ago (grumble mumble years...) I read John Lakos > _Large Scale C++_. The only thing is, it was mumble years ago, InformIT have a new livelessons vid by John Lakos on getting into large scale C++. You can look at a couple of episodes free. List of topics in the vid is fairly arduous going. Also old books, including his, there. There is a BF sale at present. |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 25 02:38AM -0600 legalize+jeeves@mail.xmission.com (Richard) wrote in > <http://amzn.to/1MB4NA0> > A good exploration of agile software development. Beck's is more > tactical and Cockburn's is more strategic. A word of caution about things called "agile". When implemented wrongly, the agile approach may be interpreted to prescribe that all of the team has about the same overview of the whole system so each member can replace any other. With large projects, this is just not possible. (When done right, the agile approach seems to become a synonym with "use some common sense and do whatever works well for your project", which is great of course but I am not sure why a buzzword is needed for doing that.) Cheers Paavo |
| Puppet_Sock <puppet_sock@hotmail.com>: Nov 25 06:42AM -0800 On Tuesday, November 24, 2015 at 6:58:06 PM UTC-5, Richard wrote: [good suggestions on books about the development process snipped] Thanks Richard. Some of these I have already read and thought very good. Most of them are new to me, and look to be very helpful. |
| Puppet_Sock <puppet_sock@hotmail.com>: Nov 25 06:55AM -0800 On Tuesday, November 24, 2015 at 7:05:51 PM UTC-5, robert...@yahoo.com wrote: [snips] > some reasonable sized bites may be an easier sell than one big > project. OTOH, that's certainly worse for you - the investors might > just lose interest at some point, and you've got little recourse. I agree with the general ideas of your post. There certainly is room for incremental improvements. Mostly I want to be sure that any small part of the solution I manage to sell will provide a good stepping stone to a larger solution. This is why I want to "swatt up" on large projects. I want to try to avoid pitfalls in my early stages. I want to be able to add lots of new stuff onto the starting parts and not have the expanding system collapse. The reason I persist trying to sell this project is the nature of my industry. Mistakes in design and construction tend to be grossly expensive to correct. It is not unknown for $billion projects to get cancelled after spending the $billion, because design or construction errors were made and detected later. Or for a $billion project to be 100% over budget, or more. So if I can make software that will save even a few such things, a huge software budget can be justified. Heh. But my personal motivation is mostly that I hate using the existing software when I know I could write better software if given the chance. Because I have written better for several smaller things. |
| legalize+jeeves@mail.xmission.com (Richard): Nov 25 06:42PM [Please do not mail me a copy of your followup] Paavo Helde <myfirstname@osa.pri.ee> spake the secret code >(When done right, the agile approach seems to become a synonym with "use >some common sense and do whatever works well for your project", which is >great of course but I am not sure why a buzzword is needed for doing that.) Agile isn't a list of practices, while Extreme Programming and TDD are presented as exactly that. The reason that the folks signing the agile manifesto didn't prescrive a set of specific practices is because they couldn't agree on the best practices to use universally. That's why the agile manifesto is a series of value propositions instead of a series of specific "do this" prescriptions. You may think that the value propositions are "common sense", but clearly they aren't so common or making so much sense to many people otherwise the manifesto wouldn't be worth writing. I worked on a team where everyone claimed they were working in an agile manner, but when I looked at the value propositions in the manifesto, my team was literally taking the exact opposite stance on all of them. If your team already has the values expressed in the manifesto, then it's going to feel like common sense to work in an agile manner. If your team is objecting to, or remains unconvinced of, the value propositions in the manifesto, then you're going to have difficulty operating in an agile manner. Sometimes it just boils down to hiring the right people. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "Öö Tiib" <ootiib@hot.ee>: Nov 25 11:57AM -0800 On Wednesday, 25 November 2015 20:42:37 UTC+2, Richard wrote: > [Please do not mail me a copy of your followup] > Sometimes it just boils down to hiring the right people. Why you did hire wrong people? However not everything is lost yet ... bears can be taught to bicycle and software developers (most bovine and dense of people) can be also sometimes taught. :D |
| Wouter van Ooijen <wouter@voti.nl>: Nov 25 09:10PM +0100 Op 25-Nov-15 om 7:42 PM schreef Richard: > propositions in the manifesto, then you're going to have difficulty > operating in an agile manner. > Sometimes it just boils down to hiring the right people. *sometimes* ?? Wouter |
| legalize+jeeves@mail.xmission.com (Richard): Nov 25 09:46PM [Please do not mail me a copy of your followup] Wouter van Ooijen <wouter@voti.nl> spake the secret code >> operating in an agile manner. >> Sometimes it just boils down to hiring the right people. >*sometimes* ?? Heh heh :). I was thinking along the lines of attempts to introduce agile practices to an existing team. Sometimes you luck out and the people on the team already agree with the value propositions in the agile manifesto. In such a situation, introducing TDD, extreme programming, story mapping and so-on can be all you need to make a difference on your team. 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. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 25 05:19PM -0600 Puppet_Sock <puppet_sock@hotmail.com> wrote in > Heh. But my personal motivation is mostly that I hate > using the existing software when I know I could write > better software if given the chance. Unless you can't. There is some pretty good stuff out there, including most of the C++ standard library and Boost, plus some other decent libraries like Crypto++ and many de-facto standard-defining C libraries. I am pretty sure you as a single person would have hard time to reproduce e.g. Boost asio library, with all the platform-specific low-level socket handling tricks all over the various platforms, etc. It's also true that not all libraries are good and in many cases one needs 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. Cheers Paavo |
| Barry Schwarz <schwarzb@dqel.com>: Nov 24 03:36PM -0800 > cout << "finished"; >return 0; >} Don't you think "whenever it feels like it" covers the ability to flush immediately regardless of the presence or absence of \n? -- Remove del for email |
| legalize+jeeves@mail.xmission.com (Richard): Nov 24 11:59PM [Please do not mail me a copy of your followup] slp53@pacbell.net spake the secret code >>But if I run a code (Visual Studio): >>cout<<"Start ....\n"; >The '\n' causes the flush. Nope. std::endl outputs a newline and then causes a flush. Reading from an input stream tied to an output stream flushes the output stream before reading from the input stream. std::flush causes a flush. There might be something else too, but I think that's it. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 25 01:30AM +0100 On 11/25/2015 12:59 AM, Richard wrote: >> JiiPee <no@notvalid.com> writes: >>> I understood that cout flushes only after we call flush(). >>> But if I run a code (Visual Studio): ^^^^^^^^^^^^^^ > output stream before reading from the input stream. > std::flush causes a flush. > There might be something else too, but I think that's it. For Visual C++, or more generally Microsoft's runtime library, i/o to the console is immediate, and is flushed one character at a time. That plays havoc with UTF-8 encoding for output. Which is not as bad as it sounds, because Windows consoles, down at the API level, do not support UTF-8 input, so it would be one-way i/o anyway, only output. In typical Microsoft fashion this is fixed by having some extended functionality that sets up special mode for the C and C++ standard streams, via their _setmode function. And /that/ again is not as bad as it sounds, because even in Unix-land one has to do some configuration to make the wide streams work, as a minimum calling setlocale( "", LC_ALL ), so, to sum up, console i/o doesn't work in C or C++ by default. Well, except ASCII. Cheers, - Alf |
| Ian Collins <ian-news@hotmail.com>: Nov 25 06:39PM +1300 Alf P. Steinbach wrote: > even in Unix-land one has to do some configuration to make the wide > streams work, as a minimum calling setlocale( "", LC_ALL ), so, to sum > up, console i/o doesn't work in C or C++ by default. Well, except ASCII. Not necessarily. On my system, the following "just works": #include <iostream> int main() { const uint32_t value = 0xa9; const char lower = 0x80|(value&0x3f); const char upper = 0xc0|(value >> 6); std::cout << upper << lower << std::endl; } > CC local.cc; ./a.out © -- Ian Collins |
| Juha Nieminen <nospam@thanks.invalid>: Nov 25 09:25AM > For Visual C++, or more generally Microsoft's runtime library, i/o to > the console is immediate, and is flushed one character at a time. In other words, in typical Windows fashion, they do it as inefficiently as possible. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Nobody <nobody@nowhere.invalid>: Nov 25 12:24PM On Tue, 24 Nov 2015 23:59:26 +0000, Richard wrote: > There might be something else too, but I think that's it. If the unitbuf flag is set on the stream, it is flushed after each operation. By default, this is set for cerr but not for cout. If the C++ ostream is synchronised with the corresponding C stdio stream (sync_with_stdio), which is the default for the standard streams, they share the same buffer. C requires that stdout is fully buffered if and only if it can be determined not to refer to an interactive device. If it might refer to an interactive device, it will be at most line-buffered, meaning that fputc(stdout,'\n') will flush stdout. AIUI, if cout is sync'd with stdio, then writing '\n' to cout (or to the underlying filebuf) will also flush it. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 25 02:24PM +0100 On 11/25/2015 6:39 AM, Ian Collins wrote: > } > > CC local.cc; ./a.out > © This is a nice example of what I wrote (so I don't understand the "not necessarily"), to wit, it avoids using wide streams and therefore doesn't work in Windows, i.e. it's not portable: <example> C:\my\forums\clc++\012>g++ foo.cpp foo.cpp: In function 'int main()': foo.cpp:7:38: warning: overflow in implicit constant conversion [-Woverflow const char lower = 0x80|(value&0x3f); ^ foo.cpp:8:38: warning: overflow in implicit constant conversion [-Woverflow const char upper = 0xc0|(value >> 6); ^ C:\my\forums\clc++\012>chcp 65001 & a Active code page: 65001 �� C:\my\forums\clc++\012>_ </example> The reason for the /two/ odd result characters is that each byte is sent separately to the console, which therefore interprets each byte separately. If the program had used wide streams it /could/ have worked in Windows by adding a translation unit with proper system-specific wide stream configuration, which in Unix-land would be a call to setlocale. Here's a program, based on yours, that illustrates the problem for byte level streams in Windows. To understand it it's necessary to know that the version of g++ I use, use Microsoft's runtime library, or else an emulation of that runtime library's quirks and faults. That also has other problems, but the main problem here is the lack of buffering: <file "oops.cpp"> #include <stdio.h> #include <windows.h> auto main() -> int { unsigned const value = 0xA9; const char utf8_bytes[] = { char( 0xC0|(value >> 6) ), char( 0x80|(value&0x3f) ) }; int const n_bytes = sizeof( utf8_bytes ); // Sending separate bytes to the console: fwrite( utf8_bytes, 1, n_bytes, stdout ); printf( "\n" ); // Sending the all bytes of an UTF-8 character together: HANDLE const winout = GetStdHandle( STD_OUTPUT_HANDLE ); WriteFile( winout, utf8_bytes, n_bytes, nullptr, nullptr ); printf( "\n" ); } </file> <example> C:\my\forums\clc++\012>g++ oops.cpp C:\my\forums\clc++\012>chcp 1252 & a Active code page: 1252 © © C:\my\forums\clc++\012>chcp 65001 & a Active code page: 65001 �� © C:\my\forums\clc++\012> _ </example> Cheers!, - Alf |
| Luca Risolia <luca.risolia@linux-projects.org>: Nov 25 08:41PM +0100 Il 24/11/2015 20:21, JiiPee ha scritto: > I am expecting everything to be printed at the end and nothing at the > 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). |
| Ian Collins <ian-news@hotmail.com>: Nov 25 12:48PM +1300 Noob wrote: > 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. One thing to remember is that std::vector has an allocator template parameter. This allows you to provide your own allocator, so you can experiment with alternatives to the standard allocator. -- Ian Collins |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 25 06:25PM On Tue, 2015-11-24, Ian Collins wrote: > One thing to remember is that std::vector has an allocator template > parameter. This allows you to provide your own allocator, so you can > experiment with alternatives to the standard allocator. Good to remember, but he should probably check first if the number of vector allocations make sense. If he's new to C++ he may accidentally be make unnecessary copies, or something ... I've personally never seen a need to mess with the allocators (which admittedly doesn't mean noone should ever do it!) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 25 06:32PM On Tue, 2015-11-24, Noob wrote: ... > BTW: I know this is not the place for such off-topic and subjective > stuff, but I'm really enjoying C++. With all the negativity around here, I am happy to read that. I don't think it's offtopic at all. > 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. It's one of many strengths, but IMO not one of the most important ones. Maybe it's more important if you come from Fortran ... Anyway, you'll notice many other strengths over time! /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| ram@zedat.fu-berlin.de (Stefan Ram): Nov 25 01:07PM >> There might be something else too, but I think that's it. >If the unitbuf flag is set on the stream, it is flushed after each >operation. By default, this is set for cerr but not for cout. Yes, to clarify the situation for cout: C++ asserts that »cerr.flags() & unitbuf && wcerr.flags() & unitbuf«, but leaves it /unspecified/ whether »cout.flags() & unitbuf«. |
| 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