C oder C++?

[HumeSikkins]

Optimizer schrieb:

Ja, das meine ich ja. Es ist allgemein bekannt, das Java-Software langsamer sind als ein Programm, das denselben Zweck in C oder C++ erfüllt. Ich mein das jetzt sehr verallgemeinert.

Das meinst du deshalb verallgemeinert, weil du nicht programmieren kannst und nicht verstehst, wie sich die Performance eines Programms zusammensetzt.
(Hast du ja bereits unter Beweis gestellt)

Verallgemeinert stimmt das doch durchaus. Schließlich bekommt man auch die Java-Features nicht umsonst. Ob der Geschwindigkeits- und Speicheranforderungsunterschied in der Praxis relevant ist, hängt natürlich von der Situation ab. Deshalb kann man aber nicht gleich so tun, als gäbe es keine Kosten.

Die Welt ist sicher nicht schwarz-weiß (nach dem Motto: C ist schnell und Java lahm), es ist definitiv aber auch nicht alles grau (nach dem Motto: Alles ist gleich. Unterschiede ergeben sich nur aus der Inkompetenz des Programmierers oder der Schwäche einer Implementation).

[Real]

Hallo

Optimizer schrieb:

Hallo,
danke für die Antworten! Was ich will, ist erst mal weg von Java! Das ist der größte Mist der Welt (zumindest ist es nicht das, was mich interessiert)!

Cool, du lernst es gerade erst, aber es ist auf jeden Fall schon mal der größte Mist der Welt.

Für mich ist es Mist, weil ich mit Java nicht mal ein CD-ROM Laufwerk öffnen könnte. Bei Java muss ich mich auf triviale Dinge einlassen und kann nicht Programme programmieren, die speziell für das OS gedacht sind.

Ja, das meine ich ja. Es ist allgemein bekannt, das Java-Software langsamer sind als ein Programm, das denselben Zweck in C oder C++ erfüllt. Ich mein das jetzt sehr verallgemeinert.

Das meinst du deshalb verallgemeinert, weil du nicht programmieren kannst und nicht verstehst, wie sich die Performance eines Programms zusammensetzt.
(Hast du ja bereits unter Beweis gestellt)

Nun, ich habe schon ein Fremdwörterbuch programmiert mit Datenbankanbindung, habe auch einige Tuning-Tips ausprobiert. Beispielsweise habe ich StringBuffer statt String benutzt. Aber ich will eben hardwarenah und speziell für das System programmieren und Java ist deswegen für mich ein Mist, weil es nicht diese Zwecke erfüllt.
Gut, es gibt einige Tricks, wie man dies und das in Java realisieren könnte, aber da kommen beispielsweise bei Windows dlls im Spiel und schon ist die Plattformunhabhängigkeit futsch. Was nützt mir da noch Java?!

Zudem ist Java umständlich! Schon mal ein einfaches I/O in Java realisiert oder einige Daten als Text-File gespeichert?!

Liebe Grüße
Real

[CMatt]

Wenn C++ bessere Features als C bietet, wieso wurde dann später nicht Unix, Linux, BSD und all die Betriebssysteme nicht mit C++ implementiert?

das neuen Zeug ist doch c++.. diese ganzen Internet/Browser/IIS interfaces, der XML krahm, Streaming Devices, DirectX (immer mehr), GDI+, bla.., blub.. fast alles COM oder DCOM... kann mir auch schlecht vorstellen das MS seine .Net platform in C und Assembler schreibt..

[CMatt]

Zudem ist Java umständlich! Schon mal ein einfaches I/O in Java realisiert oder einige Daten als Text-File gespeichert?!

Schon mal in C++ ne GUI mit 150 Dialogen, datenbankanbindung, Netzwerk, vielen klick bunti buttons, für Windows, Linux, BSD, MAC,.. gleichzeitig programmiert?

Das was du da schreibst ist doch absoluter käse... Klar ist java schrott wenn damit bitschieben auf nen I/O karte geht.. aber ebenso ist c++ für das bsp oben schrott.

[Gast]

Nun, ich habe schon ein Fremdwörterbuch programmiert mit Datenbankanbindung, habe auch einige Tuning-Tips ausprobiert. Beispielsweise habe ich StringBuffer statt String benutzt.

Respekt! Besonders im Bezug darauf, dass man wenn möglich, StringBuffer nicht nutzen soll, wenn man Strings nutzen kann.
Hängt natürlich vom genauen Verwendungszweck ab, aber deine Aussage ist so allgemein, dass StringBuffer in den allermeisten Fällen wohl die schlechtere Wahl ist. Außerdem wirst du damit nicht großartig die Performance eines Programms beeinflussen können.

Überhaupt schreibst du absoluten Mist. So ein BufferedReader/BufferedWriter für I/O ist IMO keinesfalls schlechter/langsamer als der ofstream in C++, und ja, ich habe schon mal was in eine Datei geschrieben und finde das weder in C++ noch in Java schwer.

