- Age of C programmers? - 2 Updates
- [niubbo] convert a string representing a valid date to some "binary" date - 7 Updates
- Why does this work on Xcode ??? - 4 Updates
| queequeg@trust.no1 (Queequeg): Jul 19 10:31AM > Same (in all aspects!) here. C and C++ are very much alive in the > embedded space. True. Fortunately, because I always wanted to work in embedded field... and that's what I'm doing. But, unfortunately, we still, in 2019, have to use C++03 (because of platform, SDK and infrastructure limitations). Working full time I have no means to really learn and practice modern C++ (even C++11). -- https://www.youtube.com/watch?v=9lSzL1DqQn0 |
| Real Troll <Real.Troll@Trolls.com>: Jul 19 05:13PM -0400 On 06/07/2019 17:03, Szyk Cech wrote: >> in the >> same category as Cobol. > Nope! Operating systems are wirten in pure C. Used to be the case but these days Microsoft is re-writing its Windows 10 code in C#. There are somethings they need to write in C/C++ but c# is taking hold on UI stuff. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 18 09:12PM -0700 On Thursday, 18 July 2019 00:52:42 UTC+3, Soviet_Mario wrote: > forms and have to mangle them. Recent data are pre-filtered > using google modules/sheets and RegEx, but older data were > rather irregular. Online forms also have usually date pickers. https://jqueryui.com/datepicker/ Who programs date entry as random free form text at 2019? |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 19 11:14AM +0200 On 18/07/19 22:41, Keith Thompson wrote: >>> What happened to popen()? >> sorry ? I don't understand what you mean ... > If you're on a UNIX-like system, run the "man popen" command. the thing I did not understand was : "why did you mention such command" ? > its output. Using it is *much* simpler than creating a daemon and > setting up a communication channel. I believe it's also available > under Windows. ah ok, for such reason ! Yes it simple, but imply multiple invocations not just "calls". But yes, "shelling" processes is a fallback solution, surely TY -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 19 11:16AM +0200 On 19/07/19 06:12, Öö Tiib wrote: > Online forms also have usually date pickers. > https://jqueryui.com/datepicker/ > Who programs date entry as random free form text at 2019? I should deal with students old reports, dating back some time. I mean : data are just existing, I'm not collecting them for the future. Tnx -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| David Brown <david.brown@hesbynett.no>: Jul 19 11:27AM +0200 On 19/07/2019 11:14, Soviet_Mario wrote: > ah ok, for such reason ! > Yes it simple, but imply multiple invocations not just "calls". But yes, > "shelling" processes is a fallback solution, surely You can have a single program and keep it open, if you prefer. It would still be simpler than writing a daemon. In the *nix world, creating processes is cheap. There is often little problem in using a process simply to handle one call like this. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 19 03:47AM -0700 On Friday, 19 July 2019 12:16:44 UTC+3, Soviet_Mario wrote: > time. I mean : data are just existing, I'm not collecting > them for the future. > Tnx If I would have lot of such dirty data then i would just try some set of std::get_time locales and formats. https://en.cppreference.com/w/cpp/io/manip/get_time More important is there to report dates that feel wrong or are ambiguous like 07/03/19. It takes human operator to guess if it was meant 2007/March/19, 07/March/2019, July/03/2019 or undecidable ambiguous. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 19 06:28PM +0100 > Online forms also have usually date pickers. > https://jqueryui.com/datepicker/ > Who programs date entry as random free form text at 2019? Too few. Far too few. If you have any trouble with a shaky hand on a mobile, voice input it a boon. Most date pickers are a pain compared to simply saying the date. "Progress" is inevitable! -- Ben. |
| Keith Thompson <kst-u@mib.org>: Jul 19 11:34AM -0700 > Too few. Far too few. If you have any trouble with a shaky hand on a > mobile, voice input it a boon. Most date pickers are a pain compared to > simply saying the date. "Progress" is inevitable! And if you have an existing date as text, it's good to be able to copy-and-paste it. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Christian Gollwitzer <auriocus@gmx.de>: Jul 19 08:27AM +0200 Am 17.07.19 um 23:29 schrieb Alf P. Steinbach: > It's difficult to predict because it may not be documented for the > compiler, and the compiler may optimize or not based on criteria that > only make sense internally (e.g., is the return type floating point?). Is it true that it depends on the type of something in practical cases? I thought that tail recursion can be mechanically translated like this: =========== type myfunc(x, y, z) { .... return myFunc(a, b, c); } =========== becomes ========== type myfunc(x, y, z) { start: ... x=a, y=b, z=c; goto start; } ========== Since I can do this at the source code level, I don't see why it can't be done for every function. Of course, for mutual tail recursion I can't do that because of the non-local goto, but for the compiler that should also be easy. Christian |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 19 09:09AM +0200 On 19.07.2019 08:27, Christian Gollwitzer wrote: >> compiler, and the compiler may optimize or not based on criteria that >> only make sense internally (e.g., is the return type floating point?). > Is it true that it depends on the type of something in practical cases? Yes, it's the practical particular cases where it depends. For portable code it doesn't depend: you just have no guarantee and hence risk UB. And a risk of UB = UB. > goto start; > } > ========== Modulo a number of caveats, yes. The two most important ones, to my mind: * That `type` can't be a class type with a non-trivial destructor. A rewrite can often still be done but it's more complicated, in general involving a stack, so it may not buy any efficiency. * That for a debug build the compiler can't optimize away calls. Because you can't trace into a call if it's optimized away. > be done for every function. Of course, for mutual tail recursion I can't > do that because of the non-local goto, but for the compiler that should > also be easy. You'd have to ask the compiler teams /why/ they choose to not always do this for builds where debugging support has not been requested. For the case of not doing it for floating point results I guess it has to do with floating point operations. The original x86 architecture supported floating point operations via a physically separate co-processor, the 8087. This physical separation and parallelism was retained as a logical design (although everything was put on the same chip) in later versions, as far as I know all the way till today. Consider this function: auto factorial( const int n ) -> double { if( n == 0 ) { return 1; } return n*factorial( n - 1 ); } With Visual C++ 2019, release (optimized) build: auto factorial( const int n ) -> double { 00B71000 push esi 00B71001 mov esi,ecx if( n == 0 ) { return 1; } 00B71003 test esi,esi 00B71005 jne factorial+11h (0B71011h) 00B71007 movsd xmm0,mmword ptr [__real@3ff0000000000000 (0B72108h)] 00B7100F pop esi } 00B71010 ret return n*factorial( n - 1 ); 00B71011 lea ecx,[esi-1] 00B71014 call factorial (0B71000h) 00B71019 movd xmm1,esi 00B7101D cvtdq2pd xmm1,xmm1 00B71021 pop esi 00B71022 mulsd xmm0,xmm1 } 00B71026 ret The `call` instruction there does exactly what you think it does, it calls the function, recursively; no tail recursion optimization. Cheers & hth., - Alf |
| "Öö Tiib" <ootiib@hot.ee>: Jul 19 12:20AM -0700 On Friday, 19 July 2019 09:27:15 UTC+3, Christian Gollwitzer wrote: > > compiler, and the compiler may optimize or not based on criteria that > > only make sense internally (e.g., is the return type floating point?). > Is it true that it depends on the type of something in practical cases? Not to my knowledge. It is (like any other optimization) just not required. It is not hard to implement. Likely reason is that dummies are constantly confused when debugging optimized programs. OTOH dummies are also confused when stack is exhausted. Finally, when all works then they are confused that programs fully instrumented for debugging are so sluggish. So C++ just does not suit dummies and all efforts have been in vain. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 19 09:24AM +0200 On 19.07.2019 09:09, Alf P. Steinbach wrote: > 00B71026 ret > The `call` instruction there does exactly what you think it does, it > calls the function, recursively; no tail recursion optimization. Oh, it does optimize the function rewritten to /pure/ tail-recursive: auto xfactorial( const int n, double const result = 1 ) -> double { if( n == 0 ) { return result; } return xfactorial( n - 1, n*result ); } yielding Release build machine code if( n == 0 ) { return result; } 01241000 test ecx,ecx 01241002 je xfactorial+15h (01241015h) 01241004 movd xmm0,ecx return xfactorial( n - 1, n*result ); 01241008 cvtdq2pd xmm0,xmm0 0124100C mulsd xmm1,xmm0 01241010 sub ecx,1 01241013 jne xfactorial+4h (01241004h) } 01241015 movaps xmm0,xmm1 01241018 ret I don't remember that behavior from earlier, but perhaps I don't remember everything about it. Cheers!, - Alf |
| 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