Sie sind nicht angemeldet.

  • Anmelden

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.

myabba|abra

Erleuchteter

  • »myabba|abra« ist der Autor dieses Themas

Beiträge: 4 305

Wohnort: Regensburg

Beruf: GER

  • Nachricht senden

1

25.05.2008, 13:33

kleine c++ Hilfe

Beim beenden des Programms bekomm ich eine Fehlermeldung. Irgendwo mach ich Quatsch mitm Heap.

Geht um eine Klasse Textbox, das Problem hängt mit diesen zwei Methoden zusammen:

****************

void Textbox::SetText(char *Text){
int size = sizeof(Text);
if (szText != 0)
delete[] szText;
szText = new char[size];
szText = Text;
};


Textbox::~Textbox(){
delete [] szText;
};


*******************

Das Problem tritt ich auch auf, wenn ich statt size einen fixen Wert nehme.
Nicht aber, wenn ich den Destruktor auskommentiere...

achja, szText ist ein Attribut der Klasse..

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »myabba|abra« (25.05.2008, 14:24)


2

25.05.2008, 14:55

Versuchs mal mit if-Abfrage im Destruktor.
Also wie oben
if (szText != 0)
delete[] szText;

Wenn der Zeiger nicht gesetzt wurde und du willst löschen dann geht das verständlicherweise nicht.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »GWC_Vegeta« (25.05.2008, 15:10)


myabba|abra

Erleuchteter

  • »myabba|abra« ist der Autor dieses Themas

Beiträge: 4 305

Wohnort: Regensburg

Beruf: GER

  • Nachricht senden

3

25.05.2008, 15:19

hat leider nichts gebracht :(

inzwischen hab ichs so hinbekommen:
statt sizeof strlen verwenden.... total blöder fehler
und: keine direkte zuweisung, sondern strcpy

4

25.05.2008, 15:26

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?

Da ich Java-Verseucht bin kenne ich mich mit diesem lowlevel Kram allerdings nicht allzu gut aus =)

5

25.05.2008, 19:11

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


Natürlich, daß geht so garnicht, ich habs aber auch nicht bemerkt
sizeof gibt dir ja nicht die größe des arrays zurück sondern die anzahl der bytes .
(oder irre ich mich da? Jedenfalls würde dann folgendes Sinn ergeben)
Wenn du daß allerdings noch durch die byteanzahl teilst, die ein element benötigt kommste auf die richtige länge.

sizeof(array) / sizeof(array[0])

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »GWC_Vegeta« (25.05.2008, 19:16)


6

26.05.2008, 10:21

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?

Kommt ganz darauf an ob es auf dem Stack oder auf dem Heap erzeugt wurde.

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;
}

myabba|abra

Erleuchteter

  • »myabba|abra« ist der Autor dieses Themas

Beiträge: 4 305

Wohnort: Regensburg

Beruf: GER

  • Nachricht senden

7

26.05.2008, 12:25

ja
und ich musste für szText eine tiefe Kopie anlegen (mit strcpy und new), weil der vorherige Pointer Text nur im Stack war.
War die Methode SetText also beendet, war Text weg und szText zeigte irgendwohin

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »myabba|abra« (26.05.2008, 12:26)


8

26.05.2008, 13:19

charpointer kannst du eh nicht mit '=' kopieren. Das geht NUR über strcpy. Du kopierst sonst nur dir Adresse, welche ein simpler int wert ist.

9

27.05.2008, 13:34

jetzt weiß ich wieder warum ich bei Java hängen geblieben bin ... ;)

10

27.05.2008, 14:28

Hat beides seine Vor und Nachteile. Java ist "sicher" bei der Programmierung. Keine Frage. Dafür aber elendig lahm.

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.

11

27.05.2008, 14:36

Java is auch nich das Gelbe vom Ei.

Einige Dinge sind so extrem unständlich und unelegent gelöst, das is nimmer feierlich...


Ich mache gerade berufsbedingt mit Python rum, das macht echt spass:)