Java ist sicherlich in den meisten Fällen weniger umständlich, weil es ein sehr ausführliches, plattformunabhängiges (<- relativ) API mit sich bringt und überhaupt viel vorgefertigt hat und einem viel Arbeit und Sorgen abnimmt.

Gegen Java sprechen ganz andere Dinge (es hat auch einige Nachteile, aber höchstwahrscheinlich nicht die, an die du glaubst), aber die kannst du nicht begreifen, denn du bist ganz offensichtlich nicht in der Lage, diese Dinge zu verstehen, wenn du ein Fremdwörterbuch für was besonderes hältst.
Es ist immer auch eine Frage, was für welchen Zweck geeignet ist, aber du bist sicher nicht in der Lage, eine für deine Zwecke geeignete Sprache auszuwählen, da sich deine "Systemprogrammierung" anscheinend auf das Nutzen von DLLs beschränkt.

[Bashar]

Real schrieb:

Wenn C++ bessere Features als C bietet, wieso wurde dann später nicht Unix, Linux, BSD und all die Betriebssysteme nicht mit C++ implementiert? Wieso ist der Interpreter von PHP in C geschrieben? Seine Gründe wird es doch wohl haben.

Das ist eine gute Frage, die du sicherlich auch an die Entwickler von Linux, BSD und PHP stellen kannst. Objektive Kriterien gegen C++, für C, sind aber z.B.:

1. C++ Compiler unterscheiden sich stark im Konformitätsgrad, d.h. man muss, wenn man auf einen gemeinsamen Nenner kommen will, sehr viele Abstriche bei fortgeschrittenen Features wie Templates, Exceptions und Namespaces machen (siehe z.B. Coding-Richtlinien des Mozilla-Projektes)
2. C Compiler sind verbreiteter als C++ Compiler. Es gibt effektiv auf jeder Plattform einen C-Compiler, wenn auch rudimentär. Das reicht aber, um z.B. PHP oder auch GTK+ darauf zu portieren.
3. [ die folgenden Argumente unter der Prämisse betrachten, dass effektiv der einzige (?) freie C++ Compiler der gcc ist) ]
   3a) gcc wurde erst kürzlich mit der Version 3 halbwegs standardkonform. Beim Übergang von 2 zu 3 hat sich aber z.B. das Binärinterface (ABI) geändert, was zu hohem Aufwand beim Updaten führt. Ergo wird das nicht gemacht (bzw. erst in den letzten Monaten/Jahren)
   3b) gcc übersetzt C++ sehr viel langsamer als C
   3c) die erzeugten Programme sind sehr viel größer als entsprechende C-Äquivalente

Subjektive Kriterien:
4) C++ bringt ein eigenes Denkmodell mit sich, dass mit den in der Betriebssystementwicklung oder im Compilerbau ( PHP-Interpreter) vorherrschenden kollidiert. Man muss also entweder seine Philosophie an die von C++ anpassen, oder die von C++ irgendwie zurechtbiegen, oder praktisch auf C-Level zurückgehen.
5) Objektorientierung kann man sehr schön übertreiben, insbesondere wenn es an Erfahrung mangelt. Man will nicht, dass beispielsweise Linus Torvalds, dem ich mal eine ausserordentliche Kompentenz in Sachen Betriebssysteme unterstelle, plötzlich ein mittelmäßiges bis grottiges C++-OS produziert, bis er in OO so gut ist, dass er den alten Standard wieder erreicht.

Zwangsstopp hier

[Real]

Hallo Optimizer,

Optimizer schrieb:

Respekt! Besonders im Bezug darauf, dass man wenn möglich, StringBuffer nicht nutzen soll, wenn man Strings nutzen kann.

Kennst du überhaupt den Unterschied zwischen String und StringBuffer?!
Wenn du in String etwas anhängst/veränderst, was macht das Objekt String?! Was macht StringBuffer?! Wenn du den Unterschied weisst, dann erkennst du warum String nicht nur mehr Speicher frisst, sondern auch deutlich langsamer ist.

Hängt natürlich vom genauen Verwendungszweck ab, aber deine Aussage ist so allgemein, dass StringBuffer in den allermeisten Fällen wohl die schlechtere Wahl ist.

Falsch! (Für was hat man eigentlich StringBuffer erfunden, wenn es immer die Schlechtere Wahl ist?!)
Wenn es um Sicherheit geht, ist String besser, sonst nie! :p

Außerdem wirst du damit nicht großartig die Performance eines Programms beeinflussen können.

Kommt drauf an! Wenn du eine fette Liste zusammnhängender Strings ausgibst, ist String um ein vielfaches langsamer als StringBuffer.
Ich hab´s mal in einer Schleife probiert. String braucht über eine Minute und StringBuffer nur wenige Sekunden (unter 5). Wieviele String ich angehängt habe und wie oft die Schleife durchloffen worden ist, weiss ich nicht mehr, aber probier´s am Besten selbst aus.

