C++ Community

DSD-Steve

the real depp schrieb:

c.rackwitz: er scheint selbst ein Troll zu sein.

lol... Das ist der gößte schwachsinn den ich seid langen höre! rakwitz hat richtigwas drauf!

DSD-Steve schrieb:

the real depp schrieb:

c.rackwitz: er scheint selbst ein Troll zu sein.

lol... Das ist der gößte schwachsinn den ich seid langen höre! rakwitz hat richtigwas drauf!

du hast mich falsch verstanden. ich meinte alex89ru ist ein troll.

alex89ru

An volkard:
Soweit ich weiß ist C++ (ein wenig wenn auch nicht viel) langsamer , wegen OOP.
(Vorrausgesetzt man verwendet OOP,man kann auch C++ nicht objektorientiert proggen).
Und außerdem ist OOP ressourcenfressender.

ps_ selber troll

alex89ru schrieb:

An volkard:
Soweit ich weiß ist C++ (ein wenig wenn auch nicht viel) langsamer , wegen OOP.
(Vorrausgesetzt man verwendet OOP,man kann auch C++ nicht objektorientiert proggen).
Und außerdem ist OOP ressourcenfressender.

ps_ selber troll

depp

SideWinder

Ich glaube kaum, dass du im Assembler-Code noch etwas von OOP findest...im besten Fall kannst du dich hier auf die in C nicht vorhandenen virtuellen Funktionsaufrufe rausreden...

MfG SideWinder

groovemaster

alex89ru schrieb:

Soweit ich weiß ist C++ (ein wenig wenn auch nicht viel) langsamer , wegen OOP.

Tja, dann weisst du jetzt, dass dein Wissen fehlerhaft ist. Sprachen sind nicht schneller oder langsamer, lediglich Implementierungen. Und sofern du keine ausgefallenen Sachen in C++ verwendest, wie zB RTTI, wirst du keinen Unterschied merken, da C++ Compiler mittlerweile richtig gut sind.

alex89ru schrieb:

(Vorrausgesetzt man verwendet OOP,man kann auch C++ nicht objektorientiert proggen).

Was glaubst du, macht ein Compiler denn hier:

// C
foo_bar(foo);
// C++
foo.bar();

Richtig, wenn er will, kann er daraus identischen Code machen.

alex89ru schrieb:

Und außerdem ist OOP ressourcenfressender.

Ebenfalls Unsinn. Der Punkt ist einfach der, dass C einige Sachen nicht beinhaltet, die in C++ zusätzlich Ressourcen benötigen, wie zB virtuelle Funktionen oder Templates, die für unterschiedliche Argumente auch unterschiedlich instanziert werden. Letztendlich würde sowas in C aber genauso viel Ressourcen verbrauchen.

--linuxuser--

c und c++ sind die besten sprache die es gibt wo waeren wir heute ohne sie???

in einer von ms dominierten VISCHL PESIC aera?? das szenario will sich wohl keiner ausmahlen oder??

SideWinder

MfG SideWinder

--linuxuser-- schrieb:

c und c++ sind die besten sprache die es gibt wo waeren wir heute ohne sie???

in einer von ms dominierten VISCHL PESIC aera?? das szenario will sich wohl keiner ausmahlen oder??

CarstenJ

Also ich den Titel gelesen habe, wusste ich ungefähr wie der Thread verlaufen wird. Aber meine Erwartungen wurden übertroffen. Danke Jungs.

flodur24

Ich programmiere auch in c und c++, aber ich würde nie sagen, dass eine sprache besser als die andere ist. Villeicht leistungsfähiger und schneller, aber doch nicht besser.

PS: Villeicht vergleicht mal ein mod die ip von 9 und alex89ru ? Er war nämlich so angetan.
PPS: Nachdem sich alle Smilies bekämpft haben, ist nurnoch meiner übrig geblieben. -closen-

alex89ru

