Ersatz für finally

[Simon2]

Undertaker schrieb:

...
besser so:
...

Ich glaube, Du hast nicht verstanden, worauf Shade hinauswollte.....
Hast Du eigentlich eine Forumstrigger auf den Begriff "Java" ?

Gruß,

Simon2.

[Undertaker]

Simon2 schrieb:

Ich glaube, Du hast nicht verstanden, worauf Shade hinauswollte.....

mit geschweiften klammern die 'reichweite' des locks andeuten, oder nicht?

Simon2 schrieb:

Hast Du eigentlich eine Forumstrigger auf den Begriff "Java" ?

wo ist hier java?

[Simon2]

Undertaker schrieb:

...
mit geschweiften klammern die 'reichweite' des locks andeuten, oder nicht?
...

Naja, aber Dein Code wurde (mit dieser Intention) doch bereits im 2. Posting von CStoll gepostet... deswegen vermutete ich, Du wolltest noch ein wenig mehr/anderes.

Undertaker schrieb:

...
wo ist hier java?

5 Posts über Deinem ersten:

Konrad Rudolph schrieb:

...
Hach, wieso auch der Vergleich mit Java?...

(mal ganz abgesehen davon, dass das letzte Wort aus dem Threadtitel wohl dieser Sprachen entnommen worden sein dürfte)

Gruß,

Simon2.

[Undertaker]

Simon2 schrieb:

Undertaker schrieb:

...
mit geschweiften klammern die 'reichweite' des locks andeuten, oder nicht?
...

Naja, aber Dein Code wurde (mit dieser Intention) doch bereits im 2. Posting von CStoll gepostet... deswegen vermutete ich, Du wolltest noch ein wenig mehr/anderes.

nö, das war nur als antwort auf dein posting gedacht. was auf der vorherigen seite stand, hab' ich gar nicht gelesen...

Undertaker schrieb:

...
wo ist hier java?

...

Simon2 schrieb:

(mal ganz abgesehen davon, dass das letzte Wort aus dem Threadtitel wohl dieser Sprachen entnommen worden sein dürfte)

ich dachte bei 'finally' mehr an diese microsoft extensions __try, __except, __finally, weniger an Java.
--> http://msdn2.microsoft.com/en-us/library/s58ftw19(VS.71).aspx

[Simon2]

Ach so.

Undertaker schrieb:

..
ich dachte bei 'finally' mehr an diese microsoft extensions __try, __except, __finally, weniger an Java.
--> http://msdn2.microsoft.com/en-us/library/s58ftw19(VS.71).aspx

Ist ja auch naheliegender !!
(Da Du allerdings nicht für das Verfassen des Threadtitels verantwortlich bist, ist nicht ganz ausschlaggebend - und von mir auch nicht gemeint - , was Du damit assoziierst).

Gruß,

Simon2.

[Artchi]

Dann hätte man auch __finaly schreiben müssen. War aber nirgends zu sehen.

[Undertaker]

Artchi schrieb:

Dann hätte man auch __finaly schreiben müssen.

muss man nicht. das delphi-zeugs Try/Except/Finally ist fast das selbe wie der m$-kram und wird wahrscheinlich eine 1:1 umsetzung sein, um das windows-eingebaute SEH zu nutzen (z.b. so fiese sachen wie division durch 0 abzufangen)...

[BerndD]

Konrad Rudolph schrieb:

.. Ist aber alles irrelevant, der Unterschied ist, dass das eine eben durch ein Sprachkonstrukt gegeben ist und daher jede weitere Diskussion um den Zweck entfällt, während das andere eben eine Konvention (bzw. ein Idiom ist) und damit unter die von Bernd genannte Kritik fällt.

Genau das ist auch mein Standpunkt.

Simon2 schrieb:

BerndD schrieb:

...
Ohne es zu wollen sprichst du gleich die zwei Hauptgründe an, warum es schwerer zu lesen ist als ein try/finally. ...

Und Du glaubst nicht, dass es sich hier eher um "persönliche Präferenzen" handelt ?

