Ein paar Grundsatzfragen

TdZ

Hallo... seitdem ich mit C oder C++ rumhantiere, quälen mich stetig einige Fragen, die ich aufgrund des Erlernens hobbymäßiger Natur nie ganz klären konnte. Heute wage ich mal den Schritt, zu fragen (bezieht sich alles auf C++).
Eins noch... ich weiß im Allgemeinen um Charakter dieses Forums, daher muss ich das noch anmerken... Einige werden sich jetzt bestimmt genötigt fühlen, ihre außerordentliche Fachkompetenz durch Äußerung schnippischer Kommentare hervorzuheben. Könnt ihr gern machen, aber ich möchte nur anmerken, dass das nicht notwendig ist. Ich würde ja nicht hier fragen, wenn ich darüber nicht Bescheid wüsste. (Ist nicht böse gemeint, ich möchte nur im Interesse der Allgemeinheit vermeiden, dass man sich durch zehn Seiten Offtopic-Gelaber wühlt, bevor man etwas relevantes findet!)

So, dann mal ohne weitere Umschweife:

1. Wofür sind diese uint_t-Typen? Benutzt man die anstelle regulärer Typen (int, short) oder was?

2. Sollte man memcpy und Konsorten in C++ verwenden? Wenn nicht, wie läuft das sonst ab, nur über den new-Operator?

3. Ist es wirklich wahr, dass man anstelle von normalen Type-Castings immer static_cast, dynamic_cast etc. verwenden sollte? Wenn ja... warum?

4. Sollte man echt immer std::string benutzen anstelle von const char* Zeugs?

5. Boost... gibt es (grundsätzlich) Gründe, darauf zu verzichten?

6. Warum soll man kein STL verwenden... dafür ist es doch da!?

Ich hätte bestimmt noch mehr Fragen, aber diese hier sind für mich gerade am interessantesten. Vielleicht gewährt ihr mir ja die Gunst des Nachreichens, falls mir noch was einfallen sollte...

Vielen Dank für jedes Licht, dass ihr ins Dunkel bringt!

unskilled

1. die typen braucht man eher selten - aber ab und an braucht man sie halt doch... z.bsp., wenn man bestimmte algorithmen programmiert, die genau x bit als eingansparameter erwarten... dann kann man entweder nen datentyp nehmen, der mind. x bits groß ist und sich denken: naja, dass hier 100000000 das gleiche ist, wie 000000000 wird er schon merken, oder gleich sagen, dass man nur genau 8 bit will...

2. was hat memcpy mit operator new zu tun?

3. japp, weil die normalen casts C sind und man so leicht den überblick verliert, was wirklich gecastet wird(soll nur nen const weggecastet werden oder nur ne warning unterdrückt einer ohnehin implizit stattfindenden umwandlung unterdrückt werden, ...)

4. jopp

5. mir fällt keiner ein

6. wo hast du das denn gehört? Oo

bb

Pigeon

Zu 5. Gründe dafür sollte man auch mit bringen wie ich finde.... manchmal wird das im Forum etwas zu exzessiv verwendet, wenn ich mir diese Beurteilung anmassen darf

unskilled

Pigeon schrieb:

Zu 5. Gründe dafür sollte man auch mit bringen wie ich finde.... manchmal wird das im Forum etwas zu exzessiv verwendet, wenn ich mir diese Beurteilung anmassen darf

Grund dafür: Immer, wenn es _eigenen_ Code erspart...
Wenn man es für eine Zeile weniger Code erst runterladen muss, ist das zwar nicht ganz verhältnissmäßig, aber wenn man es erstmal runtergeladen hat, kann man es ja dann einfach genug verwenden, um keinen Grund dafür zu brauchen....

bb

unskilled schrieb:

2. was hat memcpy mit operator new zu tun?

Ähm.. nix, mein Fehler. Was ich eigentlich meinte: Ist die Nutzung von memcpy in C++ vertretbar oder gibt es da etwas, das sich besser eignet?

unskilled

TdZ schrieb:

unskilled schrieb:

2. was hat memcpy mit operator new zu tun?