kann hier mal die wxWidgets empfehlen, benutze wxPython für grafische Oberflächen, einfach nur super

Jetzt muss ich aber eine Anwendung von PyQT3 auf PyQt4 protieren, unter windows, das wird vielleicht ne Arbeit... :(


Aber trotzdem: Software entwickeln macht spass :)

12

27.05.2008, 15:38

Qt3->Qt4 ist die pest. Mein Beileid.

Und ja, entwickeln macht spaß :)

13

27.05.2008, 16:16

ich versuche gerade PyQt3Support zu üebersetzen, ich bete dass ich das schaffe und hoffe inständig, dass dann alles läuft, ohne was umschreiben zu müssen.

Weil in der Anwendung wird kräftig gemalt und gezeichnet und ausgewählt und das komplette zugrundeliegende System wurde geändert.

Drückt mir die Daumen ^^

14

27.05.2008, 16:31

Also ich hab damals meinen ganzen alten code über bord geworfen und von grundauf qt4 neu entwickelt. Aber diesen Luxus kann sich nicht jeder leisten. Dieser Schnitt den die da gemacht haben war echt grausam.

Diese support lib hab ich gänzlich ignoriert. Maybe ist das jetzt besser geworden, aber am Anfang wo qt4 neu war, war es eine Katastrophe.

15

27.05.2008, 20:00

Zitat

Original von kOa_Borgg
Hat beides seine Vor und Nachteile. Java ist "sicher" bei der Programmierung. Keine Frage. Dafür aber elendig lahm.


ich möchte hier auf keinen fall eine diskussion lostreten (hab ich das schon? ^^)...
aber die aussage das java lahm wäre wird nicht wahr nur weil sie immer und immer wieder durchgekaut wird. im gegenteil: durch den just-in-time compiler kann der maschinencode während der laufzeit weiter optimiert werden und schlägt statische compilate teilweise sogar.

als regel gilt: um so länger die laufzeit einer applikation, umso mehr kann optimiert werden, umso stärker ist java in sachen performance. daher ist java zB. gerade bei serveranwendungen sehr beliebt.

und mit .NET kann Java es alle mal aufnehmen... :evil:

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.


"Quick&Dirty" ist nichts was in meinen Augen ein Vorteil wäre..

Zitat


Java is auch nich das Gelbe vom Ei.
Einige Dinge sind so extrem unständlich und unelegent gelöst, das is nimmer feierlich...


DIE Programmiersprache gibt es sowieso nicht. Aber dank dem Bean Scripting Framework ist es sehr einfach geworden Domänenspezifische Sprachen zu integrieren... Bei meinem aktuellen Projekt (ein mittelgroßes Informationssystem) benutze ich das zB. um eine Regelmaschine zu implementieren... Regeln können in JavaScript, Ruby oder Groovy gescriptet werden. Damit lassen sich Teile der Applikation welche Änderungen unterworfen sind in einer dieser Sprachen realisieren -> man hat das Beste aus mehreren Welten. Stichwort: Fluid Kernel.

Durch die Möglichkeit mehrere Sprachen auf der JVM laufen zu lassen hat die Plattform IMHO wahnsinnig an Flexibilität gewonnen.

Vor nicht allzu langer Zeit war Java sowohl die Sprache als auch die VM. Mittlerweile laufen auf der VM mehrere Sprachen, einige sind Scala, Groovy, JRuby, JPython, JavaScript, ....

so, genug des Lobes. Wofür Java wirklich absolut nicht geeignet ist sind systemnahe Geschichten. Ein weiterer Nachteil ist die extrem hohe Lernkurve aufgrund der vielen Bibliotheken und Standards. Hat man sich aber einmal durchgekämpft und einen Überblick bekommen, so bewegt man sich in einem extrem umfangreichen Ecosystem welches an Flexibilität und Mächtigkeit seines gleichen sucht.

16

27.05.2008, 23:34

Zitat

