- Best way to handle mathematical divide-by-zero case - 9 Updates
- how can I guess which OS is running a C/C++ program? - 1 Update
- Why I Dislike Synthetic Tests - 2 Updates
- Could this container I made have any use? - 2 Updates
| Manfred <mx2927@gmail.com>: Feb 06 01:08AM +0100 On 01/12/2017 05:27 PM, JiiPee wrote: > I see. But in this case I would prefer to use NaN or max_double so the > user would see there is something wrong going on. Because 0 return looks > like a success, but getting max_double would surely be noticed. I believe you got exactly the point here, except that personally I would not like NaN - INF or max_double even less. I would indeed go for the exception. Returning a valid value (0) would likely result in the containing program to silently give some result which is not correct for the input data, which in my opinion is a Bad Thing. Returning NaN would silently allow the program to complete with a NaN result, which would inform the user that invalid data was provided, but no more than that. The exception is indeed meant to provide feedback that invalid data was provided /and/ what was wrong about it. The above applies to the average() case, but more in general with floating point math division by zero can quite often be prevented by proper rearrangement of expressions and/or taking advantage of INF processing (NaN remains quite intractable though). It may be worth noting that the average() calculation is not entirely floating point math - your denominator is an integer, which by no coincidence results in the situation to need to be handled as an error. |
| JiiPee <no@notvalid.com>: Feb 06 12:39AM On 06/02/2017 00:08, Manfred wrote: > I would indeed go for the exception. But Bjarne seems to be against exception in this kind of situation... |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 06 12:50AM On 06/02/2017 00:39, JiiPee wrote: > On 06/02/2017 00:08, Manfred wrote: >> I would indeed go for the exception. > But Bjarne seems to be against exception in this kind of situation... And Bjarne isn't always correct. Throwing an exception is entirely appropriate for handling division by zero which is a BUG. /Flibble |
| David Brown <david.brown@hesbynett.no>: Feb 06 02:01AM +0100 On 06/02/17 01:39, JiiPee wrote: > On 06/02/2017 00:08, Manfred wrote: >> I would indeed go for the exception. > But Bjarne seems to be against exception in this kind of situation... Bjarne was against making it a standard for C++. You are free to throw an exception yourself if you want. But I thought this had already been thrashed to death a few weeks ago - why are we going through it all again? |
| JiiPee <no@notvalid.com>: Feb 06 07:33AM On 05/02/2017 14:26, Stefan Ram wrote: > template< typename I > > inline static double narrow_average( I first, I top, size_t size ) > { return ::std::accumulate( first, top, 0.0 )/ size; } yes should have been something like that. I use for-loop at that time, but was not so experienced that time. |
| Manfred <noname@invalid.add>: Feb 06 01:56PM +0100 On 2/6/2017 1:39 AM, JiiPee wrote: > On 06/02/2017 00:08, Manfred wrote: >> I would indeed go for the exception. > But Bjarne seems to be against exception in this kind of situation... I don't recall when/where he may have said that, I would be curious; could you be more specific if you like? |
| JiiPee <no@notvalid.com>: Feb 06 10:25PM On 06/02/2017 12:56, Manfred wrote: >> But Bjarne seems to be against exception in this kind of situation... > I don't recall when/where he may have said that, I would be curious; > could you be more specific if you like? http://stackoverflow.com/questions/6121623/catching-exception-divide-by-zero Stroustrup says, in "The Design and Evolution of C++" (Addison Wesley, 1994), "low-level events, such as arithmetic overflows and divide by zero, are assumed to be handled by a dedicated lower-level mechanism rather than by exceptions. This enables C++ to match the behaviour of other languages when it comes to arithmetic. It also avoids the problems that occur on heavily pipelined architectures where events such as divide by zero are asynchronous."` |
| JiiPee <no@notvalid.com>: Feb 06 10:26PM On 06/02/2017 22:25, JiiPee wrote: > It also avoids the problems that occur on heavily pipelined > architectures where events such as divide by zero are asynchronous. I wonder what does this mean? |
| Robert Wessel <robertwessel2@yahoo.com>: Feb 06 04:46PM -0600 >> It also avoids the problems that occur on heavily pipelined >> architectures where events such as divide by zero are asynchronous. >I wonder what does this mean? There are machines where a divide by zero traps, but the trap is not precise (not to mention other exceptions). IOW, the divide by zero does trap, but some undefined number of additional instructions might get executed before the trap actually happens, plus some *previous* instructions might not have been executed yet. This is not really an issue on non- or minimally pipelined machines. OTOH, most mainstream "large" pipelined CPUs take great pains to preserve the precise nature of exceptions. That's one of the important things the massive reordering mechanism at the back end of most x86s does. So if you rely on the hardware to catch the divide-by-zero on such a machine, you may not be able to do anything useful after it happens, since your programs state will be mangled. The alternative is then to insert a test for zero before every divide, which might be very slow. |
| alexo <alessandro.volturno@libero.it>: Feb 06 05:33PM +0100 Il 05/02/2017 19:54, Richard ha scritto: > [Please do not mail me a copy of your followup] > You didn't answer my question about the compile error. > That's the only interesting part of this thread to me. Hi, Richard. I have recompiled your code on Visual Studio and all went well. No errors or warnings. I don't know what I did wrong last time. But obviously was a fault of mine. Forget this issue. Sorry but thank you for your precious words. Cheers |
| Andrey Karpov <karpov2007@gmail.com>: Feb 06 12:56AM -0800 I don't like it when people use artificial code examples to evaluate the diagnostic capabilities of static code analyzers. There is one particular example I'm going to discuss to explain my negative attitude to synthetic tests. Bill Torpey recently wrote a blog post entitled "Even Mo' Static", where he shared his view on the results of testing Cppcheck and PVS-Studio analyzers on the itc-benchmarks project, which is a set of static analysis benchmarks by Toyota ITC. That post upset me because it would leave you with an impression that Cppcheck's and PVS-Studio's capabilities were very similar. What follows from the article is that one analyzer is better at diagnosing some types of errors and the other, at diagnosing other types of errors, but their capabilities are generally the same. I think it's a wrong conclusion. My opinion is that our analyzer, PVS-Studio, is several times more powerful than Cppcheck. Well, it's not even an "opinion" - it's what I know for sure! Full text: http://www.viva64.com/en/b/0471/ |
| "Öö Tiib" <ootiib@hot.ee>: Feb 06 03:43AM -0800 On Monday, 6 February 2017 10:56:58 UTC+2, Andrey Karpov wrote: > I think it's a wrong conclusion. My opinion is that our analyzer, > PVS-Studio, is several times more powerful than Cppcheck. Well, > it's not even an "opinion" - it's what I know for sure! Everybody expects you to have biased opinion about your product. As for neutral party ... all the text in article felt nonsensical and religious. How your product detects if null pointer dereference was designed maliciously to crash, or test of something else contains accidental defect that may crash or crash was really part of requirements? Are you making psychic software? :-D :-P Whatever it does, I don't expect it to do that. So for me your program misbehaves, sorry. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 06 12:25AM -0800 On Sunday, 5 February 2017 18:00:46 UTC+2, bitrex wrote: > > 'bucket' is special compared to such alternatives. > I remember boost::variant being a pain in the butt to use, and > boost::any is really slow! May be you conflate two things that are very far from one another. My impression of 'boost::variant' is that it is fast and easy to use. More convenient than union. My impression of 'boost::any' however is negative from every side: slow, inconvenient, fragments memory and produces cryptic diagnostics. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 06 01:48AM -0800 > that the latest version of the standard would be passed on > December 31, 2017 at 10pm (if I remember correctly). > Better late than never ... Even if the standard will be signed 2018 the implementations of std::variant were already useful 2016. > > flexible, available for more platforms, better tested and/or > > faster fixed than custom classes. > I think implementation-wise Clang shuns standard containers. Few years ago when I tried to compile LLVM on microsoft compiler then it contained lot of C that did not compile on microsoft compiler. Source of LLVM smelled like another tool of negotiations between apple and ms. That is most awful code smell. > I try to avoid them also, but I'm not successful yet in avoiding std::queue/std::deque. We discussed those queues. I suggested to check performance of boost::circular_buffer_space_optimized. You answered that it is not portable enough for you. :D If you can't improve such (quite portable, well-tested, open-source) container then you can't likely make better one either. So you should use standard containers (as maximally portable). |
| 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