- "Five Popular Myths about C++, Part 3" by Bjarne Stroustrup - 2 Updates
- std::thread...too little, too late? - 3 Updates
- pre- and post-conditions - 2 Updates
| Lynn McGuire <lmc@winsim.com>: Dec 23 06:44PM -0600 "Five Popular Myths about C++, Part 3" by Bjarne Stroustrup http://isocpp.org/blog/2014/12/myths-3 1. "To understand C++, you must first learn C" 2. "C++ is an Object-Oriented Language" 3. "For reliable software, you need Garbage Collection" 4. "For efficiency, you must write low-level code" 5. "C++ is for large, complicated, programs only" Lynn |
| "Qu0ll" <Qu0llSixFour@gmail.com>: Dec 24 11:40PM +1100 "Lynn McGuire" wrote in message news:m7d28c$hsq$1@dont-email.me... > 1. "To understand C++, you must first learn C" Definitely not required. You will *never* understand C++ no matter how many other languages you study first! > 2. "C++ is an Object-Oriented Language" Well, there's some refreshing candidness. (i.e the fact that it is NOT an OO language). > 3. "For reliable software, you need Garbage Collection" You only need garbage collection if you have garbage. > 4. "For efficiency, you must write low-level code" Define "low-level code" please? Assembler? Poor quality code? I am glad they're not required for efficiency because I never write either of those. > 5. "C++ is for large, complicated, programs only" Nah, C++ is for large, uncomplicated programs as well as small complicated, small uncomplicated, and all variations of of medium sizes and levels of complication and will fail just as spectacularly in all those scenarios! Merry Christmas! -- And loving it, -Qu0ll (Rare, not extinct) _________________________________________________ Qu0llSixFour@gmail.com [Replace the "SixFour" with numbers to email me] |
| Mr Flibble <flibble@i42.co.uk>: Dec 24 01:03AM On 23/12/2014 22:49, Ian Collins wrote: >> My platforms include Windows and POSIX. For I/O I use boost.asio which >> is non-blocking. > Isn't boost.asio normally used as an alternative to threads+blocking I?O? Who says you cannot use multiple threads with boost.asio? Think threadpools doing work. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Dec 24 02:29PM +1300 Mr Flibble wrote: >> Isn't boost.asio normally used as an alternative to threads+blocking I?O? > Who says you cannot use multiple threads with boost.asio? Think > threadpools doing work. No one, but the choice is usually between one or the other. Both have their complexities, async I/O may save synchronisation at the cost of more complex I/O processing where threads simplify the I/O processing and may require synchronisation. Adding the two complexities to one solution appears counter-intuitive. Async I/O doesn't help where the code your threads call doesn't support it. -- Ian Collins |
| Martijn Lievaart <m@rtij.nl.invlalid>: Dec 24 12:33PM +0100 On Wed, 24 Dec 2014 14:29:09 +1300, Ian Collins wrote: > solution appears counter-intuitive. > Async I/O doesn't help where the code your threads call doesn't support > it. Have a better look at asio. It is very good at exactly hiding the complexities you mention. And mixing the two solutions makes perfect sense as the result is very scalable and is actually what is done in most high performance solutions. M4 |
| mathewji <itoneymathew@gmail.com>: Dec 23 04:46PM -0800 I also come up with: cpp_int area(cpp_int length, cpp_int width) { // calculate area of a rectangle; // pre-conditions: length and width are positive // post-condition: returns a positive value that is the area { cpp_int a = 0; if (length <= 0 || width <= 0) { cout << "pre-condition true" << endl; error("area() pre-condition"); } a = length*width; cout << a << endl; if (a <= 0) { cout << "post-condition true" << endl; error("area() post-condition"); } return a; } } With Boost, and and that allows product of 2147483647 and 2 to pass pre and post. |
| Richard Damon <Richard@Damon-Family.org>: Dec 23 09:04PM -0500 > > } > In C++ it is impossible to find such values. Signed integer overflow > is undefined behavior: You can not find values which the standard will promise the results. Because it is undefined, it is possible that you will get the "desired" results, which on many platforms is actually quite predictable. > so there is no defined case where post-condition doesn't hold. (The > only case is where undefined behavior occurs, but it's undefined - so > basically anything can happen). While anything *can* happen, for a given system, the results may well be predictable (if not "defined"). This doesn't say that you should depend on how undefined behavior will behave unless you have something from the compiler that makes promises about it. As was pointed out in c.l.c, it is even possible that the compiler will be able to detect that the only way that a will be less than zero is for undefined behavior to have occurred, and then elide the post-condition test. |
| 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