- Ravioli - 1 Update
- Comment on stackoverflow about value initialization seems to contradict my gcc compiler. - 2 Updates
- Best way to handle mathematical divide-by-zero case - 3 Updates
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 13 10:37PM 2017: "Ravioli" replaced "Romeo" in the NATO phonetic alphabet. #TrumpAdministration /Flibble |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 13 02:52PM -0700 On Fri, 13 Jan 2017 03:55:01 -0800 (PST), Paul <pepstein5@gmail.com> wrote: >However, you have to keep in mind that in some cases the initialization of a instance of the class can be performed by other means. Not by default constructor, nor by constructor at all. >For example, there's a widespread incorrect belief that for class C the syntax C() always invokes default constructor. In reality though, the syntax C() performs so called value-initialization of the class instance. It will only invoke the default constructor if it is user-declared. (That's in C++03. In C++98 - only if the class is non-POD). If the class has no user-declared constructor, then the C() will not call the compiler-provided default constructor, but rather will perform a special kind of initialization that does not involve the constructor of C at all. Instead, it will directly value-initialize every member of the class. For built-in types it results in zero-initialization. >END QUOTE The key wording seems to be "If the class has no user-declared constructor, then the C() will ... perform a special kind of initialization that does not involve the constructor of C at all." In your example, C *has* a user-declared constructor, C(int), so value-initialization doesn't happen. I tried this with g++: struct C { C(int ){} }; int main() { C b; ==> error: no matching function for call to 'C::C()' C c = C(); ==> error: no matching function for call to 'C::C()' } If I remove the constructor C(int), the errors go away. Louis |
| Paul <pepstein5@gmail.com>: Jan 13 02:14PM -0800 On Friday, January 13, 2017 at 9:53:36 PM UTC, Louis Krupp wrote: > } > If I remove the constructor C(int), the errors go away. > Louis Thanks to both of you. I understand it now. Paul |
| David Brown <david.brown@hesbynett.no>: Jan 13 03:23PM +0100 On 13/01/17 14:11, JiiPee wrote: > than put an address which points to an object which does not exist. When > debugging, NULL value is easier to spot than some valid/invalid object > address value. Pointers are a little different because they have a specific value that indicates "does not point to a valid object", i.e., NULL. (Non-null pointers may also fail to point to valid objects, of course.) It is also common practice to check for NULL pointers in code - though of course people may fail to do so. NaN's are a possible signal type for functions returning a double, but how often do people check for them? Anyone that is a careful enough programmer to check that the result of your average function is not an NaN or infinity, is going to be careful enough to check that they don't pass invalid data (an empty set) to your function in the first place. The only real use of NaNs here is if the average function specifically says it will return NaN on bad input, the high level code is written by someone who expects intermediary functions to return NaN on errors, and the middle layer (that calls the average function) is written by a muppet and never checked by someone who can actually write correct code. > I dont know, I dont feel like returning 0 in average() if there was an > error, beacause that might confuse to think everything is fine.... Any value you return for a function which received invalid data /will/ be wrong. It does not matter what value you pick - there will be circumstances in which that value is wrong, and for which that value is difficult to spot in debugging or testing. It is certainly possible to pick a return value that is easier for debugging in /some/ cases - but that value can never be the "best" choice in all cases. You need to understand that, and accept that - or else you will spend a great deal of effort trying to do the impossible. |
| JiiPee <no@notvalid.com>: Jan 13 02:57PM On 13/01/2017 14:23, David Brown wrote: > pick a return value that is easier for debugging in/some/ cases - but > that value can never be the "best" choice in all cases. sure, if its about "how many time we shoot with a weapon", then 0 is pretty safe return value rather than 999999999. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 13 08:25PM On the average of no values... > On 12/01/17 17:44, JiiPee wrote: <snip> > month. If you don't drink coke, and it is averaging an empty set, would > you rather your fridge ordered 0 cokes for next month, of 99999999999999 > bottles? The average here would over time (the result being bottles/week or ml/day or whatever). The zero quantity is on the top of the division. <snip> -- Ben. |
| 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