Also moment mal...
Ich wollte nicht sagen , dass C++ schlecht (oder schlechter als C) ist!!!
Ich mag beide Sprachen(gleich)!
SO! Eigentlich wollte ich nur den/die 9 etwas anstressen , da er/sie etwas voreingenommen gegenüber C ist/war!!!!!!!
(Manche C++ Programmierer sind gegenüber C aus irgendeinem Grund voreingenommen:
Sie meinen zB dass man am statt #define NUR const verwenden sollte , da #define schlecht sei , oder so...dieser Ansicht bin ich nicht)

Naja , ich hätte auch nicht gedacht , dass iese thread solche ausmaßen annimmt!!!
Und falls meine Aussage , dass C++ lahmer als C wirklich falsch ist , dann möchte ich mich hiermit entschuldigen...hab's auch nur so irgendwo gehört

Und noch was: Nein alex89ru != 9
else{SchweineKoennenFliegen = true;}

volkard

alex89ru schrieb:

Sie meinen zB dass man am statt #define NUR const verwenden sollte , da #define schlecht sei , oder so...dieser Ansicht bin ich nicht)

diene meinung ist nicht schlimm, solange du bereits bist, sie abzulegen.

aber das ist ein unbedeutendes detail und macht c++ nicht aus. gäbe es kein const in c++, würde man inlinefunktionen dafür nehmen (machmal auch enum und machmal sogar #define).

alex89ru

Ich habe NICHT gesagt , dass man kein const verwenden sollte.
const ist gut/wichtig!
Bloß: Wenn jemand versucht irgendwelche (Sprach-)Elemente aus C++ zu verbannen , die in C vorhanden waren und durch neuere in C++ "ersetzt" wurden,dann kotz dass mich an.

(Gut: #define ist zwar nur eine (Preprozessor-)Direktive und kein Sprachelement aber egal...ich benutz des trotzdem gern)

Ich meine:

#define IRGENDWAS 123

ist einfacher als

const int IRGENDWAS 123;

OK...zugegeben: beides ist nicht wirklich schwer tu tippen

...und was ich über das "const" geschrieben habe , war nicht auf OOP bezogen ,sondern auf das obrige Beispiel...
OK?

CStoll

#define IST schlecht, aber deswegen gibt es trotzdem Situationen, in denen man nicht drumherum kommt^*. Vor allem schert sich eine #define "Konstante" überhaupt nicht um irgendwelche Sichtbarkeitsgrenzen (eben weil sie vom Präprozessor verarbeitet wird).

^* Versuch' z.B. mal einen Include-Guard ohne Präprozessort zu bauen

alex89ru

Paradebeispiel!
äham , ja:
Wie du schon sagtest: man kommt in manchen Situationen nicht um #define rum.
Und was ist wenn man die Sichtbarkeitsgrenzen (absichtlich) umgehen will, oder was ist mit den schönen #define Makros???Oder dein Beispiel mit "#include-guard"...naja...
...super! schon 3 Seiten...dieser Thread wächst wie WASWEIßICH

CStoll

Und was ist wenn man die Sichtbarkeitsgrenzen (absichtlich) umgehen will

Dafür kann man auch const (auf globaler Ebene) verwenden - hat sogar den Vorteil, daß der Compiler verständliche Fehlermeldungen ausspuckt

oder was ist mit den schönen #define Makros???

sagt dir "inline" (komplett: "template<typename T> inline f(T x);") zufällig etwas?

alex89ru

CStoll schrieb:

Und was ist wenn man die Sichtbarkeitsgrenzen (absichtlich) umgehen will

Dafür kann man auch const (auf globaler Ebene) verwenden - hat sogar den Vorteil, daß der Compiler verständliche Fehlermeldungen ausspuckt

oder was ist mit den schönen #define Makros???

sagt dir "inline" (komplett: "template<typename T> inline f(T x);") zufällig etwas?

...also auf die vollständigen Fehlermeldungen kann ich sch*iss*n...des mit der Sichtbarkeitsgrenze stimmt auch...geht aber auch mit #define wie mit const wie mit #define wie mit const wie mit #define ...

Und zu: template<typename T> inline f(T x);
Das kenn ich noch garnet. Sowas ist mir neu.
In meinem C++ Buch stand nix davon...sieht aber logisch aus.Das ist wieder Mal typisch: Man kann so gut wie kein Buch kaufen/finden in dem ALLES,also wirklich alles,beschrieben ist. Immer werden irgendwelche Sprachelemente ausgelassen.
zB: Das Bitshiften(also Infos darüber) musste ich mir aus anderen Quellen besorgen. Des mit template<typename T> inline f(T x); ist wirklich nicht schlecht.Also da muss ich dir Recht geben. Aber #define benutz ich trotzdem fröhöich weiter...!

Diskussion beendet. Bringt eh nichts.

groovemaster

alex89ru schrieb:

Bloß: Wenn jemand versucht irgendwelche (Sprach-)Elemente aus C++ zu verbannen , die in C vorhanden waren und durch neuere in C++ "ersetzt" wurden,dann kotz dass mich an.

Das Problem ist einfach, dass der Präprozessor keine Namensräume kennt, deshalb verwendet man in C++ für Konstanten idR const und nicht #define. Und das hat nichts damit zu tun, dass man alte C Sprachelemente "verbannen" will.