Name für Operator gesucht

*GAST* schrieb:
> Wie nennt man diesen Operator?
Welcher? Das & (bitweise UND), das ~ (bitweise NICHT) oder das = 
(Zuweisung)?

> Ich suche eine etwas allgemeinere
> Beschreibung, wie das genau funktioniert.
Der Variable wert_neu wird das bitweise UND aus wert und der bitweise 
invertierten maske zugewiesen.

Eine Liste der Operatoren findest du hier:
https://de.wikibooks.org/wiki/C-Programmierung:_Liste_der_Operatoren_nach_Priorit%C3%A4t

Man könnte diese Operation "Maskierung" nennen.
Von mir aus auch "Masken-Operator".

Umgangssprachlich werden dort Bits ausmaskiert.

Die Klammern kann man auch einfach weglassen, die bewirken hier exakt 
gar nichts.

a = (4);

ist nunmal nichts anderes als

a = 4;

..oOo.. schrieb:
> "Schön", dass C-Compiler solche schwachsinnigen Quellcodeformulierungen
> ohne Murren übersetzt, statt solchem verwirrenden Zeugs einen
> konsequenten Riegel vorzuschieben.

Das ist Absicht!
Der Gedanke dahinter ist der, daß sich nur halbwegs intelligente Leute 
damit auseinandersetzen und die grössten Deppen gar nicht mitspielen.
Leider hat sich diese Hoffnung nicht erfüllt, sie geben trotzdem ihren 
Senf dazu.

*GAST* schrieb:
> wert_neu = (wert &~ maske);
C-hater hater schrieb:
> Was ist denn daran verwirrend?
GAST meinte wohl, dass "&~" ein Operator ist, den er so nicht in 
seinem C-Buch findet...

..oOo.. schrieb:
> Noch einer schrieb:
>> Schönes Beispiel für den Obfuscated C Code Contest.
>
> "Schön", dass C-Compiler solche schwachsinnigen Quellcodeformulierungen
> ohne Murren übersetzt, statt solchem verwirrenden Zeugs einen
> konsequenten Riegel vorzuschieben.

Man könnte zwar für alles, was irgendwer als schwer lesbar einstufen 
könnte, spezielle Ausnahmeregeln definieren, die das unterbinden, aber 
das würde die Sprache komplexer machen, ohne daß Leute, die sowieso 
vernünftigen Code schreiben, etwas davon hätten.

Rolf Magnus schrieb:
> ..oOo.. schrieb:
>> Noch einer schrieb:
>>> Schönes Beispiel für den Obfuscated C Code Contest.
>>
>> "Schön", dass C-Compiler solche schwachsinnigen Quellcodeformulierungen
>> ohne Murren übersetzt, statt solchem verwirrenden Zeugs einen
>> konsequenten Riegel vorzuschieben.
>
> Man könnte zwar für alles, was irgendwer als schwer lesbar einstufen
> könnte, spezielle Ausnahmeregeln definieren, die das unterbinden, aber
> das würde die Sprache komplexer machen, ohne daß Leute, die sowieso
> vernünftigen Code schreiben, etwas davon hätten.

Vor allen Dingen sind solche Regeln gar nicht so einfach konsistent zu 
definieren.
Ist

1

    j=i+-3;

schwer zu lesen? Ist zwar Ansichtssache, aber ich würde mal ja sagen. 
Ist es legal? Natürlich ist es das. Wie könnte man es besser schreiben. 
Easy

1

    j = i + -3;

Ist

1

    len = sqrt(x*x + y*y);

schwer zu lesen? Ist zwar auch Ansichtssache, aber den Phythagoras wird 
wohl jeder hier erkennen. Habe ich aus dem ersten Beispiel die Lehre 
gezogen, dass eine Sprachregel her muss, wonach zwischen Operanden und 
Operator bei binären Operationen ein Whitespace stehen muss, dann zwinge 
ich damit den Programmierer das so zu schreiben

1

    len = sqrt( x * x + y * y );

Jetzt kann man natürlich debattieren, welche Lösung die besser lesbare 
sei. Ich würde trotzdem sagen die erste. Denn dort ist der optische 
Zusammenhang der Quadrate leichter zu sehen, was in der zweiten Lösung 
nicht der Fall ist. Klar, ich kann natürlich auch

1

    len = sqrt( ( x * x ) + ( y * y ) );

schreiben. Aber ist diese Version in der Schreibweise wirklich besser 
als die erste? Länger ist sie auf jeden Fall.

