Lieber Besucher, herzlich willkommen bei: MastersForum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »myabba|abra« (25.05.2008, 14:24)
Zitat
Original von myabba|abra
hat leider nichts gebracht
inzwischen hab ichs so hinbekommen:
statt sizeof strlen verwenden.... total blöder fehler
und: keine direkte zuweisung, sondern strcpy
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »GWC_Vegeta« (25.05.2008, 19:16)
Zitat
Original von fast_tam
ich bin mir nicht 100% sicher, aber wenn szText ein Attribut der Klasse ist, wieso möchtest du es im Destruktor explizit löschen? Wird die Klasse zerstört, sollte doch das Attribut automatisch zerstört werden. Muss man das in C++ Explizit im Destruktor erledigen?
Quellcode |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
class AnyProperty { int a; // aufm stack (löschen sich automatisch) int b; // aufm stack (löschen sich automatisch) } class Foo { Foo() { mustDeleteMe = new AnyProperty(); //auf dem heap } ~Foo() { delete mustDeleteMe; } /* bei initialisierung des Objektes Foo ist der Pointer auf 'mustDeleteMe' undefiniert, geschieht erst mit den new aufruf im konstruktor. Vorher zeigt der wirklich ins nirvana (also nichtmal NULL), sondern dahin, was halt im speicher an der adresse grad so rum stand*/ AnyProperty* mustDeleteMe; /* wird sofort bei erzeugen der klasse mit standard-konstruktor erzeugt, und löscht sich auch brav wieder, wenn objekt deletet wird*/ AnyProperty deletesItSelf; } |
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »myabba|abra« (26.05.2008, 12:26)
Zitat
Original von kOa_Borgg
Hat beides seine Vor und Nachteile. Java ist "sicher" bei der Programmierung. Keine Frage. Dafür aber elendig lahm.
Zitat
Und außerdem kann man bei c/c++ mal eben schnell Quick and dirty nen Zeiger hin und her biegen, wofür man bei Java erstmal riesen Kapriolen schlagen muss damit man "mal schnell" daten irgendwo anders hin bekommt.
Zitat
Java is auch nich das Gelbe vom Ei.
Einige Dinge sind so extrem unständlich und unelegent gelöst, das is nimmer feierlich...
Zitat
Original von fast_tam
"Quick&Dirty" ist nichts was in meinen Augen ein Vorteil wäre..
Zitat
Original von kOa_Borgg
Wenn man mal nur schnell was testen will schon. Den aufwendigen "sauberen" weg kann man, wenn man weiß, dass es geht immernoch implementieren. Nur bei java muss man für jeden pups ein riesiges Prumborium machen.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »kOa_Borgg« (28.05.2008, 12:42)
Zitat
Original von kOa_Borgg
Das mag sein. nur wenn es am Ende schnell laufen soll, muss ich es ja eh wieder in c machen. Von daher nützt mir das auch nix.
Zitat
Außerdem: die meisten mathe-libs ( MKL, ACML=amd math core ibrary) sind imho nur für c und fortran verfügbar. Oder bin ich da nicht auf dem neuesten Stand? Muss ich nachher gleich mal googlen.
Zitat
Original von kOa_Borgg
Die rechenintensiven Dinge geschehen dann eh meist auf dem Server oder dem DB Backend. Und das wird wohl seltenst in Java implementiert sein
Zitat
Original von kOa_Borgg
Hm interessant. Dann frag ich mich aber schon warum das sich in Uni-Kreisen noch nicht rum gesprochen hat.
Zitat
Original von kOa_Borgg
Ich komme aus der Bildverarbeitungs / Bildanalyse Ecke. So wie das in RealTime geht, wird es immer Geschwindigkeitskritisch.
Zitat
Original von kOa_Borgg
Ich lese da immer nur c/c++. Der neueste Schrei sind dann die Implementierungen auf der Grafikkarte (die ja massiv parallelisieren). Ob das noch mit c/c++ gemacht wird weiß ich garnicht. Aber mit Java etc hab ich da noch keinen hantieren sehen.
Zitat
Original von fast_tam
C/C++ ist aufgrund der fehlenden Threads IMHO eine nicht so gute Wahl für massiv parallelisierte Berechnungen.... und die GPU ist nur darin wirklich gut. Ich weiß, es gibt Bibliotheken dafür. Es ist aber kein First-Class Sprachfeature.