what operator >?= do?

[Tagore]

Hi,

I am trying to understand a code. but I am unable to understand
following expression:-

a >?= a[j] + 1;

where a is an array of integers, and i,j are loop counters etc.

It would be great if somebody could help me with this expression.

Thanks,

 

[Tagore]

Hi,

C++ compiler is not generating error for this message.
see the link:-
http://codepad.org/medovTSx

Thanks,

Tagore ha scritto:

I am trying to understand a code. but I am unable to understand
following expression:-

a >?= a[j] + 1;

This is not valid C++ and should be rejected by your compiler.

--
Christian Hackl
(e-mail address removed)

Milano 2008/2009 -- L'Italia chiam , s !

 

[red floyd]

Hi,

I am trying to understand a code. but I am unable to understand
following expression:-

a >?= a[j] + 1;

where a is an array of integers, and i,j are loop counters etc.

It would be great if somebody could help me with this expression.

It's a non-standard GNU extension. a is assigned the maximum of
a and (a[j]+1)

 

[Ian Collins]

On 12/29/10 09:48 AM, Tagore wrote:

Please don't top-post.

Tagore ha scritto:

I am trying to understand a code. but I am unable to understand
following expression:-

a>?= a[j] + 1;

This is not valid C++ and should be rejected by your compiler.

> Hi,
>
> C++ compiler is not generating error for this message.
> see the link:-
> http://codepad.org/medovTSx

Well it should (after removing deprecated header):

CC /tmp/x.cc
"/tmp/x.cc", line 13: Error: Operand expected instead of "?".

g++ /tmp/x.cc
/tmp/x.cc: In function ‘int main()’:
/tmp/x.cc:13: warning: minimum/maximum operators are deprecated

So it appears to be a gccism.

http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Min-and-Max.html

 

[BGB]

Hi,

I am trying to understand a code. but I am unable to understand
following expression:-

a>?= a[j] + 1;

where a is an array of integers, and i,j are loop counters etc.

It would be great if somebody could help me with this expression.

It's a non-standard GNU extension. a is assigned the maximum of
a and (a[j]+1)

So, a portable way to write it would be this then?

if(a< a[j]+1)
a = a[j]+1;

I'll never understand why anyone would want to write obscure, compiler-
specific code unless there is no other way to accomplish the task at
hand. Doing so just to save a few keystrokes is ridiculous.

"well, it seemed like a good idea at the time..."

 

[Jorgen Grahn]

Hi,

I am trying to understand a code. but I am unable to understand
following expression:-

a >?= a[j] + 1;

where a is an array of integers, and i,j are loop counters etc.

It would be great if somebody could help me with this expression.

It's a non-standard GNU extension. a is assigned the maximum of
a and (a[j]+1)

So, a portable way to write it would be this then?

if(a < a[j]+1)
a = a[j]+1;

I'll never understand why anyone would want to write obscure, compiler-
specific code unless there is no other way to accomplish the task at
hand. Doing so just to save a few keystrokes is ridiculous.

And indeed this one has been completely removed in modern versions of
GCC. (And so has '#include <iostream.h>' which Tagore's code also
uses. He really needs to get a modern compiler.)

/Jorgen

 

[Paul Brettschneider]

Hi,

I am trying to understand a code. but I am unable to understand
following expression:-

a >?= a[j] + 1;

[...]

I'll never understand why anyone would want to write obscure, compiler-
specific code unless there is no other way to accomplish the task at
hand. Doing so just to save a few keystrokes is ridiculous.

And indeed this one has been completely removed in modern versions of
GCC.

That's quite sad. They should have tried to get it standardized. I'm always
in the need for more operators to overload. ;-P

BTW: I wonder why the C forefathers did not introduce operators ".=" and
"->=" as in:
matrix .= inverse();
list_iterator ->= next;
which would be consistent with "+=". I guess because "+=" and colleagues
directly map to assembler instructions as do/did constructs like
"*i++=*j++".

 

[BGB]

Hi,

I am trying to understand a code. but I am unable to understand
following expression:-

a>?= a[j] + 1;

[...]

I'll never understand why anyone would want to write obscure, compiler-
specific code unless there is no other way to accomplish the task at
hand. Doing so just to save a few keystrokes is ridiculous.

And indeed this one has been completely removed in modern versions of
GCC.

That's quite sad. They should have tried to get it standardized. I'm always
in the need for more operators to overload. ;-P

yeah...

I guess the usual worry is that any new operators could, potentially,
break some obscure syntactically-dubious program somewhere in the world
(much like one can't directly add any new keywords apart from usually
doing the "__my_new_keyword__" thing, and then wrapping it in some
header, with a fallback dummy define just in case it is not present if
one uses the header in a different compiler...).

just like how:
foo(x, y)
int x, y;
{
...
}

never really goes away (from C at least), even though no one really uses
it anymore...
it is then a compiler extension to remove such things from the syntax
(along with trigraphs, ...), either allowing mis-parse or giving a
warning or error upon encountering it.
oh yes, and, hell, interpreting "foo()" as an empty arguments list
instead of "some indeterminate number of arguments", ...

BTW: I wonder why the C forefathers did not introduce operators ".=" and
"->=" as in:
matrix .= inverse();
list_iterator ->= next;
which would be consistent with "+=". I guess because "+=" and colleagues
directly map to assembler instructions as do/did constructs like
"*i++=*j++".

yeah...


I liked ".=" enough that I went and added it to the spec of a newer
language I have in-development (there is no "->=" because "." and "->"
are equivalent and "->" is only defined for pointer types).

an possible issue with ".=" though is where it goes in the operator
precedence tree.

left out a more detailed analysis, as I realized it fell out of
relevance due to a misinterpretation of the semantics of the operator
(leading to an ambiguity which has little chance of mattering with
sensible use of the operator...).


or such...