Fazit: man kann in jeder Sprache unleserliche Programme schreiben. Das 
ist keineswegs nur auf C beschränkt. Man kann - aber man muss nicht. Das 
es in C natürlich einen Haufen Sonderzeichen gibt, deren Bedeutung man 
kennen und lernen muss, ist unbestritten. Aber dazu lernt man ja auch 
eine Sprache und geht nicht mit Achtelwissen in reale Projekte rein. Das 
muss man schliesslich in jeder Sprache (bis auf die Auswanderer, die 
ohne ein Wort Schwedisch zu können nach Schweden auswandern. Aber das 
ist nicht das Problem der Schweden und eine andere Geschichte)

Auch wunderbar zum Verwirrung stiften geeignet: Der 'downto'-Operator ;)

1

int i = 10;

2

while(i --> 0) {

3

    ....

4

}

Markus schrieb:
> Whitespaces sind nicht Sprachbestandteil.

Stroustrup hatte dazu mal eine Idee ;-)
http://www.stroustrup.com/whitespace98.pdf

lalala schrieb:
> Wie wäre es damit, die Lehre zu ziehen, dass vor unären Operatoren ein
> Leerzeichen stehen sollte

Das passt leider auch nicht immer:

1

a = * *pointer:

statt

1

a = **pointer:

sieht zumindest für meine Augen sehr ungewohnt aus.

Die Regel, vor und nach binären Operatoren ein Leerzeichen zu schreiben,
ist schon in Ordnung, wenn man in speziellen Fällen (wie bspw. der
obigen Formel des Pythagoras) Ausnahmen im Sinne der besseren Lesbarkeit
zulässt.

Guten Stil kann man nicht mit starren Regeln definieren.


Markus schrieb:
> Whitespaces sind nicht Sprachbestandteil.

Doch. Sonst wären folgende Programmzeilen äquivalent:

1

interna = 5;

2

int erna = 5;

Sei sind es aber nicht.

Lukas K. schrieb:
> Auch wunderbar zum Verwirrung stiften geeignet: Der 'downto'-Operator ;)

Der ist hübsch, den kannte ich noch nicht. :)  Kann man natürlich
mit einem #define noch würzen:

1

#define downto -->

2

3

...

4

5

int i = 10;

6

while(i downto 0) {

7

    ....

8

}

Bastler schrieb:
>> Stroustrup hatte dazu mal eine Idee ;-)
>> http://www.stroustrup.com/whitespace98.pdf
> Was hatte der denn geraucht, bevor er das geschrieben hat.

Vielleicht guckst du ja mal aufs Datum?

Markus schrieb:
> Wie die Worte gebildet werden, definiert die Sprache m.W.n. aber nicht.

Wer denn sonst?

Yalu X. schrieb:
> lalala schrieb:
>> Wie wäre es damit, die Lehre zu ziehen, dass vor unären Operatoren ein
>> Leerzeichen stehen sollte
>
> Das passt leider auch nicht immer:
> a = * *pointer:
>
> statt
> a = **pointer:
>
> sieht zumindest für meine Augen sehr ungewohnt aus.

Schlimmer wird das noch, wenn man davor eine Multiplikation hat:

1

a = 3 * * *pointer;

Man könnte Klammern setzen, aber da stören die Leerzeichen auch eher:

1

a = 3 * ( * *pointer);

lalala schrieb:
>(und -3 sollte als unärer Operator angewandt auf 3 interpretiert werden :-) )

Das wird es in C sowieso schon.

Yalu X. schrieb:
>> Whitespaces sind nicht Sprachbestandteil.
>
> Doch. Sonst wären folgende Programmzeilen äquivalent:interna = 5;
> int erna = 5;
>
> Sei sind es aber nicht.

Geht auch ohne whitespace. ;-)

1

int/**/erna=5;

Bastler schrieb:
>> Stroustrup hatte dazu mal eine Idee ;-)
>> http://www.stroustrup.com/whitespace98.pdf
> Was hatte der denn geraucht, bevor er das geschrieben hat.

Spätestens beim Einführen von impliziten Whitespace Operatoren und 
Variablennamen die aus einem Unicode Zeichen bestehen sollte man 
bemerken, dass er das nicht ernst meinen kann.

Sebastian V. O. schrieb:
> Spätestens beim Einführen von impliziten Whitespace Operatoren und
> Variablennamen die aus einem Unicode Zeichen bestehen sollte man
> bemerken, dass er das nicht ernst meinen kann.

Bei den Whitespace-Operatoren hast du recht, aber Unicode-Zeichen in
Variablennamen sind mittlerweile in ziemlich vielen Programmiersprachen
erlaubt (darunter Java, Python, Ruby, Tcl, D, Haskell, Rust, Scala,
Swift und mit Einschränkungen auch C und C++):

  http://rosettacode.org/wiki/Unicode_variable_names