From: Carlos Moreno on
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
"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
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
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
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! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Prev: Special container
Next: map within map