Am Montag, den 14.05.2007, 16:47 +0200 schrieb Jan Rakelmann:
Ich sollte man das Mailprogramm wechseln, Evolution schickt beim Antworten die Mails nicht an die Liste. Entschuldigung.
Am Montag, den 14.05.2007, 16:09 +0200 schrieb Frank Gerlach:
Frank,
Noch ein Hinweis aus der Praxis: Bei Funktionsdeklarationen besser Zeiger statt Referenzen benutzen, denn damit wird beim Aufruf der Funktion/Methode sofort deutlich dass mit der uebergebenen Variable was gemacht wird(bzw gemacht werden kann). (und nicht nur ein Input-Parameter ist)
und wenn es jetzt noch ein C/C++-Gegenstück zu Fortran95's ASSOCIATED(POINTER [,TARGET]) gibt könnte ich mich auch noch mit dem Gespann anfreunden. ,-)
Die RRZN-Referenz sagt: ASSOCIATED(POINTER [,TARGET]), generische Funktion ASSOCIATED ist eine generische Abfragefunktion, die anzeigt, ob der gegebene Zeiger POINTER aktuell einem Zeigerziel zugeordnet ist oder ob der gegebene Zeiger dem vorgegebenen Zeigerziel TARGET zugeordnet ist. Der Parameter POINTER ist ein Zeiger beliebigen Typs; sein Zeigerzuordnungsstatus darf nicht undefiniert sein. Der optionale Parameter TARGET muß ein Zeiger oder ein Zeigerziel sein und den glelichen Datentyp, Typparameter und Rang und ggf. die gleiche Zeichendatenlänge wie POINTER haben.
Wenn man sowas in seine Programmen nutzt, ist die Gefahr von dangling pointer und Speicherlöchern ziemlich gering. Also erst abfragen und dann den Zeiger verbiegen.
Jan
Am Montag, den 14.05.2007, 17:08 +0200 schrieb Jan Rakelmann:
Am Montag, den 14.05.2007, 16:47 +0200 schrieb Jan Rakelmann:
Ich sollte man das Mailprogramm wechseln, Evolution schickt beim Antworten die Mails nicht an die Liste. Entschuldigung.
Da gibt es ein nettes Plugin "Mailinglisten-Aktionen" und das Tastaturkürzel: CTRL+L. Diese Liste setzt aber eigentlich das Reply-To an die Listenadresse automatisch.
Betreff angepasst.
MfG Daniel
On Monday 14 May 2007, Jan Rakelmann wrote:
und wenn es jetzt noch ein C/C++-Gegenstück zu Fortran95's ASSOCIATED(POINTER [,TARGET]) gibt könnte ich mich auch noch mit dem Gespann anfreunden. ,-)
#define ASSOCIATED(ptr) (ptr) != 0 #define ASSOCIATED(ptr,target) (ptr) == &(target)
Hab's nicht getestet, aber sollte so funktionieren:
int myint=1; int *myptr=&myint; if(ASSOCIATED(myptr)){ //do something }
if(ASSOCIATED(myptr,myint)){ //hooray! myptr points to myint! }
Ich verstehe zwar nicht was an den Originalausdrücken so kompliziert ist, dass man sie unbedingt in ASSOCIATED kapseln muss, aber ok.
So ist es richtiges C++:
if(myptr != 0) {...} if(myptr == &myint) {...}
der erste geht sogar noch kürzer:
if(myptr) {...}
Konrad
Am Montag, den 14.05.2007, 18:14 +0200 schrieb Konrad Rosenbaum:
Konrad,
Ich verstehe zwar nicht was an den Originalausdrücken so kompliziert ist, dass man sie unbedingt in ASSOCIATED kapseln muss, aber ok.
ich muss jetzt erstmal über deine Lösung etwas nachdenken. Sowas hab ich mir auch schonmal gestrickt. Richtig toll find ich das aber nicht wenn sich jeder eine eigene Lösung bastelt. Irgendwie gehört sowas schon in den Sprachstandard.
Jan
On Mon, May 14, 2007 at 06:14:18PM +0200, Konrad Rosenbaum wrote:
On Monday 14 May 2007, Jan Rakelmann wrote:
Hi Konrad,
und wenn es jetzt noch ein C/C++-Gegenstück zu Fortran95's ASSOCIATED(POINTER [,TARGET]) gibt könnte ich mich auch noch mit dem Gespann anfreunden. ,-)
#define ASSOCIATED(ptr) (ptr) != 0 #define ASSOCIATED(ptr,target) (ptr) == &(target)
Hab's nicht getestet, aber sollte so funktionieren:
Ich verstehe zwar nicht was an den Originalausdrücken so kompliziert ist, dass man sie unbedingt in ASSOCIATED kapseln muss, aber ok.
Ich nehme an das Fortran im Gegensatz zu C++ intern eine Liste der initialisierten Pointer hält (und diese Updated wenn ein Objekt gelöscht wird) und ASSOCIATED wirklich nachprüft ob der Pointer noch gültig ist.
So etwas wirst du in C++ trotz aller Template/Macro Magie nicht hinbekommen. Qt hat mit QPointer da zwar einen ganz netten Ansatz und STL bietet auch etwas ähnliches, aber ein solches Feature muss in der Laufzeitumgebung verangert sein, nicht auf der Sprache aufgesetzt.
Ciao, Tobias
On Mon, May 14, 2007 at 07:34:35PM +0200, Jan Rakelmann wrote:
Am Montag, den 14.05.2007, 18:43 +0200 schrieb Tobias Koenig:
Tobias,
Hi,
STL bietet auch etwas ähnliches,
kannst du mir genauer sagen wo ich suchen muss?
gg boost
Ciao, Tobias
Tobias Koenig schrieb:
Ich nehme an das Fortran im Gegensatz zu C++ intern eine Liste der initialisierten Pointer hält (und diese Updated wenn ein Objekt gelöscht wird) und ASSOCIATED wirklich nachprüft ob der Pointer noch gültig ist.
Nein tut es nicht. Der Fortran95-Code:
integer,pointer :: a,b allocate(a) b => a a = 77 if (associated(b)) print *,'b=',b deallocate(a) !(*) if (associated(a)) print *,'a=',a if (associated(b)) print *,'b=',b end
Wird dir entweder eine Zahl ausgeben, oder einen Speicherzugriffsfehler produzieren. Das hängt davon ab, ob die Laufzeitbibliothek bei (*) entscheidet den Speicher dem System zurückzugeben oder noch andere Bereiche im verwendeten Block liegen.
Auch bei Fortran kann es deshalb passieren, dass ein Programm nach einer Änderung wegen eines Speicherzugriffsfehlers an einer völlig anderen Stelle abschmiert.
Am Dienstag, den 15.05.2007, 09:58 +0200 schrieb Tobias Schlemmer:
Tobias,
Wird dir entweder eine Zahl ausgeben, oder einen Speicherzugriffsfehler produzieren.
Dein Code erzeugt: b = 77 b = 0 <- und hier sollte ich eigentlich stutzig werden, ok dies ist ein Negativbeispiel
als Ausgabe auf Standard-Etch x86_64.
Sinn und Zweck dieser Funktion ist nachwievor vor Speicherlöchern zu schützen, das Problem dabei ist allerdings immernoch 50 cm vor dem Monitor sitzend.
Ich habe mir oft in den Fuß geschoßen und viel Zeit bei Fehlersuche verbracht, also bin ich froh daß mir F95 sowas bietet.
Das hängt davon ab, ob die Laufzeitbibliothek bei (*) entscheidet den Speicher dem System zurückzugeben oder noch andere Bereiche im verwendeten Block liegen.
Auch bei Fortran kann es deshalb passieren, dass ein Programm nach einer Änderung wegen eines Speicherzugriffsfehlers an einer völlig anderen Stelle abschmiert.
Lug-dd maillist - Lug-dd@mailman.schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
Hallo,
Jan Rakelmann schrieb:
Wird dir entweder eine Zahl ausgeben, oder einen Speicherzugriffsfehler produzieren.
Dein Code erzeugt: b = 77 b = 0 <- und hier sollte ich eigentlich stutzig werden, ok dies ist ein Negativbeispiel
als Ausgabe auf Standard-Etch x86_64.
Halt gfortran, vermute ich. 4.2 und 4.3 von gestern machen das auch so.
Sinn und Zweck dieser Funktion ist nachwievor vor Speicherlöchern zu schützen, das Problem dabei ist allerdings immernoch 50 cm vor dem Monitor sitzend.
Ich habe mir oft in den Fuß geschoßen und viel Zeit bei Fehlersuche verbracht, also bin ich froh daß mir F95 sowas bietet.
Was die Demonstration zeigt: associated(x) macht nichts anderes, als in C/C++ x==0, bzw. associated(x,y) ist tatsächlich nichts anderes als Fall a) y ist ein Zeiger: x == y Fall b) y ist kein Zeiger x == &y
Was aber schon mal praktisch ist: deallocate(x) setzt x auch gleich auf den Nullpointer.
Tobias.
Am Dienstag, den 15.05.2007, 14:52 +0200 schrieb Tobias Schlemmer:
Hallo,
Halt gfortran, vermute ich.
Na was halt in Etch als Standardkompiler festgelegt wurde, 4.1.irgendwas.
Was die Demonstration zeigt:
Was in Fortran geht weis ich, schließlich wurde ich reichlich gequält. Meine Frage war nach einer allgemeingültigen Funktion in C/C++! Nicht selbstgesticktes.
associated(x) macht nichts anderes, als in C/C++ x==0, bzw. associated(x,y) ist tatsächlich nichts anderes als Fall a) y ist ein Zeiger: x == y Fall b) y ist kein Zeiger x == &y
Und sowas will ich als allgemeingültige Funktion in irgendeiner Standardbibliothek. Mensch, die C/C++-Leute sind doch auch nicht doof! ;-)
Jan
BTW: GCC 4.2 ist raus
Jan Rakelmann schrieb:
associated(x) macht nichts anderes, als in C/C++ x==0, bzw. associated(x,y) ist tatsächlich nichts anderes als Fall a) y ist ein Zeiger: x == y Fall b) y ist kein Zeiger x == &y
Und sowas will ich als allgemeingültige Funktion in irgendeiner Standardbibliothek. Mensch, die C/C++-Leute sind doch auch nicht doof! ;-)
Wenn überhaupt, dann gehört sowas nicht in eine Bibliothek, sondern in den Sprachumfang.
Viele Grüße, Eric
Konrad Rosenbaum schrieb:
if(myptr != 0) {...} if(myptr == &myint) {...}
der erste geht sogar noch kürzer:
if(myptr) {...}
Semantisch korrekt aber es drückt nicht aus was Du meinst.
Einen Fall kann man bei Pointern in C und C++ aber nicht trivial abfangen:
void f1(A *a) { if (a != 0) { //oops } a->TuWas(42); }
void f2() { A *a = new A(); f1(a); // ok delete a; f1(a); // vomit }
Viele Grüße, Eric
On Monday 14 May 2007 19:51:15 Eric-Alexander Schaefer wrote:
Semantisch korrekt aber es drückt nicht aus was Du meinst.
Einen Fall kann man bei Pointern in C und C++ aber nicht trivial abfangen:
[...baumelnde Zeiger...]
Es gibt ein paar Workarounds: * Der Pointer selbst wird zu einem Objekt gemacht. Unter Qt gibt es beispielsweise die Klasse QGuardedPtr, deren Instanzen beim Löschen auf 0 gesetzt werden. * Die (De-)Allokierung wird speziell gehandhabt. Also etwa so:
template <class T> T* newclass() { T *ret = new T; // ret registrieren return ret; }
Wenn man das nun als "operator new" irgendwo einsetzt, hat man eine Übersicht über alle Objekte (std::map reicht aus) und kann ASSOCIATED damit implementieren. Unter C ist das durchaus etwas üblicher (malloc-Wrapper mit Debug-Informationen zu fehlerhaften free()-Aufrufen), aber unter C++ ist es auch möglich. * Boost hat bestimmt auch noch was :-)
Aber es sind halt alles nur Workarounds, der direkte Speicherzugriff verlangt seinen Tribut.
Josef
Am Dienstag, den 15.05.2007, 08:25 +0200 schrieb Josef Spillner:
Josef,
- Boost hat bestimmt auch noch was :-)
Boost ist sehr schön, und die smart-pointer gefallen mir gut. Aber wenn ich mir hier die Diskussion so ansehe werde ich wohl mal in die Dokumentation von Valgrind und Mpatrol abtauchen müssen.
Jan
lug-dd@mailman.schlittermann.de
-
Daniel Leidert -
Eric-Alexander Schaefer -
Jan Rakelmann -
Josef Spillner -
Konrad Rosenbaum -
Tobias Koenig -
Tobias Schlemmer