C# Ermitteln, ob zwischen einer Zeitspanne das Datum liegt!

[Nick_SMI]

Hallo zusammen!

Ich möchte in meinem Programm ermitteln, ob ein bestimmtes Datum dazwischen liegt!

Als Beispiel: Liegt das Datum 03.01.2016 Zwischen dem 01.01.2016 und dem 05.01.2016?


Grüße und danke an alle Helfer im Voraus!

 

[Valeria]

check is das Datum was du überprüfen willst.
>= und <= benutzen wenn 1.1 und 5.1 auch noch drin liegen darf.

bool dazwischen(DateTime check, DateTime untereSchranke, DateTime obereSchranke)
        {
            if (check > untereSchranke) && (check < obereSchranke)
            {
                return true;
            }
            return false;
        }

bool erg = dazwischen(new DateTime(2016,1,3),new DateTime(2016,1,1), new DateTime(2016,1,5));

Willst du das?

 

[Nick_SMI]

Perfekt, danke!

 

[Physikbuddha]

if (check > untereSchranke) && (check < obereSchranke)
{
    return true;
}
return false;

Was spricht denn gegen

return (check > untereSchranke) && (check < obereSchranke)

 

[Drexel]

Ist Geschmackssache würde ich ganz einfach mal sagen. Der Compiler macht eh das gleiche draus. Nicht immer ist kompakter Code besser lesbar. Aber das nur am Rande.

Wenn man wegen solcher Trivialitäten einen Thread aufmacht, sollte man sich eher mal fragen, ob Programmieren das richtige für einen ist.

 

[Physikbuddha]

Ich finde den Einzeiler deutlich besser lesbar als den Fünfzeiler, aber das ist wohl wirklich Geschmackssache.
Bei dem anderen rollen sich mir die Nägel bis zum Knie.

 

[Drexel]

Ja was wer besser lesen kann ist natürlich hoch individuell. Das merkt man gerade beim Programmieren stark, jeder Kopf tickt anders...

 

[andy_m4]

Optimal wäre

return untereSchranke < check < obereSchranke

Oder gibt das C# nicht her?

Gruß
Andy

 

[crvn075]

Optimal wäre

return untereSchranke < check < obereSchranke

Oder gibt das C# nicht her?

Gruß
Andy

Was soll das denn bedeuten? untereSchranke < check evaluiert zu bool, und dann steht da boolscher Wert < obereSchranke ??

 

[andy_m4]

Was soll das denn bedeuten? untereSchranke < check evaluiert zu bool, und dann steht da boolscher Wert < obereSchranke ??

Nö. Der ganze Ausdruck ergibt "Boolean". Alles andere würde ja kein Sinn machen.

Aber ich seh schon, C# sieht das anders und wertet da etwas seltsam aus und verhindert so, das man klar hinschreiben kann was man eigentlich meint.

Gruß
Andy

 

[crvn075]

Nö. Der ganze Ausdruck ergibt "Boolean". Alles andere würde ja kein Sinn machen.

Aber ich seh schon, C# sieht das anders und wertet da etwas seltsam aus und verhindert so, das man klar hinschreiben kann was man eigentlich meint.

Und in welcher Sprache geht das?

Etwas als seltsam zu bezeichnen, was wahrscheinlich in 99% aller Sprachen gleich funktioniert ist schon... naja seltsam.

 

[John Reese]

Mathe, da geht das

Ne, in üblichen Programmiersprachen (aus der C-Familie) ist sowas nicht üblich / machbar - zumindest kenne ich keine, in der man eine solche Gleichung 1:1 in Code darstellen kann.

 

[Miuwa]

@Drexel: Generell gebe ich dir Recht, dass kompakter Code nicht unbedingt lesbarer ist.

In diesem Fall gewinnt man durch die zusätzlichen Zeilen aber nichst. Der Ausdruck "(check > untereSchranke) && (check < obereSchranke)" kommt ja in beiden Versionen vor. In der kürzeren ist das das einzige, was man sich ansehen muss, in der längeren gibts zusätzlich noch ne Verzweigung.

 

[andy_m4]

Und in welcher Sprache geht das?

Gut. Ich komm aus der Lisp-Welt.
Da hat man ja standardmäßig Präfix-Notation. Da würde man schreiben

(< untereSchranke check obereSchranke)

was aber sich aber absolut so verhält wie von mir beschrieben.
Da würde auch niemand auf die Idee kommen zwei Vergleiche zu machen, um die anschließend mit AND zu verknüpfen.

Abgesehen davon, das man Makros (bzw. gibt es auch schon Fertige) schreiben kann die auch die gewohnte Infix-Notation umsetzen.
Und auch da wird

untereSchranke < check < obereSchranke

in dem von mir beschriebenen Sinne umgesetzt.

Allerdings verwende ich das nicht, weil man eben überall die Präfix Notation hat und so ein vollkommen homogene Syntax hat.
Während "Deine" 99% Sprachen da unlogischer sind. Bei Operatoren (warum wird eigentlich überhaupt zwischen Operatoren und Funktionen unterschieden?) nimmt man Infix. Bei Funktionen/Methoden Präfix. Das ist in der Tat seltsam. Zumindest aus meiner Sicht. :-)

Etwas als seltsam zu bezeichnen, was wahrscheinlich in 99% aller Sprachen gleich funktioniert ist schon... naja seltsam.

Ok. War vielleicht unglücklich formuliert.
Aber ich finde es etwas ungeschickt vom Sprachdesign, wenn man gezwungen ist eigentlich simple Sachverhalte so kompliziert auszudrücken.

Gruß
Andy

 

[Physikbuddha]

Da würde auch niemand auf die Idee kommen zwei Vergleiche zu machen, um die anschließend mit AND zu verknüpfen.

Auch in Lisp werden am Ende zwei Vergleiche gestartet und per AND verknüpft. Genauso wie du es im Kopf machen würdest, wenn die Aufgabe auf Papier steht. Alles nur syntaktischer Zucker.

warum wird eigentlich überhaupt zwischen Operatoren und Funktionen unterschieden?

Es wird nicht unterschieden, auch hier ist das nur eine reine Schreibweisensache. Der Operator ist auch nur als Funktion definiert:

public static bool operator <(DateTime t1, DateTime t2) {
   return t1.InternalTicks < t2.InternalTicks;
}

Bei Operatoren nimmt man Infix. Bei Funktionen/Methoden Präfix. Das ist in der Tat seltsam. Zumindest aus meiner Sicht. :-)

Diese 99 % der Sprachen halten sich an die gängige mathematische Schreibweise, die mir schon in der Schule gelehrt wurde.

• y = f(x) = mx + n
• a < b

 

[andy_m4]

Auch in Lisp werden am Ende zwei Vergleiche gestartet und per AND verknüpft. Genauso wie du es im Kopf machen würdest, wenn die Aufgabe auf Papier steht. Alles nur syntaktischer Zucker.

Das ist eher eine Frage dessen, was der Compiler draus macht und hat mit syntaktischen Zucker nichts zu tun. Sonst wäre ja jedes Hochsprachenkontrukt lediglich syntaktischer Zucker.

Es wird nicht unterschieden, auch hier ist das nur eine reine Schreibweisensache. Der Operator ist auch nur als Funktion definiert:

public static bool operator <(DateTime t1, DateTime t2) {
   return t1.InternalTicks < t2.InternalTicks;
}

Eben. Es ist nicht Konsequent warum eine Funktion Präfix angewendet wird und die andere Infix.
Ich meine, wenn man schon so ne Verrenkung macht und bei solchen "Operatoren" die Infix-Schreibweise anbietet so von wegen besserer Lesbarkeit, dann doch bitteschön konsequent.

In den 70er und 80er Jahren da war man mit den Compilern noch nicht so weit, das die hätten sowas auswerten können bzw. musste man da ja auch noch auf Hardware-Ressourcen achten weshalb Compiler auch nicht zu groß werden sollten. Da machte der C-Style Sinn, weil es von der Analyse und Umsetzung her einfacher war.
Aber heutzutage? Das nur noch mit schleppen so nach dem Motto "Ham wa immer so gemacht" ?

Diese 99 % der Sprachen halten sich an die gängige mathematische Schreibweise, die mir schon in der Schule gelehrt wurde.

Die gängige mathematische Schreibweise wäre aber a<b<c und nicht a<b and b<c

Auch Dein Funktionsbeispiel haut nicht hin.
Man kann ja gerade nicht schreiben z.B.:

f(x) = 4

Sondern ist immer angewiesen auf geschweifte Klammern und ein explizites return.

Lisp dürfte da mit einem funktionalen Charakter sogar deutlich näher an mathematischen Funktionen sein als das eher imperative C#
Wenn schon eine # Sprache müsstest Du eher auf F# verweisen.

Gruß
MichaelK

 

[Miuwa]

@andy_m4: Nichts gegen Lisp, aber wie lange programmierst du schon in Lisp, dass sowas wie "print(a+b)" statt (print (+ a b)) (oder wie auch immer das unter Lisp aussehen würde) auf dich seltsam wirkt?

 

[crvn075]

Gut. Ich komm aus der Lisp-Welt.
Da hat man ja standardmäßig Präfix-Notation. Da würde man schreiben

(< untereSchranke check obereSchranke)

was aber sich aber absolut so verhält wie von mir beschrieben.

Die Operatoren funktionieren in Lisp bezüglich der Evalierung doch erst mal genau gleich. Beispielsweise resultiert "<" auf die Operanden angewendet in T oder Nil. Du kannst jetzt praktischerweise (< a b c) schreiben, weil das so unterstützt wird. Was du aber auch in Lisp nicht machen kannst ist sowas wie (< a (< b c)), denn der innere Vergleich führt zu T oder Nil, mit dem der äußere Operator nichts anfangen kann ("not a number" o.ä.). Aus dem gleichen Grund funktioniert (a < b < c) in C# nicht.

Wenn man jetzt Dinge in C# ganz offensichtlich in Infix schreibt (wobei sich nun mal binäre Operatoren für genau zwei Operanden anbieten), dann frage ich mich, wie du zur Ansicht kommst, dass das Verhalten unlogisch sei. Für binäre Operatoren ist das Verhalten völlig logisch.

Die gängige mathematische Schreibweise wäre aber a<b<c und nicht a<b and b<c

Wenn man Dinge definiert o.ä., dann ja. Aber was wir hier machen ist doch eher boolsche Algebra um relationale Operatoren erweitert.

 

[andy_m4]

@andy_m4: Nichts gegen Lisp, aber wie lange programmierst du schon in Lisp, dass sowas wie "print(a+b)" statt (print (+ a b)) (oder wie auch immer das unter Lisp aussehen würde) auf dich seltsam wirkt?

Es ist zumindest konsequent.

print wird ja auch davor geschrieben. Warum also auch nicht das Plus?
Immerhin kann man dann solche Sachen machen wie:

(+ a b c d f g)

und man braucht nur einmal das Pluszeichen zu schreiben. Das ist schon von der Seite her praktisch, als das ich ne Liste an Werten an die + Funktion übergeben kann ohne das ich erst irgendwie ne Schleife basteln müsste die über ne Zwischensumme (wo man ja auch wieder extra ne Variable braucht) mir den Kram zusammenrechnen.

Das Ergebnis: Man hat viel kürzeren und gleichzeitig klareren Code.

Gruß
Andy

Ergänzung (8. Januar 2016)

Die Operatoren funktionieren in Lisp bezüglich der Evalierung doch erst mal genau gleich. Beispielsweise resultiert "<" auf die Operanden angewendet in T oder Nil.

So gesehen hast Du natürlich Recht.

Du kannst jetzt praktischerweise (< a b c) schreiben, weil das so unterstützt wird.

Ja. Und das ja auch viel voller Absicht. Bei vielen Funktionen kannst Du ja sozusagen beliebig viele Argumente übergeben.
Daher sehe ich das auch nicht als syntaktischen Zucker. Es ist quasi der Normalfall.
Syntaktischer Zucker ist für mich eher, wenn man für einen spezielleren Fall eine angenehmere Syntax schafft.
Typisches Beispiel dürfte das Hochkomma sein, um sich quote bzw list zu sparen.

Was du aber auch in Lisp nicht machen kannst ist sowas wie (< a (< b c)), denn der innere Vergleich führt zu T oder Nil, mit dem der äußere Operator nichts anfangen kann ("not a number" o.ä.). Aus dem gleichen Grund funktioniert (a < b < c) in C# nicht.

Mir ist schon klar, warum es nicht funktioniert. Ich finds nur unglücklich es so zu implementieren.

Wie wir ja festgestellt haben sind ja diese Infix-Operatoren lediglich syntaktischer Zucker für ne darunter liegende Funktion. Aber wenn ich schon syntaktisch zuckere (was ja immer ein Bruch mit der Konsequenz ist), dann doch um die Lesbarkeit zu erhöhen.

Wenn man jetzt Dinge in C# ganz offensichtlich in Infix schreibt (wobei sich nun mal binäre Operatoren für genau zwei Operanden anbieten), dann frage ich mich, wie du zur Ansicht kommst, dass das Verhalten unlogisch sei. Für binäre Operatoren ist das Verhalten völlig logisch.

Aus irgendeiner Sichtweise ergibt sich natürlich immer eine Logik. Und die ist mir ja auch klar. Trotzdem finde ich sie in dem Fall unglücklich.
Weil sie ja eben zu solchen komplizerten Konstrukten für wie gesehen.

Und mal ehrlich. Findest Du ein

if a<x<b

nicht auch lesbarer?

Gruß
Andy

 

[Miuwa]

Können wir diese Diskussion vielleicht in einem separaten thread fortführen? Fehlende Sprachfeatures und die Gründe dafür haben doch nun wirklich nichts mit der Frage zu tun (die ja schon im ersten Post beantwortet wurde).