Überhaupt schreibst du absoluten Mist. So ein BufferedReader/BufferedWriter für I/O ist IMO keinesfalls schlechter/langsamer als der ofstream in C++

Nein, tut mir Leid das sagen zu müssen, aber du schreibst absoluten Mist! Warum tust du das? Keiner deiner genannten Behauptungen habe ich jemals erwähnt, sage mir bitte wo!
Ich wollte dir jediglich übermitteln, dass es in Java umständlicher (weder langsam, noch schwer, noch sonst irgendwas) ist.

Gegen Java sprechen ganz andere Dinge (es hat auch einige Nachteile, aber höchstwahrscheinlich nicht die, an die du glaubst), aber die kannst du nicht begreifen, denn du bist ganz offensichtlich nicht in der Lage, diese Dinge zu verstehen, wenn du ein Fremdwörterbuch für was besonderes hältst.

Tu ich nicht, ich wollte dir nur mitteilen, auf welchem Stand ich gerade bin.
Erzähl mir bitte die Nachteile von Java.
Wie gesagt gefällt mir Java nicht, da ich damit nicht hardwarenah proggen kann und OS-spezifisch, darum habe ich mich entschieden erst mal in C anzufangen und dann später mit C++, so kann ich beide Vorteile kombinieren.

Es ist immer auch eine Frage, was für welchen Zweck geeignet ist, aber du bist sicher nicht in der Lage, eine für deine Zwecke geeignete Sprache auszuwählen, da sich deine "Systemprogrammierung" anscheinend auf das Nutzen von DLLs beschränkt.

Sag bitte, wo habe ich das erwähnt?
In diesem Satz den du erwähnst, kam der Satz "beispielsweise" vor und noch weiter oben erwähnte ich, das ich an Linux interessiert bin (und mich auch teilweise damit beschäftige - bald kommt Debian drauf).

Ich würde gerne dein Anliegen erfahren, warum du dir irgendwelche Geschichten zusammenreimst!
Ich bin hier Gast und kann hier nichts editieren, zeig mir bitte deine erwähnten Behauptungen.

Hallo Bashar!
Deine Gründe klingen logisch, aber C ist soweit ich weiss noch hardwarenhäer als C++. Ich werde mal in einem Linux-Forum nachfragen.

Liebe Grüße
Real

[Shade Of Mine]

Real schrieb:

aber C ist soweit ich weiss noch hardwarenhäer als C++

Was kannst du in C machen was du in C++ nicht kannst?

[Gast]

Hallo Real,

Kennst du überhaupt den Unterschied zwischen String und StringBuffer?!
Wenn du in String etwas anhängst/veränderst, was macht das Objekt String?! Was macht StringBuffer?! Wenn du den Unterschied weisst, dann erkennst du warum String nicht nur mehr Speicher frisst, sondern auch deutlich langsamer ist.

Ja, den kenne ich. Ein String ist eine immutable Sequenz von Zeichenketten. Aus diesem Grund können sie wesentlich effizienter implementiert werden, weil sie einfach neu erstellt werden, wenn du an ihnen arbeitest. length und andere Eigenschaften sind Konstanten. Wenn du z.B. den String nach Uppercase konvertierst, wird der eigentliche String überhaupt nicht angefasst, sondern es wird ein neuer erstellt (was in Java übrigens ziemlich schnell geht), der die passenden Daten enthält und eine Referenz darauf zurückliefert.
Außerdem können Strings im Gegensatz zu StringBuffers geshared werden.
String a = b;
bewirkt nur die Kopie eines Zeigers. So einfach kannst du das in C++ bestenfalls mit der Copy-on-write Technik erreichen, die einigermaßen aufwändig zu implementieren ist und auch Overhead erzeugt. Btw. die std::string implementierung von meinem Compiler nutzt diese Vorgehensweise nicht, da wird wirklich jedesmal der String kopiert.

StringBuffer dagegen sind mutable und können entsprechende Vorteile nicht genießen. Sie sind dafür gedacht, dass wenn man einen StringBuffer ändert, alle Referenzen darauf diese Änderung mittragen. Der '+' Operator nutzt übrigens StringBuffer (vlg. Java API Dokumentation).

Falsch! (Für was hat man eigentlich StringBuffer erfunden, wenn es immer die Schlechtere Wahl ist?!)
Wenn es um Sicherheit geht, ist String besser, sonst nie!

Ok, zu StringBuffer siehe oben. Manchmal braucht man halt die Eigenschaften von veränderlichen Strings.

Kommt drauf an! Wenn du eine fette Liste zusammnhängender Strings ausgibst, ist String um ein vielfaches langsamer als StringBuffer.
Ich hab´s mal in einer Schleife probiert. String braucht über eine Minute und StringBuffer nur wenige Sekunden (unter 5). Wieviele String ich angehängt habe und wie oft die Schleife durchloffen worden ist, weiss ich nicht mehr, aber probier´s am Besten selbst aus

