«

Grizlyk wrote:

> IR wrote:
>
>> BCC 5.5
>
> Free BCC 5.5.1 command line tools does not support last C++
> standard (at least my copies).

FWIW, neither does the paying C++Builder 6.
My point, though, was not about standard conformance, but rather
about the fact that _all_ Borland compilers I have worked with
(namely, BC4/4.5, BCB4/5/6, and BCC5.5) are buggy like hell, even
when fully patched.

>> I recently had headaches on a simple ( ? : ) statement which did
>> not behave as expected, until I made it an if-else. This is just
>> one of many examples I could tell.
>
> In most cases you can try find out command line keys, switching
> Borland/Microsoft extentions of C++.

Sorry, but we won't change that kind of compiler settings on a
project which is already about 300kloc, and counting.

> What is the trouble with ( ? : ) statement there?

This very case is indeed a strange BCB6 bug.
I don't have the code at hand, but it was something very
straightforward:


AnsiString __fastcall SomeNetworkMessage::getMessage() const
{
AnsiString msg;
//...
msg = msg + (bool_expression ? "a string" : "another string");
//...
return msg;
}


The "msg = msg + ..." line always added garbage to msg, no matter
the value of bool_expression.

Switching to


if (bool_expression)
msg = msg + "a string";
else
msg = msg + "another string";


solved the bug. Note that in other places, ?: works perfectly fine.

Debugging at asm level showed that both "a string" and "another
string" where in fact taken from the stack (hence the garbage) in
the ?: version, while the if-else version correctly points at the
data segment.


> IR wrote:
>> This is just one of many examples I could tell.
[...]
>> I'm tired of all those strange compilation/linking
>> problems...


Cheers,
--
IR

"IR" <> wrote in message
news:Xns98B76EC5112BCZjx3HdoP0Qwt@194.177.96.26...
>> What is the trouble with ( ? : ) statement there?
>
> This very case is indeed a strange BCB6 bug.
> I don't have the code at hand, but it was something very
> straightforward:
>
> [some examples]

That's harsh. On VC++ (all versions AFAIK) I also had issues with the ?: in
combination when used with references.

#include <iostream>

struct A
{
virtual void foo() { std::cout << "A::foo()" << std::endl; }
};

struct B : public A
{
virtual void foo() { std::cout << "B::foo()" << std::endl; }
};

int main()
{
A a;
B b;
A & aRef = false ? a : b;
aRef.foo();
}

Guess what above program outputs. Right, A::foo(), because a temporary A is
copy-constructed out of a B, and tied to the reference (which shouldn't even
be possible according to the standard, as the reference is not const, but
VC++ allows it when language extensions are enabled). It took me some time
to find out why my data appeared to corrupt.

I fixed it by explicitely static_casting 'b' to an A&. So apparently the
compiler prefers value over reference when the two opererands are not of the
same type. "Luckily" this is only a mere misinterpretation of the standard,
it isn't as severe as wrong assembly code actually being generated (like in
your example)

- Sylvester