[C#] Öhh kP Problem einfach :P

Term!nX · 08/08/2007, 21:56

Also, ich wollte ein Prog schreiben, um zu prüfen, ob eine Zahl eine Primzahl ist. Hab das ganze vorher mit au3 gemacht und auch schon alle Primzahlen bis 200000 errechnet, aber aus Übung wollt ich das auch mit C# machen.

Erstmal den kode:

Code:

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication1
{
  class Program
  {
    static void Main&#40;string&#91;&#93; args&#41;
    {
      float zwischenwert;
      int testwert;

      int Zahl = int.Parse&#40;Console.ReadLine&#40;&#41;&#41;;

      int prime = IsPrime&#40;Zahl&#41;;

      if &#40;prime == 1&#41;
      {
        Console.WriteLine&#40;&#34;Die Zahl ist leider keine Primzahl.&#34;&#41;;
      }
      
      public int IsPrime&#40;int wert&#41;
      {
        for &#40;int i = 2; i &#60; &#40;Zahl / 2&#41;; i++&#41;
        {
          zwischenwert = wert / i;
          testwert = Convert.ToInt32&#40;zwischenwert&#41;;

          if &#40;zwischenwert == testwert&#41;
          {
            return 1;
          }
        }
        return 0;
      }

      Console.ReadLine&#40;&#41;;
    
    }
  }
}

Das ich anfänger bin muss ich hier niemandem flüstern, das sieht jeder Hanz.
In meinen Augen ganz k die geschichte aber VCS ist anderer Meinung:

Fehler 1 } erwartet. ...Program.cs 21 14 Prims

Fehler 2 Ungültiges Token "(" in Klasse, Struktur oder Schnittstellenmemberdeklaration. ...Program.cs 38 29 Prims

Fehler 3 Typ- oder Namespacedefinition oder Dateiende erwartet. ...Program.cs 42 1 Prims

Im groben Schätze ich einfach, dass die Probleme vom inkorrekten Aufbau meiner FUnktion herrühren, aber mir kommts sinnvoll vor wie es ist.

grüsse

psych0o · 08/09/2007, 00:10