Ist nicht langsamer. Der Sourcecode würde mich interressieren. Es hat dir ja keiner gesagt, dass du '+' benutzen sollst, um mehrere Strings auszugeben (wie gesagt, '+' ist über StringBuffer implementiert).
Mehrere print's erfüllen genau den selben Zweck.

Ich wollte dir jediglich übermitteln, dass es in Java umständlicher (weder langsam, noch schwer, noch sonst irgendwas) ist.

Was genau ist umständlicher, besonders in Bezug auf I/O und im speziellen File I/O ?

Tu ich nicht, ich wollte dir nur mitteilen, auf welchem Stand ich gerade bin.
Erzähl mir bitte die Nachteile von Java.

Für mich persönlich sprechen ein paar sprachliche Beschränkungen gegen Java. Zum Glück kommen jetzt bald Generics. Ich vermisse Templates (homogene Container), const-correctness, Referenzen auf primitive Typen und Operator overloading, zumindest bei allen Operatoren außer '==', '!=' und offizielle Unterstützung für DirectX (die auch nie kommen wird).

Es gibt viele Anwendungen (vielleicht die meisten), wo ich Java vorziehe, weil es IMO einfacher und produktiver ist. Ich sehe aber auch ab und zu Dinge, die ich lieber in C++ löse.
Aber deine Begründungen, warum Java überhaupt keine Existenzberechtigung hat, ist IMO nicht nachvollziehbar.

[Shade Of Mine]

Optimizer schrieb:

Außerdem können Strings im Gegensatz zu StringBuffers geshared werden.
String a = b;
bewirkt nur die Kopie eines Zeigers. So einfach kannst du das in C++ bestenfalls mit der Copy-on-write Technik erreichen, die einigermaßen aufwändig zu implementieren ist und auch Overhead erzeugt.

Wozu? Java macht doch auch kein Copy-On-Write, wozu soll ich das also machen? Sind ja 2 verschiedene Sachen. Ich share einfach auch das Objekt:

shared_ptr<string> p(new string("hallo"));
shared_ptr<string> p2(p);

Btw. die std::string implementierung von meinem Compiler nutzt diese Vorgehensweise nicht, da wird wirklich jedesmal der String kopiert.

Sehr kluge entscheidung des Herstellers.

Was genau ist umständlicher, besonders in Bezug auf I/O und im speziellen File I/O ?

EOF ist eine Exception?
Ich muss BufferedReader, Writer und sonstwas erstellen.
Also gerade IO gefällt mir in Java weniger gut.

Aber deine Begründungen, warum Java überhaupt keine Existenzberechtigung hat, ist IMO nicht nachvollziehbar.

wo hat er das gesagt?

[gomberl]

JUHUUUUUUU

FLAMEWAR

EOF ist eine Exception?
Ich muss BufferedReader, Writer und sonstwas erstellen.
Also gerade IO gefällt mir in Java weniger gut.

das mit eof geb ich dir - das hatten wir schon mal an anderer stelle.

hier sei angeführt das java einen anderen ansatz zur dateibearbeitung hat als alles das ich kenne. es gibt das file (quasi der pointer auf die file structur in gutem alten C), die streams zum einlesen und auslesen und den reader und writer (schreiben und lesen)
das alles macht es universell auf allen plattformen einsetzbar ohne das man an der implementierung was ändern müsste

man hat ausserdem wesentlich mehr möglichkeiten verschiedenste dinge objekt orientiert zu schreiben

also ich mag das - auch wenn es mehr aufwand als in C++ ist

ich würde Real nicht so abtun, er hat halt keine lust sich wo einzuarbeiten und hat sicher viele vorurteile die auch andere haben
aber wenn es nicht sein bier ist soll er halt mit C schreiben
wenns wirklich tief runtergehen soll empfehle ich assembler
da gehts dann rund

gomberl

[Real]

Hi Optimizer,
gut, den Unterschied zwischen String und StringBuffer kennst du ja. Viele Java-Programmierer sehen genau das als Nachteil.
String wird bei einer Anhänung nicht verändert, wie viele meinen, sondern es wird ein neues Objekt erstellt. Bei kurzen Sachen mag das ok sein, aber bei vielen Anhängungen und langen Liste tendiere ich zu StringBuffer.

Optimizer schrieb:

Kommt drauf an! Wenn du eine fette Liste zusammnhängender Strings ausgibst, ist String um ein vielfaches langsamer als StringBuffer.
Ich hab´s mal in einer Schleife probiert. String braucht über eine Minute und StringBuffer nur wenige Sekunden (unter 5). Wieviele String ich angehängt habe und wie oft die Schleife durchloffen worden ist, weiss ich nicht mehr, aber probier´s am Besten selbst aus

