[C/C++] const auf integrale typen in einer Funktion sinnvoll?

[;fricky]

DEvent schrieb:

Volatile macht z.B. immer Sinn, so gibt es auch keinen volatile_cast, ebenso wenig einen static_cast.

doch, c++ hat einen 'static_cast', aber der castet nicht zwischen static und nicht-static hin und her, sondern er heisst offenbar so, damit man ihn vom 'dynamic_cast' unterscheiden kann. ja, ich weiss, in C++ schon alles ziemlich äääh.. seltsam.

[Tyrdal]

Volatile macht z.B. immer Sinn

Unsinn, es macht nur in Spezialfällen Sinn.

Ebenso macht private und protected immer Sinn

Auch Unsinn. Auf protected könnte man verzichten.

Was deine Hämmer angeht ist das so eine Sache. Spezialhämmer skalieren schlecht. Wenn man bis jetzt nur Vogelhäuschen gebaut hat aber jetzt nen Pfahl in den Boden rammen soll steht man mit deinem Haushaltshammer dumme da. Hätte man eine flexiblere Hammersprache könnte man sich nen Vorschlaghammer schreiben und weitermachen.

[Don06]

Mit const_cast kann man auch volatile wegcasten. const_cast ist ein schlechter Name. Damit kann man cv-Qualifizierungen umwandeln.

[DEvent]

Tyrdal schrieb:

Volatile macht z.B. immer Sinn

Unsinn, es macht nur in Spezialfällen Sinn.

Ebenso macht private und protected immer Sinn

Auch Unsinn. Auf protected könnte man verzichten.

Wann bitte kommst du in die Gelegenheit "ach diese Methode, die private ist, koennte ich sehr gut fuer meine Klasse gebrauchen, neme ich doch mal ein private_cast". Ich habe gemeint, wenn du etwas als private/protected/usw deklarierst, dann bleibt es auch dabei. Man hat keine Faelle, in denen man das gerne "wegzauebern" moechte. Das ist anders zu cost-correctnes. (der Trick mit dem #define private public zaehlt nicht, weil der Preprozessor nicht zu der Sprache gehoert, anders als das const_cast).

[Shade Of Mine]

DEvent schrieb:

Man hat keine Faelle, in denen man das gerne "wegzauebern" moechte.

Doch, sicher. Und virtual hinzufügen.
Kommt alles vor...

[abc.w]

DEvent schrieb:

Ansonsten muss man sich ein Regelwerk einfallen lassen, was alles verboten ist, und dann haellt sich einer nicht daran wegen *Besonderer-Grund-#465* und man verbringt die Haelfte der Zeit mit der Suche nach *Besonderer-Grund-#465-Bug #1, #2, #3, #4, #5...*.

Es gibt Tools, die ähnliche Analyse des Quellcodes machen. Ich kenne leider nur einen PRQA QA-C++ "Checker", in welcher Version, weiss jetzt nicht. Kennt jemand vielleicht andere?
Übrigens, bei solchen Sachen wie hier:

int GetSomething(char *pInput)
{
    ... also pInput wird hier nur gelesen
}

würde man zwei Warnungen bekommen wie "pInput könnte const sein" o.ä. Und die bekommt man nur dann weg, wenn man so was machts:

int GetSomething(const char * const pInput)
{
    ... pInput wird hier nur gelesen
}

Finde ich gut. Damit sehe ich, das ist eine "getter" Funktion, und wer innen drin pInput Daten doch irgendwie verändert, selber Schuld.

[DrGreenthumb]

abc.w schrieb:

int GetSomething(const char * const pInput)
{
    ... pInput wird hier nur gelesen
}

Finde ich gut

womit wir wieder bei dem Ausgangspost dieses Threads wären... da ist ein const zu viel.

[abc.w]

DrGreenthumb schrieb:

abc.w schrieb:

int GetSomething(const char * const pInput)
{
    ... pInput wird hier nur gelesen
}

Finde ich gut

womit wir wieder bei dem Ausgangspost dieses Threads wären... da ist ein const zu viel.

Warum denn? Zeigerarithmetik ist doch auch fehleranfällig.

[DrGreenthumb]

3. Post:

volkard schrieb:

dort const halte ich für quatsch. ob ich später mal doch a ändern mag, ist mein geheimnis und hat in der schnittstelle nichts zu suchen.

[abc.w]

Ich will aber nicht, dass jemand diese Parameter ändert, weil wenn er es tut, dann kann er dabei etwas falsch machen, es sei denn, er ist wirklich gut, aber wer kann denn schon von sich behaupten, er wäre wirklich gut

[;fricky]

Don06 schrieb:

Mit const_cast kann man auch volatile wegcasten. const_cast ist ein schlechter Name. Damit kann man cv-Qualifizierungen umwandeln.

wenn ich c++ proggen müsste, würde ich sowieso nur C-casts verwenden, ausser wenn ich in einer vererbungshierarchie downcasten will. sowas geht mit C-casts ja nicht.

[hustbaer]

;fricky schrieb:

Don06 schrieb:

Mit const_cast kann man auch volatile wegcasten. const_cast ist ein schlechter Name. Damit kann man cv-Qualifizierungen umwandeln.

wenn ich c++ proggen müsste, würde ich sowieso nur C-casts verwenden, ausser wenn ich in einer vererbungshierarchie downcasten will. sowas geht mit C-casts ja nicht.

ja fricky.
weil du ein uneinsichtiger koffer bist.

wegen leuten wie dir gibt es so viel furchtbar miesen C++ code.

[;fricky]

hustbaer schrieb:

;fricky schrieb:

Don06 schrieb:

Mit const_cast kann man auch volatile wegcasten. const_cast ist ein schlechter Name. Damit kann man cv-Qualifizierungen umwandeln.

wenn ich c++ proggen müsste, würde ich sowieso nur C-casts verwenden, ausser wenn ich in einer vererbungshierarchie downcasten will. sowas geht mit C-casts ja nicht.

ja fricky.
weil du ein uneinsichtiger koffer bist.
wegen leuten wie dir gibt es so viel furchtbar miesen C++ code.

ach nö. schlechten c++ code gibts durch diese vielen 'zu-kompliziert-denker'. das sind bestimmt 2/3 aller c++ anwender.
hier ein beispiel von heute: http://www.c-plusplus.net/forum/viewtopic-var-t-is-250597.html
ein c-cast erschlägt alle c++ casts, nur nicht den polymorphen 'dynamic_cast'. das steht sogar, glaub ich, im c++ standard drin. es gibt eine feste reihenfolge, in der die anderen casts durchprobiert werden. warum sollte man diese automatik nicht nutzen?

[hustbaer]

;fricky schrieb:

ach nö. schlechten c++ code gibts durch diese vielen 'zu-kompliziert-denker'. das sind bestimmt 2/3 aller c++ anwender.
hier ein beispiel von heute: http://www.c-plusplus.net/forum/viewtopic-var-t-is-250597.html

jajablabla

ein c-cast erschlägt alle c++ casts, nur nicht den polymorphen 'dynamic_cast'. das steht sogar, glaub ich, im c++ standard drin. es gibt eine feste reihenfolge, in der die anderen casts durchprobiert werden.

dynamic_cast überhaupt nicht. davon abgesehen richtig. und?

warum sollte man diese automatik nicht nutzen?

weil man damit unabsichtlich einen const_cast machen kann (ohne dass der compiler ne warnung gibt).
weil man damit unabsichtlich einen reinterpret_cast machen kann (ohne dass der compiler ne warnung gibt).
weil man sie nicht per "find in files" auffinden kann.
weil sie weniger "sichtbar" und weniger aussagekräftig sind (man braucht länger, um draufzukommen "wohin" eigentlich gecastet wird, und warum).

[;fricky]

hustbaer schrieb:

weil man damit unabsichtlich einen const_cast machen kann (ohne dass der compiler ne warnung gibt).
weil man damit unabsichtlich einen reinterpret_cast machen kann (ohne dass der compiler ne warnung gibt).
weil sie weniger "sichtbar" und weniger aussagekräftig sind (man braucht länger, um draufzukommen "wohin" eigentlich gecastet wird, und warum).

das stimmt doch garnicht. du schreibst in die klammern rein, wohin gecastet werden soll. da ist nichts unbeabsichtigt und auch nicht schlecht sichtbar.

hustbaer schrieb:

weil man sie nicht per "find in files" auffinden kann.

hier: http://hz211.blogspot.com/2006/03/regular-expression-to-find-c-style.html
aber mal ehrlich, nach casts zu suchen kommt ja wohl sehr selten vor.

[hustbaer]

;fricky schrieb:

hustbaer schrieb:

weil man damit unabsichtlich einen const_cast machen kann (ohne dass der compiler ne warnung gibt).
weil man damit unabsichtlich einen reinterpret_cast machen kann (ohne dass der compiler ne warnung gibt).
weil sie weniger "sichtbar" und weniger aussagekräftig sind (man braucht länger, um draufzukommen "wohin" eigentlich gecastet wird, und warum).

das stimmt doch garnicht. du schreibst in die klammern rein, wohin gecastet werden soll. da ist nichts unbeabsichtigt und auch nicht schlecht sichtbar.

ach ne, klar.

class Base {};
class Derived : public Base {};
class SomethineCompletelyDifferent {};

void foo(Derived* p){}
void foo(SomethineComplep){}

void test1(Base const* p)
{
    foo((Derived*) p); // const_cast - OOPS!
}

void test2(Base* p)
{
    foo((SomethineCompletelyDifferent*) p); // reinterpret_cast - OOPS!
}

class X;
class Y;

void register_xy(X* p) {}
void register_xy(Y* p) {}
void unregister_xy(X* p) {}
void unregister_xy(Y* p) {}

template <class DERIVED>
class curiously_recurring_template_pattern
{
public:
	curiously_recurring_template_pattern()
	{
		register_xy((DERIVED*) this);
	}

	~curiously_recurring_template_pattern()
	{
		unregister_xy((DERIVED*) this);
	}
};

class Y : public curiously_recurring_template_pattern<Y> // OK
{
};

// und nu ein kleiner copy & pase fehler...
// (sollte curiously_recurring_template_pattern<X> heissen, aber das hat wohl wer übersehen)
class X : public curiously_recurring_template_pattern<Y>
	// OOOOOPS! C-style cast wird zu reinterpret_cast in
	// curiously_recurring_template_pattern's ctor und dtor...
{
};

void stupid_function(Base* p) { }
void stupid_function(Derived* p) { }

template <class T>
void stupid_function2(T* t)
{
	// ...

	// wir wollen immer den Base* overload, daher casten wir
	stupid_function((Base*) t);
}

void test4()
{
	Derived const* p = new Derived();
	stupid_function2(p); // const_cast in stupid_function2 - OOPS!
}

hustbaer schrieb:

weil man sie nicht per "find in files" auffinden kann.

hier: http://hz211.blogspot.com/2006/03/regular-expression-to-find-c-style.html
aber mal ehrlich, nach casts zu suchen kommt ja wohl sehr selten vor.

ja klar, man will sich ja auch nie vergewissern dass keiner irgendwo nen const_cast macht (und dann böses damit anstellt). kommt auch gerade beim fehler-suchen nie vor.

p.S.: die regex ist "schön", ja, danke. ist aber auch sehr "einfach", ne?
vielleicht sollte ich da gleich morgen nen check in unseren pre-commit hook hängen.

[Nexus]

DEvent schrieb:

Oder man nimmt einfach eine vernueftige Sprache fuer das Problem, anstelle kostbare Entwicklungszeit mit dem Erstellen, der Kontrolle und der Durchsetzung idiotischen Regeln zu verplempern.

Noch einfacher wäre es, beim Programmieren selbst und nicht nur bei der Wahl der Sprache die Vernunft einzusetzen.

abc.w schrieb:

Ich will aber nicht, dass jemand diese Parameter ändert, weil wenn er es tut, dann kann er dabei etwas falsch machen, es sei denn, er ist wirklich gut, aber wer kann denn schon von sich behaupten, er wäre wirklich gut

Tatsache ist aber, dass das Top-Level- const nichts in der Schnittstelle zu suchen hat, weil es keine relevante Information beinhaltet.

[;fricky]

hustbaer schrieb:

hier: http://hz211.blogspot.com/2006/03/regular-expression-to-find-c-style.html
aber mal ehrlich, nach casts zu suchen kommt ja wohl sehr selten vor.

ja klar, man will sich ja auch nie vergewissern dass keiner irgendwo nen const_cast macht (und dann böses damit anstellt). kommt auch gerade beim fehler-suchen nie vor.

ich hab' gerade überlegt, wann ich mal code nach casts durchsucht habe, aber mir ist echt nichts eingefallen. kann natürlich sein, dass suchen nach casts unter c++ üblich ist (vielleicht weil's verschiedene casts gibt, die man verwechseln kann?), aber das entzieht sich meiner kenntnis.
zu dem code-beispiel: falls du zeigen wolltest, dass man absichtlich fehler einbauen kann, so isses dir gelungen. nur, mit c++-cast hättest du ebenso fehler produzieren können. man muss wissen was man tut. ich sehe nicht, dass c++ casts einem das abnehmen.

[otze]

abc.w schrieb:

Ich will aber nicht, dass jemand diese Parameter ändert, weil wenn er es tut, dann kann er dabei etwas falsch machen, es sei denn, er ist wirklich gut, aber wer kann denn schon von sich behaupten, er wäre wirklich gut

Dann kopiert er einfach. Das können auch schlechte Programmierer. Du hast also nichts gewonnen. Das Interface ist schwerer verständlich, der Profi ist genervt, und der Anfänger macht den selben Müll wie sonst auch immer.

@ Basher. oder Basher_ist_nicht_Bashar (Wettschulden sind Ehrenschulden)

das stimmt doch garnicht. du schreibst in die klammern rein, wohin gecastet werden soll. da ist nichts unbeabsichtigt und auch nicht schlecht sichtbar.

Aber Interfaces ändern sich. Der cast macht aber trotzdem weiterhin, was er immer macht. Dann geht etwas kaputt und niemand merkt es, weil der Compiler bevormundet wird.

[;fricky]

otze schrieb:

das stimmt doch garnicht. du schreibst in die klammern rein, wohin gecastet werden soll. da ist nichts unbeabsichtigt und auch nicht schlecht sichtbar.

Aber Interfaces ändern sich. Der cast macht aber trotzdem weiterhin, was er immer macht. Dann geht etwas kaputt und niemand merkt es, weil der Compiler bevormundet wird.

^^endlich ein gutes argument gegen c-casts, dazu fällt mir keine lästerei mehr ein. static- und dynamic-casts scheitern, wenn die typen nicht mehr zueinander passen, ne?
das klappt natürlich nicht, wenn einer reinterpret-cast verwendet hat.