- Assert - 3 Updates
- MS VS bug, or other compilers have bug? - 6 Updates
- Stand up for Christ - 5 Updates
- New appreciation for C++ - 4 Updates
- accumulate with copy - 5 Updates
- EXAMPLE - 2 Updates
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 09 07:24PM I assert therefore I am. -- Thank you, Rick C. Hodgin |
| Ian Collins <ian-news@hotmail.com>: Mar 10 09:13AM +1300 On 03/10/2018 08:24 AM, Rick C. Hodgin wrote: > I assert therefore I am. I assert therefore I terminate would be me appropriate :) -- Ian |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 09 08:26PM On 09/03/2018 20:13, Ian Collins wrote: > On 03/10/2018 08:24 AM, Rick C. Hodgin wrote: >> I assert therefore I am. > I assert therefore I terminate would be me appropriate :) Unfortunately this tedious spamming process seems to be immune to false assertions; must have been built with NDEBUG defined. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bob Langelaan <bobl0456@gmail.com>: Mar 09 09:51AM -0800 If you have code such as: int var; cin >> var; and the user inputs: 12345i afterward, with MS VS, var will contain 12345 and the character 'i' remains in the cin buffer. No error flags will be raised for the cin object. With some other compilers, including Xcode and Clion , var will contain the value 0 after the operation and the 'i' will have been swallowed up in the operation as well. In other words, the 'i' will no longer be in the cin buffer. Not sure about the error state of the cin object after the operation. Does the C++ language specify what the result should be? Could both results be "correct"? Any input would be appreciated. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 09 06:36PM On 09/03/2018 17:51, Bob Langelaan wrote: > With some other compilers, including Xcode and Clion , var will contain the value 0 after the operation and the 'i' will have been swallowed up in the operation as well. In other words, the 'i' will no longer be in the cin buffer. Not sure about the error state of the cin object after the operation. > Does the C++ language specify what the result should be? Could both results be "correct"? > Any input would be appreciated. The fact that only you and three others use Xcode and Clion and everyone else uses g++, clang or VC++ should answer your question. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bob Langelaan <bobl0456@gmail.com>: Mar 09 11:24AM -0800 On Friday, March 9, 2018 at 10:36:39 AM UTC-8, Mr Flibble wrote: |
| Bob Langelaan <bobl0456@gmail.com>: Mar 09 11:32AM -0800 On Friday, March 9, 2018 at 9:52:04 AM UTC-8, Bob Langelaan wrote: > With some other compilers, including Xcode and Clion , var will contain the value 0 after the operation and the 'i' will have been swallowed up in the operation as well. In other words, the 'i' will no longer be in the cin buffer. Not sure about the error state of the cin object after the operation. > Does the C++ language specify what the result should be? Could both results be "correct"? > Any input would be appreciated. I am having trouble with the interface I am using to this use group. So while I meant to reply to Mr. Flibble, I can't seem to be able to do so. Mr. Flibble - if I understand you correctly, you are saying that the VC++ result is the correct result? I think you may have misunderstood me, since I actually use VC++. It is 2 of my students that are using Xcode and Clion. I did not want to tell they that their compiler is crap without some ammunition. It seems that you have just given me that ammunition :) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 09 08:05PM On Fri, 2018-03-09, Bob Langelaan wrote: >> > Any input would be appreciated. >> The fact that only you and three others use Xcode and Clion and everyone >> else uses g++, clang or VC++ should answer your question. Something is wrong here: Clion is not a compiler; it's an IDE. I've seen it used on Linux with gcc and clang as backends. IIRC the same goes for Xcode. It's probably better to first establich which behavior is correct C++. (I won't try, since I'm disinterested in parsing text using std::istream.) One piece of advice though, which I've mentioned here in the past: if this is for a student exercise and std::istream reading is not the main point, reformulate it so it's driven as a unit test instead of as a main() which prompts for user input. Use Google Test, or something. Much easier to handle for you and the students, and they can focus on their main task. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| James Kuyper <jameskuyper@verizon.net>: Mar 09 03:06PM -0500 On 03/09/2018 12:51 PM, Bob Langelaan wrote: > afterward, with MS VS, var will contain 12345 and the character 'i' remains in the cin buffer. No error flags will be raised for the cin object. > With some other compilers, including Xcode and Clion , var will contain the value 0 after the operation and the 'i' will have been swallowed up in the operation as well. In other words, the 'i' will no longer be in the cin buffer. Not sure about the error state of the cin object after the operation. > Does the C++ language specify what the result should be? Could both results be "correct"? Yes, though figuring out what the specification means gets complicated. The starting point is 27.7.2.2.2p3, which describes the Arithmetic extractors for std::basic_istream<>::operator>>(int& val). It describes their behavior in terms of use_facet< numget >(loc).get(*this, 0, *this, err, lval), where lval has the type 'long'. 22.2 specifies that std::use_facet<Facet>() returns a Facet& 22.4.2.1.1 specifies that std::num_get::get(in, end, str, err, val) calls do_get(in, end, str, err, val), which is a virtual function. 22.4.2.1.2 specifies that std::num_get::do_get(in, end, str, err, val) reads in characters from the string, converting the locale-specific decimal_point character to '.', discarding characters prior to the decimal point which match the locale-specific thousands_sep(), and converting any other characters that cannot be found in the string "0123456789abcdefxABCDEFX+-" to null characters, and stopping as soon as a character is found which is not allowed by the conversion specifier. Note that 'i' is not allowed by any of the conversion specifiers, so it is permitted only when using a locale which specifies 'i' as the thousands separator :-). do_get() then passes the character string to the C standard library function strtoll(). At this point, you have to switch standards to get a complete description of the process, but you don't need that much detail for this question. For this input, strtoll() should set lval to 12345. Coming back to the C++ standard, 27.7.2.2.2p3 specifies that operator>> sets val to the value stored in lval. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 09 08:58AM -0800 Billy Graham on a 1998 TED Talk: Technology, faith and human shortcomings: https://www.youtube.com/watch?v=90mj79GqWhc A brilliant talk. Published in 2008. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 09 09:24AM -0800 He talks about Blaise Pascal, and how in 1654 he became a Christian through a revelation written in his journal. A French historian two centuries later remarked that rarely does such a towering intellect come to devout faith in Jesus Christ. "After running from God until he was 31 years old, on November 23, 1654 at 10:30 pm, Pascal met God and was profoundly and unshakably converted to Jesus Christ." Blaise Pascal died at age 39. Before Nov.23.1654 he was an atheist, writing much on the lack of need for God, believing the same fully. It takes God drawing a person from within. It's a supernatural change leading to eternal forgiveness for our sin. Technology, faith and human shortcomings: https://www.youtube.com/watch?v=90mj79GqWhc It's more important than C++, or any other things in our life because none of us know on which day or hour we will die. We must address our salvation presently, today, even right now. All who come to Jesus asking forgiveness for their sin are completely forgiven. They pass from death by judgment for sin to eternal life as Jesus takes our sin away by His sacrifice on the cross, His love for us pouring out with every drop of blood. Love has a name. His name is Jesus Christ. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 09 10:51AM -0800 The devil and demons in our lives is real. Their influence is all around us. Anything that is contrary to God and His teachings. They are pervasive in your life, and even in your body. But Christ can set you free. Billy Graham 1971 https://www.youtube.com/watch?v=lA5KUfzkfYE Every person outside of Christ is subject to literal demon possession. It's not like in The Exorcist, but it is an evil spirit at work in your flesh, augmenting your natural senses, natural thoughts, with their senses, their thoughts. Famous people often talk about something they feel entering their body when they go on stage to perform. Famous singers like Beyonce, Bon Scott, Robert Plant, and performers like Angus Young, Keith Richards. These are owerful demons who enter those in front of thousands, but many other lesser demons enter your life and change you from within. Why can't you kick that destructive habit despite a sincerity in wanting to stop. Why can't you break that addiction? It's because you're not alone. It isn't just your will at work in your body. Evil spirits apply their own existence to your body, giving it input and prompting, sparking thoughts, feelings, emotions. And they have access to your flesh through sin, and their various temptations to sin which you voluntarily acquiesce to, resulting in them having a legal license by your acceptance of their offer to sin, to enter in and become a part of your life. The only combatant we have against such attacks is to have our sin taken away. To come to Christ and be forgiven. He breaks every contract you've agreed to, setting you free, giving you back your own life, giving you new spiritual life, giving you the ability and power to say no to sin. Lives are changed by Christ. But the enemy does not give up the moment you are saved. He is cast aside that self-same moment, and you can feel it all coming off you, the judgment, the condemnation, the evil spirit. It's of such a profound power that it causes people to shake and cry out in greatest joy. That freedom lasts for a time as you glow in your new life, and some people hold on to it and never go back to their former ways. But the devil comes back at you, and God gives him space to try you and tempt you, but He always protects you and instructs you, and even when you fall down is He there to pick you up and get you going again. It is a never-ending relationship between God and us, that He never leaves ud or forsakes us, but guides us continually from that day forward. Jesus will set you free from demons, set you free from addictions, break every chain and tie that bind, and set your feet on the path of life ... if you will let Him. He won't force Himself on you, but continually offers to save you, sometimes through men and women like me who point you to Him. Spiritual oppression by demons is real. So is sin, judgment, condemnation, and full forgiveness of all sin past, present, and future, by Jesus Christ. You can have freedom today, eternal security to no longer fear death, and inner peace in the storm. It just takes that humbling, "Lord, I am a sinner. Please forgive my sin and give me eternal life." He never turns anyone away who comes to Him sincerely. -- Rick C. Hodgin PS - Demons in music: https://www.youtube.com/watch?v=_7Ut0LyUq6Y&t=2m41s |
| Daniel <danielaparker@gmail.com>: Mar 09 11:30AM -0800 On Friday, March 9, 2018 at 1:52:03 PM UTC-5, Rick C. Hodgin wrote: > Jesus will set you free from demons ... if you will let Him. > He won't force Himself on you, but continually offers to save you, > sometimes through men and women like me who point you to Him. Bad Mr Flibble! You really must stop this satirizing of Rick C. Hodgin's beliefs. He's not _that_ nutty. Thanks, Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 09 07:34PM On 09/03/2018 19:30, Daniel wrote: >> sometimes through men and women like me who point you to Him. > Bad Mr Flibble! You really must stop this satirizing of Rick C. Hodgin's > beliefs. He's not _that_ nutty. A multi-pronged attack against the tedious spam is indeed what we need. :D /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| wyniijj@gmail.com: Mar 08 09:40PM -0800 Rick C. Hodgin於 2018年3月8日星期四 UTC+8下午10時47分33秒寫道： > I've always looked at C++ as being overtly complex, obtuse in much > of its syntax, having some ideals and goals which seemed outside of > what I would consider to be a "proper norm" for data processing. If C++ is complex, in a way, it's because you chose to explore "complex" You can start from https://sourceforge.net/projects/cscall/, A concrete C++ library built from concrete things. In C, there are macro enthusiasts, so are template enthusiasts in C++. No one has to fall into the concept explaining concept spiral, advanced fancy as it may be. Neither one has to join the test of the untested ideology of C++/standard library. Tao Te Ching [https://en.wikipedia.org/wiki/Tao] Heaven and Earth are not kind. They regard creatures as guinea pigs The sage is not kind. He regards people as guinea pigs. I say: C++ is not kind, it regards programmers as guinea pigs. > longer hold it in such negative regard. However, there are still > many aspects about its design choices that I disagree with, and > CAlive development will continue (James 4:15 Lord willing). C++ has its (hidden) ideals and goals, you can feel it only, though it is changing. C++ and its standard library design choices are mixtures intertwined over time, not easy to say which is which. C++ has to be good in some way, since we chose C++, not C. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 09 07:18AM -0800 > it is changing. C++ and its standard library design choices are mixtures > intertwined over time, not easy to say which is which. > C++ has to be good in some way, since we chose C++, not C. I agree with pretty much everything you wrote. I use C++ for mostly C code because I like tighter type checking, relaxed syntax constraints on "struct" keyword and line comment syntax. I rarely use the class, or many other of C++'s conventions. As I mature in my understanding of C++, I do begin to appreciate some of its design I previously held solely in contempt. -- Rick C. Hodgin |
| asetofsymbols@gmail.com: Mar 09 08:06AM -0800 I use class operators, operators and function overloading not use exceptions and C++ library (I have my own) I like streams too (<< >>) and their type oriented way Not use iterator and C++ libraries but C libraries yes |
| asetofsymbols@gmail.com: Mar 09 08:10AM -0800 I used template only for matrix of type |
| Ralf Goertz <me@myprovider.invalid>: Mar 09 07:34AM +0100 Am Thu, 8 Mar 2018 18:59:58 +0000 (UTC) > >have been ignorant up to now. > A good way to discover stuff like this is to search > cppreference.com :) I know that. As I said, I knew *of* <numeric> but thought it's *content* were boring for me (e.g. numerical limits, but they are in <limits>, or special functions like error function). |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 09 10:58AM > I know that. As I said, I knew *of* <numeric> but thought it's *content* > were boring for me (e.g. numerical limits, but they are in <limits>, or > special functions like error function). It's certainly and odd place for std::accumulate to be because it's not inherently numeric but it is a generic algorithm. Maybe <numeric> pre-dates <algorithm>... -- Ben. |
| Ralf Goertz <me@myprovider.invalid>: Mar 09 03:27PM +0100 Am Thu, 8 Mar 2018 16:19:12 +0100 > > > cout<<*a<<endl; > Of course, it's passed by value! How blind of me. I didn't think that > I would ever be caught in that beginner's trap again. There are two main reasons I stumbled into the trap. Firstly, in my imagination iterators are smart pointers and for pointers it usually doesn't matter whether they are used by copy or by reference. But, as the "pointed to" object was part of my iterator class, in this case it did matter. Secondly, I was confused by the number of copies of a (seven if I counted correctly). If there had been only two, I might have spotted the problem myself. By the way why are there so many copies? It seems as if std::copy makes them. ;-) But not for every element. Even with an empty vector there are seven. |
| James Kuyper <jameskuyper@verizon.net>: Mar 09 09:40AM -0500 On 03/09/2018 05:58 AM, Ben Bacarisse wrote: > It's certainly and odd place for std::accumulate to be because it's not > inherently numeric but it is a generic algorithm. Maybe <numeric> > pre-dates <algorithm>... The oldest version of the STL that I could easily find <http://stepanovpapers.com/butler.hpl.hp/stl/stl.zip> has accumulate defined inside ALGO.H, and the accompanying documentation organizes the generalized numeric operations (what is now <numeric>) in section 10.4, underneath section 10, "Algorithms". |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 09 04:06PM On Fri, 09 Mar 2018 10:58:22 +0000 > It's certainly and odd place for std::accumulate to be because it's > not inherently numeric but it is a generic algorithm. Maybe <numeric> > pre-dates <algorithm>... I agree it is odd to put a generic 'fold' function in the <numeric> header, but once you have separate <algorithm> and <numeric> headers[1] I guess it is difficult to know where to draw the line. What about std::inner_product(), which carries out a fold over two sequences? (Although std::inner_product, unlike most common implementations of multi-sequence folds, does not take one combining function receiving an element from each sequence and the accumulated value: instead std::inner_product() takes two binary callable objects, the first of which receives an element from each sequence, and the second receives the result of that application together with the result of the previous application, the accumulator; so it can also be used to perform a kind of map-reduce.) Then there is std::partial_sum(), which is a variant of std::accumulate() which stores intermediate results. Although it can be used to fold over any type which is copyable/movable to provide partial results, it is in essence an integration function, the opposite of std::adjacent_difference()'s differentiation. Anyway the C++ standard committee have stuck to their guns - C++17 adds generic std::reduce() and std::transform_reduce() algorithms to the <numeric> header. Having a separate <numeric> header may have been a mistake, but they no doubt feel they now have to stick with it. Chris [1] There is also a third header, <memory> which contains the uninitialized_copy() algorithms and cognate operations. |
| Gareth Owen <gwowen@gmail.com>: Mar 09 05:32AM > That's were we disagree. Fair enough > functions can be tested independently of the parent function, so we: > a) don't have to test its behaviour when we test the parent. > b) can mock them to make testing the parent easier. Fair enough, I can see that that has a benefit. Personally, I don't believe in test-suites that exercise implementation details, as it prevents effective refactoring. Do you really write test suites / mocks that link to functions in anonymous namespaces? |
| Ian Collins <ian-news@hotmail.com>: Mar 09 11:19PM +1300 On 03/09/2018 06:32 PM, Gareth Owen wrote: > Fair enough, I can see that that has a benefit. Personally, I don't > believe in test-suites that exercise implementation details, as it > prevents effective refactoring. It can do, but sometimes you need to go a little deeper than you would like to get full coverage. Usually important implementation details can be extracted and tested. > Do you really write test suites / mocks that link to functions in > anonymous namespaces? Well obviously not! If something can fail in such a way as to disrupt the behaviour of a public interface, it should also be public. -- Ian. |
| 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