- while (cin >> x) - 3 Updates
- Telemetry in "hello world" MS C++ 2015 - 3 Updates
- use of the new override specifier - 1 Update
| Rosario19 <Ros@invalid.invalid>: Jun 11 06:26AM +0200 On Wed, 8 Jun 2016 21:08:07 -0700 (PDT), Andrew Z wrote: > sum += x ; >} >[/code] i find cin >> not good for get input... possibly it is better use low functions from the C + malloc() free() and write from there some functions for the input even in C++ possibly in C and in C++ there are not hight level function for to get input from stdin sufficietly robust or strong ( i not know the word right) |
| Barry Schwarz <schwarzb@dqel.com>: Jun 11 03:44AM -0700 On Fri, 10 Jun 2016 13:26:56 -0700 (PDT), Andrew Z <formisc@gmail.com> wrote: >On Thursday, June 9, 2016 at 1:21:10 PM UTC-4, Barry Schwarz wrote: <snip> >Barry, > thank you for help. > This is how i _imagine_ the cin works. Your imagination is incorrect. >[/code] >The cin has value(s) for "name" first and then (after some time) values for "Lname". >(again -in my mind) After i read the input (into a variable) the cin gets cleared out, and the next input value can be read. This is obviously wrong, since a "while" condition, obtains values for everything that was entered previously. That last sentence makes no sense. For visualization purposes, imagine that there is a FIFO queue associated with cin. Something like a paper towel dispenser where a supply of towels is added at the top and towels are pulled off one by one at the bottom. cin's job is to transfer data from the queue to a variable. If the variable is a string, the data is transferred as is. If the variable is an int, the data is first converted before being stored in the variable. Similarly for other types of variables. In most cases, when cin extracts characters from the queue, it will ignore any white space until it finds a non-white space one. It then extracts "meaningful" characters until it has a reason to stop. The two normal reasons to stop are finding another white space character or finding a character that is invalid for the variable type. Two abnormal reasons for stopping are an error when data is being transferred to the queue or a signal indicating there is no more data (referred to commonly as end of file). Simply having an empty queue is neither an error nor a terminating condition.. It simply means cin must wait until more data arrives. >[code] >int main() { > cout<< " Please enter your First name: "; At this point it would be perfectly legal for you to enter " John 96 82 88 93 79 " and press Enter. As a result, the queue would contain " John 96 82 88 93 79 \n" To see how the processing differs when you enter the data one at a time, see iteration 4 below. > string name; > cin >> name ; The white space is skipped, John is transferred to name, and the queue no contains " 96 82 88 93 79 \n" > cout << "Please enter your Midterm and Final exam grades: " ; > double midterm, final; > cin >> midterm >> final ; The white space is skipped, midterm is set to 96.0, white space is skipped, final is set to 82.0, and the queue now contains " 88 93 79 \n" > we have read count grades for far, and sum is the sum of the first count grades > */ > while (cin >> x) { In iteration 1, white space is skipped, x is set to 88.0, the condition evaluates to true, and the queue now contains " 93 79 \n". In iteration 2, white space is skipped, x is set to 93.0, the condition evaluates to true, and the queue now contains " 79 \n". In iteration 3, white space is skipped, x is set to 79.0, the condition evaluates to true, and the queue now contains " \n". In iteration 4, white space is skipped and the queue is empty. cin waits for more typing. The condition is still being evaluated. You type "91" and press Enter. The queue now contains "91\n". x is set to 91.0, the condition evaluates to true, and the queue now contains "\n". In iteration 5, the initial processing the same as iteration 4. Now you signal EOF (^D on Unix, ^Z on Windows, etc) and press Enter. The while condition evaluates to false and you exit the while loop. > ++count; > sum += x ; These statements are process only during iterations 1-4, not 5. -- Remove del for email |
| Andrew Z <formisc@gmail.com>: Jun 11 09:02AM -0700 On Saturday, June 11, 2016 at 6:44:59 AM UTC-4, Barry Schwarz wrote: > > ++count; > > sum += x ; > These statements are process only during iterations 1-4, not 5. Barry , perfect and detailed explanation. Thank you very much for finding time and putting the effort in breaking this down for me. Finally i got it. Thank you Andrew |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 10 05:40PM -0700 Melzzzzz wrote: > https://yro.slashdot.org/story/16/06/10/1350245/visual-studio-2015-c-compiler-secretly-inserts-telemetry-code-into-binaries Why is it in there? What's it doing? Internet activity? Or just local info for app analysis at runtime? One of VS2015's features is an app analysis ability. Is that what this is? Best regards, Rick C. Hodgin |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 10 09:20PM -0400 On 6/10/2016 8:40 PM, Rick C. Hodgin wrote: > is an app analysis ability. Is that what this is? > Best regards, > Rick C. Hodgin If I had a guess, it would not be favorable to a certain company. It could be, for instance, trying to track the commercial use of a educational or other non-commercial use of their compiler. But this brings up a very important point (one which I saw back in the 90's but hasn't been followed up in much). We all trust our compilers and libraries not to add extra code. But is this trust misplaced? I have no answer to the question. It's just something that is worth though. And it is true in any language - not just C++. So I guess it's really more of a meta-question. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 11 11:31AM +0200 On 11.06.2016 02:40, Rick C. Hodgin wrote: > Why is it in there? What's it doing? Internet activity? Or just > local info for app analysis at runtime? One of VS2015's features > is an app analysis ability. Is that what this is? It's probably sold in internally as a means for customer support. But such nefarious opt-out obscure functionality is multi-purpose. Microsoft has a long history of doing things like this. In the 16-bit Windows days (early 1990s) there was the simple xor-encrypted and self-modifying obscure code that checked which version of DOS Windows was running in, known as the AARD code after it was discovered. It was present but not enabled in the final release of Windows 3.1, much like the code in question now seems to be present but not yet enabled. The AARD code produced a cryptic and intentionally misleading error message if Windows was running on DR DOS or some other vendor's DOS instead of MS-DOS. The intention is known because of internal memos uncovered during later anti-thrust litigation, where, quoting ¹the Wikipedia article about it, "Microsoft Senior Vice President Brad Silverberg later sent another memo, stating: "What the [user] is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR-DOS and then go out to buy MS-DOS."". Cheers!, - Alf ¹ https://en.wikipedia.org/wiki/AARD_code |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Jun 11 09:58AM +0200 On 10.06.16 19.53, Richard wrote: >> I leave it up to the IDE to identify overrides. This is more reliable. > Nothing is more reliable than the compiler, IMO. IDEs are notorious > for taking shortcuts that result in false positives or negatives. Well, you are talking about parser bugs, aren't you? True, from time to time the IDE is confused by the code. But programmers tend to fail too. So if I have the choice to rely on the programmer or on the IDE to identify an overridden method I would trust the IDE more. That's why I do not call code that uses override more readable. However, there are other use cases. I.e. in case of refactoring of the overridden method the override keyword prevents accidentally missed changes in derived classes. But this improves maintainability not readability. Marcel |
| 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