Was bedeutet ? :

Kann mir jemand die Bedutung von der Syntax erklären?
int on = bitRead(cmd, bit) ? 1056 : 395;

Ist es so, dass on bei 0 mit 1056 geladen, und bei 1 mit 395 geladen wird?
Versteht man darunter einer Skalierung??

Das ist die in C ( und zB auch in PHP) mögliche Kurzform von

if(bitRead(cmd, bit)==1)
  {
  on = 1056;
  }
else
  {
  on = 395;
  }

Grüße Uwe

Besten Dank.

Danke für das Beispiel, an solchen Sachen verzweifle ich gerade regelmäßig, wenn ich fremden Code lese.
Gibt es einen Parser oder irgendetwas, welches C Code in die ausführlichstmögliche Schreibweise zurückverwandelt? Oder eine Liste, wo ALLE diese Kniffe, Optimierungen und Kurzformen drinstehen?

Es ist extrem frustrierend, wenn ich Stunden benötige, um 2 Zeilen Code (vielleicht) zu verstehen...

Was macht man da, außer geduldig viel Erfahrung sammeln? Muß doch mal ein C Buch her? Welches?

Helmuth (abgetörnt)

edit: Warum benutzen Leuten überhaupt solche krypischen Formulierungen? Weil es cool ist? Damit es nur Eingeweihte verstehen? Ich habe den Eindruck, dass bei vielen Projekten nur der uninteressante Teil des Codes ausführlich kommentiert wird...

uwefed:
Das ist die in C ( und zB auch in PHP) mögliche Kurzform von

if(bitRead(cmd, bit)==1)

{
 on = 1056;
 }
else
 {
 on = 395;
 }

Nö, das sehe ich nicht so. Dein Code ist trotz der Länge kein vollständiger Ersatz für die Kurzform, da die Deklaration von "on" fehlt.

Für mich ist es daher eher eine Kurzform von:

  int on;
  if (bitRead(cmd, bit)) on=1056; else  on= 395;

:wink:

@jurs
ist das jetzt smartshitting :stuck_out_tongue: :smiley:

Warum muss ich jetzt an die damaligen Zeiten denken, wo es Wettbewerbe für den C64 gab, indem man den wildesten Einzeiler schreiben sollte. :smiley:

Manche Leute haben es hinbekommen, winzige Maschinencodes in eine Zeile zu quetschen, die dann sogar noch funktionsfähig und genial waren. Aber soetwas habe ich mit meinen bescheidenen Programmierkenntnissen nie hinbekommen:)

Man möge großzügig sein und mir das unterschlagene "int" verzeien und mir keinem Strick daraus drehen.
Ok Danke. Jetzt fühle ich mich besser.

?: in der im Beispiel verwendeten Form
int on = bitRead(cmd, bit) ? 1056 : 395;
ist keine vollwertiger Ersatz von IF ELSE sondern eher eine bedingte Zuweisung von Werten einer Variablen.

?: wird verwendet, weil es kürzer ist und weniger zu schreiben ist. Wenn man es einmal verstanden hat, dann ist es gleich einfach zu verstehen wie ein IF-ELSE.

@Helmuth
Ich kann Dir keine Quelle nennen, noch fallen mir weitere solche Kniffe ein. Ich kann Dir nicht weiterhelfen.

Grüße Uwe

@Uwe: Ich glaube, mein Problem ist, dass ich manche Operatoren noch nicht sofort als solche erkenne bzw. mir die Erfahrung fehlt, zu verstehen / mir vorzustellen, was sie exakt bewirken, warum sie an dieser Stelle verwendet werden...

Hab´mich wieder beruhigt, ich arbeite dran.

Grüße :wink:

Der Unterschied ist, daß "if" eine Anweisung und "?:" ein dreistelliger Operator ist. Das wird besonders auffällig wenn man Konstanten deklariert. Mit der "if" Anweisung kann man nicht sinnvoll Konstanten deklarieren mit "?:" schon. Der Operator ist außerdem gut lesbar wenn man das Idiom kapiert hat und vernünftig einrückt.

Lighthouses | Blinkenlight liest sich mit "?" deutlich besser als mit "if".

Und hier ein Beispiel wo ich ausnutze, daß "?" zur Compilezeit ausgewertet werden kann:

Allerdings könnte man beim letztgenannten Beispiel auch geschickter Einrücken :wink:

Nachtrag: was die Liste mit "ALLEN" Tricks angeht, die wird es niemals geben. Die Sprache C entwickelt sich ja weiter und die Liste der Tricks ist lang. Hier ist einer bei dem sich die Experten garantiert streiten würden ob er überhaupt in einer Liste stehen sollte: Duff’s Device – Wikipedia

Oder mal anders formuliert: gibt es eigentlich eine Liste mit ALLEN Tricks und Kniffen die ein Fußballprofi kann, so, daß jeder Dorfkicker die einfach lernen kann und mithalten könnte??? Wenn nein, wieso sollte das bei der Softwareentwicklung anders sein?

@Udo: Danke für die Präzisierungen. Ich merke schon, wir reden hier von Kunst, welche bekanntlich von können kommt.
Das ist kein Statement bezüglich Fußball... :wink:

Ok, die vollständige Liste ist unmöglich. Ich konkretisiere die Frage: Gibt es eine (zwangsläufig unvollständige) Beschreibung der gängigen Methoden, Operatoren "geschickt" einzusetzen?

z.B. Hat es mich mehrere Stunden gekostet, bis ich das Bitshiften begriffen habe. Ich nehme an, man verwendet das, weil es schneller ist, als "normales" multiplizieren / dividieren(?). Wenn man es nicht gewöhnt ist, soetwas zu lesen, raucht einem schnell der Kopf, während die Schmierzettel auf dem Tisch immer voller werden - nur, um dann zu erkennen, dass es die Umschreibung einer einfachen mathematischen Funktionen ist.

int x = 1000;
int y = x >> 3;

Wenn da ein kurzer Kommentar // y = x / 8 dranstehen würde, währe es erheblich leichter nachzuvollziehen.

Oder ist das ein Anfängerproblem und jedem halbwegs erfahrenem Programmierer sofort klar, was das bedeutet?

Beste Grüße, Helmuth

Hallo,

ich bin ja auch noch Anfänger. Bei dem Beispiel merke ich aber das es bestimmt darauf ankommt was man gewohnt ist oder mit welchen Büchern man angefangen hat. Dieses um 3 Bit nach rechts verschieben stach mir sofort ins Auge. Weis auch nicht warum. Vielleicht weil ich sowas auch gern verwende. Eben aus Gewohnheit. Wenn man tiefer nachdenkt bedeutet es eben wie schon geschrieben 2^3 = 8, also 1000 / 8.

Eine generell bessere Code Kommentierung wäre aber schon angebracht. Nur wem sagt man das?

Ich meine, wer wirklich mit Arduino anfängt bzw. angefangen hat, dem wird es sicherlich schwer fallen gebräuchliche Schreibweisen zu erkennen. Ich nehme mich davon nicht aus. Bei Arduino ist eben alles etwas einfacher gehalten, damit jeder loslegen kann. Allerdings ist manches für mich in meinen Augen zu vereinfacht. Wenn man da jedesmal erst eine for Schleife schreiben soll für Pin Input/Output Setzung wenn es ein klarer Befehl auch macht ... dann halte ich das einfache schon wieder für umständlicher ... :smiley:

Zudem Thema wird es bestimmt 4 << 8; :slight_smile: verschiedene Meinungen geben.

Aber nicht das ihr mich falsch versteht. Obigen Code kann/konnte ich auch nicht entziffern.

Professionelle Entwickler lernen eine neue Sprache normalerweise in 1-3 Wochen. Außer es ist neuer Sprachtyp den sie nicht kennen (wechsel zwischen imperativ, Objekt orientiert, Stack orientiert, funktional, Mengen orientiert oder eine völlig neue Syntax) Für eine umfangreiche API 1/2 - 1 Jahre. Danach können die das im Halbschlaf. "Gute" Kommentare sind so eine Sache. Anfänger schreien oft nach "guten" Kommentaren, wollen aber eigentlich schlechte Kommentare. Schlechte Kommetare sagen "was" der Code macht. Gute Kommentare sagen "warum" der Code etwas macht und zeigen kritische Stellen auf. Optimalerweise ist Code so geschrieben, daß er möglichst keine Kommentare braucht.

Auf was ich raus will: im Arduino Umfeld ist der Code fast immer so einfach, daß er leichter und schneller zu lesen ist als die Kommentare. In so einem Umfeld sind Kommentare störend. Wer umbedingt die Kommentare haben will die nur wiedergeben "was" der Code macht kann sich die auch gleich von Doxygen generieren lassen.

Was "x << y" angeht: das ist nicht immer ein Shift, vor allem bei Strings nicht. Professionelle Entwickler erwarten für einen einzelnen Operator keinen Kommentar. Auch nicht für ?:

Im empfehle für solche Fragen im Zweifelsfall das Buch "Code Complete" von McConnel.

@Udo: Habe mal diagonal reingelesen, der Schreibstil und pragmatische Ansatz sagen mir sehr zu. Wird bestellt, danke für den Tip.

Ich kann Deine Ausführungen bezüglich "gut" und "schlecht" vollumfänglich nachvollziehen. Meine Wahrnehmung ist jedoch, dass im Arduinoland deutlich mehr unerfahrene Quereinsteiger und Autodidakten unterwegs sind, als Vollblutprofis mit Erfahrung in verschiedenen Sprachen. Vielleicht täusche ich mich.

Manchmal würde mir ein wenig mehr Kommentar zum wie/was neben dem warum sehr hilfreich sein, da ich ein Typ bin, der sich neue Techniken zuerst mittels Beispielstudium aneignet - Grundlagenlektüre folgt später, falls eine Vertiefung aus pragmatischen Gründen nötig erscheint. An dem Punkt bin ich wohl gerade.