Vorab: Ich bin auch nicht so der C(#) Coder..

Was mir sofort auffält ist, dass keine Ausgabe gemacht wird, wenn die Zahl eine Prim Zahl ist.

Ausserdem würde ich die Funktion isPrime eventuell ausserhalb des main subs setzen.

Und du verwendest die Variable Zahl in der Funktion isPrime, solltest hier dann aber auch wert benutzen.

Naja hier tummeln sich viel bessere coder als ich ^^
(ja ihr dürft mich ebenfalls gerne verbessern ^^)

termi · 08/09/2007, 03:39

Ich habe mir den Code mal schnell angeschaut und folgendes entdeckt:
Die Fehlermeldung die ich bekam wies auf den falschen Zustand der Funktion "isPrime" hin - also habe ich das Ding mal auf static gesetzt und siehe da es geht

Vorher hatte ich die Funktion aus der Hauptfunktion befreit (weis nicht obs anders auch ginge - aber ich finde das so "schöner").
Dann habe ich einen catch für eine Exception bei falsche Eingabe eingebaut (es soll ja nicht wirklich Text geprüft werden).

Hier und da noch nen paar Variablen definiert (deinen Returntyp von int auf bool geändert - wir brauchen ja nur 1/true oder 0/false)

Und so sieht das ganze dann aus:

Code:

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication1
{
  class Program
  {
    public static bool IsPrime&#40;int wert&#41;
    {
      for &#40;int i = 2; i &#60; &#40;wert / 2&#41;; i++&#41;
      {
        float zwischenwert = wert / i;
        int testwert = Convert.ToInt32&#40;zwischenwert&#41;;

        if &#40;zwischenwert == testwert&#41;
        {
          return true;
        }
      }
      return false;
    }
    static void Main&#40;string&#91;&#93; args&#41;
    {
      int Zahl;
      bool prime;
      string input = Console.ReadLine&#40;&#41;;
      try
      {
        Zahl = int.Parse&#40;input&#41;;
      }
      catch &#40;Exception&#41;
      {
        throw new Exception&#40;&#34;Input wasn't valid&#34;&#41;;
      }
      prime = IsPrime&#40;Zahl&#41;;

      if &#40;prime == true&#41;
      {
        Console.WriteLine&#40;&#34;Die Zahl ist leider keine Primzahl.&#34;&#41;;
      }
      else
      {
        Console.WriteLine&#40;&#34;Die Zahl ist eine Primzahl!&#34;&#41;;
      }

      Console.ReadLine&#40;&#41;;

    }

  }
}

Als kleine Anmerkung dazu (keine Kritik an deiner Übung welche ich als sehr gut empfinde):
C# und der restliche .NET kram sind zwar recht leicht zu programmieren allerdings ist die Performance übelst lahm.... noch dazu kommt, wenn immer mehr Leute nurnoch auf .NET-Basis programmieren wird es früher oder später keinen mehr geben der C/C++ lernt so wie es heute leider teilweise schon mit Assembler ist. Auf die Dauer könnte dann ein ernsthafter Mangel an Fachkräften für diese Gebiete herrschen und evtl. einfach immer weiter auf die gegebene Struktur aufgesetzt (z.B. eine weitere Programmiersprache die dann auf .NET basiert würde wieder mehr Speicher für Hello-World verschlingen und nocht langsamer laufen....)

Gute Nacht

termi

Term!nX · 08/09/2007, 15:33

Hi,

Danke für die Antworten. Habe den Code jetzt nochmal überarbeitet. Jetzt läuft es glatt.
C# fand ich irgendwie genau das richtige um einzusteigen. Zum einen ist in meinen Augen die .net Sache eine gute Idee und zum anderen fand ich die Sprache irgendwie einfacher. C++ war mir einfach ne Spur zu schwer, das spar ich mir für die Uni.

SilonVier · 08/09/2007, 23:35

Quote:

Originally posted by termi+Aug 9 2007, 03:39--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (termi @ Aug 9 2007, 03:39)</td></tr><tr><td id='QUOTE'>C# und der restliche .NET kram sind zwar recht leicht zu programmieren allerdings ist die Performance übelst lahm....[/b]

"übelst lahm"? Auf welchen begrenzten Horizont basiert deine Meinung? Skippen wir diesen Schritt, weil du sagen würdest "Im Vergleich zu C/C++ oder Assembler". Wenn du Software schreiben würdest, die wirklich zeitkritisch ist, dann würdest du es mit Sicherheit nicht unter einem gängigen Betriebssystem wie Windows tun. Windows ist - sehr abstrakt betrachtet - eine virtuelle Maschine, die deinen Code interpretiert und dann ausführen lässt. Das heisst wenn du ein mov [eax], 1 siehst und bei Intel für deinen Prozessor die Geschwindigkeit anfragst, die dein Prozessor braucht um den zu verarbeiten, wirst du ganz weit von dieser Zahl entfernt sein.
Wenn du dir die CLR-Architektur und den generierten Code jemals angesehen hättest (das schließt auch das debuggen in .NET Funktionen ein), dann wüsstest du, dass du so eine extreme Aussage wie "übelst lahm" gar nicht benutzen solltest. Performance ist für Neulinge ein toller Grund diese anzusprechen, weil sie es irgendwo gelesen haben und denken, man könnte da mitreden, ohne weit genug gedacht zu haben.
Der C++ Compiler (ich beziehe mich hier auf die 8er Version von VS2005) generiert keinen schnelleren Code, da der C# Compiler im Backend exakt der gleiche ist. Schreibe in C++ die gleiche Funktionalität als Klasse für "Int" und dein generierter C++ Code wird mit sehr hoher Wahrscheinlichkeit nicht schneller sein. Vielleicht würde er auch langsamer sein ... wer weiss.

Quote:

Originally posted by -termi@Aug 9 2007, 03:39
noch dazu kommt, wenn immer mehr Leute nurnoch auf .NET-Basis programmieren wird es früher oder später keinen mehr geben der C/C++ lernt so wie es heute leider teilweise schon mit Assembler ist.

Ich bin in einem Ort augewachsen, der so abgelegen ist, dass Wissen über Mechanik/Maschinenbau und Landwirtschaft für jedermann lebenswichtig war. Heute muss man nur noch Wissen, wo die nächste Werkstatt des "Spezialisten" zu finden ist und das man im Supermarkt an der Kasse für sein Essen bezahlt. Nichtsdestotrotz funktioniert das System und das in vielerlei Hinsicht besser als früher. Mache dir einige Gedanken darüber und frage dich dann, was du mit der Programmierung erreichen möchtest ... versuche dich auch in die Leute und Firmen hineinzuversetzen, die Programmiersprachen entwickeln und welche Ziele sie verfolgen.

Quote:

Originally posted by -termi@Aug 9 2007, 03:39
Auf die Dauer könnte dann ein ernsthafter Mangel an Fachkräften für diese Gebiete herrschen

Ein Mangel an Fachkräften bedeutet entweder dass der Fachbereich nicht mehr in dem Ausmaß benötigt wird oder es gäbe nicht genug Menschen, die sich das Wissen aneignen könnten. In diesem Fall wird eher das erste zutreffen. Das Wissen über Assembler wird nicht mehr in diesem großen Umfang benötigt. Es ist zurzeit essenziell für Prozessor- und Compilerentwickler. Aus technischer Sicht könnte die volle Funktionalität, die mit Assembler realisiert werden kann - wenn das nicht bereits geschehen ist -, voll in C realisiert werden. Wieviel Sinn das ganze macht anstatt für das eine oder andere doch Assembler zu nutzen ist ein eigenes Thema.

<!--QuoteBegin--termi@Aug 9 2007, 03:39
und evtl. einfach immer weiter auf die gegebene Struktur aufgesetzt (z.B. eine weitere Programmiersprache die dann auf .NET basiert würde wieder mehr Speicher für Hello-World verschlingen und nocht langsamer laufen....)[/quote]
Die Hardwareentwicklung befindet sich nicht in der Stagnation. Vor 20 Jahren hat niemand daran gedacht eine Programmiersprache zu entwickeln, die ernsthaft eine voll automatische Speicherverwaltung beinhaltet, um die sich der Programmierer nicht mehr kümmern muss und dessen Code zur Laufzeit interpretiert/kompiliert wird. Ob ich nun Code in C oder C# schreibe macht was die Geschwindigkeit angeht nicht den geringsten Unterschied. Ich kriege bei beiden in meiner Toleranzgrenze (Prozessorzeit) das gewünschte Resultat. Es kommt mir mehr auf die Entwicklungszeit/Entwicklungsaufwand und Wartbarkeit an.

~~CyRuSTheViRuS~~ · 08/10/2007, 11:47

Also das .NET "lahm" ist wär mir auch neu. Das zeigt mir einfach das derjenige der das gesagt hat noch nie mehr als nen Währungsrechner in der Schule programmiert hat.
Und das !.NET-Programmierer aussterben kann ich auch nicht gerade sagen. Ich mein ... .NET wurde wahrscheinlich nicht in C# programmiert oder ? ;o

SilonVier · 08/10/2007, 12:59

Quote:

Originally posted by CyRuSTheViRuS+Aug 10 2007, 11:47--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (CyRuSTheViRuS @ Aug 10 2007, 11:47)</td></tr><tr><td id='QUOTE'>Und das !.NET-Programmierer aussterben kann ich auch nicht gerade sagen.[/b]

"Gute" .NET-Programmierer sind Mangelware. Vorausgesetzt man möchte diesem über 5000? zahlen, wo du sicherlich genug finden wirst. Die Frage ist nur ob sich das auf Dauer durch Projekte rentiert.

<!--QuoteBegin--CyRuSTheViRuS@Aug 10 2007, 11:47
Ich mein ... .NET wurde wahrscheinlich nicht in C# programmiert oder ? ;o[/quote]
Wenn du die CLR meinst: Nein

Andere Komponenten in der .NET Framework (der System.*-Zweig z. B.) wurden in einer .NET-fähigen Sprache geschrieben. Andernfalls würde Reflections in der Form auch nicht funktionieren. Du kannst also alle diese Dlls im .NET Reflector öffnen und dir den rekonstruierten Quellcode ansehen, wenn du möchtest.

~~4C1D^~~ · 08/11/2007, 18:34

erstmal:
.net is wohl schneller als C++, auf jeden fall soweit ich das bis jetz mitgekriegt hab.
zweitens:
mangel an programmierern von anderen hochsprachen wird wohl erst in > 15 jahren geben.
gibt immernoch leute, die assembler lernen(wenig ^^). aber warum haben die leute wohl sprachen wie C oder so entwickelt und sind nich einfach bei assembler geblieben? richtig, weils einfacher war.

just my 3,1415926 cents

termi · 08/11/2007, 18:51

Quote:

Originally posted by CyRuSTheViRuS@Aug 10 2007, 11:47
Also das .NET "lahm" ist wär mir auch neu. Das zeigt mir einfach das derjenige der das gesagt hat noch nie mehr als nen Währungsrechner in der Schule programmiert hat.
Und das !.NET-Programmierer aussterben kann ich auch nicht gerade sagen. Ich mein ... .NET wurde wahrscheinlich nicht in C# programmiert oder ? ;o

Ich geh da nun jetzt nicht weiter drauf ein aber ich kann dir sagen das ich schon durchaus kritischeres als einen Währungsumrechner programmiert habe....
Ich wollte mit dem Kommentar nur andeuten, dass ich es etwas zu aufgeblasen finde und es kein wirklicher Ersatz für eine "normale" Programmiersprache darstellt, weil der Code (meines Wissens nach) auf ein bestimmtest Framework setzt dessen Quellen nicht offen und (für mich) deshalb nicht vertrauenswürdig sind.

Um noch auf den Punkt Geschwindigkeit einzugehen:
"übelst lahm" mag zwar etwas übertrieben gewesen sein, aber es eindeutig merkbar langsamer als in C/C++ programmierte Programme, solange diese natürlich keine schlechten Algorithmen enthalten.

Ich selbst nutze auch gerne mal .NET für kleinere Anwendungen allerdings find ich es für Rechenintensive Anwendungen zu langsam. Beispiel: RShare/StealthNET (möglicherweise nicht am saubersten programmiert aber ok) - hier werden einige Verbindungen zu anderen Rechnern aufgebaut (genau 5 - sofern der Quellcode nicht geändert wurde) welche verschlüsselt sind und nur als Brücke zu anderen Knoten dienen. (Das ganze muss man sich ähnlich eines Briefes vorstellen der in einer Klasse von Person zu Person wandert bis er irgendwann am Ziel ankommt)
Für dieses "relativ" einfache Szenario wird meiner Meinung nach zuviel Rechneleistung verbraten (3 GHZ Rechner hat ~90% CPU-Last wenn !!keine!! Pakete versand werden).

Von mir aus stellt weiter mein Wissen/Kompetenz über Programmiersprachen infrage allerdings bin und bleib ich ein Verfächter von C/C++ unter Windows sowie (vorzugsweise) Unix/Linux.

Disktuiert gerne weiter aber ich werde für eine solche Grundsatzdiskussion keine Zeit mehr verschwenden....

Harko · 08/11/2007, 22:16

NET und Asm, ist genauso wie Äpfel und Birnen zu vergleichen da das Einsatzgebiet komplett verschieden ist. NET ist aufjedenfall langsamer aber die Performanceeinbuße sind bei fast allen Anwendungsgebieten vernachlässigbar. In der Wirtschaft geht es um kurze Entwicklungszeiten und Stabilität und beides bietet .Net-Programmierung.

Natürlich wird ein Spiel wie Crysis nie in NET programmiert werden, zumindest nicht in den nächsten Jahren, genauso wird man bei einem Microsoft Entwickler sehr viel lachen verursachen wenn man nachfragt wann endlich die WinDDK .Net supportet.

Achja und wenn ein .Net Server mit 5 Clients 90% der Cpu beansprucht sollte man dem Programmierer nochmal die Reihe der Dummies Bücher anbieten.

Term!nX · 08/11/2007, 23:35

Wodrin ist denn Crysis programmiert?

Und wie groß sind denn die Geschwindigkeitsunterschiede zwischen NET und einer net unabhängigen hochsprache?

Harko · 08/12/2007, 02:08

Quote:

Originally posted by Term!nX@Aug 11 2007, 23:35
Wodrin ist denn Crysis programmiert?

Und wie groß sind denn die Geschwindigkeitsunterschiede zwischen NET und einer net unabhängigen hochsprache?

die Geschwindigkeitsunterschiede hängen doch ganz von dem ab was man vor hat und wie man es umsetzt.

Will man z.b. ein Programm schreiben welches Primzahlen faktorisiert. Der Algorithmus dahinter ist der gleiche und bei kleinen Primzahlen würde es auch kein merkbaren Unterschied machen. Wenn man größere Primzahlen verwendet würde man es sehen ob das eine Programm nun 24 und das andere vielleicht 24 1/2 Stunden braucht. Bei einem normalen Windows Programm hingegen wird es sicher niemanden interessieren ob dieses nun in 0.1s oder in 0.2s gestartet ist...

Die CryEngine, genauso wie die UnrealEngine und jedes andere gute 3D Spiel werden in C++ programmiert sein, was halt auch Sinn macht wenn man eine ungefähre Vorstellung hat wieviel Code durchgehend verarbeitet werden muß und ein Kunde wird es dann schon interessieren ob er 15 oder 30fps hat.

psych0o · 08/12/2007, 07:34

Oh man diese Diskussion ist total überflüssig und wird niemals was bringen...

C# ist eine weiterentwicklung. Das die Welt nicht stehen bleibt und sich stetig weiterentwickelt versteht sich von selber...

.NET richtet sich nicht an die aufwendigen Spiele-Engines, sondern eher an Windows-Anwendungen (auch wenn es irgendwie plattform-unabhängig sein soll (hab ich mal gelesen)). Ich bin zwar nicht der beste Coder und hab von C++ nur minimalistisch Ahnung, ich bin mir aber sicher, dass .NET in dem Bereich einfach besser ist als C++, weil es viel besser auf Windows-Ressourcen zugreifen kann und weil es schon viele Funktionen bietet, dann man dann nicht erst noch coden muss.

Ich beschränke mich mal auf mein Gebiet (jaa nun kommen die Buuu-rufe).

VB6 fehlten viele sachen. Doch all dies wurde mit .NET implementiert. Als einfachstes und bestes Beispiel ist die Mail funktion oder die Crypt-Funktionen.

Ich denke, dass man C# (und somit auch .NET) und C++ kaum vergleichen kann. Beides hat vor und nachteile.

Term!nX · 08/12/2007, 14:47

Quote:

Originally posted by Harko+Aug 12 2007, 02:08--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (Harko @ Aug 12 2007, 02:08)</td></tr><tr><td id='QUOTE'> <!--QuoteBegin--Term!nX@Aug 11 2007, 23:35
Wodrin ist denn Crysis programmiert?

Und wie groß sind denn die Geschwindigkeitsunterschiede zwischen NET und einer net unabhängigen hochsprache?

die Geschwindigkeitsunterschiede hängen doch ganz von dem ab was man vor hat und wie man es umsetzt.

Will man z.b. ein Programm schreiben welches Primzahlen faktorisiert. Der Algorithmus dahinter ist der gleiche und bei kleinen Primzahlen würde es auch kein merkbaren Unterschied machen. Wenn man größere Primzahlen verwendet würde man es sehen ob das eine Programm nun 24 und das andere vielleicht 24 1/2 Stunden braucht. Bei einem normalen Windows Programm hingegen wird es sicher niemanden interessieren ob dieses nun in 0.1s oder in 0.2s gestartet ist...

Die CryEngine, genauso wie die UnrealEngine und jedes andere gute 3D Spiel werden in C++ programmiert sein, was halt auch Sinn macht wenn man eine ungefähre Vorstellung hat wieviel Code durchgehend verarbeitet werden muß und ein Kunde wird es dann schon interessieren ob er 15 oder 30fps hat. [/b][/quote]
Ja dachte ich mir schon, dass bei normalen Kleinanwendungen der Unterschied nicht spürbar ist und da die meisten denke ich keine hochkomplexen Programme schreiben, ist die Einfachheit einer Sprache eher ein Kriterium als die Geschwindigkeit.

Und diese Engines, die sind alle nur in C++ geschrieben? Schon seltsam, die Sprache muss echt zu allem fähig sein. Aber was macht denn jetzt C++ schneller als C#? Ist es nur, dass C++ sich die Umwandlung in diesen .net spezifischen Zwischencode spart?

~~CyRuSTheViRuS~~ · 08/12/2007, 17:51

Lol ... Performance ... Hallooo ? Wir reden hier von Windows ;D

Hm naja ich habs jedenfalls nie selber getestet und kanns daher auch nicht sagen. Aber selbst wenn .NET langsamer ist als C/C++, was macht das schon ;D