Solid C++ by example
in [C++]
|
Prev: Lifetime of a temporary bound to a reference
Next: When I convert "0.0003" and "3.e-4" in VC++ they are the same
From: Nick Hounsome on 29 Jun 2010 16:51 On 28 June, 21:51, Olve Maudal <olve.mau...(a)gmail.com> wrote: > At the NDC2010 conference, I gave a presentation where I demonstrated > Solid C++ code by example: > > http://www.slideshare.net/olvemaudal/solid-c-by-example > > It would be great to have your opinion about the examples I present. > Is this solid code, or can it be improved even further? Assuming that we are pretending someone else wrote this and we are reviewing it or just doing some mods on a module: I know it's not necessary but pretty much everyone I've ever met uses braces with sizeof and in such cases it's always best to go with majority taste. Even braces with return - Whoever wrote it found it more readable that way so I would probably, reluctantly, leave them. I certainly wouldn't change existing code to remove extra braces unless I was rewriting anyway - It's kind of rude and it doesn't help when you come to diff the code to see what changes were made. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Kaba on 29 Jun 2010 16:55 Edward Diener wrote: > On 6/28/2010 9:32 PM, Johannes Schaub (litb) wrote: > > I would also not recommend using a "size_t" to store an offset containing > > "12" - i think it's bad to use "unsigned" just to signify a quantity is > > unsigned. > > I have never understood such reasoning. If I have an integer value which > I know must be unsigned, why would I not use an unsigned integer rather > than a signed integer ? My opinion is also that unsigned should not be used for integer quantities. My reasoning goes as follows: 1. Robustness 1a) The neighborhood of zero is perhaps the most used of all integer values. 1b) It is easy to get buggy computations off by few, leading to negative values. Negative values then get wrapped to positive values, and these can't be taken as a bug, because there are no invalid values. 1c) More robust programs are created by allowing for negative values so that they can be used to detect bugs. You can also do this with unsigned values by allocating the last half to this purpose, but that does not correspond with logic anymore. 2. Preservation of information 2a) Unsigned<->signed conversions are, in general, lossy. 2b) The only way to deal with these conversions are to avoid them. Thus you should either use only unsigned or signed. 2c) When used to model the ring of integers, unsigned integers have robustness issues, as explained in 1), and they can't, by definition, deal with negative integers. 2d) Therefore signed integers are the proper model for the ring of integers. 3. Consistency and traps 3a) Try to for-loop from positive n to zero using an unsigned integer index: it never finishes, although no negatives are conceptually used. 3b) Is there a difference between looping in the range [-4, 15] or [0, 15]? What about forward or backwards? It makes code more consistent to always use a signed integer, and you will never have to think things like 3a). 4. Floating point analogue One can imagine an unsigned floating point type by stripping off the sign bit, and perhaps giving an additional bit to the mantissa. Such a type would have similar problems as listed here for the integers. Interestingly, people don't seem to have anxiety over this lost bit, although the situation is exactly as with the integers. 5. Summary I think all of the previous can be summarized as follows. Most of the time we are interested in modeling the ring of integers (math Z), even though we'd only use the non-negative values. This is because values are rarely simply stored: rather, they are used for further computations. We want to (or most often implicitly) think of all operations (+, -, *) as if we were working in Z. Because of finite storage, this does not hold on the limits. But it does hold most of the time, that is, when we work on the neighborhood of zero. Being able to work in this neighborhood safely and cleanly is important for bug-free programs. This is what signed integers offer over unsigned integers. The story for the imaginary unsigned floating point type would be similar, now discussing reals and non-negative reals. -- http://kaba.hilvi.org [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: joe on 29 Jun 2010 16:58 Edward Diener wrote: > On 6/28/2010 9:32 PM, Johannes Schaub (litb) wrote: >> Olve Maudal wrote: >> >>> At the NDC2010 conference, I gave a presentation where I >>> demonstrated Solid C++ code by example: >>> >>> http://www.slideshare.net/olvemaudal/solid-c-by-example >>> >>> It would be great to have your opinion about the examples I present. >>> Is this solid code, or can it be improved even further? >>> >> >> One thing i really don't agree with is depending on things included >> by other 3rd party headers. >> >> I would also not recommend using a "size_t" to store an offset >> containing "12" - i think it's bad to use "unsigned" just to signify >> a quantity is unsigned. > > I have never understood such reasoning. If I have an integer value > which I know must be unsigned, why would I not use an unsigned > integer rather than a signed integer ? You just opened up the can of worms that was a long thread or 3 last month! From what I gathered, it is personal preference though each "side" will try to convince the other that they are "right". -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Öö Tiib on 29 Jun 2010 17:09 On 28 juuni, 23:51, Olve Maudal <olve.mau...(a)gmail.com> wrote: > At the NDC2010 conference, I gave a presentation where I demonstrated > Solid C++ code by example: > > http://www.slideshare.net/olvemaudal/solid-c-by-example > > It would be great to have your opinion about the examples I present. > Is this solid code, or can it be improved even further? Overall ... some such "issues" may be matter of taste. Good teams agree about policies by what they code and then review each others code to ensure that they follow their policy. Teams are different, tasks are different and C++ is multiple paradigm language. Also language evolves and so do teams and their policies. frame 16: "Weekly Top Five"? Base class must have either a virtual destructor or a protected destructor. I would additionally typedef in class ntml_message: typedef std::vector<uint8_t> bytes; "bytes" (some like names like "byte_buffer") is better to read than "std::vector<uint8_t>". Lot of other issues (32,52,78) are basically because of lack of such typedef. frame 56: "use std::size_t when appropriate" using std::size_t instead of int as type of constant value 12 is not making it more readable. Since it is pointer offset some pedantic code policy can demand usage of std::ptrdiff_t however. History has shown that each team has to agree what is correct for them and then stick to it. I am usually happy with comment near sole usage of magic number ("12 is ssp flags offset"). Same about frame 118. frame 110/111: I have seen coding policy that explicitily required parentheses for return and sizeof claiming it is "more readable and clear". If yours forbids, remove them. I do not care. Beware that such things do not compile: std::size_t const unsigned_long_size = sizeof unsigned long; -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: TheGunslinger on 29 Jun 2010 17:08
On Mon, 28 Jun 2010 14:51:10 CST, Olve Maudal <olve.maudal(a)gmail.com> wrote: >At the NDC2010 conference, I gave a presentation where I demonstrated >Solid C++ code by example: > > http://www.slideshare.net/olvemaudal/solid-c-by-example > >It would be great to have your opinion about the examples I present. >Is this solid code, or can it be improved even further? > >Thanks, >- olve Sorry, but for some reason, it doesn't always display properly and I cannot tell what the balloons are actually referencing. MJR -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |