Kritik zu Code

ZockerFloh7

tschuldigung, fehlpost, kann gelöscht werden...

cooky451

1. Sollte man doch mal kurz schreiben was der Code eigentlich machen soll, wenn man sich sinnvolle Kritik erhofft.
2. Ist dir hoffentlich klar, dass das kein Standard-C++ ist? Das was du da nutzt ist eine Microsoft Erweiterung von C++.

C++ Forumbot

Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x und C++11) in das Forum C++/CLI mit .NET verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

krümelkacker

Eine kleine Zwischenfrage, wenn mir das erlaubt ist:

ZockerFloh7 schrieb:

TMT2Hex::TMT2Hex()
{
	tmtFileAccess = gcnew TMTFileAccess();
	line = 0;
	counter = 0;
	errormessage = "";
	readTMTfileheader = true;
}

TMT2Hex::~TMT2Hex()
{
	tmtFileAccess->~TMTFileAccess();
}

Macht man das so in C++/CLI, dass man den Destruktor einer "ref-class" direkt aufruft? Und wenn ja, gibt's für sowas nicht schon schnuckelige Schlau-Zeiger, die so etwas automatisch machen? Z.B. ein "unique_handle" oder sowas ...

ZockerFloh7

ka, bin anfänger^^

mein ausbilder hat gemeint dass ihm des so lieber ist, aber eig. wird der destruktor ja automatisch aufgerufen oder?

Martiniclan

ZockerFloh7 schrieb:

Hey, würd mich freuen wenn sich jemand diesen Code anschauen könnte und mir Tips gibt was ich besser machen kann

In Bezug auf was?

Optik
Design / Funktionatlität

Hätte ich den Code geschrieben, sähe er anders aus!
Hätte ich das Problem lösen wollen, sähe es anders aus!

Deswegen bin ich ich und Du Du.

Willst Du wissen, ob es gut ist?

Es ist gut, wenn niemand fragen muss "was macht das denn?" und der Code fehlerfrei funktioniert.

Ciao MM

krümelkacker

ZockerFloh7 schrieb:

ka, bin anfänger^^

Das richtete sich auch eher an die restlichen C++/CLI Profis. Ich habe von CLI keine Ahnung. Ich kann nur C++. Und in C++ ruft man (typischerweise) Destruktoren nicht direkt selbst auf, "weil pfui".

ZockerFloh7 schrieb:

mein ausbilder hat gemeint dass ihm des so lieber ist,

also mir wär das egal, was ihm lieb ist oder nicht. Ich würd's halt nur "richtig" machen wollen. Lass dir das von ihm nochmal erklären, warum das, was ihm lieb ist, eine gute Idee sei.

ZockerFloh7 schrieb:

aber eig. wird der destruktor ja automatisch aufgerufen oder?

K.A.. Ich habe noch nicht verstanden, wie man GC (garbage collection) "vernünftig" mit Destruktoren verheiraten kann. Solltest du mal selbst nachrecherchieren und/oder auf eine Antwort einer schlauen Person warten, die C++/CLI beherrscht.

ZockerFloh7

krümelkacker schrieb:

ZockerFloh7 schrieb:

ka, bin anfänger^^

Das richtete sich auch eher an die restlichen C++/CLI Profis. Ich habe von CLI keine Ahnung. Ich kann nur C++. Und in C++ ruft man (typischerweise) Destruktoren nicht direkt selbst auf, "weil pfui".

ZockerFloh7 schrieb:

mein ausbilder hat gemeint dass ihm des so lieber ist,

also mir wär das egal, was ihm lieb ist oder nicht. Ich würd's halt nur "richtig" machen wollen. Lass dir das von ihm nochmal erklären, warum das, was ihm lieb ist, eine gute Idee sei.

ZockerFloh7 schrieb:

aber eig. wird der destruktor ja automatisch aufgerufen oder?

K.A.. Ich habe noch nicht verstanden, wie man GC (garbage collection) "vernünftig" mit Destruktoren verheiraten kann. Solltest du mal selbst nachrecherchieren und/oder auf eine Antwort einer schlauen Person warten, die C++/CLI beherrscht.

thx krümelkacker, ich werd ihn mal fragen

Jochen Kalmbach

Vergiss in C++/CLI bitte die Destruktoren.
Als Regekl soltle gelten: Implementier das "IDisposable" pattern. Dies wird in C++/CLi schon automatisch angelegt, wenn Du einen "Destrktor" definiert.
beachte auch, dass ein C++/CLI-Destruktor *kein* C++-Destruktor ist.

In C++/CLI gibt es *keine* Destruktoren... es sieht von der Syntax her nur so aus.

Es gibt ein "Dispose" und ein "Finalize". Der Finalizer (RefClass::!RefClass) darf man *nur* für unmanaged Dinge verwenden und darin *nie* Managed Objekte referenzieren! Das führt sonst zu Abstürzen oder Objec-Resurrection!

Siehe auch:
http://weblogs.thinktecture.com/cnagel/2006/04/ccli-finalize-and-dispose.html

krümelkacker

Jochen Kalmbach schrieb:

