strlen()
-
Tim schrieb:
Was ist an inline problematisch?
lässt sich schlecht debuggen und grosse inline-funktionen mehrfach aufgerufen blähen das binary auf, sonst nix.
-
Undertaker schrieb:
Tim schrieb:
Was ist an inline problematisch?
lässt sich schlecht debuggen und grosse inline-funktionen mehrfach aufgerufen blähen das binary auf, sonst nix.
Stimmt, debuggen könnte aufwändiger werden. Und dass die Binaries größer werden liegt ja fast schon in der Natur von inline. Und wer große Funktionen inlinen will ist selbst schuld
-
martin_salo schrieb:
Es ist ein Klasse/Warpper für eine CryptoEngine die ich benutzen muß.
"Klasse" klingt für mich nach C++ - und das ist eine Etage tiefer
Das STRLEN Makro ist lokal nur in dieser Klasse gültig;
Bin ich der einzige, den es stört, daß "Makro" und "lokal in der Klasse" in einem Satz erwähnt werden?
@inline: Von C++ Compilern erwartet man, daß sie selber entscheiden, ob sie eine Funktion tatsächlich inlinen (und bei extrem großen Funktionen verzichten sie idR freiwillig drauf). Warum sollen da C-Compiler dümmer sein? (oder ist inline-Expansion in C vorgeschrieben?)
-
CStoll schrieb:
(oder ist inline-Expansion in C vorgeschrieben?)
Ja leider nicht. Aber das ist ein anderes Thema.
-
Tim schrieb:
CStoll schrieb:
(oder ist inline-Expansion in C vorgeschrieben?)
Ja leider nicht. Aber das ist ein anderes Thema.
C compiler, auch vor C99, haben oft #pragmas etc, mit denen man 'inline' erzwingen kann.
-
Undertaker schrieb:
ein mindestmass an C-kenntnisssen musste schon voraussetzen
Naja, darum gehts ja bei dem Beispiel nicht, glaube es ist jedem klar, dass man es so nicht schreiben darf, deswegen ja auch ein 'extremes' Beispiel...
. CStoll hat das Problem, worauf ich hinweisen wollte, schon perfekt auf den Punkt gebracht 
:CStoll schrieb:
Das Problem bei dem Makro ist aber, daß der Aufruf 'STRLEN(5)' anstandslos durch den Compiler kommt - und zur Laufzeit mächtig auf die Nase fallen wird.
-
CStoll schrieb:
Das STRLEN Makro ist lokal nur in dieser Klasse gültig;
Bin ich der einzige, den es stört, daß "Makro" und "lokal in der Klasse" in einem Satz erwähnt werden?
Das verstehe ich nicht so ganz? Wenn ich das Makro in der cpp Datei schiebe (und nicht in den Header) bleibt es innerhalb der Klasse und keiner der meinen Wrapper benutzen will kriegt was mit.
-
martin_salo schrieb:
CStoll schrieb:
Das STRLEN Makro ist lokal nur in dieser Klasse gültig;
Bin ich der einzige, den es stört, daß "Makro" und "lokal in der Klasse" in einem Satz erwähnt werden?
Das verstehe ich nicht so ganz? Wenn ich das Makro in der cpp Datei schiebe (und nicht in den Header) bleibt es innerhalb der Klasse und keiner der meinen Wrapper benutzen will kriegt was mit.
lass dich doch nicht verunsichern, benutz' das makro und gut is
falls du an deinen programmierkünsten zweifelst und glaubst, dass du aus versehen ein STRLEN(5) hinschreiben könntest, dann natürlich nicht.
btw: man kann die verrücktesten fehlermöglichkeiten konstruieren. eigentlich sollte man keine zeile code schreiben, ohne sowas wie http://www.splint.org/ darüber laufen zu lassen
-
Die Frage ist immer: ist es nötig das Risiko einzugehen? Es geht dabei weniger um strlen(5) als um strlen(foo) und foo ist plötzlich kein unsigned char*.
Es ist wie mit dem links-rechts schauen wenn man über die Straße geht: der Aufwand es zu tun ist so gering, dass es sich einfach lohnt. Ob ich nämlich ein makro schreibe oder eine funktion - der aufwand unterschied ist minimal. aber der gewinn von einer funktion ist im verhältnis zum aufwand einfach deutlich größer.
Edit: danke Tim
-
Beim Aufruf von strlen() mit einem unsigned char * als Argument zu casten ist zum einen nicht notwendig und nutzt zum anderen nichts.
Die vermeintliche Lösung mit dem Makro ist nicht gut, denn sie verschleiert das eigentliche Problem:Ob die Funktionen aus der string.h mit unsigned char-Werten funktionieren ist nicht vorhersagbar! strlen() wird wohl gehen, strcmp() vermutlich nicht.
Der Ansatz von (D)Evil ist der richtige, nämlich eine eigene Funktion ustrlen() zu schreiben. (Allerdings ohne "ustrlen(NULL) == 0"...)
-
na gut, dann eben kein makro
aber vielleicht so://#include <string.h> // <--- auskommentieren extern size_t strlen (unsigned char*); // <--- das da hinschreiben ... unsigned char us[] = {1,2,3,0}; size_t x = strlen(us); // <--- tätä ! ...
-
@Undertaker: Und woher soll strlen() dann kommen?
Die Funktionssignatur von (D)Evils Funktion kann ich nicht so recht deuten. Was soll denn das zweite const bedeuten?
(D)Evil schrieb:
[cpp]inline size_t ustrlen(const unsigned char* const string) {[/cpp]
Aber müsste ich ustrlen() global in meinem Projekt zur Verfügung stellen würde ich diese Funktion schreiben:
unsigned int ustrlen(const unsigned char *string) { return strlen((const char*)string); }
-
martin_salo schrieb:
Und woher soll strlen() dann kommen?
Die kommt immernoch daher wo sie vorher auch herkam. Du behauptest gegenüber dem Compiler nur, dass die Funktion einen unsigned char* bekommt, entgegen dem was der Erzeuger der Standardbibliothek sich gedacht hat.
-
Der Linker würde doch nach einem "size_t strlen (unsigned char*)" suchen aber nur ein "size_t strlen (const char*)" finden und deshalb meckern?
-
Der Linker sucht nur nach der Funktion strlen - und C-Compiler codieren idR keine Typ-Informationen in den dekorierten Funktionsnamen (weil's in C nicht notwendig ist). Wenn du das Ding unter C++ verwenden willst, kann das durchaus zu einem Problem werden (Stichwort: Überladungen).
-
Ach so. Danke
Was sagt hier eigentlich die 2 const aus:
inline size_t ustrlen(const unsigned char* const string)Wenn ich der Funktion "strlen(const char *str)" etwas übergeb sagt mir das const das an den übergebenen Daten nichts verändert wird. Was bewirkt das 2te const von oben zusätzlich?
-
Das sagt dir, daß die Funktion den übergebenen Zeiger nicht verändert (aber da dieser Zeiger sowieso eine Kopie des Arguments ist, ist das eigentlich bedeutungslos).
-
zum thema 'const' guckt ihr auch: http://c2.com/cgi/wiki?ConstIsaVirus und http://c2.com/cgi/wiki?AvoidConstCompletely
-
Ok vielen Dank