Ist nicht langsamer. Der Sourcecode würde mich interressieren. Es hat dir ja keiner gesagt, dass du '+' benutzen sollst, um mehrere Strings auszugeben (wie gesagt, '+' ist über StringBuffer implementiert).
Mehrere print's erfüllen genau den selben Zweck.

Leider weiss ich nicht, wie ich bei Strings das "+" umgehen kann.
Hier poste hier mal den kompletten Code, so dass du das Programm ausprobieren kannst. Es war eine kleine Hausaufgabe, wo man den Preis eingibt und die Jahre in denen man das Produkt abbezahlen will.
Ersetze alle StringBuffer mit String und gib mal bei Preis= 10000 und Jahre=10 000 000. Mit StringBuffer kannst du sogar höhere Werte eingeben und es wird trotzdem deutlich schneller sein als String. Klar, das Beispiel mag etwas übertrieben sein, aber es zeigt einem deutlich den Gewschindigkeitsvorteil von StringBuffer.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.io.*;

public class HauptFenster extends JFrame {
  JPanel contentPane;
  TextField tfPreis = new TextField();
  Label lbPreis = new Label();
  TextField tfJahre = new TextField();
  Label lbJahre = new Label();
  Button btBerechnen = new Button();
  Button btSpeichern = new Button();
  TextArea taKapital = new TextArea();
  Button btLoeschen = new Button();
  Label lbStatus = new Label();
  StringBuffer kapitalAusgabe = new StringBuffer(); //Instanzvariable
  Button btLesen = new Button();
  JMenuBar jMenuBar = new JMenuBar();
  JMenu jMDatei = new JMenu();
  JMenuItem jMSchliessen = new JMenuItem();

  /**Den Frame konstruieren*/
  public HauptFenster() {
    enableEvents(AWTEvent.WINDOW_EVENT_MASK);
    try {
      jbInit();
    }
    catch(Exception e) {
      e.printStackTrace();
    }
  }

  /**Initialisierung der Komponenten*/
  private void jbInit() throws Exception  {
    //setIconImage(Toolkit.getDefaultToolkit().createImage(HauptFenster.class.getResource("[Ihr Symbol]")));
    contentPane = (JPanel) this.getContentPane();
    contentPane.setLayout(null);
    this.setJMenuBar(jMenuBar);
    this.setSize(new Dimension(400, 346));
    this.setTitle("Produkt-Abbezahlung");
    tfPreis.setBounds(new Rectangle(227, 42, 108, 32));
    lbPreis.setFont(new java.awt.Font("Dialog", 1, 12));
    lbPreis.setText("Preis in €");
    lbPreis.setBounds(new Rectangle(228, 15, 56, 25));
    tfJahre.setBounds(new Rectangle(228, 104, 108, 32));
    lbJahre.setBounds(new Rectangle(221, 77, 123, 25));
    lbJahre.setText("Abbezahlung in Jahre");
    lbJahre.setFont(new java.awt.Font("Dialog", 1, 12));
    btBerechnen.setBackground(Color.white);
    btBerechnen.setFont(new java.awt.Font("Dialog", 1, 12));
    btBerechnen.setLabel("Berechnen");
    btBerechnen.setBounds(new Rectangle(234, 156, 99, 35));
    btBerechnen.addActionListener(new java.awt.event.ActionListener() {
      public void actionPerformed(ActionEvent e) {
        btBerechnen_actionPerformed(e);
      }
    });
    btSpeichern.addActionListener(new java.awt.event.ActionListener() {
      public void actionPerformed(ActionEvent e) {
        btSpeichern_actionPerformed(e);
      }
    });
    btSpeichern.setBounds(new Rectangle(18, 214, 99, 35));
    btSpeichern.setLabel("Speichern");
    btSpeichern.setFont(new java.awt.Font("Dialog", 1, 12));
    btSpeichern.setBackground(Color.white);
    taKapital.setEditable(false);
    taKapital.setBounds(new Rectangle(8, 20, 202, 172));
    btLoeschen.addActionListener(new java.awt.event.ActionListener() {
      public void actionPerformed(ActionEvent e) {
        btLoeschen_actionPerformed(e);
      }
    });
    btLoeschen.setBounds(new Rectangle(75, 255, 99, 35));
    btLoeschen.addMouseListener(new java.awt.event.MouseAdapter() {
    });
    btLoeschen.setLabel("Löschen");
    btLoeschen.setFont(new java.awt.Font("Dialog", 1, 12));
    btLoeschen.setBackground(Color.white);
    lbStatus.setBounds(new Rectangle(190, 260, 130, 33));
    btLesen.setBackground(Color.white);
    btLesen.setFont(new java.awt.Font("Dialog", 1, 12));
    btLesen.setLabel("Auslesen");
    btLesen.setBounds(new Rectangle(128, 214, 99, 35));
    btLesen.addActionListener(new java.awt.event.ActionListener() {
      public void actionPerformed(ActionEvent e) {
        btLesen_actionPerformed(e);
      }
    });
    jMDatei.setText("Datei");
    jMSchliessen.setText("Schließen");
    jMSchliessen.addMouseListener(new java.awt.event.MouseAdapter() {
      public void mousePressed(MouseEvent e) {
        jMSchliessen_mousePressed(e);
      }
    });
    contentPane.add(tfPreis, null);
    contentPane.add(lbPreis, null);
    contentPane.add(tfJahre, null);
    contentPane.add(lbJahre, null);
    contentPane.add(btBerechnen, null);
    contentPane.add(btSpeichern, null);
    contentPane.add(taKapital, null);
    contentPane.add(lbStatus, null);
    contentPane.add(btLesen, null);
    contentPane.add(btLoeschen, null);
    jMenuBar.add(jMDatei);
    jMDatei.add(jMSchliessen);
  }
  /**Überschrieben, so dass eine Beendigung beim Schließen des Fensters möglich ist.*/
  protected void processWindowEvent(WindowEvent e) {
    super.processWindowEvent(e);
    if (e.getID() == WindowEvent.WINDOW_CLOSING) {
      System.exit(0);
    }
  }

