3. int statt unsigned short - Wieso?

int statt unsigned short - Wieso?

  • A

    volkard schrieb:

    Du nimmst möglichst immer die <>-casts. Aus prinzipiellen Gründen.

    Ja, aus praktischen Gründen:
    (a) Suchmöglichkeit
    (b) Sicherheit
    (c) Konsistenz (Nicht mal C-Style Casts und dann C++ Casts)

    Und nur dort wo nötig. Sprich: wo man sie umgehen kann nicht. Und in den Beispielen hätte man sie weitgehend umgehen können.

    volkard schrieb:

    Daß Du das innerhalb eines Satzes abstreitest und dann doch belegst, beleidigt meine Intelligenz.

    Ich dachte eher es beleidigt deine Arroganz.

    Davon abgesehen ist es mir durchaus bekannt das es nicht für jeden Typ eine direkte Typisierung gibt, aber dort wo es sie gibt, kann man sie auch verwenden. Interessanterweise ist in meinen Programmen die Signalwirkung der C++ Casts dennoch vorhanden => Ich verwende so gut wie keine Casts in meinen Programmen...

    0
  • V

    Dravere schrieb:

    @volkard,
    Benutzt du eigentlich C++ Casts oder verfolgst du den Dogmatismus "Alles nur mit C Cast"? Wenn du C++ Casts verwendest: wann, wo und wieso?
    Würde mich jetzt mal interessieren.
    Grüssli

    ich verwende eigentlich gar keine c-casts.

    reinterpret_cast nehme ich immer, wenn ich was reinterpretiere. wegen der signalwirkung. zum beispiel zeiger in int für i32 hash(void*).
    dynamic_cast nehme ich eher in

    if(Foo* f=dynamic_cast<Foo*>(baseptr))
  f->machwas();

    um frühe Designfehler voll auszukosten.
    static_cast um in der klassenhierarchie downzucasten (kein witz, aber das hatten wir schon).
    const_cast eher nicht.
    c-casts eher nicht.
    function style casts ganz oft. wie einstellige konstruktoren auch. es wäre auch quatsch, da einen unterschied zu machen, finde ich.

    0
  • Administrator

    volkard schrieb:

    function style casts ganz oft. wie einstellige konstruktoren auch. es wäre auch quatsch, da einen unterschied zu machen, finde ich.

    AH! lol ...
    Bisher kam es bei mir so rüber, dass du dich extrem für C Casts einsetzt 🙂

    Aber ok, darüber kann man sich streiten. Ich persönlich nehme zwar ein static_cast für fundamentale Typen und einstelliger Konstruktor für Klassen, aber ob man jetzt bei fundamentalen Typen nicht auch den "Konstruktor" nehmen darf ... das ist wohl wirklich Geschmacksache 😉

    Aber nochmals genauer nachgefragt, wie würdest du denn das mit dem BYTE* machen?

    foo(BYTE*("blablabla"));
// oder
foo((BYTE*)"blablabla");
// oder
foo(reinterpret_cast<BYTE const*>("blablabla")); // <- meine Auswahl
// oder was anderes?

// (oder ohne const bei meiner Auswahl)
BYTE buf[] = "blablabla";
foo(buf);

    Grüssli

    0
  • G

    Dravere schrieb:

    [cpp]
    // oder
    foo((BYTE*)"blablabla");

    den Cast nehme ich immer.

    0
  • _

    Hier was zum Diskutieren für euch:

    long GetPtrLong(T_Handle *handle) {
	return (long)handle->ptr;	//ptr ist ein char*
}

    😉

    0
  • V

    Dravere schrieb:

    Aber nochmals genauer nachgefragt, wie würdest du denn das mit dem BYTE* machen?

    Das

    foo(BYTE*("blablabla"));
// oder

    fällt leider weg wegen "geht nicht". Auch da wechsle ich gelegentlich zum C-Cast wie Sebastian Pizer.

    Sicherlich war gemeint

    static BYTE tmp[]={'b','l','a','b','l','a','b','l','a',};
foo(tmp);

    , also ohne Nullterminierung und kein char-Array. Da einfach ein char-Array zu nehmen, ist eigentlich Computervergewaltigung.

    foo((BYTE const*)"blablabla");

    Das BYTE-Array als string zu schreiben, ist ein dunkler Hack. Ich weiß halt zufällig, daß das geht und daß das auch so bleiben wird. Dabei ist das ganze (BYTE const*)"blablabla" aber eine unschädliche Hack-Einheit. Das komische const muß wohl rein, weil ich immer von string pooling ausgehe. Ja, so könnte ich es bei einmaligem Auftauchen wohl machen.

    foo(reinterpret_cast<BYTE const*>("blablabla")); // <- meine Auswahl

    Auch ok, ich würde es vermutlich nicht löschen.

    // (oder ohne const bei meiner Auswahl)
BYTE buf[] = "blablabla";
foo(buf);

    Ja, das isses.

    0
  • ?

    volkard schrieb:

    foo(BYTE*("blablabla"));
// oder

    fällt leider weg wegen "geht nicht". Auch da wechsle ich gelegentlich zum C-Cast wie Sebastian Pizer.

    Huch!? Ich kann mich nicht erinnern, etwas in der Richtung gesagt zu haben. Nur, um das nochmal klarzustellen: Ich benutze keine C-style casts. Ich wüsste bei (char*)"Hallo" auch nicht, was da rauskommen soll. Wird das Array als Zeiger interpretiert, oder findet vorher noch der/das "array-to-pointer decay" statt? Da will ich gar nicht drüber nachdenken müssen. 🙂

    0
  • _

    Sebastian Pizer schrieb:

    Ich wüsste bei (char*)"Hallo" auch nicht, was da rauskommen soll.

    So in etwa das gleiche wie bei "Hallo".

    0
  • ?

    _matze schrieb:

    Sebastian Pizer schrieb:

    Ich wüsste bei (char*)"Hallo" auch nicht, was da rauskommen soll.

    So in etwa das gleiche wie bei "Hallo".

    Mit Sicherheit nicht, denn "Hallo" ist vom Typ const char[6] . Aber darum ging's mir auch nicht. Wenn ich einen "static cast" meine, dann schreibe ich auch einen -- entweder mit static_cast oder auch über die Funktions-Syntax (Beispiel: double(3) ).

    0
  • V

    Sebastian Pizer schrieb:

    Huch!? Ich kann mich nicht erinnern, etwas in der Richtung gesagt zu haben.

    Huch!? Sorry.

    Geht nicht wie aus Deinem Posting

    Das geht ja genausowenig wie int*(0) für einen Nullzeiger auf int. Es muss schon ein Wort sein.

    Sonst benutz ich aber auch mal gern die Funktions-Syntax für's statische Casting.

    Hier hab ich kompletten Mist gelesen, es kam in meinem Kopf an als "Sonst benutze ich auch gern mal die C-Syntax, für's statische Casting, um das GehtNicht zu umgehen". Das stand aber gar nicht da. 🙂

    0
  • G

    Sebastian Pizer schrieb:

    _matze schrieb:

    Sebastian Pizer schrieb:

    Ich wüsste bei (char*)"Hallo" auch nicht, was da rauskommen soll.

    So in etwa das gleiche wie bei "Hallo".

    Mit Sicherheit nicht, denn "Hallo" ist vom Typ const char[6] .

    Spitzfindigkeiten helfen nicht weiter

    0
Anmelden zum Antworten