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: Zeljko Vrba on 3 Jul 2010 07:56 On 2010-07-03, Francis Glassborow <francis.glassborow(a)btinternet.com> wrote: > Zeljko Vrba wrote: >> On 2010-07-01, Francis Glassborow <francis.glassborow(a)btinternet.com> wrote: >>> The main reason fgor using default arguments was that it reduced problems with multiple constructors where you could not use a wrapper to forward to the genral version. That has been fixed in C++0x and so the largest motive for using default arguments has gone. >>> >> For me, the largest motive for using default arguments is to extend >> functionality of methods without breaking existing code, where >> overloading is not practical. > > Please give me an example because I can make no sense of your claim. > > void foo(int, float, int. double); > inline void foo(int i, int j, double d){ > return foo(i, 0.0, j, d); > } > > How can that break anything? And it works just as well for member functions. > My actual use-case was void foo(int, double *result1, int *result2 = 0) When result2 != 0, it is both a flag that extra data has to be computed and provides storage for the extra results. In this case, the extra computation reuses the intermediate results already stored in local variables. Making an overload would entail copy-pasting the entire body of 2-argument foo and adding extra code, so I'd have to fix bugs in two places. Alternative would be packaging both overloads into a class so that 3-argument foo can reuse intermediate results computed by 2-argument foo, which is an overkill. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 3 Jul 2010 17:27 Walter Bright wrote: > Edward Diener wrote: >> 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 ? > > > Because unsigned types tend to be 'sticky', i.e. (1 + 1u) is an > unsigned. This propagation of unsigned-ness is subtle and surprises even > experienced programmers. > > There was a long thread on this over on the D n.g., and I must say that > although I started from your position, I'm slowly moving towards using > unsigned only if you expect the values to have the high bit set. > And there is the fact that unsigned is a strict modular arithmetic type whereas signed types have undefined behaviour when they overflow. That means that in high integrity processes checks for overflow potential must be made prior to evaluation of signed arithmetic. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 3 Jul 2010 17:23 In article <i0lkli$kct$1(a)news.eternal-september.org>, Walter Bright <walter(a)digitalmars-nospamm.com> wrote: >Edward Diener wrote: >> 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 ? > >Because unsigned types tend to be 'sticky', i.e. (1 + 1u) is an unsigned. >This propagation of unsigned-ness is subtle and surprises even experienced >programmers. If only it were that simple :-( Worse, C99 is subtly incompatible with C90 in this respect, which will therefore impact C++0X. And, of course, all standards are not so subtly incompatible with pre-standard versions, but that's getting to be a historical footnote. >There was a long thread on this over on the D n.g., and I must say that >although I started from your position, I'm slowly moving towards using >unsigned only if you expect the values to have the high bit set. Absolutely. The only safe rule is NEVER to mix signed and unsigned, unless you are absolutely certain that ALL possible values can be held in ALL of the operand types without any conversion or promotion. A simpler and safer rule is never to use unsigned, but that isn't feasible in C and C++. I know as much about this area as anyone I know, and I don't even try to remember the detailed rules - in my courses, I say "Here Be Dragons" and don't try to describe the details. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jens Schmidt on 3 Jul 2010 17:46 Alf P. Steinbach wrote: > The key idea is to define the support lacking in the standard library, namely > > * a signed Size type (as ptrdiff_t), and a ditto Index type, > > * size, startOf and endOf functions where size() yields Size, and > > * to support those functions, automatic iterator type deduction. > > Then your example becomes > > for( Index i = 0; i < size( v ); ++i ) > > which works no matter if v is a std::vector or a raw array or whatever, > and which also works just as nicely for a countdown, > > for( Index i = size( v ) - 1; i > 0; -- ) If I read this correctly, you want "i >= 0" as comparison and "--i" as statement. For countdown: why not just use a pattern like for_down (Index i = size (v); i > 0; --i)? Here for(a;b;c) d; expands as usual to a; while (b) { d; c; } and for_down(a;b;c) d; expands to a; while (b) { c; d; } (note the reversed order in the body). This pattern works with signed and unsigned types. -- Greetings, Jens Schmidt [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 3 Jul 2010 17:45
On Jul 2, 9:56 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > * Mathias Gaunard, on 01.07.2010 16:23: > Depends. In ordinary code, if ADL selects something that is unacceptable then > that is most probably a design problem that should be fixed. IMHO. > > But in Boost-like code and other TMP code that routinely exploits the most > subtle and intricate features of C++ it may perhaps be extremely dangerous to > let anything be implicit except where the implicit selection is the point. Not only are namespaces in which the argument is in considered by ADL, the namespace of the template parameters of the arguments are considered as well. This means that something like boost::array<boost::fusion<int, char>, 42> array; begin(array); is ambiguous, as both boost::begin and boost::fusion::begin are being considered. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |