int statt unsigned short - Wieso?

volkard

asc schrieb:

Das "Aber wenn man dogmatisch alles mit <>-casts macht, wie Du es vorschlägst" habe ich niemals gesagt, sondern nur das ich statt C-Casts immer die C++ Pendants verwenden würde (Da ich danach auch suchen kann, bei C-Casts ist dies nicht eindeutig möglich).

Du nimmst möglichst immer die <>-casts. Aus prinzipiellen Gründen. Unabhängig vom Umfeld. Das ist doch Dogmatismus pur. Daß Du das innerhalb eines Satzes abstreitest und dann doch belegst, beleidigt meine Intelligenz.[/quote]

Ich würde an den meisten Stellen keinen Cast verwenden, wenn ich dies durch eine explizite Typangabe eh umgehen kann. Ich verwende statt "static_cast<unsigned long>(5)", "(unsigned long)5" oder "unsigned long(5)" einfach gleich die typisierte 5 ("5ul").

Ich sehe, daß Du noch nicht auf die einschlägigen Probleme damit gestoßen bist. Ich leuchte mal voraus:

bool isprime(u16 n);//lookup and wheel
bool isprime(u32 n);//additional SPRP
bool isprime(u64 n);//more SPRP, result truth depending on riemann hypothesis
...
cout<<isprime(u16(100));

Welche typsuffixe nimmt man eigentlich für einen 16-bittigen unsigned int? welchen suffix für size_t?

Dravere

asc schrieb:

volkard schrieb:

asc schrieb:

Doch, genau das machst du hier: Konvertieren (Teilweise unnötig, und zudem solltes du lieber wenn du konvertierst auf die C++ Casts zurückgreifen - sind sicherer).

Bockmist!
foo(static_cast<char>(5)); ist nicht sicherer als foo(char(5)); oder foo((char)5);

Aber dies:
IrgendeineFunktion((BYTE*)"Irgendein String");
empfinde ich als Sicherheitsrisiko - wenn man sich nicht darauf verlässt das BYTE* gleich char* ist. Da sehe ich lieber wenn eine reinterpretierung statt findet.
IrgendeineFunktion(reinterpret_cast<BYTE*>("Irgendein String"));

Da hätte ich jetzt irgendwie anders argumentiert:

IrgendeineFunktion(static_cast<BYTE*>("Irgendein String"));

Gibt einen Fehler, falls es unterschiedliche Zeiger sind. Daher eben auch sicherer.

@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

asc

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...

volkard

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.

Dravere

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

general bacardi

Dravere schrieb:

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

den Cast nehme ich immer.

_matze

Hier was zum Diskutieren für euch:

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

volkard

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.

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.

_matze

Sebastian Pizer schrieb:

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

So in etwa das gleiche wie bei "Hallo".

_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) ).

volkard

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.

general bacardi

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