Vergiss in C++/CLI bitte die Destruktoren.

Den Satz finde ich ganz schön missverständlich. Die einzige Assoziation bei dem Wort "Destruktoren" -- zumindest bei mir -- ist die "~Klasse"-Syntax. Aber du willst ja bestimmt nicht sagen, dass diese Syntax und das, wofür sie in C++/CLI steht, nicht benutzt werden soll; denn dann wär das ja ein Widerspruch zum Rest deines Beitrags inklusive des von dir verlinkten Artikels.

Bashar

krümelkacker schrieb:

Macht man das so in C++/CLI, dass man den Destruktor einer "ref-class" direkt aufruft?

Man nutzt eigentlich delete.

Jochen Kalmbach

krümelkacker schrieb:

Jochen Kalmbach schrieb:

Vergiss in C++/CLI bitte die Destruktoren.

Den Satz finde ich ganz schön missverständlich. Die einzige Assoziation bei dem Wort "Destruktoren" -- zumindest bei mir -- ist die "~Klasse"-Syntax. Aber du willst ja bestimmt nicht sagen, dass diese Syntax und das, wofür sie in C++/CLI steht, nicht benutzt werden soll; denn dann wär das ja ein Widerspruch zum Rest deines Beitrags inklusive des von dir verlinkten Artikels.

Ich meine: In C++/CLI gibt es keine Destruktoren; und deswegen sollte man diesen Begriff in C++(CLI vergessen.
Es gibt nur:
Dispose: ~RefClass; aufruf durch "delete instance"
Finalizer: !RefClass; aufruf automatisch durch den Finalizer-Thread; sollte im Dispose verhindert werden durch "GC::SupressFinalize(this)"

theta

Hier noch eine alte Zusammenfassung bezüglich ~, !, etc., inkl. C# Syntax:
http://www.c-plusplus.net/forum/242975-10?highlight=finalize

krümelkacker

Jochen Kalmbach schrieb:

Ich meine: In C++/CLI gibt es keine Destruktoren; und deswegen sollte man diesen Begriff in C++(CLI vergessen.
Es gibt nur:
Dispose: ~RefClass; aufruf durch "delete instance"
Finalizer: !RefClass; aufruf automatisch durch den Finalizer-Thread; sollte im Dispose verhindert werden durch "GC::SupressFinalize(this)"

Naja, das ist doch aber auch ... sagen wir mal ... "ungenau". ~RefClass ist nicht die Dispose-Funktion und !RefClass ist nicht der Finalizer. Diese ~/!-Funktionen werden aber irgendwie indirekt von Dispose bzw dem Finalizer aus aufgerufen, wobei GC::SuppressFinalize(this) irgendwo im Dispose auch schon ausgeführt wird. Wenn ich das also richtig verstanden habe, niommt einem der C++/CLI Compiler schon ein Standard "Dispose/Finalize-Pattern" ab, wo auch eine virtuelle Dispose(bool disposing)-Funktion eine Rolle spielt (die von Dispose bzw dem Finalizer mit true bzw false aufgerufen wird). Und von dort aus wird dann entweder ~RefClass oder !RefClass aufgerufen.

Mal zusammenfassend: Aus

ref class Foo
{
public:
  ~Foo() { bla; !Foo(); }
protected:
  !Foo() { blupp; }
};

wird "intern" so etwas wie (pseudo code)

ref class Foo : public IDispose
{
public:
  ~Foo() { bla; !Foo(); }

  void Dispose()
  {
    Dispose(true);
    GC::SuppressFinalizer(this);
  }

protected:
  !Foo() { blupp; }

  virtual void Dispose(bool disposing)
  {
    if (disposing) ~Foo();
    else           !Foo();
  }

protected: // nur für den GC
  void Finalize()
  {
    Dispose(false);
  }
};

Und wenn man von Foo ableitet

ref class Bar : public Foo
{
public:
  ~Bar() { bla; !Bar(); }
protected:
  !Bar() { blupp; }
}

dann wird daraus "intern" (pseudo)

ref class Bar : public Foo
{
public:
  ~Bar() { bla; !Bar(); }
protected:
  !Bar() { blupp; }

  override void Dispose(bool disposing)
  {
    if (disposing) ~Bar();
    else           !Bar();
    Foo::Dispose(disposing);
  }
}

wobei ~RefClass für die Freigabe von allen Resourcen (managed und unmanaged) und !RefClass nur für die Freigabe von managed Resourcen ist, weswegen hier sinnigerweise ~RefClass auch !RefClass aufruft.

Habe ich das jetzt endlich mal richtig komplett verstanden?

Jochen Kalmbach

Ja, da wird intern einiges gemacht... ich finde das nicht sehr toll, da man hier sehr leicht den Überblick verliert und nicht mehr selber versteht, was eigentlich passiert... sowas sollte bei einer Programmiersprache eigentlich nicht geben.... in C# ist das "einfacher" (obwohl man da mehr von "Hand" machen muss).

Man kann sich den Code immer noch mit dotPeek anschauen, damit man sieht, was wirklich passiert