3. Ein paar Grundsatzfragen

Ein paar Grundsatzfragen

  • U

    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

    0
  • ?

    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

    0
  • D

    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.

    0
  • ?

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

    0
  • U

    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

    0
  • Administrator

    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

    0
  • U

    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

    0
  • Administrator

    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

    0
  • T

    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?

    0
  • U

    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

    0
Anmelden zum Antworten