Original von fast_tam
"Quick&Dirty" ist nichts was in meinen Augen ein Vorteil wäre..

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.

17

28.05.2008, 01:13

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.


Die Frage ist halt welche Anforderungen man hat ;)
Ich bin eigentlich der meinung mit C/C++ braucht man um einiges länger als mit Java... Aber ich denke auch man ist immer mit der Sprache am schnellsten mit der man tagtäglich zu tun hat.

Zum prototypen eignet sich aber IMHO sowieso Smalltalk am besten 8)
Nicht so dicht gefolgt von Groovy / Ruby und Scala.

18

28.05.2008, 10:16

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.

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.

19

28.05.2008, 12:22

doppel-post

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »GWC_Vegeta« (28.05.2008, 12:23)


20

28.05.2008, 12:23

welche mathelib für c++ könntest du mir empfehlen?

Inversenberechnung und co selber proggn nimmt erfahrungsgemäß arg zeit in anspruch^^

21

28.05.2008, 12:37

Also ich nutze derzeit die it++ library

Diese benötigt wiederum eine Implementierung von BLAS und LAPACK.
Davon gibts viele Implementierungen ich nutze hierfür die ACML

Was ich auch Empfehlen kann ist Numerical Recipes. Da sind viele nette sachen drin.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »kOa_Borgg« (28.05.2008, 12:42)


22

28.05.2008, 12:41

doppel

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »kOa_Borgg« (28.05.2008, 12:42)


23

28.05.2008, 12:52

ok

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »GWC_Vegeta« (28.05.2008, 12:55)


24

29.05.2008, 19:58

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.


schon wieder diese falsche behauptung mit der geschwindigkeit ;)
Nochmals: Java ist in vielen Bereichen schneller als C(++)
Aber dieses alte Märchen wird sich noch lange halten - es kommt übrigens aus einer Zeit in welcher Java noch interpretiert wurde... fast ein Jahrzehnt ist das her...

-> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
-> http://www.javaworld.com/jw-02-1998/jw-02-jperf.html (sehr ausführlich, und sehr interessant)
-> http://java.sys-con.com/read/45250.htm
-> http://www.kano.net/javabench/
(schlechte quelle, aber trotzdem:
-> http://en.wikipedia.org/wiki/Comparison_…C++#Performance
)

man bedenke auch das die meisten dieser artikel ein bisschen angestaubt sind - die letzten paar jahre sind derartige vergleiche sinnlos geworden. niemand behauptet mehr ernsthaft das virtuelle maschinen langsam sind...

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.


da bin ich ein bisschen überfragt... wissenschaftliches zeug interessiert mich nicht.
kann auch nicht beurteilen ob das hier irgendwie vergleichbar ist:
-> http://mathlib.sourceforge.net/
-> http://math.nist.gov/javanumerics/
-> http://commons.apache.org/math/

25

30.05.2008, 09:12

Tam, es muss aber schon einen Grund geben, warum alle, die wirklich rechenintensive Dinge tun in c/c++ und Fortran implementieren oder? Sicher, wenn du nur Oberflächen zusammen clickst und ein paar DB's anbindest ist das völlig egal. Die rechenintensiven Dinge geschehen dann eh meist auf dem Server oder dem DB Backend. Und das wird wohl seltenst in Java implementiert sein ;)

26

30.05.2008, 13:55

für die Leute die Mathe und Physikklassen brauchen: Ich kann da root von root.cern.ch sehr empfehlen. Ist ordentlich dokumentiert und gerade wenn man mit relativistischen 4-er Vektoren rechnen muss sehr bequem.

27

30.05.2008, 15:45

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 ;)


Hier liegst du falsch - genau auf dem Server ist Java am stärksten vertreten. Es hat ja sicher einen Grund wieso alle großen Application Server in Java implementiert sind:
IBM WebSphere, BEA WebLogic, Oracle AS, JBoss, auch Apple's WebObjects ist Java. Glassfish und SUN Java System AS lasse ich aussen vor... da von SUN ;)

