3. C++ oder Java

C++ oder Java

  • N

    Ponto schrieb:

    Templates werden jedoch nicht ohne Grund als Mittel für compile-time Polymorphie bezeichnet. Wenn man also Polymorphie schon beim Kompilieren anwenden kann, kann man zur Laufzeit verzichten.

    cool, dann ist 'c' ja auch ein bisschen objektorientierung. #define, #ifdef etc. ist ja wohl auch compile-time polymorph 😉

    0
  • O

    moin ihr, vielelicht lasst ihr mich auch an eurem flamewar teilhaben 😉

    ich kann jetzt über java nicht allzuviel sagen(will ich auch garnicht ;)), aber zur stl kann ich mich äußern:

    die stl ist objektbasiert, aber auch nur als mittel zum zweck.
    Der Kern der stl ist in einem rein funktionalen stil gehalten(sogut wie alle verändernden stl algorithmen basieren auf funktoren um nur ein beispiel zu nennen), wohingegen die Schale rein generisch ist. Die objekte dienen sozusagen nur dazu, um sinneinheiten zusammenzuhalten. Auch vererbung kann man in der stl finden, als beispiele nenn ich mal die streams, oder die functoren die von unary/binary_function abgeleitet sind. Im endeffekt kann ich nur sagen, dass die stl ein paradebeispiel für den coding style von C++ ist(von den variablennamen mal abgesehen...),halt von allem etwas, funktionale programmierung, oop, generics, und das alles gut durchgerührt.

    Aber das ist nur meine interpretation des aufbaus, sicher werdet ihr mich jetzt in grund und boden flame

    //edit dummes forum-.-

    0
  • J

    Willst Du Deinen Postingzähler hochtreiben? 😉

    Die STL ist nicht funktional programmiert. Bitte schlag irgendwo nach was funktionale Programmierung ist.

    0
  • O

    hab ich, und dabei bin ich unter anderem auf diese aussage gestoßen(hab ja auch mal im rund um die programmeirung nach ner genauen definition gefragt, viel rumgekommen ist dabei aber auch nicht :D)

    0
  • I

    Ein Thread mit den Wörtern "Java" und "C++" im Titel und erst 4 Seiten?? 🕶

    0
  • C

    Wieso erst? Ich dachte, er würde nach Seite 1 geschlossen. Aber zumindest kann man hier jeden Mist reinschreiben und es wird kommentiert. Ist doch auch was.

    0
  • V

    Respekt, als ich es letzte mal geschaut hab, da war der Thread noch eine Seite
    lang. Unglaublich, wie schnell sich das bei den zwei Streitwoertern aendert :).

    Wollt ich auch mal gesagt haben, es sich immer nur zu denken ist langweilig.

    mfg
    v R

    0
  • H

    Auf Vererbung wird in der C++ std-lib größtenteils verzichtet und das macht Objektorientierung nun mal aus.

    Ach. Und wenn irgendwo nicht vererbt wird ist es definitiv nicht oo? Quatsch.

    @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.

    0
  • ?

    Und wenn irgendwo nicht vererbt wird ist es definitiv nicht oo?

    Das ist jetzt auch ziemlich überspitzt wiedergegeben. So in der Form habe ich das nie gesagt.

    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.
    Und das trifft IMHO auf die stdlib, insbesondere auf den STL-Teil größtenteils zu (dass ohne Vererbung gearbeitet wird).

    0
  • N

    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?

    0
  • O

    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 😃

    0
  • G

    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?

    0
  • G

    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.

    0
  • O

    für sowas werden die dokumentationen geschrieben ;).
    ansonsten gibts zur precompilezeit eigentlich keine möglichkeit das rauszubekommen.

    //edit groove war schneller 😃

    0
  • G

    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?

    0
  • I

    net schrieb:

    welche andere sprache hat so viele möglichkeiten?

    Keine - zum Glück. :p

    0
  • V

    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

    0
  • H

    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.

    0
  • C

    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....

    0
  • ?

    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

    0
Anmelden zum Antworten