Ähm.. nix, mein Fehler. Was ich eigentlich meinte: Ist die Nutzung von memcpy in C++ vertretbar oder gibt es da etwas, das sich besser eignet?

Naja - bei PODs funktioniert memcpy noch - allerdings ist das noch lange kein Grund, es auch zu nutzen...
Eigtl deutet ein memcpy immer darauf hin, dass man irgendwo zu faul war, einen (Standard-)Constructor zu erstellen...
Falls man die Funktionalität jedoch wirklich mal bräuchte:
http://www.cplusplus.com/reference/algorithm/fill_n/

Also:
Nein, lieber std::fill_n aus algorithms nutzen...

bb

TdZ schrieb:

4. Sollte man echt immer std::string benutzen anstelle von const char* Zeugs?

besser wäre ein string der auch unicode usw. kann

drakon

unskilled schrieb:

5. mir fällt keiner ein

Mir schon. Der ganze Overhead ist unnötig, wenn man nur etwas kleineres benutzen will. Es gibt Fälle, wo ich etwas eigenes boost bevorzugen würde, sofern ich lediglich einen kleinen Teil brauche und ansonsten zu viel anderes mitkommt.

zu 6.
Mehrkernprozessoren sind die Zukunft und Software kann das nicht ignorieren. Die STL ist todgeweiht.

unskilled

BöserBub schrieb:

zu 6.
Mehrkernprozessoren sind die Zukunft und Software kann das nicht ignorieren. Die STL ist todgeweiht.

und? was erwartest du von der standard-lib? einzelne funktionen in mehrere threads aufzuspalten, die so langsamer sind, wenn nur eine cpu verwendet wird, als zuvor?
nein - dafür ist der aufrufer verantwortlich - und der kann threads verwenden, wann und wo er möchte...

bb

Dravere

Ich gehe mal auch noch über alle Fragen durch. Sofern du nichts dagegen hast, ansonsten kannst du den Beitrag einfach ignorieren. Oder ka, worauf du dich da genau bezogen hast in den paar Sätzen vor den Fragen. Es wird halt manchmal ein wenig diskutiert, weil die Leute nicht ganz einig sind. Aber oft sind die Diskussionen sehr lehrreich und interessant. Aber naja ...

TdZ schrieb:

1. Wofür sind diese uint_t-Typen? Benutzt man die anstelle regulärer Typen (int, short) oder was?

Welche uint_t Typen? Waren das nicht typedef s aus C99? Somit kein gültiges Standard C++. Kann ich nichts dazu sagen, da ich sie nicht verwende.

TdZ schrieb:

2. Sollte man memcpy und Konsorten in C++ verwenden? Wenn nicht, wie läuft das sonst ab, nur über den new-Operator?

Ich würde nicht sagen, dass man kein memcpy in C++ verwenden sollte. Es gibt Einsatzzwecke für das effiziente Kopieren von PODs. Aber das sind Anwendungsbereiche, welche ein Anfänger sicher nicht so schnell sieht. Und ich würde sogar sagen, dass viele C++ Programmierer gar nie in den Bereich kommen. Die erste Auswahl in C++ sollte ein std::copy sein. Das von unskilled vorgeschlagene std::fill oder std::fill_n wäre eher mit memset zu vergleichen

TdZ schrieb:

3. Ist es wirklich wahr, dass man anstelle von normalen Type-Castings immer static_cast, dynamic_cast etc. verwenden sollte? Wenn ja... warum?

Die Meinungen gehen zwar auseinander in dem Punkt, vor allem weil gewisse die C++ casts als unschön empfinden, glaub ich jedenfalls, denn anders kann ich es mir nicht erklären. Ich persönlich finde es oft gut, dass sie so grob sind, denn damit kennzeichnen sie den Punkt im Code sehr gut.

Und ja, ich vertrete auch, dass man diese Casts verwenden sollte. Ein C style cast oder old style cast ist sehr mächtig. Er kann alles und kann daher schnell Dinge tun, welche man womöglich gar nicht möchte. Die C++ casts sind da differenzierter und können jeweils nur etwas. Sind für Anwendungszwecke spezialisiert und es gibt einen Kompilerfehler, wenn man sie falsch einsetzt.
Auch ist ein dynamic_cast mit C style cast nicht möglich, bzw. kann zu Fehler führen oder noch besser zu undefiniertem Verhalten.