SAP NetWeaver ist Java oder ABAP.. aber es geht afaik in Richtung Java.

Wenn du dir das Finanzumfeld ansiehst, so findest du mittlerweile neben den "historischen" Systemen eigentlich ausschließlich Java. Guck mal dein Onlinebanking genau an... selbst das Frontend dürfte in Struts implementiert sein =) Und ich glaube hier wird sehr viel gerechnet...

Das ist alles Java Enterprise ( JavaEE und EJBs ). Für verteile Hochverfügbarkeitsanwendungen hat man auch nicht sehr viel Auswahl abseits von Java.... C/C++ fällt hier komplett raus.

[edit:]
guck mal hier womit boing so rechnet:
-> http://www.netbeans.org/community/articl…s-platform.html
oder Nokia:
-> http://www.netbeans.org/community/articles/nokia-netact.html

28

01.06.2008, 14:12

Hm interessant. Dann frag ich mich aber schon warum das sich in Uni-Kreisen noch nicht rum gesprochen hat. Ich komme aus der Bildverarbeitungs / Bildanalyse Ecke. So wie das in RealTime geht, wird es immer Geschwindigkeitskritisch. 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.

29

01.06.2008, 15:37

Zitat

Original von kOa_Borgg
Hm interessant. Dann frag ich mich aber schon warum das sich in Uni-Kreisen noch nicht rum gesprochen hat.


Was man als Student lernt ist in der freien Wirtschaft doch sowieso nur sehr beschränkt einsetzbar. Ich hatte neulich erst einen Studenten - der konnte hochkomplizierte Algorithmen implementieren, aber bei den simpelsten Aufgaben welche weniger mathematisch waren hat er einen Murks zusammengeschustert das alles zu spät war...

Allerdings kenne ich auch einige welche neben dem Studium schon ihre Firma aufbauen.. kann man also wohl nicht verallgemeinern. Diese sind dann in der Regel aber nicht auf dem Arbeitsmarkt verfügbar.

Zitat

Original von kOa_Borgg
Ich komme aus der Bildverarbeitungs / Bildanalyse Ecke. So wie das in RealTime geht, wird es immer Geschwindigkeitskritisch.


Ich kenne eine Firma welche ihre Bildverarbeitungssoftware damals auf Turbo Pascal aufgebaut hat :-)

Aber das nur am Rande... Bildverarbeitung ist wirklich nicht die große Stärke von Java und performance müsste man einfach mal vergleichen - ich habe dafür allerdings zu wenig Plan von der Materie.
-> http://rsb.info.nih.gov/ij/

Was RealTime angeht... wird das in der Bildverarbeitung wirklich benötigt?
Ich kenne RealTime möglichkeiten in ADA und Java. In C/C++ braucht man hierfür doch wieder einen Umweg über ein RTOS wie QNX oder RTLinux...

-> http://java.sun.com/javase/technologies/realtime/
-> http://www.embedded.com/columns/technica…equestid=442880
-> http://javolution.org/

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.


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.

Für Java gibt es Überlegungen die JVM durch eine evtl. vorhandene GPU zu beschleunigen. Das würde dann ohne Änderung am Code _allen_ Java-Anwendungen zu gute kommen. Es passt nicht in die Philosophie von Java Berechnungen manuell auszulagern und zu steuern. Ich starte einen Thread - auf welcher CPU er dann abläuft entscheidet die Java Virtual Machine. Hier könnte dann bei bestimmten Aufgaben zusätzlich die GPU ins Spiel kommen.

Die derzeitigen Ansätze laufen ja eher über Bibliotheken der Grafikkartenhersteller. Ich glaube nicht das sich das durchsetzen wird... (Ich möchte meine Anwendung ungern an einen Hardwarehersteller koppeln...).
Dann gibt es noch die Möglichkeit über OpenGL - hier ist die eingesetzte Sprache dann ziemlich egal.

30

01.06.2008, 16:05

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.


Eine Bibliothek einzubinden sollte wohl kein prob sein ;)