Nein, weil es in meiner Argumentation nicht darum ging welche Sprache die bessere ist. Solche Diskussionen halte ich für Sinnfrei. Daher auch der Hinweis mit den "Glaubenskrieg".
Hätte ich die Wahl zwischen try/finally oder RAII würde ich mich sicher für RAII entscheiden. Mir wäre aber trotzdem bewusst, das mein Quelltext für Personen, die das Idiom nicht kennen, schwerer zu lesen wäre. Daher auch der begeisterte Ausruf: "Elegant und schwer lesbar. Eine echte C++ Lösung!"

Simon2 schrieb:

Irgendwie erinnert mich das an Diskussionen aus meinem Studium: ...

Ein schönes Beispiel. Es deckt sich auch mit meinen Erfahrungen. Nur wenige Menschen haben es geschafft den hohen Abstraktionsgrad zu erreichen, den du als Physiker erreicht hast. Nur mit diesem kannst du über die formale Sprache "Formel" kommunizieren. Alle anderen sind ausgesperrt. Es würde mir aber keine Sorgen bereiten von einen Chirurgen operiert zu werden, der die Maxwellsche Gleichung nicht anwenden kann. Mehr Sorge ich mich, des es Menschen gibt die zwar einen hohen Grad an Erkenntnis erlagt haben, es aber nicht mehr Schaffen dieses Wissen in ein interdisziplinäre Anwendergruppe einzubringen, weil sie nicht mehr allgemein verständlich kommunizieren können (Bitte das jetzt nicht auf dich beziehen).

...Ist für mich komplett wertfrei - und definitiv nicht zu klären, wer jetzt "Recht" hat.

Das wollen wir doch auch nicht klären! Wir schauen von verschiedenen Standpunkten auf die selbe Sache. Und ich habe ein "Schwätzchen" darüber gemacht, was ich von meinem Standpunkt aus sehe. Ich hoffe es war nicht zu langweilig für euch.

Gruß,
Bernd

[Konrad Rudolph]

BerndD schrieb:

Und ich habe ein "Schwätzchen" darüber gemacht, was ich von meinem Standpunkt aus sehe. Ich hoffe es war nicht zu langweilig für euch.

Nö, auf keinen Fall. Ich finde diese Diskussionen generell bereichernd, weil man sich dadurch häufig zum ersten Mal über gewisse Sachverhalte Gedanken macht und diese hinterfragt.

[Simon2]

BerndD schrieb:

...

Simon2 schrieb:

BerndD schrieb:

...
Ohne es zu wollen sprichst du gleich die zwei Hauptgründe an, warum es schwerer zu lesen ist als ein try/finally. ...

Und Du glaubst nicht, dass es sich hier eher um "persönliche Präferenzen" handelt ?

Nein, weil es in meiner Argumentation nicht darum ging welche Sprache die bessere ist. ...

Da das Argument gar nichts mit dem zu tun hat, was ich sagen wollte, liegt hier wohl ein Missverständnis vor. Meine Aussage war: "Deine Einschätzung 'ist schwerer zu lesen als' ist IMO zu stark mit persönlichen Präferenzen verknüpft als dass man sie in der Allgemeinheit stehen lassen kann. Und das liegt gar nicht mal am Thema ("finally/RAI"), sondern an der Kategorie "lesbar" ..."

BerndD schrieb:

...
Mehr Sorge ich mich, des es Menschen gibt die zwar einen hohen Grad an Erkenntnis erlagt haben, es aber nicht mehr Schaffen dieses Wissen in ein interdisziplinäre Anwendergruppe einzubringen, weil sie nicht mehr allgemein verständlich kommunizieren können (Bitte das jetzt nicht auf dich beziehen). ...

Das ist einfach das übliche Problem menschlicher Kommunikation: Man steckt in seinem eigenen Kopf und kann sich nur bruchstückhaft in den Anderen hineinversetzen ... einige mehr, andere weniger. Und das gilt "für beide Seiten": Wer etwas als selbstverständlich lesbar empfindet, kann nicht verstehen, dass jemand anderes (ohne "dümmer" zu sein) das nicht tut ... und auch wer etwas "natürlich" total unlesbar empfindet, tut sich mit der Vorstellung schwer, dass Andere das ebenso "natürlich" lesbar finden (ohne "abgefahrene Freaks" zu sein).

BerndD schrieb:

