Multi-Byte Zeichen vergleichen?

Belli

otze schrieb:

Hacker schrieb:

Das const gibt keine Sicherheit, inline ist unnötig.

[...]
Ohne inline führt das nach ODR zu Linkerfehlern.

So pauschal ist das nicht richtig. Ich habe in meinen Codes jede freier Funktionen ohne das Schlüsselwort inline deklariert und definiert ohne Linkerfehler zu bekommen.

Belli schrieb:

otze schrieb:

Hacker schrieb:

Das const gibt keine Sicherheit, inline ist unnötig.

[...]
Ohne inline führt das nach ODR zu Linkerfehlern.

So pauschal ist das nicht richtig. Ich habe in meinen Codes jede freier Funktionen ohne das Schlüsselwort inline deklariert und definiert ohne Linkerfehler zu bekommen.

Und die waren in Header-Dateien?

Belli

Nö, wieso sollten sie? Steht hier etwa irgendwo, dass die hier in Rede stehende Funktion in einer Header-Datei ist?

Edit: Die Deklarationen waren in Header-Dateien, die Definitionen nicht ... ist das nicht der übliche Weg?

hustbaer

"nach ODR zu Linkerfehlern" ist doch sowieso quatsch.
Der Standard kennt die ODR, aber keine Linker.
Bei ODR violations sind auch "no diagnostics required".

otze

hustbaer schrieb:

"nach ODR zu Linkerfehlern" ist doch sowieso quatsch.
Der Standard kennt die ODR, aber keine Linker.
Bei ODR violations sind auch "no diagnostics required".

*seufz* *reicht dir eine Korinthe*

hustbaer

Naja, es is halt doof wenn man davon ausgeht dass man nen Fehler bekommt wenn man was falsch macht, aber eben keinen bekommt.
Wie es z.B. passiert wenn man ne Inline Funktion in mehreren Übersetzungseinheiten unterschiedlich definiert.

Das ist nämlich auch ne ODR Verletzung. Dem Compiler/Linker ist das bloss vollkommen egal, die prüfen das nicht.

Edit: stopp. irgendwas ist faul.

otze

hustbaer schrieb:

Das ist nämlich auch ne ODR Verletzung. Dem Compiler/Linker ist das bloss vollkommen egal, die prüfen das nicht.

Okay, das ist mir neu. Ich dachte eigentlich, dass der Linker nur nach den Symbolen sucht und dann doppelte Symbole als Fehler ausspuckt.(er muss ja mindestens einmal alle Symbole anschauen um die Sprungaddressen richtig hinzukriegen) In dem Sinne ist dein Einwand nützlich. Aber ich denke, dass diese Fehlerquelle so selten ist, dass man sie im Vergleich zu einem fehlenden inline erstmal vernachlässigen kann. Ich würde das eher zur DLL-hell zählen.

Im Vergleich dazu fand ich den Einwand mit dem Linker halt doch etwas kleinlich. Es ist schwer, sich ein Übersetzungsmodell für C++ ohne Linker vorzustellen.

hustbaer

Das hat nix mit "DLL hell" zu tun, DLLs sind hier keine im Spiel.

Beispiel:

// a.cpp ----------------------------------------------------------

#include <iostream> 

inline int fib(int x)
{
	if (x > 1)
		return fib(x - 1) + fib(x - 2);
	else
		return x;
}

void a(int x)
{
	std::cout << "a: " << fib(x) << std::endl;
}

void b(int x);

int main()
{
	a(7);
	b(7);
}

// b.cpp ----------------------------------------------------------

#include <iostream>

// wäre OK, wenn die definition equivalent zu der in a.cpp wäre
inline int fib(int x)
{
	if (x > 1)
		return fib(x - 1) + fib(x - 2) + 1; // bah, FEHLER
	else
		return x;
}

void b(int x)
{
	std::cout << "b: " << fib(x) << std::endl;
}

Was meinst du was das Programm ausgibt? Bei mir (VC10) kompiliert das einwandfrei, linkt einwandfrei, und der Output ist

a: 33
b: 33

Dreh die Reihenfolge der .obj Files beim Linken um, und du wirst vermutlich

a: 13
b: 13

bekommen.

otze

ich zitiere mich mal:

Aber ich denke, dass diese Fehlerquelle so selten ist, dass man sie im Vergleich zu einem fehlenden inline erstmal vernachlässigen kann. Ich würde das eher zur DLL-hell zählen.

Heißt: Ich bezweifle, dass es diesen Fehler in der freien Wildbahn gibt, außer wenn man aus irgendeinem Grund merkwürdig linken muss, um das Programm zum laufen zu kriegen (Abhängigkeit x linkt statisch gegen foo.a.3.1 und Abhängigkeit y gegen dynamisch gegen foo.so.3.2)