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

tntnet

;fricky schrieb:

tntnet schrieb:
#define const

void foo(const int* v)
{
  *v = 5;
}
^^auch nicht schlecht, aber manche compiler lassen's nicht zu, wenn man schlüsselwörter mit #define verändern will.

Wie schaffen die das? Es ist doch der Präprozessor, der die Ersetzung macht. Der Compiler sieht das doch gar nicht mehr.

Übrigens noch übler finde ich:

#define private public
#include <someclassfile.h>

Das habe ich mal im echten Code gesehen. Wäre ein Fall für Daily WTF.

drakon

Das habe ich mal im echten Code gesehen. Wäre ein Fall für Daily WTF.

Ich hoffe jetzt mal, dass du den dafür zuständigen Programmierer aufgespürt hast und ihm ordentlich eine verpasst hast.

Oder noch besser mit ihm das hier gemacht:

#define zustaendiger_programmierer void

DEvent

drakon schrieb:

Das habe ich mal im echten Code gesehen. Wäre ein Fall für Daily WTF.

Ich hoffe jetzt mal, dass du den dafür zuständigen Programmierer aufgespürt hast und ihm ordentlich eine verpasst hast.

Oder noch besser mit ihm das hier gemacht:
#define zustaendiger_programmierer void

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. Ernsthaft, als Entwickler sollte man sich doch nicht mit Politik beschaeftigen. Die Sprache selber sollte die Regeln festlegen und von dem Compiler automatisch ueberprueft und durchgesetzt werden.

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...*. Als Bonus darf man sich Code-Validierer schreiben, die versuchen das Regelwerkt irgendwie automatisch zu kontrollieren, was eigentlich die Aufgabe der Compiler- und Sprach-Designer war.

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.

wahrscheinlich finden es manche einfach spannender so.

pumuckl

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.

Zeig mir eine Sprache wo man keinen Mist bauen kann und die trotzdem die nötige Flexibilität mitrbingt.

pumuckl schrieb:

Zeig mir eine Sprache wo man keinen Mist bauen kann und die trotzdem die nötige Flexibilität mitrbingt.

reicht auch eine sprache, die ebenso flexibel ist, aber in der man weniger mist bauen kann?

DEvent

pumuckl schrieb:

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.

Zeig mir eine Sprache wo man keinen Mist bauen kann und die trotzdem die nötige Flexibilität mitrbingt.

Die wirklich interessante Frage ist, wie viel Flexibilität man ueberhaupt braucht.

Um einen Nagel in die Wand zu schlagen brauche ich nur einen Hammer, aber manche nehmen eine Sprache, die die Moeglichkeit bietet spezialisierte Haemmer zu schreiben. Ist ja schoen, dass du fuer jeden Spezialfall einen neuen Hammer implementieren kannst, aber die Aufgabe war einen Nagel einzuschlagen.

Wenn man sich doch wenigstens auf const-correctnes verlassen koennte. Aber man kann es weg-casten, mit structs wegtricksen und mit define ganz wegmachen. Alleine die Existens von const_cast zeigt doch schon, dass const-correctnes in manchen Situationen keinen Sinn macht. So kann man sich fragen, ob so etwas ueberhaupt in einer Sprache sinnvoll ist.

Volatile macht z.B. immer Sinn, so gibt es auch keinen volatile_cast, ebenso wenig einen static_cast. Ebenso macht private und protected immer Sinn, es gibt ja auch keinen private_cast oder protected_cast. Wieso dann bei const?

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

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.

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?