Im allgemeinen sollte man aber sowieso darauf achten, dass man gar keine casts benötigt.

TdZ schrieb:

4. Sollte man echt immer std::string benutzen anstelle von const char* Zeugs?

Nein, auf gar keinen Fall! std::string ist halt nur deutlich einfacher zu verwenden. Allerdings wenn du zum Beispiel eine Konstante hast, welche einen Pfad angibt, dann ist std::string meistens überdimensioniert und ein char const* hätte völlig gereicht.
Sobald du allerdings anfängst Funktionen aus <cstring> zu verwenden, um den String zu bearbeiten, wäre wohl ein std::string meistens besser gewesen.

TdZ schrieb:

5. Boost... gibt es (grundsätzlich) Gründe, darauf zu verzichten?

Viele! Kleines Programm, in der Firma nicht zugelassen, Code/Bibliotheks Unabhängigkeit, usw. usf.
Wenn man Boost aber verwenden kann oder darf, dann wüsste ich nicht, wieso man darauf verzichten sollte. Man muss höchstens darauf achten, dass man gewisse Dinge aus Boost nicht überbenutzt. Boost.Bind oder Boost.Lambda sind da gute Kandidaten, welche man schnell zu stark benutzt und wenn man mal drei Schritte zurück geht, merkt man, dass man es deutlich einfacher hätte machen können

TdZ schrieb:

6. Warum soll man kein STL verwenden... dafür ist es doch da!?

In C++ gibt es keine STL, sondern nur die Standardbibliothek
Gut, dass ist Erbsenzählerei, aber ich könnte mir gut vorstellen, dass du irgendwo sowas aufgeschnappt hast. Denn wieso man auf die Standardbibliothek verzichten sollte, ist mir nicht klar. Ausser du hast eine grausam schlechte Implementierung oder eine andere Bibliothek, welche auf dein Problem spezialisierter ist.

Grüssli

unskilled

Dravere schrieb:

TdZ schrieb:

1. Wofür sind diese uint_t-Typen? Benutzt man die anstelle regulärer Typen (int, short) oder was?

Welche uint_t Typen? Waren das nicht typedef s aus C99? Somit kein gültiges Standard C++. Kann ich nichts dazu sagen, da ich sie nicht verwende.

imho meint er unit8_t etc - und somit hast du sie bestimmt schon mal verwendet ^^ (boost::random z.bsp. - da ist der seed glaube auch ein unit32_t)

Dravere schrieb:

TdZ schrieb:

2. Sollte man memcpy und Konsorten in C++ verwenden? Wenn nicht, wie läuft das sonst ab, nur über den new-Operator?

Ich würde nicht sagen, dass man kein memcpy in C++ verwenden sollte. Es gibt Einsatzzwecke für das effiziente Kopieren von PODs. Aber das sind Anwendungsbereiche, welche ein Anfänger sicher nicht so schnell sieht. Und ich würde sogar sagen, dass viele C++ Programmierer gar nie in den Bereich kommen. Die erste Auswahl in C++ sollte ein std::copy sein. Das von unskilled vorgeschlagene std::fill oder std::fill_n wäre eher mit memset zu vergleichen

Jopp - danke - iwie hatte ich mich so auf memset eingeschossen, dass ich gar net noch ma gelesen hab ^^

bb

Dravere

unskilled schrieb:

imho meint er unit8_t etc - und somit hast du sie bestimmt schon mal verwendet ^^ (boost::random z.bsp. - da ist der seed glaube auch ein unit32_t)

Er hat dort aber nichts von Boost gesagt, denn Boost hat sie im namespace boost verpackt. Denn es gibt im C99 Standard ein <stdint.h> , was aber kein Standard C++ ist. Boost.Integer ist ja auch für die "Simulierung" von diesem Header unter C++ da.

