|
Prev: Special container
Next: map within map
From: Carlos Moreno on 11 Aug 2005 13:42 Jeff Schwab wrote: > // Unecessary use of preprocessor. > > T* p = NULL; // T* p = 0; IMO, your alternative is wrong. Deeply wrong. I know that I'm just re-triggering an endless discussion (a-la MAC vs PC, Unix vs. Windows, Ford vs. GM, etc.) One of the things that I profoundly hate of C++ is the use of 0 as the name of a null pointer. 0 should mean *only* 0 -- the numeric value of zero; and not the null value for a pointer. When I see NULL, it stands out and I know immediately that we are talking about a null pointer. When I see 0, my mind tells me that there is a number in there, and it requires some additional effort to realize that it is a pointer what's really involved. Perhaps the pet peeve should be with the language itself -- the fact that NULL is not a core language keyword. I also disagree (though not strongly) with your complaint about if (p != 0) or p != NULL as opposed to if (p). The p != NULL tells me a lot more on quick visual inspection than simply if (p) Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gabriel Dos Reis on 11 Aug 2005 16:59 "msalters" <Michiel.Salters(a)logicacmg.com> writes: | Jeff Schwab schreef: | | > // Redundant tests. | > | > if( some_bool == true ) | | In code reviews, point out that you can also write | | if( ( some_bool == true ) == true ) I think it should have been written if ( ( (some_bool == true ) == true ) == true ) -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: kevin.hall on 11 Aug 2005 17:03 Andrei, With all due respect (and I do respect you -- you have a lot of insight and the work you have done has helped me tremendously as a developer), but what are you trying to say in your post? It's not really clear since you only posted code. Are you saying that people shouldn't develop their own find algorithm and should use the STL instead? Ok, I got one more pet-peeve: Cryptic comments in source code [and cryptic messages in comp.lang.c++.moderated ;-) ] - Kevin [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Thomas Tutone on 11 Aug 2005 17:01 tony_in_da_uk(a)yahoo.co.uk wrote: > The define vs const issue is more concrete though. To illustrate, I've > included CC -S output from Sun Workshop (no optimisation)... [assemly output snipped] > Conclusion: it's only extern const values that weren't inlined. In > general, headers declaring extern consts do lead to larger, slower code > than headers using these other techniques. Actually, your example proves very little. Try it with optimizations turned on - after all, your release version will be optimized, won't it? - and see if there's still a difference. The complaint "I didn't turn on optimizations when I compiled my code, and now my code is larger and slower" is not compelling. In gcc, for example, the compiler does't bother to inline much - if anything - unless the lowest level of optimization is applied - so looking at unoptimized assembly output tells you very little about how efficient the compiled code can be. I've profiled code where a const int was accessed hundreds of thousands of times a second, and substituting a literal for the variable had no effect on optimized compilations (which is the only thing I bothered to profile). If you want to show me a counterexample involving code compiled with optimizations turned on, I'd be interested in seeing it. > No excuse for using #define > for ints though, as enum is available. This used to be the standard hack. On many (most?) modern compilers, the enum hack shouldn't be necessary any more. Best regards, Tom > > Cheers, Tony [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ulrich Eckhardt on 11 Aug 2005 17:00
B. Perlman wrote: [writing about constants and their different implementations] > Also, a more general issue -- if one is using this in more than one > source file, one will want to put it into a header file. It seems to > me that either one must declare it "static" and it will be instantiated > once for each source file in which the header is included, or one must > declare it "extern" and have the "real" declaration in some source > file. > > Is there a simpler way, or is it really worth it to do this? In some > cases, the gain (type checking) I find not very helpful IIRC, constant values don't have extern linkage in C++, i.e. at least the few compilers I used didn't complain when having constants defined in a header and that header being included in multiple translation units. It seems to works like integral static constants in classes or inline functions. Uli -- Questions ? see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first ! [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |