strlen()

Hey! Das Define ist eine gute Idee.

CodeFinder

martin_salo schrieb:

Hey! Das Define ist eine gute Idee.

Finde ich gar nicht, extremes Beispiel:

STRLEN(5);

Aber ist wohl Ansichtssache.

Ein C++ Template dafür zu erstellen wäre aber Overkill.

CodeFinder

Schreib einfach die Casts aus...
Oder Du verwendest Inline-Funktionen.

Undertaker

CodeFinder schrieb:

martin_salo schrieb:

Hey! Das Define ist eine gute Idee.

Finde ich gar nicht, extremes Beispiel:
STRLEN(5);

ein mindestmass an C-kenntnisssen musste schon voraussetzen

CodeFinder schrieb:

Schreib einfach die Casts aus...

das will er doch nicht.

*D*Evil

inline size_t ustrlen(const unsigned char* const string)	
{
	if (string == 0)
		return 0;

	size_t res = 0;
	while (string[res])	++res;
	return res;
}

vllt?

CStoll

Undertaker schrieb:

CodeFinder schrieb:
martin_salo schrieb:

Hey! Das Define ist eine gute Idee.

Finde ich gar nicht, extremes Beispiel:
STRLEN(5);
ein mindestmass an C-kenntnisssen musste schon voraussetzen

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.

Ansonsten ist es wohl besser, die Cast's notfalls in einer Funktion zu verstecken (btw, seit welcher Version versteht C 'inline'?).

Shade Of Mine

CStoll schrieb:

Ansonsten ist es wohl besser, die Cast's notfalls in einer Funktion zu verstecken (btw, seit welcher Version versteht C 'inline'?).

ja, in eine funktion packen ist deutlich besser als das makro. makros sind kein ersatz für funktionen.

inline gibts seit c99

inline ist aber nicht ganz unproblematisch - aber solange man nicht zuviel hackt, sollte das kein problem darstellen.

Es ist ein Klasse/Warpper für eine CryptoEngine die ich benutzen muß. Das STRLEN Makro ist lokal nur in dieser Klasse gültig; ich bin der einzige der an diesem Modul arbeitet. Für mich ist es ein guter Kompromiss aus Übersichtlichkeit und Korrektheit...

Shade Of Mine schrieb:

inline ist aber nicht ganz unproblematisch - aber solange man nicht zuviel hackt, sollte das kein problem darstellen.

Was ist an inline problematisch?

(ausser dass es nicht immer inlined wenn angegeben)

Undertaker

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

CStoll

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.

Undertaker

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.

CodeFinder

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.

Undertaker

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

Shade Of Mine

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

2am

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