- use of the new override specifier - 9 Updates
- "Why I don't spend time with Modern C++ anymore" by Henrique Bucher - 4 Updates
- while (cin >> x) - 12 Updates
| Lynn McGuire <lmc@winsim.com>: Jun 09 03:30PM -0500 So is anyone using the new C++11 override specifier? We have been retroactively adding it to our code with some surprising new errors. We are using Visual Studio C++ 2015. http://en.cppreference.com/w/cpp/language/override Thanks, Lynn |
| Ian Collins <ian-news@hotmail.com>: Jun 10 08:35AM +1200 On 06/10/16 08:30 AM, Lynn McGuire wrote: > So is anyone using the new C++11 override specifier? We have been > retroactively adding it to our code with some surprising new errors. Yes, I have been doing the same, mainly in older code that re-declared a virtual function virtual. I haven't found any new errors, but it does make the code easier to read knowing a member function is virtual in the base class. -- Ian |
| Wouter van Ooijen <wouter@voti.nl>: Jun 09 11:05PM +0200 Op 09-Jun-16 om 10:30 PM schreef Lynn McGuire: > So is anyone using the new C++11 override specifier? We have been > retroactively adding it to our code with some surprising new errors. I teach more than I program, but I use override whenever possible, and I require the students to use it. And I'd like a (gcc) command line parameter to make it a warning when it is omitted! Wouter "Objects? No Thanks!" van Ooijen |
| Ian Collins <ian-news@hotmail.com>: Jun 10 09:12AM +1200 On 06/10/16 09:05 AM, Wouter van Ooijen wrote: > I teach more than I program, but I use override whenever possible, and I > require the students to use it. And I'd like a (gcc) command line > parameter to make it a warning when it is omitted! Imagine compiling something big and old such as OpenOffice with that warning turned on... -- Ian |
| red floyd <no.spam@its.invalid>: Jun 09 02:41PM -0700 On 6/9/2016 2:12 PM, Ian Collins wrote: >> parameter to make it a warning when it is omitted! > Imagine compiling something big and old such as OpenOffice with that > warning turned on... I thought OOo was written in Java? Not that it matters, your point still stands. |
| Robert Wessel <robertwessel2@yahoo.com>: Jun 09 05:01PM -0500 On Thu, 9 Jun 2016 14:41:37 -0700, red floyd <no.spam@its.invalid> wrote: >> warning turned on... >I thought OOo was written in Java? Not that it matters, your point >still stands. It's mostly C++, although Java is far from a trivial component. Java is needed for Base to function at all, but all the other components will run without, with some features missing. |
| Good Guy <hello.world@example.com>: Jun 09 11:10PM +0100 On 09/06/2016 21:30, Lynn McGuire wrote: > We are using Visual Studio C++ 2015. With RC3? <https://blogs.msdn.microsoft.com/visualstudio/2016/06/07/visual-studio-2015-update-3-rc/> |
| legalize+jeeves@mail.xmission.com (Richard): Jun 09 10:27PM [Please do not mail me a copy of your followup] Lynn McGuire <lmc@winsim.com> spake the secret code >So is anyone using the new C++11 override specifier? clang-tidy (was clang-modernize) has an automatic transform that applies override and removes virtual where it is appropriate. I haven't seen people reporting problems with running this on their code, but they would most likely already be using clang/gcc for their compiler if they're running clang-tidy. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Jun 09 10:29PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >> parameter to make it a warning when it is omitted! >Imagine compiling something big and old such as OpenOffice with that >warning turned on... ...which is why you first run clang-tidy on it :) -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "Öö Tiib" <ootiib@hot.ee>: Jun 09 12:40AM -0700 On Wednesday, 8 June 2016 20:52:11 UTC+3, Jerry Stuckle wrote: > > what such a PHP programmer thinks about C or C++ then why you > > post here? > So what? What does where I post have to do with it? Have to do with what "it"? It is plain logic. People discuss what they are proficient in and focused on and do so on forums meant for it. Only trolls do only pretend discussing and do not care if it is topical to forum or is not. You are long time regular in PHP groups like alt.php and comp.lang.php. At same time you did never post to any of C or C++ groups. > For your information, I've been doing C for around 35 years, and C++ for > almost 30 (since the late 80's). It may be that you indeed had some C or C++ job before PHP came out somewhere before 1995 but I think that you just lie like usual. > No, one again you show your total ignorance. But you're just a troll, > so that's nothing new. Why should I know where you work? Why should I care why you discuss PHP all those years and not C nor C++ and why you suddenly claim being C and C++ expert now? I concluded the obvious from those facts and it must be clear that bald assertions and denial can not convince anyone in opposite. > > You have? All you have are empty words with no other substance but > > attempts to annoy or insult others. Nonsense troll. > Yup, and it's a lot more that you get, that's for sure. I am not claiming being seasonal programmer or consultant or what you were. I sometimes am buyer of such services, but rarely. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 09 11:52AM -0400 On 6/9/2016 3:40 AM, Öö Tiib wrote: > trolls do only pretend discussing and do not care if it is topical to > forum or is not. You are long time regular in PHP groups like alt.php and > comp.lang.php. At same time you did never post to any of C or C++ groups. Yea, right. If you discuss what you are proficient in, why are you here? And posting in this newsgroup is NO measurement of proficiency. If it were, there would be about 12 C++ programmers in the whole world. One more thing that I know is *really hard* for you to understand because you are not proficient in even one language. But there are people who are proficient in two or even three or more languages. Yours is just another of your typical troll posts. >> almost 30 (since the late 80's). > It may be that you indeed had some C or C++ job before PHP came out > somewhere before 1995 but I think that you just lie like usual. You wouldn't know, would you? You're just trolling, as usual. As for you thinking I am lying - to quote Rhett Butler, "Frankly, my dear, I don't give a damn." > and C++ expert now? I concluded the obvious from those facts and it > must be clear that bald assertions and denial can not convince anyone > in opposite. If you knew who my customers were in the past, you would be singing another tune. Let's just say the majority of them are Fortune 500 companies on three continents (North America, Europe and Asia). Why should I care what you think? Those are just more of your invalid assumptions. And just because someone doesn't post here does not mean they are not knowledgeable or an expert on C++ - just like those who do post here are not necessarily knowledgeable or export on C++. You are proof of that. But again, just more proof that you are just an ignorant troll. >> Yup, and it's a lot more that you get, that's for sure. > I am not claiming being seasonal programmer or consultant or > what you were. I sometimes am buyer of such services, but rarely. No, but you are proving you are a troll. And not someone I would consider taking on as a client. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Öö Tiib" <ootiib@hot.ee>: Jun 09 09:51AM -0700 On Thursday, 9 June 2016 18:52:28 UTC+3, Jerry Stuckle wrote: > > forum or is not. You are long time regular in PHP groups like alt.php and > > comp.lang.php. At same time you did never post to any of C or C++ groups. > Yea, right. If you discuss what you are proficient in, why are you here? I did not write that I am proficient in something. > And posting in this newsgroup is NO measurement of proficiency. If it > were, there would be about 12 C++ programmers in the whole world. I did not write that posting is measurement of proficiency. > One more thing that I know is *really hard* for you to understand > because you are not proficient in even one language. But there are > people who are proficient in two or even three or more languages. I did not claim even proficiency in my mother tongue above. WTF are you squirming there? Those things were not under discussion. > Yours is just another of your typical troll posts. You discuss pile of straw men that I have not claimed and that do not follow from anything I wrote. You hope to dodge a simple question with such empty insults and nonsense? That proves that you lie and try to wriggle out with those insults. I wrote that people who have proficiency and focus discuss it in some related forum. It does no way follow from it that people who discuss something in some forum have proficiency in subject there. However if you do not discuss C or C++ at all but instead post other things in neighbour newsgroups then that shows what I claimed about you that you maybe know PHP or may be just troll there but C and C++ gained your attention only recently. > You wouldn't know, would you? You're just trolling, as usual. As for > you thinking I am lying - to quote Rhett Butler, "Frankly, my dear, I > don't give a damn." I do not know nor care. I can not even know why to lie about such things. > If you knew who my customers were in the past, you would be singing > another tune. Let's just say the majority of them are Fortune 500 > companies on three continents (North America, Europe and Asia). That is again just bald assertion that does convince no one since plain logic shows that you lie. > post here are not necessarily knowledgeable or export on C++. You are > proof of that. > But again, just more proof that you are just an ignorant troll. I really do not know why you care what I think. |
| Christian Gollwitzer <auriocus@gmx.de>: Jun 09 07:21PM +0200 Am 09.06.16 um 18:51 schrieb Öö Tiib: >> companies on three continents (North America, Europe and Asia). > That is again just bald assertion that does convince no one since plain > logic shows that you lie. It can be true as well: every predicate holds for the empty set. Christian |
| Andrew Z <formisc@gmail.com>: Jun 08 09:08PM -0700 Hello, in the "Accelerated C++" book, that i'm reading, the below code is used as an example of using CIN to determine the number of the previously entered values. [code] while (cin >> x) { ++count; sum += x ; } [/code] From the reference i understood that cin/cout are created and kept "alive" for the duration of the program execution. If i were to have some high frequency input data on CIN for rather long period of time then, potentially, by checking number of values sent with the code above, i could run into memory or type length problems... I'm sure my imagination is running wild, dueto the luck of knowledge. Appreciate your explanation. |
| Barry Schwarz <schwarzb@dqel.com>: Jun 08 10:54PM -0700 On Wed, 8 Jun 2016 21:08:07 -0700 (PDT), Andrew Z <formisc@gmail.com> wrote: >[/code] >From the reference i understood that cin/cout are created and kept "alive" for the duration of the program execution. If i were to have some high frequency input data on CIN for rather long period of time then, potentially, by checking number of values sent with the code above, i could run into memory or type length problems... >I'm sure my imagination is running wild, dueto the luck of knowledge. Appreciate your explanation. The frequency of input does not matter. Two things that do matter are the number of inputs and the actual values. If sum is a signed integer, then it is possible to eventually exceed the maximum value for that type. Underflowing the minimum value is also possible. The same is true if x is a floating point type. If sum is a std::string, then you could possibly exceed the largest allowable length or you could run out of memory before that happens. Since you are accepting input from the user, these are not likely events. His fingers will fall off sooner. -- Remove del for email |
| Ralf Goertz <me@myprovider.invalid>: Jun 09 09:25AM +0200 Am Wed, 08 Jun 2016 22:54:45 -0700 > allowable length or you could run out of memory before that happens. > Since you are accepting input from the user, these are not likely > events. His fingers will fall off sooner. Except when cin is redirected. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 09 12:17PM > while (cin >> x) { This just means that it will read space-delimited strings and (try to) convert them to the type of x (eg. to int if that's the type of x). Since the return value of the operator>> is a referece to cin itself, and cin has an implicit conversion to bool operator which tells if the stream is still in a good state, the loop will end when the input ends or there some kind of error with the reading. It is not a very good way of reading any kind of input except in extremely narrow situations (where you can control exactly what is fed to the program as input), but it suffices as a simple beginner example. > some high frequency input data on CIN for rather long period of time > then, potentially, by checking number of values sent with the code > above, i could run into memory or type length problems... You aren't going to run into memory problems unless you are storing every single value you are getting from cin (eg. into a vector). As for the counter value, if it's your typical int, it would probably take days or months of feeding the program input before it wraps around, at the speeds that text can be fed to a C++ stream. (If the counter is 64-bit, the universe will cease to exist before it wraps around.) But if that's a worry, it's trivial to add a conditional to check if the counter is getting too large. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Paavo Helde <myfirstname@osa.pri.ee>: Jun 09 04:30PM +0300 On 9.06.2016 15:17, Juha Nieminen wrote: > take days or months of feeding the program input before it wraps around, > at the speeds that text can be fed to a C++ stream. (If the counter > is 64-bit, the universe will cease to exist before it wraps around.) This is a bit exaggerated. With a modest 1000 words per second input rate a 64-bit counter gets wrapped around already in 800 million years (and a 32-bit counter in 50 days). Cheers Paavo |
| "Fred.Zwarts" <F.Zwarts@KVI.nl>: Jun 09 03:37PM +0200 "Barry Schwarz" schreef in bericht news:2l0ilbh03fqgtv4kb9rka9b19ssc2mln5n@4ax.com... >allowable length or you could run out of memory before that happens. >Since you are accepting input from the user, these are not likely >events. His fingers will fall off sooner. If x and sum are ints, even 64 bit integers, and the user is not restricted to typing small values, sum may overflow very soon. |
| Andrew Z <formisc@gmail.com>: Jun 09 06:55AM -0700 Juha, > operator which tells if the stream is still in a good state, the loop will end > when the input ends or there some kind of error with the reading. that is another question i had - in the book this loop is _after_ all read/wrte to std was done. so in my mind, by the time "when" starts to execute, CIN has no data (empty stream since everything was already read) and the loop should be infinite. It seems that i do not understand how iostreams is implemented/designed. Where can i read on it in "beginners" words? Gentlemen, thank you for input. It is making sense now. |
| cross@spitfire.i.gajendra.net (Dan Cross): Jun 09 03:43PM In article <t7WdndCfj_4N8sTKnZ2dnUU78UHNnZ2d@giganews.com>, >This is a bit exaggerated. With a modest 1000 words per second input >rate a 64-bit counter gets wrapped around already in 800 million years >(and a 32-bit counter in 50 days). Quite modest, indeed. On my 2010-era workstation and an old version of GCC, this trivial program takes just under 15 minutes to overflow a 32-bit unsigned integer: : spitfire; uname -m -s Linux x86_64 : spitfire; cat foo.cc #include <iostream> int main() { unsigned int counter = 1; unsigned long sum = 0; int num; std::cout << "sizeof(counter) = " << sizeof(counter) << std::endl; std::cout << "sizeof(sum) = " << sizeof(sum) << std::endl; while (std::cin >> num && ++counter != 0) sum += num; std::cout << "counter = " << counter << ", sum = " << sum << std::endl; return 0; } : spitfire; make foo g++ foo.cc -o foo : spitfire; yes 1 | time ./foo sizeof(counter) = 4 sizeof(sum) = 8 counter = 0, sum = 4294967294 851.73user 4.74system 14:16.74elapsed 99%CPU (0avgtext+0avgdata 1204maxresident)k 0inputs+0outputs (0major+750minor)pagefaults 0swaps : spitfire; - Dan C. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 09 09:03AM -0700 On Thursday, 9 June 2016 18:43:28 UTC+3, Dan Cross wrote: > Quite modest, indeed. On my 2010-era workstation and an old version of > GCC, this trivial program takes just under 15 minutes to overflow a 32-bit > unsigned integer: Then it also takes some more than 100K years to overflow 64-bit unsigned counter. For perspective of running software it is as far in the future as is the end of the universe since any actual hardware capable of running it will decay long before. |
| cross@spitfire.i.gajendra.net (Dan Cross): Jun 09 04:27PM In article <cdad4610-978b-4290-b9db-8287a9f73f08@googlegroups.com>, >counter. For perspective of running software it is as far in the future as is the >end of the universe since any actual hardware capable of running it will decay >long before. Believing that the hardware will fail before overflowing a 64-bit integer by incrementing from zero is a fair assumption. However 32-bit counters are still used quite frequently and can -- and regularly do -- overflow rather quickly. Caveat programmer. - Dan C. |
| Cholo Lennon <chololennon@hotmail.com>: Jun 09 01:32PM -0300 On 06/09/2016 08:39 AM, Stefan Ram wrote: >> values sent with the code above, i could run into memory or >> type length problems... > I have no idea what »CIN« refers to. C'mon... you know it (we all know it)! Why this newsgroup is so hostile to newcomers/newbies? -- Cholo Lennon Bs.As. ARG |
| Barry Schwarz <schwarzb@dqel.com>: Jun 09 10:21AM -0700 On Thu, 9 Jun 2016 06:55:05 -0700 (PDT), Andrew Z <formisc@gmail.com> wrote: >> operator which tells if the stream is still in a good state, the loop will end >> when the input ends or there some kind of error with the reading. >that is another question i had - in the book this loop is _after_ all read/wrte to std was done. so in my mind, by the time "when" starts to execute, CIN has no data (empty stream since everything was already read) and the loop should be infinite. It seems that i do not understand how iostreams is implemented/designed. Where can i read on it in "beginners" words? C++ is case sensitive. It will eliminate confusion (and snide remarks) if your text reflects this. What do you mean when you say cin is empty? If you mean it has reached end of file, then the while condition will evaluate to false, the substatement will not execute, and control will flow to the statement following the while statement. If you mean the stream is waiting for more input, such as from the keyboard, then the evaluation of the condition will wait for that input. After this evaluation concludes, the substatement will execute of not based on the evaluation result. In neither case will the loop iterate an infinite number of times. As a beginner, you should not care how streams are implemented or designed. That is an advanced and system dependent topic. For now, you should be content to use the standard functions and operators to transfer data between the stream and your program. -- Remove del for email |
| 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