Board index » cppbuilder » Re: C++\CLI compiler

Re: C++\CLI compiler


2007-09-18 01:02:12 AM
cppbuilder3
Frank J wrote:
Quote
No problem, I'll still hang out to keep you guys honest :)
Everyone is welcome here, even self-appointed honesty arbiters.
.a
 
 

Re:Re: C++\CLI compiler

dhoke wrote:
Quote
I think the notion that C/C++ (-based languages) have an implicit
conversion to bool in conditional tests is wrong.

C, and C++, do not have an implicit conversion to bool in conditional
tests.

They are asking the question of whether the expression is zero or
non-zero (which generally matches the capabilities of the underlying
assembler instruction sets I've been exposed to.)
One of the problems of C++ is that pointers can also be 0. In Pascal,
nil can only be assigned to pointers, and while it generally has the
ordinal value 0, that doesn't have to be true.
--
Rudy Velthuis [TeamB]
"For centuries, theologians have been explaining the unknowable
in terms of the-not-worth-knowing."
-- Henry Louis Mencken (1880-1956)
 

Re:Re: C++\CLI compiler

Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
[...]
for (n = firstnode; n; n = n.next)

will compile [...]
Of course, that depends on the definition of 'n', but IME
it's rather unlikely it will compile. 'n->next', OTOH,
probably will. :)
Schobi
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"A patched buffer overflow doesn't mean that there's one less way attackers
can get into your system; it means that your design process was so lousy
that it permitted buffer overflows, and there are probably thousands more
lurking in your code."
Bruce Schneier
 

{smallsort}

Re:Re: C++\CLI compiler

Hendrik Schober wrote:
Quote
Let's stop this nevertheless.
Agreed.
- Leo
 

Re:Re: C++\CLI compiler

Hendrik Schober wrote:
Quote
Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
>[...]
>for (n = firstnode; n; n = n.next)
>
>will compile [...]

Of course, that depends on the definition of 'n', but IME
it's rather unlikely it will compile. 'n->next', OTOH,
probably will. :)
Sorry, C# and Delphi habits. I've been using both extensively. <g>
--
Rudy Velthuis [TeamB]
"Talent does what it can; genius does what it must."
- Edward George Bulwer-Lytton (1803-1873)
 

Re:Re: C++\CLI compiler

In article < XXXX@XXXXX.COM >, Rudy Velthuis
[TeamB] wrote:
Quote
Of course, the fact that both = and == are operators, and that almost
enything can be (mis)used as a boolean result doesn't make this easier.
If = were not an operator (like in Delphi),
Yes, that's the point, really. The problem is not that you can place an
assignment in an if() statement -- that's sometimes useful -- but that the
language will automatically take the result of such an assignment and
silently convert it to bool when in fact the programmer didn't mean to put
an assignment there at all.
That is:
if( result = ERROR_VALUE ) foo();
is probably a mistake, while
if( (result = bar())==ERROR_VALUE ) foo();
is explicitly not a mistake, and has some meaning.
Either removing the automatic conversion to bool or making the result of
POD assignment void, rather than having the type and value of the quantity
being assigned, would prevent this error (and the latter convention would
make it a lot easier to write efficient assignment operators for UDTs) ...
but it's too late to change the language now.
Quote
The introduction of a real nil type, i.e. something that can only be an
invalid pointer with a predefined value would also make things easier.
Yeah, the first language I ever programmed in, Algol68, had a keyword NIL
that was essentially that; I used to find it very surprising that languages
didn't embody such a simple comcept. The old idea of defining NULL as
((void *)0) is a step in that direction, too. The distinction between 0 and
zero-valued-pointer is a useful one to be able to make in C, but in C++ we
shouldn't be playing with pointers ...
Cheers,
Daniel.
 

Re:Re: C++\CLI compiler

Quote
That is:

if( result = ERROR_VALUE ) foo();

is probably a mistake, while

if( (result = bar())==ERROR_VALUE ) foo();

is explicitly not a mistake, and has some meaning.
Does your compiler not warn on the first case of a possible incorrect
assignment?