Ich wollte euch mal nach eurer Meinung fragen da des öfters mein Stil kritisiert wurde.

Also, wie sieht es mit dem benutzen von C-Funktionen aus wenn es C++-Alternativen gibt?
Ich persönlich ziehe zum Beispiel printf() immer std::cout vor.
Da gibt es noch einen Haufen weiterer Beispiele aber ihr könnt es euch sicher denken was mein Punkt ist.

Dann...wie das mit der Rückgabe einer Funktion handeln? Die meisten C-Funktionen speichern den Rückgabewert ja direkt in einer Variable die als Pointer übergeben würde während das meiste in C++ den Wert zurückgibt.

Zb.

int value = calc(1,2);

oder

int value;
calc(1,2, &value);

Blödes Beispiel aber ist das Schreiben von Funktionen von zweiter Art in C++ schlechterer Stil?

Grüße

Also, wie sieht es mit dem benutzen von C-Funktionen aus wenn es C++-Alternativen gibt?
Ich persönlich ziehe zum Beispiel printf() immer std::cout vor.
Da gibt es noch einen Haufen weiterer Beispiele aber ihr könnt es euch sicher denken was mein Punkt ist.

Wenn es sinnvoll ist C Funktionen zu nutzen, kann man sie nutzen. Aber aus Prinzip das nicht typsichere printf dem typsicheren cout vorzuziehen halte ich für einen Fehler.

Blödes Beispiel aber ist das Schreiben von Funktionen von zweiter Art in C++ schlechterer Stil?

Ja.
Ausgabeparameter an sich sollten schon nicht mit Pointern gemacht werden, sondern mit Referenzen, diese sind sicherer und es gibt an dieser Stelle kein Grund, der mir einfällt, der für Pointer sprechen sollte => unnötige Unsicherheit.
Dazu kommt, dass ich mich frage, warum man nicht die Funktionsrückgabe verwenden sollte. Mir fallen in C 2 Gründe ein: Rückgabe ist oft Fehlerbehandlung und man will dem Aufrufer die Speicherbehandlung überlassen, für ersteres gibt es in C++ Exceptions und für zweiteres Smartpointer etc..
Wenn du also keinen Grund hast, solltest du die Rückgabe verwenden.

Hi.

Ich wollte euch mal nach eurer Meinung fragen da des öfters mein Stil kritisiert wurde.

Also, wie sieht es mit dem benutzen von C-Funktionen aus wenn es C++-Alternativen gibt?
Ich persönlich ziehe zum Beispiel printf() immer std::cout vor.
Da gibt es noch einen Haufen weiterer Beispiele aber ihr könnt es euch sicher denken was mein Punkt ist.

Dann...wie das mit der Rückgabe einer Funktion handeln? Die meisten C-Funktionen speichern den Rückgabewert ja direkt in einer Variable die als Pointer übergeben würde während das meiste in C++ den Wert zurückgibt.

Zb.

int value = calc(1,2);

oder

int value;
calc(1,2, &value);

Blödes Beispiel aber ist das Schreiben von Funktionen von zweiter Art in C++ schlechterer Stil?

Grüße

Ich persönlich finde übrigens das extreme Mischen von C und C++ nicht gut. Es kann beim Mixen von C und C++ Ein- und Ausgabeströmen sogar zu Problemen kommen.

Wenn es keinen Grund dafür gibt, das etwas unbedingt als Parameter übergeben werden muss, dann sollte man definitiv auf den Rückgabewert zurückgreifen. Dafür ist er ja da! Und das der Rückgabewert durch irgendwelche Fehlercodes "blockiert" ist, kann eigentlich auch nicht sein. Dafür gibt es ja dann wieder Exceptions...

Alles in allem ist das was du machst also nicht besonders empfehlenswert

Blödes Beispiel aber ist das Schreiben von Funktionen von zweiter Art in C++ schlechterer Stil?

Nein, aber einfach unnötig. In C wird der Rückgabewert oftmals dazu benutzt, um anzuzeigen, ob die Funktion erfolgreich war, oder nicht. In C++ hat man hingegen Exceptions und somit ist der Rückgabewert frei für jegliche Benutzung. Ich persönlich finde diese Zeiger übergeben Sache extrem hässlich, weil man oftmals so gezwungen ist eine Variable anzulegen, nur um schnell den Wert darin zu speichern und damit weiterzuarbeiten.

Was die C Funktionen in C++ anbelangen, bevorzuge ich üblicherweise die C++ Funktionalitäten, weil sie oftmals mehr leisten (nicht unbedingt Geschwindikeit). Aber wenn man einen (guten) Grund hat C Funktionen zu benutzen, dann sollte man nicht davor zurückschreken und diese zu nutzen, "nur weil es C ist".

Ausgabeparameter an sich sollten schon nicht mit Pointern gemacht werden, sondern mit Referenzen, diese sind sicherer und es gibt an dieser Stelle kein Grund, der mir einfällt, der für Pointer sprechen sollte => unnötige Unsicherheit.

Dazu gibt es hier einen ganzen Thread zu (fängt ungefähr auf Seite 2 an, interessant zu werden). Im wesentlichen gibt es die Meinung, dass durch den Zeiger und das dafür verwendete & besser lesbar wird, dass an der Stelle Modifikationen am Argument vorgenommen werden.

Felix

Ich persönlich ziehe zum Beispiel printf() immer std::cout vor.

In Zusammenhang mit templates wirst du mit printf übelst auf die Schnauze fliegen ;). Da sind die C++ Ströme echt besser. Und "einfach" wechseln kannst du bei Bedarf auch nicht, weil sich printf und iostream meistens nicht so gut vertragen. Kann man zwar richten, aber das ist dann auch recht mühselig, die synchron zu halten

Zu den Rückgabeparamtern: Wenn der Rückgabewert frei hat, sollte man ihn verwenden. Außer, man muss größere Datenblöcke zurückgeben, dann spart man damit Rechenzeit.

Im Allgemeinen ist aber

int result=calc(1,2)

besser lesbar als die Parameteralternative.

Außer, man muss größere Datenblöcke zurückgeben, dann spart man damit Rechenzeit.

Wenn man Zeit und Lust hat, würde ich da empfehlen, sich mit dem "move" Prinzip vertraut zu machen.
Sobald man einen Compiler hat, der r-value references unterstützt, kann man "move" sehr schön und einach implementieren.

Soll es auch mit anderen Compilern funktionieren, kann man es immer noch "ausreichend gut" nachbilden.

Wie das gehen kann, kann man sich z.B. in der Boost angucken, da wird das an einigen Stellen schon verwendet.
U.a. in Boost.Thread.
Evtl. auch schon einige der Container-Klassen.

----

Das übergeben grosser Datenmengen über Output-Parameter ist halt einfach ein unschöner Workaround. Da es in absehbarer Zeit weit bessere Möglichkeiten gibt, sollte man sich IMO garnichtmehr darauf einschiessen diesen Workaround zu verwenden.
Bzw. wenn man schon darauf eingeschossen ist, versuchen umzudenken

EDIT: Typo korrigiert

sollte man sich IMO garnichtmehr darauf einscheissen diesen Workaround zu verwenden.

Ne, das sollte man wirklich nicht *scnr*