  void btBerechnen_actionPerformed(ActionEvent e) {

if(tfPreis.getText().equals("") || tfJahre.getText().equals(""))
{
JOptionPane.showMessageDialog(this,"Bitte Textfelder komplett ausfüllen!");
}

else
{
  double preis, jahre, kapital;
  preis=Double.parseDouble(tfPreis.getText());
  jahre=Double.parseDouble(tfJahre.getText());

  kapital=(preis/jahre);

  int jahreUmrechnung = (int) jahre; //in int umwandeln

  kapitalAusgabe=new StringBuffer(""); //Automatisches Löschen, wenn man z.B. gleich danach nochmal etwas rechnet

  for(int i=1; i<= jahreUmrechnung; i++)
  {
   preis= preis-kapital;
   kapitalAusgabe= kapitalAusgabe.append(i).append(". Jahr: ").append(preis).append(" € \n");
    if(preis < kapital && preis !=0)
    {
    preis=0;
    kapitalAusgabe= kapitalAusgabe.append(i+1).append(". Jahr: ").append(preis).append(" € \n");
    }
  }
  taKapital.setText("Sie zahlen jährlich "+kapital+" € \n"+kapitalAusgabe.toString());
  }
  }
  void btSpeichern_actionPerformed(ActionEvent e) {
  if(taKapital.getText().equals(""))
  {
  JOptionPane.showMessageDialog(this,"TextArea noch leer");
  }
  else
  {
      try
    {
    BufferedWriter daten= new BufferedWriter(
    new FileWriter ("kapital.txt", true));

    daten.write(kapitalAusgabe.toString());
    daten.newLine();
    daten.write("________________________");
    daten.newLine();
    daten.close();
    JOptionPane.showMessageDialog(this, "Speichern war erfolgreich!");
    }
    catch(IOException f)
      {
      JOptionPane.showMessageDialog(this,"Fehler beim Speichern");
      }
    }
  }
  void btLoeschen_actionPerformed(ActionEvent e) {
  //Kleiner (blinkender) Gag eingebaut :-)
  try{
    lbStatus.setText("Wird gelöscht...");
    btLoeschen.setBackground(Color.red);
    Thread.sleep(500);
    btLoeschen.setBackground(Color.white);
    Thread.sleep(500);
    btLoeschen.setBackground(Color.red);
    Thread.sleep(500);
    btLoeschen.setBackground(Color.white);
    lbStatus.setText("Gelöscht!");
    taKapital.setText("");
    Thread.sleep(1500);
    lbStatus.setText("");
  }
  catch(InterruptedException fx)
    {
    JOptionPane.showMessageDialog(this,"Fehler!");
    }
  }
  void btLesen_actionPerformed(ActionEvent e) {

  try
  {
  BufferedReader daten= new BufferedReader(
  new FileReader("kapital.txt"));

  String line=daten.readLine();

  kapitalAusgabe=new StringBuffer(daten.readLine()).append("\n");
  while(line!=null)
    {
    kapitalAusgabe=kapitalAusgabe.append(line).append("\n");
    line=daten.readLine();
    }
  taKapital.setText(kapitalAusgabe.toString());
  daten.close();
  }
  catch(IOException fx)
    {
    JOptionPane.showMessageDialog(this, "\"kapital.txt\" nicht vorhanden");
    }

  }

  void jMSchliessen_mousePressed(MouseEvent e) {
  System.exit(0);
  }
}

Was genau ist umständlicher, besonders in Bezug auf I/O und im speziellen File I/O ?