...Ist für mich komplett wertfrei - und definitiv nicht zu klären, wer jetzt "Recht" hat.

Das wollen wir doch auch nicht klären!

Wieder ein Missverständnis: Ich habe das nicht erwähnt, um Dich damit zu belehren/korrigieren/... , sondern nur, damit Du meine vorherigen Thesen gerade NICHT missverstehst (als wertend) - was ich damit geschickt ad absurdum geführt habe.

Gruß,

Simon2.

[Dravere]

BerndD schrieb:

Konrad Rudolph schrieb:

BerndD schrieb:

Elegant und schwer lesbar.

Nicht schwer lesbar sondern ein Idiom, das man sich aneignen muss. Wenn man RAII verstanden hat, ist diese Lösung sehr verständlich und leuchtet auf den ersten Blick ein.

Ich meinte weniger "Schwer lesbar, weil nicht Wissen wie es funktioniert", sondern "Schwer lesbar, weil Implementationsabhängig".
Die Zeile

CAqqLock lock(cs);

könnte auch ein vergessene lokale Variable sein oder ein Makro oder sonstwas. Natürlich lässt sich das schnell klären. Das Problem ist nur, wenn es nicht der eigene Quelltext ist, wird es unzählige Stellen geben die "nur mal schnell abzuklären" sind.

Als ich das las, dachte ich im ersten Moment: "hmmm, hat er wohl recht. Vor allem, wenn man verschiedene Locks benötigt. Das sind immer wieder neue Klassen und man muss womöglich immer wieder schnell nachschauen was das ist".

Aber hatte dann eine kleine Idee und sie umgesetzt. Ich staune selber, dass es funktioniert ^^

#include <iostream>
#include "conio.h"

template<class C>
class CLock
{
	C& m_Class;
	void (C::*m_funcConstruct)();
	void (C::*m_funcDestruct)();

public:
	CLock(C& Class, void (C::*funcConstruct)(), void (C::*funcDestruct)()) 
		: m_Class(Class)
		, m_funcConstruct(funcConstruct)
		, m_funcDestruct(funcDestruct)
	{
		if(m_funcConstruct) (m_Class.*m_funcConstruct)();
	}

	~CLock()
	{
		if(m_funcDestruct) (m_Class.*m_funcDestruct)();
	}
};

// Testen ob es funktioner:

class CTest
{
public:
	void start() { std::cout << "Start" << std::endl; };
	void end() { std::cout << "End" << std::endl; };
};

int main()
{
	{
		CTest t;
		CLock<CTest> Lock(t, &CTest::start, &CTest::end);

		_getch();
	}

	_getch();

    return 0;
}

Daher, du siehst diese Klasse einmal und weisst immer was sie macht. Kommt doch beinahe an das finally heran, eine Formel? Dafür hat man den Spass es selber zu machen *g*

Grüssli

PS: Die Klasse ist sicherlich noch Verbesserungswürdig, ist nur so "schnell" dahingeklatscht

[Konrad Rudolph]

Dravere schrieb:

Aber hatte dann eine kleine Idee und sie umgesetzt. Ich staune selber, dass es funktioniert ^^
*snip*

Dieses Idiom (bzw. Muster) trägt sogar einen Namen, habe vergessen, welchen aber ich glaube, es war „delegated responsibility“.

[Jester]

Und wem die Syntax nicht eindeutig genug ist, der kann sich ja noch ein Makro definieren, das einen präziseren Namen trägt.

[BerndD]

Templates und dann vielleicht noch Makros darüberlegen, hat man da überhaupt noch die geringste Chance sich mit den Debugger durch den Quelltext steppen zu können?

Ich würde allzu gerne mal in einen Team von C++ Programmierern ein komplexeres Programm entwanzen. Entweder ich würde dabei ganz neue Dinge lernen oder ich würde danach "Templates? Nein, Danke!" sagen.

[ghorst]

debugging von template-klassen macht spaß...
naja. man kann mit jeder menge unittests vorher dafür sorgen, dass die hinterher kein mist machen. dann noch ein paar nett eingestreute asserts, dann klappt das schon.
ansonsten besteht bei den meisten debugger auch nicht wirklich ein problem, durch templates im quelltext zu steppen. natürlich nur in der tatsächlichen nutzung.