- "In defense of printf" - 5 Updates
- I am a Recruiter with a active Job position: C/C++ Developer - 1 Update
- std::thread...too little, too late? - 11 Updates
| scott@slp53.sl.home (Scott Lurndal): Dec 22 03:39PM >The inserter "<<" and the extractor ">>" had been deliberately chosen >for a number of reasons: >1. it was not possible to invent new lexical elements s/possible/desirable/ and you may be closer to the truth. I think BS was just in love with operator overloading and thought he was being clever when he introduced the output streams in C++ (cfront) 3.0 (preceeded by an experimental unusable implementation in C++ (cfront) 2.1). >5. they are rarely used with base types Actually, pretty much every C++ program I've ever written has extensively used the bit-shifting operations on integral types. Two examples (both processor simulators): $ egrep '<<|>>' */*.[ch]* |wc -l 2795 $ sloccount . Totals grouped by language (dominant language first): cpp: 182067 (99.26%) python: 1350 (0.74%) $ egrep '<<|>>' */*/*/*.[ch]* */*/*.[ch]* */*.[ch]* |wc -l 718 $ sloccount . Totals grouped by language (dominant language first): cpp: 53587 (97.48%) ansic: 1051 (1.91%) sh: 334 (0.61%) Neither of these projects use C++ I/O streams. |
| Luca Risolia <luca.risolia@linux-projects.org>: Dec 22 05:22PM +0100 On 22/12/2014 16:39, Scott Lurndal wrote: > integral types. > Two examples (both processor simulators): > $ egrep '<<|>>' */*.[ch]* |wc -l [...] > Neither of these projects use C++ I/O streams. You did not apparently get the point. You want to search for the statements where you actually use printf() as in "printf("%d", integral_var_or_constant << nbits);" only, or as in "cout << (integral_var_or_constant << nbits);" (if you used cout). |
| "Öö Tiib" <ootiib@hot.ee>: Dec 22 01:17PM -0800 On Monday, 22 December 2014 18:22:52 UTC+2, Luca Risolia wrote: > statements where you actually use printf() as in "printf("%d", > integral_var_or_constant << nbits);" only, or as in "cout << > (integral_var_or_constant << nbits);" (if you used cout). Exactly. Bit shift is rather specific operation. The left argument (number of bits) is rather limited. It must be tiny positive integer or all bets are off. Also it is about bit crunching that is uncommon in same expression with those ??printfs. I do not understand how people who aren't confused with piles of true quirks of C and C++ claim with straight face that they are suddenly incapable to learn to make difference. We can somehow read hundreds of posts during those decades that whine about how confusing that overload of operator is. Isn't it sort of self-insulting? |
| "Öö Tiib" <ootiib@hot.ee>: Dec 22 01:50PM -0800 On Monday, 22 December 2014 23:17:43 UTC+2, Öö Tiib wrote: > The left argument (number of bits) is rather limited. Meant "right argument". |
| Lynn McGuire <lmc@winsim.com>: Dec 22 04:45PM -0600 On 12/19/2014 2:55 PM, red floyd wrote: > snprintf(buffer, sizeof(buffer), "%d", val); > return buffer; > } Probably. I wrote that code a decade ago. There are about 20 more asString functions just like that one. Plus we also use Open Watcom C++ on Windows for a while longer. Not sure if it supports snprintf. Thanks, Lynn |
| priyanka das <priyankacs.tekwissen@gmail.com>: Dec 22 10:26AM -0800 Hello, Greeting! My name is Priyanka Das and I'm a Technical Recruiter at TekWissen LLC, a global staffing and IT consulting company. We are constantly on the lookout for professionals to fulfill the staffing needs of our clients, and we currently have a job openings that may interest you. Below is a summary of the position. Position C/C++ developers Location: Germantown, MD Duration: Long term Description: We are looking programmers with strong experience of C and/or C++ programming Candidates must be good at SQL Querying and must have over 4 years' experience with SQL Candidates must have prior experience working on a Linux/Unix environment. Unix Scripting (preferably Shell scripting) is also a must skill Thanks & Regards, Priyanka Das Technical Recruiter 321 S Main street, Suite 300, Ann Arbor, Michigan-48104, USA. Tel : 734-259-2181 Ext 288 Direct : 734-274-2348 Fax : 734-468-0881 Email : priyanka.cs@tekwissen.com Web : www.tekwissen.com Global : USA | Dubai | Singapore | India | Our emails are intended to engage in communication for business purposes only. If it is your preference to not receive further communication, please reply to the email received and place "No Further Emails Please" in the subject line before sending. Thank you. Disclaimer: The information contained in this e-mail and attachments (if any) are privileged and confidential and are intended for the individual(s) or entity(ies) named in this e-mail. If you are not the intended recipient, or employee or agent, you are hereby notified that dissemination, distribution or copying of this communication or attachments thereof is strictly prohibited. IF YOU RECEIVED this communication in error, please immediately notify the sender and DELETE the original message from the Inbox. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 21 11:44PM On Sun, 21 Dec 2014 23:21:06 +0000 Mr Flibble <flibble@i42.co.uk> wrote: [snip] > The first sensible thing you've said but alas mostly irrelevent to me > as I am able to write non-blocking code; shame you can't. Ad hominem: you've lost. Of course I can write non-blocking code. In one of the languages I use (not C#, python or javascript, which are quite well advanced on this) I have written assymetrical coroutines which provide await-type semantics on asynchronous code via an event loop. That might come with C++17 (probably later) but to break out of nests of asynchronous callbacks in C++ sometimes you just need blocking code. And thread cancellation without it is pointless, in my opinion. Chris |
| Mr Flibble <flibble@i42.co.uk>: Dec 21 11:48PM On 21/12/2014 23:44, Chris Vine wrote: > nests of asynchronous callbacks in C++ sometimes you just need blocking > code. > And thread cancellation without it is pointless, in my opinion. If ad hom is losing then you lost about 10 posts ago mate. Get a proper job. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Dec 22 01:49PM +1300 Mr Flibble wrote: >> opposite of thread cancellation where the operation is initiated from >> another thread. > In my designs threads cancel themselves or can be told to cancel themselves. How can something cancel itself if it is busy or blocked doing something else? -- Ian Collins |
| Mr Flibble <flibble@i42.co.uk>: Dec 22 12:52AM On 22/12/2014 00:49, Ian Collins wrote: >> themselves. > How can something cancel itself if it is busy or blocked doing something > else? In my designs a thread will not be blocked for any significant length of time. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Dec 22 01:54PM +1300 Mr Flibble wrote: >> else? > In my designs a thread will not be blocked for any significant length of > time. So your designs avoid any system calls that can block? I wish I had that luxury... -- Ian Collins |
| Mr Flibble <flibble@i42.co.uk>: Dec 22 12:56AM On 22/12/2014 00:54, Ian Collins wrote: >> time. > So your designs avoid any system calls that can block? I wish I had > that luxury... Such as? /Flibble |
| Ian Collins <ian-news@hotmail.com>: Dec 22 02:03PM +1300 Mr Flibble wrote: >> So your designs avoid any system calls that can block? I wish I had >> that luxury... > Such as? I guess that depends on the platform, but on mine (POSIX) most I/O and process management calls (including the ubiquitous system()) are both blocking and cancellation points. -- Ian Collins |
| Richard Damon <Richard@Damon-Family.org>: Dec 21 08:43PM -0500 On 12/21/14 3:07 PM, Chris Vine wrote: > object. The second provides compile time binding in the class > definition but with run time virtual method selection. I very much > prefer the first. I find that it very much depends on the application. I find that I often have a set of classes representing things in the system, some of which may have several instances, and these classes have a natural "thread of execution" to handle them. In this case, having a base class for a thread-class using a virtual "run" function can make sense. As you say, sometimes you also have operations that aren't naturally tied to a class that you want to schedule to run. What I find tends to work is to have the actual thread system use a provided function pointer with a void* parameter, and a void* value, and the base thread-class use a function that takes pointer to the object (converted to a void* pointer) and calls the "run" method of the class. This lets you use which ever method is right for you application. You could also do the reverse, and start from a class interface and make a generic class that takes a function pointer (and any data to pass to the function) and the run method just calls that function. In both case "function pointer" could be generalized function like object like std::function. |
| Melzzzzz <mel@zzzzz.com>: Dec 22 03:00AM +0100 On Sun, 21 Dec 2014 20:07:10 +0000 > the BSDs and linux (and possibly commercial unixes), forced stack > unwinding on cancellation would cause the program to terminate when it > hits your catch-all clause. Nope. As I see he re throws, it is fine. Program would be terminated without re throw. As I said, that is not a problem in > windows (your platform) because it does not have meaningful/usable > cancellation. For thread cancellation to work one must assure that program is in sensible state by disabling/enabling cancellation at appropriate points anyway, |
| "Öö Tiib" <ootiib@hot.ee>: Dec 22 03:49AM -0800 On Monday, 22 December 2014 03:03:34 UTC+2, Ian Collins wrote: > I guess that depends on the platform, but on mine (POSIX) most I/O and > process management calls (including the ubiquitous system()) are both > blocking and cancellation points. On Windows there are "Alertable I/O" and "Asynchronous Procedure Calls". You just need to make threads to enter into "alertable state" now and then (call waits or sleeps with special flags) for those to work. |
| Mr Flibble <flibble@i42.co.uk>: Dec 22 02:28PM On 22/12/2014 01:03, Ian Collins wrote: > I guess that depends on the platform, but on mine (POSIX) most I/O and > process management calls (including the ubiquitous system()) are both > blocking and cancellation points. My platforms include Windows and POSIX. For I/O I use boost.asio which is non-blocking. For "system()" I don't invoke processes that block for any significant amount of time. If none of your threads block for more than, say, a second then thread cancellation remains trivial. The key to writing non-blocking code is getting your head around the concept of splitting up work into manageable chunks. /Flibble. |
| 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