Gut, vielleicht trotzdem noch eine Erklärung dazu, bzw. wozu die vorhanden sind. In C++ gibt es kaum Garantien über die Grösse von den Datentypen. Also ob ein int 4 Bytes ist oder 40 Bytes, ist im C++ Standard nicht garantiert. Bei diesen speziellen typedefs hat man dagegen die Garantie, dass sie mindestens so gross sind. Falls man also tatsächlich auf eine gewisse Grösse angewiesen ist, dann ist das durchaus hilfreich.
Allerdings unter C++ würde ich nicht die C99 Variante verwenden, sondern die Boost Variante, da man mit Boost dem C++ Standard treu bleibt und somit auch Kompilerunabhängiger

Grüssli

TdZ

Dravere schrieb:

Ich gehe mal auch noch über alle Fragen durch. Sofern du nichts dagegen hast, ansonsten kannst du den Beitrag einfach ignorieren. Oder ka, worauf du dich da genau bezogen hast in den paar Sätzen vor den Fragen. Es wird halt manchmal ein wenig diskutiert, weil die Leute nicht ganz einig sind. Aber oft sind die Diskussionen sehr lehrreich und interessant. Aber naja ...

Ganz und gar nichts hab ich dagegen, im Gegenteil. So langsam komm ich mal auf den Trichter und natürlich ist's auch okay, wenn hier diskutiert wird, so meinte ich das ja auch gar nicht.

Ich hab bisher alle Argumentationen/Statements mit großem Interesse verfolgt und habe auch schon ein paar Schlüsse daraus gezogen, dafür schonmal vielen Dank an Euch!

Zwei Fragen stehen für mich gerade noch im Raum:

- Es wurde ja darauf hingewiesen, dass man statt std::string lieber einen UTF-kompatiblen Typen wählen sollte (std:wstring?). Aber im Prinzip brauche ich UTF doch nur für Benutzereingaben oder Text-Ausgabe, interne Strings (z.B. Resourcen-IDs, Pfade oder sowas in der Art) kann ich doch auch weiterhin mittels char* / std::string verarbeiten, richtig?

- Was genau hat Multithreading mit den Standardheadern zu tun? Sind die nicht kompatibel?

unskilled

TdZ schrieb:

- Es wurde ja darauf hingewiesen, dass man statt std::string lieber einen UTF-kompatiblen Typen wählen sollte (std:wstring?). Aber im Prinzip brauche ich UTF doch nur für Benutzereingaben oder Text-Ausgabe, interne Strings (z.B. Resourcen-IDs, Pfade oder sowas in der Art) kann ich doch auch weiterhin mittels char* / std::string verarbeiten, richtig?

Völlig richtig - so lange diese Schnittstelle mit char* zurechtkommt...
Bei Ein- und Ausgabe sollte man allerdings so früh wie möglich mit wide-strings (std::wstring) arbeiten - da man sonst spätestens beim Hinzufügen anderer Sprachen Probleme bekommt - und dann vermutlich alles ändern muss...

TdZ schrieb:

- Was genau hat Multithreading mit den Standardheadern zu tun? Sind die nicht kompatibel?

Wie weiter oben schon mal gesagt: Nichts
Es sind Algorithmen - und der Benutzer müsste dafür sorgen, dass bestimmte Teile in Threads ausgelagert werden - sofern dies sinnvoll wäre...
Evtl war hiermit auch die fehlende Thread-Unterstützung gemeint - das wird sich aber im nächsten Jahr ändern - und bisher gibts ja mit boost::thread auch ne ganz gute Lösung...

Dravere schrieb:

Er hat dort aber nichts von Boost gesagt, denn Boost hat sie im namespace boost verpackt. Denn es gibt im C99 Standard ein <stdint.h>, was aber kein Standard C++ ist. Boost.Integer ist ja auch für die "Simulierung" von diesem Header unter C++ da.

Er hat aber auch nicht gesagt, dass er sie aus der Standard-Bibliothek hat...
Und es gibt ja auch viele Frameworks, die so ne Typen anbieten - japp, ich hab z.bsp boost gemeint ^^

bb