Bei Eingabe und Ausgabe ist erst mal try/catch Pflicht, auch wenn die Anwedung noch so simpel ist. Bei größeren Projekten mag das zwar Sinn ergeben, aber das möchte ich schon selbst entscheiden. Dann brauche ich noch InputStreamReader und BufferedReader und dann kann´s mit dem .readLine() Befehl los gehen.
Bei C++ braucht man nur eine Variable und Tschink (cin>>) kann´s losgehen.

Für mich persönlich sprechen ein paar sprachliche Beschränkungen gegen Java. Zum Glück kommen jetzt bald Generics. Ich vermisse Templates (homogene Container), const-correctness, Referenzen auf primitive Typen und Operator overloading, zumindest bei allen Operatoren außer '==', '!=' und offizielle Unterstützung für DirectX (die auch nie kommen wird).

Sagt mir nicht viel, da ich momentan nur marginale Kenntnisse über C/C++ habe. Ich hörte ebenfalls eine Beschwerde von einem C++-Programmierer, dass bei Java die Grenze bei GUI schnell erreicht ist (bzw. bei Swing). Ein Klassenkamerad von mir, der zuvor in VB programmierte, reklamierte, dass er keine Möglichkeit sieht, die von der Datenbank erhalten Informationen in Tabellen darstellen lassen zu können.

Aber deine Begründungen, warum Java überhaupt keine Existenzberechtigung hat, ist IMO nicht nachvollziehbar.

Niemals behauptet.
Ich sehe in Java ebenfalls viele Vorteile, es kann sogar sehr viel Geld mit Java eingespart werden wegen seiner Plattformunabhängigkeit, aber genau diese Vorteile sind bei mir nicht von großer Interesse (momentan zumindest nicht, vielleicht kommt die Zeit, wo ich das schätzen werde.)

@Shade of Mind:
Aus einem anderen Forum:

....
Geht es ums lernen würde ich eher zu C raten. Warum?
Meiner Meinung nach sollte man die Grundlagen können, bevor man sich mit irgendwas "höherem" beschäftigt. D.h. man sollte mal selber mit Zeigern gearbeitet haben, die Bits einzeln verschieben und Speicher von Hand belegt und freigegeben haben bevor man sich solchen Hilfsmitteln wie new, delete,... bedient, einfach um ein Bild davon zu haben was hinter den Kulissen vorgeht.

Liebe Grüße
Real

PS: Deine Antwort fand ich jetzt gut!

[Sgt. Nukem]

Optimizer schrieb:

Ich vermisse [...] offizielle Unterstützung für DirectX (die auch nie kommen wird).

Ohhhh jaaa... *seufz*

Shade Of Mine schrieb:

Ich muss BufferedReader, Writer und sonstwas erstellen.
Also gerade IO gefällt mir in Java weniger gut.

Ich find' das eigentlich sehr gut.
Ich kann so lowlevel runter wie ich will und so highlevel wie ich will (indem ich einfach mehrere InputStream/Reader-Objekte in die Pipeline schmeisse), und das sehr komfortabel. Kann also den Stream byte-weise auslesen, mir noch einen Reader davor knallen, z.B. LineNumberReader (für komfortable ReadLine() Aufrufe), den auch noch puffern mit Buffered..., und das sowohl als Zeichenstreams und Binärstreams. Am Ende jage ich noch alles durch einen Tokenizer und schwupps.
Allerdings wirkt die IO API am Anfang ziemlich overbloated und man fühlt sich ziemlich erschlagen, das ging mir auch so.

[Real]

Hi gomberl,

gomberl schrieb:

ich würde Real nicht so abtun, er hat halt keine lust sich wo einzuarbeiten und hat sicher viele vorurteile die auch andere haben
aber wenn es nicht sein bier ist soll er halt mit C schreiben
wenns wirklich tief runtergehen soll empfehle ich assembler
da gehts dann rund

in der Schule bin ich in Java am weitesten, ich würde mich gerne weiter einarbeiten, aber ich bin etwas demotiviert! Ich kann zwar das Gelernte umsetzen, aber nur irgendwelche Klassen aufzurufen, das mir dies und das erledigt ist für einen Anfänger nicht das wahre, da ich gerne kapieren will was da vorsichgeht!

Ein anderer Grund, was mich demotiviert ist eben, dass Java nicht hardwarenah ist und man nicht richtig Systemprogrammierung praktzieren kann. Mit Aufrufen von externen Programmen und Anbindung fremder Programme die in anderen Sprachen implementiert wurden, kann man sich zwar etwas durchmogeln, aber dann ist auch schon der größte Lebenssin von Java futsch- die Plattformunahängigkeit (und die ist mir momentan soetwas von Wurst!).
Wenn ich Ansi-C(++) verwende und da es portabel ist, muss es nur noch in einem anderen Compiler des jeweiligen System schmeissen und alles geht, ohne das etwas meckert (ausser man proggt eben systemspezifisch oder hardwarenah).

Liebe Grüße
Real

[SirLant]

