C++ oder Java
-
Optimizer schrieb:
Objektorientierung schließt den Einsatz von Vererbung ein, das heißt natürlich nicht, dass alles von java.lang.Objekt abgeleitet sein muss.
Trotzdem ist Vererbung ein zentraler Bestandteil der Objektorientierung, ohne Vererbung spricht man von Objektbasierung.ist doch egal. mit c++ kann man objektorientiert, objektbasiert, prozedural, generisch, mit inline assembler oder sonstwie coden. mit 'n paar defines macht man basic oder pascal draus.
welche andere sprache hat so viele möglichkeiten?
-
Helium schrieb:
@otze: Ich gebe dir zwar recht, das die STL in einigen Aspekte sehr funktional (vom Paradigma her) ist, aber die Aussage "Der Kern der stl ist in einem rein funktionalen stil gehalten" halte ich für falsch.
hab die stelle wieder gefunden, wo ich die aussage her hab: boost::spirit::phoenix dokumentation ;), ich halte diese quelle doch schon für sehr glaubwürdig
-
HumeSikkins schrieb:
// geht nicht in Java class Foo<T> { public void foo(T aT) {aT.doSomething();} }
Ist zwar OT, aber...
Als naiver Java-Programmierer habe ich mich schon immer gefragt, warum Leute soetwas tun sollten, was du da in deinem Beispiel machst. Mir stellt sich da in erster Linie folgende Frage:
Wie ist aus der Schnittstelle erkenntlich, welche Anforderungen an den Typ T gestellt werden? Hier muss ja offensichtlich eine Methode "doSomething" vorhanden sein. Gibt es da wenigstens Hilfsmittel von den IDEs, die einen das erkennen lassen, oder muss man "mal zur Probe" kompilieren, um zu sehen, ob die Klasse Foo mit einem bestimmten Typ parametrisiert werden kann?
-
Gregor schrieb:
Gibt es da wenigstens Hilfsmittel von den IDEs, die einen das erkennen lassen, oder muss man "mal zur Probe" kompilieren, um zu sehen, ob die Klasse Foo mit einem bestimmten Typ parametrisiert werden kann?
Eine ordentliche Doku zur Klasse ist sicherlich das sinnvollste.
-
für sowas werden die dokumentationen geschrieben ;).
ansonsten gibts zur precompilezeit eigentlich keine möglichkeit das rauszubekommen.//edit groove war schneller
-
Eine Doku soll die Lösung sein?! ...naja, ich denk mir dann halt mal meinen Teil dazu.
...wird das wenigstens von Tools wie Doxygen automatisch in die Doku geschrieben, oder muss man alles per Hand machen?
-
net schrieb:
welche andere sprache hat so viele möglichkeiten?
Keine - zum Glück. :p
-
Ich glaube, ihr solltet die Diskussion jetzt besser beenden. Liesst sich schon
wie flame war. Und diese Diskussion muss doch nun echt nicht jede Woche neu
durchgekaut werden, oder?mfg
realisticer
-
Gregor schrieb:
HumeSikkins schrieb:
// geht nicht in Java class Foo<T> { public void foo(T aT) {aT.doSomething();} }
Als naiver Java-Programmierer habe ich mich schon immer gefragt, warum Leute soetwas tun sollten
Ich kann dir dazu nur den Tipp geben mal einen Blick über den Tellerrand zu wagen und anderen Paradigmen als OOP zu betrachten. Muss ja nicht in C++ sein. Wenn's auch C++ sein kann: wirf ein Blick in eine nahezu beliebige boost-Bibliothek. Oder schau dir eine C++ Bibliothek für Numerische Mathematik an. Überall wirst du die Anwendung dieser Technik finden. Generische Programmierung bzw. solche Idiome wie oben sind ja nur eine weitere Technik (nicht die Technik) mit der man ein Problem lösen kann.
Mir stellt sich da in erster Linie folgende Frage:
Wie ist aus der Schnittstelle erkenntlich, welche Anforderungen an den Typ T gestellt werden?
In C++ aus der Schnittstelle direkt überhaupt nicht. Das liegt daran, dass C++ was generische Programmierung angeht zwar einiges bietet, aber leider längst nicht alles was das Herz begehrt. Es fehlt derzeit z.B. ein einfacher Constraint-Mechanismus. Diesen muss man bisher selbst programmieren. D.h. man kann das Ganze in der Schnittstelle sichtbar machen, muss dies aber mit "ad hoc"-Mechanismen tun (siehe z.B. HP von Stroustrup)
Hier muss ja offensichtlich eine Methode "doSomething" vorhanden sein. Gibt es da wenigstens Hilfsmittel von den IDEs, die einen das erkennen lassen, oder muss man "mal zur Probe" kompilieren, um zu sehen, ob die Klasse Foo mit einem bestimmten Typ parametrisiert werden kann?
Kompilieren ist eine Möglichkeit. Das ist sozusagen der letzte Sicherheitszaun.
Eine andere sind Constraints. Die sind in C++ aber wie gesagt leider etwas umständlich zu formulieren, da kann man noch einiges verbessern. Prinzipiell ist das aber eine gute Technik um Anforderung an einen Typen T zu formulieren.Der Vorteil gegenüber Basisklassenschnittstelle ist z.B. dass du nicht die genaue Signatur festlegen musst. Außerdem ist das Ganze natürlich weniger komplex, sowohl was die Laufzeitkosten angeht (keine Indirektion über eine virtuelle Methode), als auch, was die Anzahl der nötigen Klassen betrifft (keine Einführung zusätzlicher abstrakter Klassen oder Kapselklassen für primitive Datentypen).
Auf der anderen Seite verlierst du natürlich Flexibilität (wobei man in diesem konkreten Fall natürlich T später auch mit einer Basisklasse instanziieren könnte)Eine Doku soll die Lösung sein?! ...naja, ich denk mir dann halt mal meinen Teil dazu.
Mach das. Aber urteile nicht zu schnell. Könnte dir einiges entgehen.
Zum Thema Doku:
Natürlich ist es immer schön, wenn man soviel wie möglich im Code direkt ausdrücken kann. Aber um eine Doku kommt man imo in keiner Sprache drum rum.
Die wenigsten Sprachen kennen Vor- und Nachbedingungen oder Klasseninvarianten, einige Sprachen arbeiten mit wesentlich weniger erzwungener const-correctness als z.B. C++, Exception-Spezifikationen gibt es in einigen Sprachen gar nicht in anderen sind sie ein "Maintenance-Nightmare" usw.
Was macht man, wenn man nicht alles direkt im Code ausdrücken kann? Man lagert bestimmte Informationen in die Doku aus. Ist eine natürliche Reaktion.
Genauso sieht es mit parametrsierbaren Klassen auch aus. Der Compiler kann zwar garantieren, dass dein T eine Methode foo hat, die Semantik musst du aber sowieso weiterhin in der Doku genauer festlegen. Die Doku einer
parametrisierbaren Klasse ist auch einer gute Ort um die Anforderungen an den Parametertyp zu spezifizieren.wird das wenigstens von Tools wie Doxygen automatisch in die Doku geschrieben
Wohl kaum. Dazu müssten solche Tools deine Gedanken lesen können. Bedenke: In C++ werden nur solche Templates instanziiert, die auch wirklich verwendet werden. Techniken wie SFINAE werden auch immer wieder gerne eingestzt.
Ein Tool kann also nicht so ohne weiteres ohne vollständigen Kontext automatisch erkennen, was genau gefordert ist. Der vollständige Kontext ergibt sich aber erst aus dem Clientcode.Ich glaube, ihr solltet die Diskussion jetzt besser beenden. Liesst sich schon wie flame war. Und diese Diskussion muss doch nun echt nicht jede Woche neu durchgekaut werden, oder?
Man könnte natürlich auch einfach mal versuchen das Ganze auf einer technischen Ebene zu betrachten statt sich immer gleich persönlich angepisst zu fühlen. Imo ist es unprofessionell, wenn man, nachdem man eine bestimmte Technologie erlernt hat, von da an völlig blind gegenüber anderen Dingen wird und jede Auseinandersetzung mit solchen anderen Dingen vermeidet.
Natürlich kann man jedes Thema in dem die Worte Java und C++ (Windows und Linux, Strukturelle und objektorientierte Programmierung, Golf GTI und Opel Manta) vorkommen gleich in ein billiges "mein X ist besser als dein Y" verkommen lassen, so wie das hier so gerne praktiziert wird, man kann aber auch einfach mal versuchen bestimmte Sachen rational zu untersuchen.
-
vorkommen gleich in ein billiges "mein X ist besser als dein Y" verkommen lassen, so wie das hier so gerne praktiziert wird, man kann aber auch einfach mal versuchen bestimmte Sachen rational zu untersuchen.
Da wird dir hier jeder Recht geben, allerdings muss es so einen Thread nicht jede Woche geben. Oft werden ja auch einfach mal irgendwelche Sachen reingeworfen, die nur halbwahr sind oder überhaupt nicht zum Thema gehört, und darüber wird dann stundenlang diskutiert. Und für einen Anfänger ist es eben dann auch schwer, da die richtigen und wichtig Infos rauszusaugen, stattdessen ist er hinterher verwirrter als vorher. Das kann ja auch nicht Sinn der Sache sein....
-
HumeSikkins schrieb:
Gregor schrieb:
HumeSikkins schrieb:
// geht nicht in Java class Foo<T> { public void foo(T aT) {aT.doSomething();} }
Als naiver Java-Programmierer habe ich mich schon immer gefragt, warum Leute soetwas tun sollten
Ich kann dir dazu nur den Tipp geben mal einen Blick über den Tellerrand zu wagen und anderen Paradigmen als OOP zu betrachten. Muss ja nicht in C++ sein. Wenn's auch C++ sein kann: wirf ein Blick in eine nahezu beliebige boost-Bibliothek. Oder schau dir eine C++ Bibliothek für Numerische Mathematik an. Überall wirst du die Anwendung dieser Technik finden. Generische Programmierung bzw. solche Idiome wie oben sind ja nur eine weitere Technik (nicht die Technik) mit der man ein Problem lösen kann.
Mir stellt sich da in erster Linie folgende Frage:
Wie ist aus der Schnittstelle erkenntlich, welche Anforderungen an den Typ T gestellt werden?
In C++ aus der Schnittstelle direkt überhaupt nicht. Das liegt daran, dass C++ was generische Programmierung angeht zwar einiges bietet, aber leider längst nicht alles was das Herz begehrt. Es fehlt derzeit z.B. ein einfacher Constraint-Mechanismus. Diesen muss man bisher selbst programmieren. D.h. man kann das Ganze in der Schnittstelle sichtbar machen, muss dies aber mit "ad hoc"-Mechanismen tun (siehe z.B. HP von Stroustrup)
Hier muss ja offensichtlich eine Methode "doSomething" vorhanden sein. Gibt es da wenigstens Hilfsmittel von den IDEs, die einen das erkennen lassen, oder muss man "mal zur Probe" kompilieren, um zu sehen, ob die Klasse Foo mit einem bestimmten Typ parametrisiert werden kann?
Kompilieren ist eine Möglichkeit. Das ist sozusagen der letzte Sicherheitszaun.
Eine andere sind Constraints. Die sind in C++ aber wie gesagt leider etwas umständlich zu formulieren, da kann man noch einiges verbessern. Prinzipiell ist das aber eine gute Technik um Anforderung an einen Typen T zu formulieren.Der Vorteil gegenüber Basisklassenschnittstelle ist z.B. dass du nicht die genaue Signatur festlegen musst. Außerdem ist das Ganze natürlich weniger komplex, sowohl was die Laufzeitkosten angeht (keine Indirektion über eine virtuelle Methode), als auch, was die Anzahl der nötigen Klassen betrifft (keine Einführung zusätzlicher abstrakter Klassen oder Kapselklassen für primitive Datentypen).
Auf der anderen Seite verlierst du natürlich Flexibilität (wobei man in diesem konkreten Fall natürlich T später auch mit einer Basisklasse instanziieren könnte)Eine Doku soll die Lösung sein?! ...naja, ich denk mir dann halt mal meinen Teil dazu.
Mach das. Aber urteile nicht zu schnell. Könnte dir einiges entgehen.
Zum Thema Doku:
Natürlich ist es immer schön, wenn man soviel wie möglich im Code direkt ausdrücken kann. Aber um eine Doku kommt man imo in keiner Sprache drum rum.
Die wenigsten Sprachen kennen Vor- und Nachbedingungen oder Klasseninvarianten, einige Sprachen arbeiten mit wesentlich weniger erzwungener const-correctness als z.B. C++, Exception-Spezifikationen gibt es in einigen Sprachen gar nicht in anderen sind sie ein "Maintenance-Nightmare" usw.
Was macht man, wenn man nicht alles direkt im Code ausdrücken kann? Man lagert bestimmte Informationen in die Doku aus. Ist eine natürliche Reaktion.
Genauso sieht es mit parametrsierbaren Klassen auch aus. Der Compiler kann zwar garantieren, dass dein T eine Methode foo hat, die Semantik musst du aber sowieso weiterhin in der Doku genauer festlegen. Die Doku einer
parametrisierbaren Klasse ist auch einer gute Ort um die Anforderungen an den Parametertyp zu spezifizieren.wird das wenigstens von Tools wie Doxygen automatisch in die Doku geschrieben
Wohl kaum. Dazu müssten solche Tools deine Gedanken lesen können. Bedenke: In C++ werden nur solche Templates instanziiert, die auch wirklich verwendet werden. Techniken wie SFINAE werden auch immer wieder gerne eingestzt.
Ein Tool kann also nicht so ohne weiteres ohne vollständigen Kontext automatisch erkennen, was genau gefordert ist. Der vollständige Kontext ergibt sich aber erst aus dem Clientcode.Ich glaube, ihr solltet die Diskussion jetzt besser beenden. Liesst sich schon wie flame war. Und diese Diskussion muss doch nun echt nicht jede Woche neu durchgekaut werden, oder?
Man könnte natürlich auch einfach mal versuchen das Ganze auf einer technischen Ebene zu betrachten statt sich immer gleich persönlich angepisst zu fühlen. Imo ist es unprofessionell, wenn man, nachdem man eine bestimmte Technologie erlernt hat, von da an völlig blind gegenüber anderen Dingen wird und jede Auseinandersetzung mit solchen anderen Dingen vermeidet.
Natürlich kann man jedes Thema in dem die Worte Java und C++ (Windows und Linux, Strukturelle und objektorientierte Programmierung, Golf GTI und Opel Manta) vorkommen gleich in ein billiges "mein X ist besser als dein Y" verkommen lassen, so wie das hier so gerne praktiziert wird, man kann aber auch einfach mal versuchen bestimmte Sachen rational zu untersuchen.süß wie viel mühe er sich gibt. nur leider total sinnlos
-
Man könnte natürlich auch einfach mal versuchen das Ganze auf einer technischen Ebene zu betrachten statt sich immer gleich persönlich angepisst zu fühlen. Imo ist es unprofessionell, wenn man, nachdem man eine bestimmte Technologie erlernt hat, von da an völlig blind gegenüber anderen Dingen wird und jede Auseinandersetzung mit solchen anderen Dingen vermeidet.
Natürlich kann man jedes Thema in dem die Worte Java und C++ (Windows und Linux, Strukturelle und objektorientierte Programmierung, Golf GTI und Opel Manta) vorkommen gleich in ein billiges "mein X ist besser als dein Y" verkommen lassen, so wie das hier so gerne praktiziert wird, man kann aber auch einfach mal versuchen bestimmte Sachen rational zu untersuchen.Ja, definitiv. Nur muss man sich bei manchen Threads diese Posts rauspicken. Ich
lese gerne in diesen Threads die guten Posts, da ich viel zu wenig Ahnung von
diesen Dingen (C++ und Java sowieso). Aber langsam beginnt es wirklich zu nerven,
dass man in so einem Thread nach guten Posts, wie deiner oder Gregors (um mal euch
beiden jetzt zu nennen, ist ja nicht auf euch begrenzt), zu suchen. Irgendwer
muss immer seinen Senf auf flame-weise hier praesentieren. Klar reg ich mich
unnoetig darueber auf und mit diesem Posting hier mache ich wahrscheinlich
nichts anderes, aber ich werde dazu lieber wieder den Mund halten und mir meins
alleine denken, so wie ich es eigentlich zu tun flege.Es ist schade, dass in solchen Threads Postings wie deiner oder Gregors
untergehen!mfg
v R
-
virtuell Realisticer schrieb:
Man könnte natürlich auch einfach mal versuchen das Ganze auf einer technischen Ebene zu betrachten statt sich immer gleich persönlich angepisst zu fühlen. Imo ist es unprofessionell, wenn man, nachdem man eine bestimmte Technologie erlernt hat, von da an völlig blind gegenüber anderen Dingen wird und jede Auseinandersetzung mit solchen anderen Dingen vermeidet.
Natürlich kann man jedes Thema in dem die Worte Java und C++ (Windows und Linux, Strukturelle und objektorientierte Programmierung, Golf GTI und Opel Manta) vorkommen gleich in ein billiges "mein X ist besser als dein Y" verkommen lassen, so wie das hier so gerne praktiziert wird, man kann aber auch einfach mal versuchen bestimmte Sachen rational zu untersuchen.Ja, definitiv. Nur muss man sich bei manchen Threads diese Posts rauspicken. Ich
lese gerne in diesen Threads die guten Posts, da ich viel zu wenig Ahnung von
diesen Dingen (C++ und Java sowieso). Aber langsam beginnt es wirklich zu nerven,
dass man in so einem Thread nach guten Posts, wie deiner oder Gregors (um mal euch
beiden jetzt zu nennen, ist ja nicht auf euch begrenzt), zu suchen. Irgendwer
muss immer seinen Senf auf flame-weise hier praesentieren. Klar reg ich mich
unnoetig darueber auf und mit diesem Posting hier mache ich wahrscheinlich
nichts anderes, aber ich werde dazu lieber wieder den Mund halten und mir meins
alleine denken, so wie ich es eigentlich zu tun flege.Es ist schade, dass in solchen Threads Postings wie deiner oder Gregors
untergehen!mfg
v Rmir kommen die tränen. lol