- industrial code (over flow...) - 4 Updates
- casting that's a lot of extra typing :-) - 11 Updates
- Read again, i correct a typo because i write fast... - 2 Updates
- is there a C++ version of the strtok() function? - 3 Updates
- What does C++ say about climate change? - 3 Updates
- #define - 2 Updates
| David Brown <david.brown@hesbynett.no>: Jun 29 11:56PM +0200 On 29/06/2019 04:46, G G wrote: > } > the code above is taken from: > https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow Signed integer overflow is undefined behaviour in C++ (and C). There are many ways to avoid overflowing, depending on the circumstances, the operations you are doing, the target compiler (if portability is not a concern), etc. In most cases, signed integer overflow is an error - it's a case of garbage in, garbage out. And in most cases, a check like you have made above is meaningless and inefficient because all it does is check if the addition can be done with those types, without overflowing. It is rare that you are adding two integers with unknown origins, and unknown usage, and that adding them is all you are doing - and thus rare that it makes sense to make a check like that. It is far better to check for the validity of data when it comes in from the outside, checking against sensible limits. And then make your calculations valid for all sensible data (use bigger types if necessary). |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 30 03:00AM -0700 On 6/28/2019 7:46 PM, G G wrote: > are these checks still necessary or is there another way? [...] Its been a while since I read the following, cannot remember if it goes into overflows: http://www.stroustrup.com/JSF-AV-rules.pdf |
| David Brown <david.brown@hesbynett.no>: Jun 30 10:24PM +0200 On 30/06/2019 11:43, G G wrote: >> people. > I'm sure too. > I thank him, you, and everyone who helps me learn. (/Please/ use appropriate attributions. Even if you have to use the appalling google groups interface instead of a proper newsreader and newsserver, you should make the effort to keep attributions.) |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 30 06:22PM +0200 On 30.06.2019 17:18, Öö Tiib wrote: >> Will always be true for two's complement form, by definition. floor( >> (2^n)-1)/2 ) = floor( 2^(n-1) - 1/2 ) = 2^(n-1)-1, which is LONG_MAX. > Yes but two's complement is not guaranteed for long. Oh it is. No extant compiler uses anything else, and next year you get it guaranteed from the standard too. > vote each decision ... if the specs were defective then > these would likely suggest same, incorrect decision > unanimously. Cheers! - Alf |
| "Öö Tiib" <ootiib@hot.ee>: Jul 05 04:43PM -0700 On Friday, 5 July 2019 19:47:31 UTC+3, Manfred wrote: > Then you don't have seen much of it. > > This kind of child-proof lock in C++ is simply useles. > Just the opposite, as many have said. It is may be not worth to repeat that endlessly. Melzzzzz, Alf, Juha and Chris have seemingly already pointed out most of the meaningful benefits of C++ casts. Bonita has apparently none experience with it and won't come up with anything resembling counterarguments so ... end of story. Either time will teach her or wont. Pointless to warm it up. ;) |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 06 11:05AM +0200 > ... Melzzzzz, Alf, Juha and Chris have seemingly already > pointed out most of the meaningful benefits of C++ casts. ... They pointed them out just as chid-proof locks. |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 06 03:28AM -0700 On 7/6/2019 2:05 AM, Bonita Montero wrote: >> ... Melzzzzz, Alf, Juha and Chris have seemingly already >> pointed out most of the meaningful benefits of C++ casts. ... > They pointed them out just as chid-proof locks. They have their place. Btw, you might get a kick out of the following scene: Cork on the Fork in Dirty Rotten Scoundrels: https://youtu.be/SKDX-qJaJ08 You think the C++ casts are akin to the cork on the fork? |
| "Öö Tiib" <ootiib@hot.ee>: Jul 06 05:53AM -0700 > They pointed them out just as chid-proof locks. They nowhere did it, you did. C++ casts don't unfortunately work as child proof locks. If there was a feature that worked like baby proof lock and kept stupid people from using C++, then I would really love it. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 06 06:36AM -0700 On Saturday, July 6, 2019 at 5:05:30 AM UTC-4, Bonita Montero wrote: > > ... Melzzzzz, Alf, Juha and Chris have seemingly already > > pointed out most of the meaningful benefits of C++ casts. ... > They pointed them out just as chid-proof locks. A child-proof lock is designed to protect something from tampering by less-sophisticated users, while retaining accessibility for more sophisticated ones. I see no way to make an analogy connecting that concept to the advantages of the named casts in C++. A failure to use them when appropriate is a strong indication of inexperience with C++, but there use itself doesn't have any consequence that varies with experience level. The key advantage they provide is that they make it an easily diagnosed constraint violation to accidentally perform a different kind of conversion than was intended. The mistakes that they help diagnose are among the most common mistakes made when using C-style casts. Like all such mistakes, they are made less commonly by experienced developers than by inexperienced ones, but experience doesn't make such mistakes impossible, merely less likely. That you claim to have never seen such mistakes suggests a lack of experience with C-style casts. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jul 01 12:45PM > double ( a_value ) or (double) a_value > vs. > static_cast<double>( a_value ) /* c++ 11 + */ no that's 98 -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 01 01:14PM On Sun, 2019-06-30, G G wrote: > double ( a_value ) or (double) a_value > vs. > static_cast<double>( a_value ) /* c++ 11 + */ Do you have a question, or do you want to make a statement about something? And what is the smiley for -- is the whole posting a joke? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 01 02:53PM +0200 >> C++-style casts are superfluous child-proof locks in most cases. >> And in many cases they're even syntactic sugar. > No. No, sure. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 01 02:40PM +0200 C++-style casts are superfluous child-proof locks in most cases. And in many cases they're even syntactic sugar. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jul 01 12:46PM > C++-style casts are superfluous child-proof locks in most cases. > And in many cases they're even syntactic sugar. No. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 01 12:53PM -0700 On 7/1/2019 5:53 AM, Bonita Montero wrote: >>> And in many cases they're even syntactic sugar. >> No. > No, sure. There is a difference between static_cast and reinterpret_cast. No? |
| Real Troll <real.troll@trolls.com>: Jun 30 08:45PM -0400 On 30/06/2019 22:09, Mr Flibble wrote: > Why would we read it again Because he told you so, dickhead!!! In future if you don't like his posts then kill-file him and stop replicating his post or his name. Some of us don't see his posts but silly people like you not only reads them but also replicates them here and and messes our normally fine set-ups!!. I don't expect you to abide by this rule so I'm kill-filing you also so that I don't have to read any of your crap here. Real Troll Here with new agenda!!!!!!!!!!!!!! |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 01 12:55PM -0700 On 6/30/2019 5:45 PM, Real Troll wrote: > On 30/06/2019 22:09, Mr Flibble wrote: >> Why would we read it again > Because he told you so, dickhead!!! Sorry, but this made be bust out laughing. :^D [...] |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 29 04:51PM +0200 > * Microsoft submitted their silly *_s bounds checking functions for > standardization in C. They aren't silly! If you don't use C++-strings but stick with C char-arrays the make sense. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 01 06:56AM +0200 > What's with all the `::std::`? `std::` is fine. Your code is nearly as > bad as Alf's. ::std:: is because of Stefan's compulsiveness. |
| scott@slp53.sl.home (Scott Lurndal): Jul 01 01:09PM >> If it works, why "improve" it? strtok is perfectly legal C++. >Because strtok has known and acknowledged limitations which make it >unsuitable for many applications. I'm well aware of strtok and its shortcomings. However, my question stands. If it works already [in an application], why change it? The impression I got was that the OP didn't think it was "C++" enough. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 29 02:55PM On Sat, 2019-06-29, Stefan Ram wrote: ... Lots of things are more important than C++, but they are still offtopic here. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 29 10:36PM +0100 On 29 Jun 2019 12:09:08 GMT > n4800, 28.10.3.4 Member functions [syncstream.osyncstream.members] > (It might sound cynical, but when people are driving > 90 miles an hour down a dead-end road what else is left?) I think that by mistake you posted to the wrong group. C++ says nothing about climate change. C++ is a programming language. Evidence indicates beyond reasonable dispute that global temperatures are rising, partly because of human intervention. Sea levels are about 2cm higher than 200 years ago. They are about 130 metres higher than at the end of the last glaciation maximum, mainly because of natural temperature and climate variation because we are now in an inter-glacial period of an ice age. Sea levels are still over 200 metres lower than they were 100 million years ago (a blink of the eye geologically speaking). 250 million years ago Antartica was forested even though it was only somewhat further north than now, because the joining of the North and South American continents had not then occured so extinguishing trans-global currents. For the larger part of earth's history there has been no permanent ice on both poles: ice ages such as the present one are typically unusual (plate techtonics have been a big driver of climate variation): in earth's history there have been at least 5 of them. One of them (the Cryogenian) may have produced a "snowball earth" with ice sheats to the equator. Carbon dioxide absorption by silicate weathering will in due course become a threat to bio-diversity (100 to 500 million years ahead) by reducing carbon dioxide below the level required for the main form of photosynthesis to occur (but new forms of vegetation will adapt). Increased solar radiation is a bigger long term threat as nuclear fuel is slowly expended, which at some point (approx 1 billon years ahead) will cause thermal runaway and evaporation of the oceans, long before the sun turns into a red giant. If technology is sufficiently existent at that time, then it may possibly be averted technologically be reflecting the radiation back into space. Nothing is likely to defend when the sun becomes a red giant in some 5 billion years time, and nothing at all will defend the subsequent extinguishment of solar radiation. As Private Fraser would say, "we are all doomed". We are all on your dead-end road. (The universe is also, by virtue of the 2nd law of thermodynamics - the universe has an arrow of time.) |
| Keith Thompson <kst-u@mib.org>: Jun 29 02:23PM -0700 > Subject: Re: What does C++ say about climate change? Nothing. > »"Goodbye, " << "Planet!"« > n4800, 28.10.3.4 Member functions [syncstream.osyncstream.members] In context, it's simply a phrase in contrast to "Hello, World!". -- 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 */ |
| Keith Thompson <kst-u@mib.org>: Jul 05 04:49PM -0700 >> Where did you see this macro? > http://www.minix3.org/documentation/AppendixB.pdf > line 00034 That's C, not C++. And it's *old* C, designed to work with pre-ANSI C compilers. It might or might not even compile as C++. The macro is defined as: #define _PROTOTYPE(function, params) function params for ANSI C mode, and as: #define _PROTOTYPE(function, params) function() for pre-ANSI mode. So if I have a function named "foo" that takes two int arguments and returns an int result, I might write: int _PROTOTYPE(foo, (int x, int y)) In ANSI C mode, that would expand to: int foo(int x, int y) and in pre-ANSI mode it would expand to int foo() It's useless for modern C, or for C++. You'd just write the prototype directly and not worry about obsolete C compilers. Yes, it would work for C++ -- but only if the tests that determine the value of _ANSI were updated. They're not even correct for C99 or C11, much less for C++. (C99 defines __STDC__ as 199901L, not 1). If you're trying to learn C, then (a) this is the C++ newsgroup, and (b) this is not a good place to start. If you're trying to learn C++, then this *definitely* is not a good place to start. It's a demonstration of what C programmers had to deal with in the old days before the standard. Standards were written precisely so programmers would no longer have to do this kind of thing. -- 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 */ |
| "Öö Tiib" <ootiib@hot.ee>: Jul 05 04:56PM -0700 On Saturday, 6 July 2019 02:23:03 UTC+3, G G wrote: > > yes > i stop at line 34. preprocessor macros > are you say those preprocessor statement would not work in C++? No. I trust that C99 and C++11 preprocessors are quite fully compatible. I was saying that most macro usages valid in C will be rightfully frowned upon by experienced C++ programmers. Don't snip next time without reading. If you can't read, study that art first. |
| 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