Ob man jetzt new schreibt oder malloc (in C), ist ja egal und du wirst in jedem
C++ Lehrbuch am Anfang zuerst einmal all das kennen lernen was C auch kann.
Nimm dir z.B. den C++ Primer der behandelt zuerst prozedurale Programmierung,
Objektbasierte Programmierung und erst zum Schluss Objektorientierte Programmierung.

[operator void]

Warum sollte ein gutes C++-Buch die C-IO-Funktionen erklären? Und irgendeine Möglichkeit für die Ein-/Ausgabe wird man als Anfänger schnell brauchen. Da kann man auch mit den IOStreams klein anfangen. Ob man nun printf oder cout benutzt ohne es zu verstehen, ist ja eigentlich kein Unterschied - nur, dass man mit cout weniger Fehler machen kann.

[Gast]

Shade schrieb:

Wozu? Java macht doch auch kein Copy-On-Write, wozu soll ich das also machen? Sind ja 2 verschiedene Sachen. Ich share einfach auch das Objekt:

shared_ptr<string> p(new string("hallo"));
shared_ptr<string> p2(p);

Is vielleicht nicht rübegekommen. Wenn du std::strings sharest, hast du wohl das Problem:

string a = "gduksfkszhdug"
string b = a;   // ANGENOMMEN, buffer würde geshared
a  +=  "öoisufg";  // oh SHIT, jetzt hab sich b auch geändert!

Das hast du doch bei nem shared_ptr auch?
Das könnte dann man mit copy-on-write lösen (wie gesagt). Ist aber IMHO immer noch nicht halb so elegant (das ist IMO ein ziemlicher Aufwand) wie immutable Strings.
Dazu kommt noch hinzu, dass mir das in Java gefällt:

"Mein String-Literal"  // Ist kein char*, kein char[] sondern ein String   :)
"Mein String-Literal".length  // funktioniert

Gut, das ist Spielerei, aber ich finde es schön. Vor allem, weil es nicht ineffizienter ist, da wird nichs konstruiert, ein String is ja nur ein Zeiger auf einen immutable Buffer. Wichtig ist es natürlich nicht, aber es gibt ja eigentlich auch keinen Grund, mit Pointern zu hantieren.

Übrigens: EOF ist AFAIK keine Exception, sondern das Ende wird mit einem negativem Wert angezeigt. Nur wenn du dann noch weiter liest, gibt's ne Exception. Bin mir jetzt nicht mehr 100% sicher, aber ich glaub das war so.

Was hast du dagegen, einen Reader oder Writer zu erstellen? Ein new Aufruf, und du musst nicht mal an ein delete denken.

// Muss jetzt so nicht korrekt sein:
BufferedReader a = new BufferedReader(new InputStream());

Wenn dich des "Buffered" stört, dann musst du ihn ja nicht buffern.

@Real: ja lol, du benutzt überall append(), wenn du da Strings hernimmst, müssen die erstmal in StringBuffer konvertiert werden. Du hast also nicht Strings mit StringBuffer verglichen. Wo ist denn jetzt genau das Problem, mehrere Strings nacheinander auszugeben?
Und wenn du sie unbedingt konkatenieren willst, dann mach das alles in einer Anweisung mit '+', dann legt die VM gleich einen großen StringBuffer an und haut blitzschnell alles rein.

[SirLant]

Ok die C Lib wird meist nicht wirklich behandelt, höchstens Teile davon, aber
für jeden fortgeschrittenen Anfänger sollte es kein Problem sein, sich anhand
einer Doku die Informationen holen die er benötigt um z.B. printf() zu benutzen.
Oft reicht auch bereits nur ein Blick auf die deklaration der Funktion.

[Gregor]

Real schrieb:

Ich kann zwar das Gelernte umsetzen, aber nur irgendwelche Klassen aufzurufen, das mir dies und das erledigt ist für einen Anfänger nicht das wahre, da ich gerne kapieren will was da vorsichgeht!

Wenn du wissen willst, was da vor sich geht, dann empfehle ich dir, ein Buch über Rechnerarchitektur usw. zu lesen. Da erfährst du mehr, als wenn du C lernst.

[Gregor]

gomberl schrieb:

JUHUUUUUUU

FLAMEWAR

EOF ist eine Exception?
Ich muss BufferedReader, Writer und sonstwas erstellen.
Also gerade IO gefällt mir in Java weniger gut.

das mit eof geb ich dir - das hatten wir schon mal an anderer stelle.

Ich habe es schon wieder vergessen, also könnte mir einer von euch mal erklären, was passieren sollte, wenn ich eine Datei mit 5 Bytes habe und 10 mal eine Methode "liesNächstesByte" aufrufe? Warum sollte in so einem Fall keine Exception ausgelöst werden? Vielleicht weil der Programmierer immer perfekt ist und solche offensichtlichen Fehler in der Realität garnicht vorkommen?!